---
{
  "title": "Cloud security architecture",
  "summary": "Map cloud data paths and management authority together, then design identity boundaries, logging, keys, and recovery around the critical workflows.",
  "topic": "networking",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "units": [
    6
  ],
  "aliases": [],
  "sources": [
    {
      "title": "AWS: Shared Responsibility Model",
      "url": "https://aws.amazon.com/compliance/shared-responsibility-model/"
    },
    {
      "title": "NIST: Definition of Cloud Computing",
      "url": "https://csrc.nist.gov/pubs/sp/800/145/final"
    }
  ],
  "published": "2026-10-02",
  "editorialVersion": 2
}
---
## The idea

Cloud security architecture defines how access and protection work across the chosen services. Important elements include account structure, network design, identity permissions, key management, logging, and recovery. Start from critical resources and workflows rather than assuming a traditional perimeter maps directly to cloud services. Management-plane APIs can change the environment without touching a virtual machine, so monitor control-plane actions as well as workload behavior.

## In practice

A cloud administrator restricts deployment identities, separates environments, enables audit records, and verifies that sensitive storage is reachable only through intended access paths.

## A common misunderstanding

A protected workload network does not stop an overprivileged management identity from changing resource policies.

## Check your understanding

Which plane can alter infrastructure configuration?

**Think it through:** The management or control plane, commonly accessed through console and API operations.

## Begin with a critical user journey

Imagine a fictional academy accepts homework, stores it, and lets an instructor review it. Draw the browser, application, storage, processing job, and instructor access. Identify the data and identity crossing each boundary before selecting controls.

The diagram should also show management operations that can alter those components. A protected application network does not stop an overprivileged console identity from changing storage sharing or replacing the workload.

## Separate environments without losing recovery

Development and production may need different identities and data. Avoid giving a test job broad production access merely because both environments use the same deployment tooling. Configuration convenience should not obscure the intended separation.

At the same time, recovery needs deliberate access to backups, keys, deployment artifacts, and required service configuration. An isolated backup that nobody can restore under realistic outage conditions does not meet the business objective.

## Visibility needs resource context

A management audit record and an application event describe different parts of the workflow. The academy may need both to explain who changed a storage policy and which records were later accessed.

Enable and retain appropriate records with clear owners, while limiting exposure of secrets and learner content. Collection should be tested before an incident rather than inferred from a dashboard saying logging is enabled.

For a paper exercise, add a compromised processing identity to the homework diagram. State which resources it can reach, which policy changes it cannot make, and which records would reveal unexpected activity. Then add a lost primary environment and trace recovery dependencies. The architecture should answer both attack-impact and restoration questions using specific boundaries and ownership, not only a perimeter around a group of cloud icons.

## Keep exploring

- [[cloud-identity]]
- [[cloud-storage-security]]
- [[cloud-audit-logs]]
- [[zero-trust]]