Cloud Security Architecture, and What the Providers Actually Publish

Your halfWhere your half of the work begins

Every cloud security architecture starts at the line between the cloud provider and you, and the providers are explicit about where that line falls.

Security of the cloud against security in the cloud. AWS states its half plainly: it is responsible for protecting the infrastructure that runs all of the services offered in the AWS Cloud, composed of the hardware, software, networking and facilities.

Your half is what it calls security in the cloud, and the amount of it depends on which services you pick.

The service model decides how much is yours. AWS uses its own services as the example. An EC2 instance is infrastructure as a service, so the customer performs all of the necessary security configuration and management: the guest operating system with its updates and patches, the software installed on it, and the firewall rules.

For an abstracted service like S3 or DynamoDB, AWS operates the infrastructure, the operating system and the platform, and the customer manages the data, the classification and the permissions.

Some controls are shared rather than owned. AWS separates inherited controls, which a customer fully inherits, from shared controls that apply to both layers in different contexts. Patch management is its example of a shared control: the provider patches the infrastructure, you patch everything you put on it.

This is why the same workload has a different architecture on each cloud platform. Two companies running the same application, one on virtual machines and one on managed cloud services, do not have the same amount of security work to do, and no reference architecture can decide that for them.

The shapeThe shape the reference architectures share

Read the published designs side by side and the same skeleton shows up in all of them, described in different words.

Separation by account, not by tag. The AWS Security Reference Architecture walks through organizational units and accounts: an organization management account, a security OU holding a security tooling account and a log archive account, an infrastructure OU holding a network account and a shared services account, and a workloads OU holding the application accounts.

The boundary between them is an account boundary, which is the strongest one the platform offers.

Logging is its own account. A log archive separate from the tooling that reads the logs is not redundancy, it is the answer to the question an incident always raises: could the person who caused this have edited the record of it.

Security tooling lives outside the workload. The account that runs detection is not the account being watched, so a compromise of an application does not reach the thing watching it.

The network is not the workload either. Shared connectivity in its own account is what lets a network change be reviewed and granted separately from an application change.

Google says the same thing about defense in depth. Its enterprise foundations blueprint describes a model combining architecture controls, which are the configuration of resources like networks and the resource hierarchy, with policy controls and detective controls, and states the underlying point directly: the provider's own infrastructure is secure, and it is your responsibility to design security into the systems you build on top of it.

Kinds of controlThree kinds of control, and why the distinction is useful

Google's split is the most useful sentence in any of these documents, because it tells you what is missing rather than what to buy.

Policy controls are programmatic constraints. In Google's words these security controls enforce acceptable resource configurations and prevent risky ones, using infrastructure as code validation in the pipeline and organization policy constraints. On Azure the same job is done by Azure Policy, which Microsoft names alongside blueprints as the way to automate secure configuration and enforce compliance.

Architecture controls are the shape of the thing. The resource hierarchy, the network layout, which cloud account a workload lives in. These are the controls that cost the most to change later, which is why the reference designs spend most of their pages on them.

Detective controls find the threats that got past the first two. Google names Security Command Center; the AWS design places the detection services in the security tooling account; Microsoft points at Defender for Cloud. The pattern is identical: detection is centralized, and it does not live in the account it watches.

Most real cloud environments are strong in one and empty in another. A company with excellent monitoring and no policy controls re-discovers the same misconfiguration every quarter. A company with strict policy and no monitoring finds out about its threats from somebody else.

What it protectsWhat a cloud security architecture actually protects

Underneath the structure, every one of these designs covers the same four surfaces, and the split between the provider and the customer falls differently on each.

Identity and access. Access management is the first surface because it crosses all the others, and because cloud access is granted by configuration rather than by cable.

For abstracted cloud services AWS puts it squarely on the customer: manage the data, classify the assets, and use IAM tools to apply the appropriate permissions. The account structure exists to limit what any single identity can reach when those permissions turn out to be wider than anyone intended.

Data. AWS names the customer's data responsibilities in the same sentence: managing the data, including encryption options, and classifying assets. Encryption at rest is a setting in most cloud services now, so the architectural question is not whether the data is encrypted but who holds the encryption keys and which identity can use them.

Classification is the half people skip, and without it no control knows which data is sensitive, so every rule has to be written for the strictest case or for none.

Network. Google counts the network layout among its architecture controls, alongside the resource hierarchy. In cloud environments the network is a configuration rather than a cable, which means it can be changed by anyone with the right permission, which puts it back in the identity column.

What runs, and what is watching. Detection is the fourth surface and the one that reports on the other three. Google describes detective controls as the way to detect anomalous or malicious behavior, and names Security Command Center; Microsoft names Defender for Cloud; AWS places its detection services in a security tooling account away from the workloads.

Continuous monitoring is the part that turns a design into compliance evidence, because it is the only one that produces a record over time, and it is where cloud threats become visible rather than theoretical.

Cloud security tools are sold for each of these four surfaces, and a cloud security architecture is what decides where each tool is pointed, which cloud account it runs in, and which data it is allowed to read.

The threats the design is built against

The threats to cloud environments are a short and stable list, and each one maps to a surface above.

• Misconfiguration: storage, security groups or APIs left open. Policy controls exist to prevent it.
• Unauthorized access through stolen keys or hijacked privileged accounts. Access management and account boundaries limit the reach.
• Insecure interfaces and APIs on the applications themselves.
• Insider threats, which are the reason the log archive sits where no administrator can edit it.

A cloud security architecture does not remove any of these. It is there to protect the data and applications by making each threat smaller, easier to see, and contained to one account.

Measuring itMeasuring it against something

A cloud security architecture nobody measures is a diagram, and this is where the benchmarks come in.

Microsoft publishes a benchmark for this purpose. The Microsoft cloud security benchmark gives prescriptive best practices for workloads, data and services on Azure and multicloud environments, drawn from its own Cloud Adoption Framework, the Well-Architected Framework, the Secure Future Initiative and the CISO Workshop, alongside industry sources it names: the AWS Well-Architected Framework, CIS Controls, NIST and PCI DSS.

The mapping is the point. Microsoft's own instruction is to plan the implementation by reviewing how the security controls map to CIS, NIST and PCI DSS, then to monitor the result in the regulatory compliance dashboard of Defender for Cloud. That mapping is what turns a cloud security architecture into a compliance answer without a second project.

A benchmark is a starting point, not a finish line. Microsoft's argument for using one is speed: a comprehensive framework from the cloud provider gives you somewhere to start when selecting configuration settings across providers, and one place to monitor them. Nothing in it knows which of your data is sensitive or what it is worth.

Track drift, not just the compliance score. The first measurement is the easy one. The number that matters is how far the environment moves between measurements, because that is the rate at which the architecture is being worked around.

Smaller companiesWhat this looks like for a company that is not an enterprise

The published designs assume a cloud environment with dozens of accounts. The structure still applies at a much smaller size, with fewer boxes.

Three cloud accounts beat one. Production, non-production and a place where the logs land, with separate credentials and separate access, gives you most of the separation the reference design is after.

Turn on the free guardrails first. Organization level deny policies, mandatory multi-factor authentication for the cloud accounts that matter, and a default deny at the edge cost nothing and rule out whole categories of threat. Zero trust is the same instinct applied to every request, and conditional access is where most companies actually implement it.

Centralize the log, even if it is one bucket. Write-once storage in a cloud account the workload cannot reach is the single highest value item on this list, and it is usually cheaper than the cloud security tools people buy instead.

Protect what runs, not just what is configured. Configuration scanning finds the bucket of sensitive data left open, and the workload itself still needs runtime protection once it is running.

Write down who is responsible for what. The shared responsibility model is a two column table until you add the third column: which of your people, or which cloud provider, covers each row. That table is the part an auditor asks for and the part nobody writes.

PitfallsWhere people go wrong

Buying cloud security tools before deciding the structure. A scanner reports on whatever data it is pointed at. It cannot create the account boundary that would have contained the incident.

Treating the cloud provider's half as your half. The infrastructure is the cloud provider's problem. The guest operating system, the access permissions, the data classification and the firewall rules are not, and for infrastructure as a service that is nearly everything.

One cloud account for everything. With a single account, every control is a rule that a person with access can change, and the log of the change lives in the same place that person can reach.

Copying the reference architecture literally. AWS says outright that not every workload or cloud environment has to deploy every security service, and that the document is a reference for a range of options. A small company deploying all of it is buying operational load it cannot staff.

Confusing the benchmark with the architecture. A high compliance score on a badly structured cloud environment is a measurement of the controls that were measured, not of the systems underneath them.

Leaving identity and access out of the architecture. Most cloud security incidents are an access problem wearing an infrastructure costume: a key in a repository, a role that can assume another role, a service account with no expiry. The account structure exists to limit what any one identity reaches.

Designing it once. The cloud providers publish revisions because the platforms change. An architecture that has not been re-read since the environment was built is describing a different environment.

ComparisonAWS, Google and Microsoft side by side

The first row is the one to copy even if you use none of the rest: the unit of separation is the account, and everything else follows from it.

FAQFrequently asked questions

Keep readingRelated concepts

Read next · Identity and access Zero Trust Explained The principle the account structure exists to make enforceable. Open this next13 min

• Identity and access · 8 min Conditional Access, and the Policy That Locks Out the Person Who Wrote It Where the identity half of this architecture is actually configured.
• Network security · 11 min What a CWPP Is, What It Protects, and What It Costs What protects the workload once the structure around it is settled.
• Cloud and data security · 9 min Posture Management, and the Family of Tools Behind It Where cloud security posture management does most of its work.
• Cloud security · 11 min KMS vs Secrets Manager, and Why Every Secret Already Uses KMS The data and identity layers of that design, made concrete for keys and credentials.