Cloud security architecture

Teams write down a cloud security architecture because the cloud makes every control a configuration choice, and a hundred small choices across accounts, networks and services only add up to security if someone designed how they fit.

Why does cloud security architecture matter?

• Misconfiguration is the main risk. Most cloud incidents trace to an open bucket, an over-broad role or a public database rather than a clever exploit.
• Controls interact. A private subnet is pointless if the instance has a role with full permissions. Only a view of all the layers shows the gaps between them.
• Teams need a reference. Application teams ship faster when the account layout, network paths and identity rules are drawn once.

What are the layers of cloud security architecture?

The diagram at the top of this page shows the layers as nested regions around a workload. Reading from the outside in:

• Identity and access. Who and what can act in the account. Single sign-on with MFA for people, least-privilege roles for services, short-lived credentials instead of long-lived keys and separate accounts per environment so a mistake in staging cannot reach production.
• Network segmentation. Where traffic can flow. Private subnets for anything the internet does not need to reach, security groups that allow only named paths, a web application firewall and DDoS protection in front of public endpoints and private endpoints for managed services.
• Workload protection. The compute itself. Hardened base images, automated patching or image replacement, runtime protection that notices unexpected processes and a secrets manager so no credential lives in code or environment variables.
• Data protection. The innermost layer. Encryption at rest for every store, TLS for every connection, keys held in a key management service with rotation and access logging and encrypted, tested backups.
• Logging and monitoring. A band that watches all of the above: audit logs of every API call, network flow logs, threat detection over both and alerting that reaches a person.

What is the shared responsibility model?

The provider secures the cloud; you secure what you put in it. Where the line falls depends on the service.

Service type	Provider secures	You secure
Virtual machines	Hardware, hypervisor, physical network	OS, patches, network rules, identities, application, data
Containers and managed Kubernetes	The above plus the control plane	Images, pod policies, network policies, identities, data
Managed databases and functions	The above plus the OS and runtime	Configuration, access control, encryption settings, data
SaaS	Everything except your settings	Identities, sharing settings, data classification

The common mistake is assuming the provider’s share is bigger than it is. Encryption at rest is available everywhere, but turning it on, choosing who holds the key and restricting who can read the data are on your side of the line.

How do you read a cloud security architecture diagram?

Start at the data in the middle of the hero diagram and work outward, asking what an attacker needs at each layer. To read customer data, someone needs a key, which the key management service grants only to the application’s role. To reach the application, traffic has to pass the security groups, which admit only the load balancer. To change any of that, a person needs a role, which requires SSO with MFA and is scoped to one environment.

Then read the bottom band. Every layer emits logs, and threat detection correlates them. If an attacker steals a credential and starts listing storage buckets from an unusual location, the identity layer did not stop them, but monitoring should notice within minutes. That is defense in depth: no single control is trusted to hold.

How do you design a cloud security architecture?

1. Inventory the data. Classify what you store, mark the sensitive stores on an architecture diagram and draw a data flow diagram of where each class moves.
2. Draw the account structure. One account or project per environment and per major system, joined under an organization with central logging.
3. Design identity first. Federate people through single sign-on, give services roles instead of keys and write the least-privilege policies.
4. Segment the network. Draw a network diagram of subnets and allowed paths, with nothing public that does not have to be.
5. Harden workloads and data. Choose base images, patching cadence, secrets handling and encryption keys per data class.
6. Wire up monitoring. Turn on audit and flow logs everywhere, route them to one place and define the alerts that page someone.
7. Threat model the result. Run a threat modeling session against the diagram and fix what it finds before the first workload lands.

What are common cloud security architecture mistakes?

• Long-lived access keys. Keys in config files and CI secrets are the most stolen credential in the cloud.
• Public by accident. Buckets, databases and dashboards opened for a demo and never closed.
• Trusting the network alone. A flat private network where every service can call every other is the pattern zero trust architecture exists to replace.

How does cloud security architecture compare with related terms?

Term	Scope	Question it answers
Cloud security architecture	A cloud account or organization	What controls protect our workloads, in layers?
Zero trust architecture	Access to resources, anywhere	How is every request verified?
Threat modeling	One system at a time	What can go wrong here, and what do we do about it?
Network diagram	The network layer only	How are the subnets, gateways and firewalls connected?

An API gateway usually sits at the edge of the network layer, where it enforces authentication and rate limits for every public endpoint.

What tools help with cloud security architecture?

• Cloud security posture management. Services that scan an account’s configuration against benchmarks and flag public buckets, over-broad roles and unencrypted stores.
• Infrastructure as code with policy checks. Accounts, networks and roles defined in code, with rules that fail a pull request when it opens a port or widens a permission.
• AI diagramming tools. Tools like Eraser turn infrastructure code or a description of an account into a cloud architecture diagram you can keep editing, which gives a security review something accurate to look at.

For more on this kind of diagram, see architecture diagrams.

Frequently asked questions