Every construct manages a constraint
A virtual network, a storage account and an IAM role look like three unrelated products. They aren't. Each exists because something underneath it is scarce, slow, unreliable or untrusted, and the product is the pattern that has settled around that constraint. Learn the constraint and the product stops being something to memorise: you can predict what it will do, where it will be awkward, and how it will fail.
The table below runs from the hardware upwards. Read the last column as "this is why the thing you click on in the console exists".
| Primitive | The constraint | What it forces | The construct it produces |
|---|---|---|---|
| CPU, cores, NUMA | Clock speeds stopped rising, so the only way forward is parallelism, and memory is closer to some cores than others | Threading, placement, per-core licensing | vCPUs, instance families, VMware and database core licensing |
| GPU | Matrix maths is cheap; high-bandwidth memory capacity and bandwidth are not | Batching, memory management, scarce scheduling | GPU instances, capacity blocks, quotas, Kubernetes DRA |
| Memory | Fast, volatile, finite | Cache tiers, with the durable copy somewhere else | Caches, memory-optimised SKUs |
| Storage media | Durable but slower, and random access costs more than sequential | The split between block, file and object; replication | EBS, Managed Disks and Persistent Disk; file shares; S3, Blob Storage and Cloud Storage |
| Processes and the OS | Isolation, and the kernel's privilege | Patching, and trust in anything running in ring 0 | Images, kernel-level EDR (the CrowdStrike lesson) |
| Virtualisation | One machine shared between tenants | Multi-tenancy, noisy neighbours | VMs, dedicated hosts, confidential computing |
| Containers | A shared kernel | An image supply chain, weaker isolation than a VM | Registries, Kubernetes, serverless containers |
| IP and routing | Addresses and paths, at about 1 ms of round trip per 100 km of fibre | Address plans, latency budgets | VPCs and VNets, route tables, transit hubs, regions |
| DNS | Names have to resolve, and a TTL delays every change | Ownership of zones, split-horizon answers | Private zones, resolvers |
| Distributed systems | Partial failure, no global clock, network partitions | Replication, consensus, idempotency, timeouts | Zones, regions, Spanner, DynamoDB, Cosmos DB |
| Cryptography | Keys give confidentiality, integrity and authenticity, if you can manage them | A lifecycle for keys and certificates | KMS, Key Vault, HSMs, managed certificates |
| Identity and authorization | Prove who the caller is, then decide what they may do | Federation, tokens, policy engines | Entra ID, AWS IAM, Google Cloud IAM, workload identity federation |
| Queues and events | Producers and consumers don't run at the same speed or time | Back-pressure, at-least-once delivery, idempotency | SQS, Service Bus, Pub/Sub, Kafka, Event Hubs, Kinesis |
| Caching | Being close beats being far | Invalidation, and stampedes when entries expire together | CDNs, Redis, DNS caches, the LLM KV cache |
| Load balancing | Spread the load and stop sending it to what has failed | Health checks, layer 4 against layer 7, global against regional | ALB and NLB, Front Door, Cloud Load Balancing |
| Fault domains | Failures arrive together when things share a cause | Spreading work across domains that don't | Availability zones, regions, sovereign partitions |
A few of these rows explain more than they seem to. The GPU row is why the economics of AI are a memory problem rather than an arithmetic one, which the inference page works through. The DNS row is why a private endpoint is really a DNS override, covered on the networking page. And the caching row includes the KV cache on purpose: a language model's working memory follows the same rules as a CDN, including what happens when it fills up.
Physics on one side, logic on the other
The primitives fall into two families, and the clouds build on both.
Physics gives you latency, partial failure and time. You can't negotiate with any of them. Latency puts a floor under any protocol that crosses a continent. Partial failure means that at any moment some disk, switch or rack is broken, so the system has to be built from fault domains (zones, regions, whole providers) that fail separately, with data replicated across them and a consistency model saying what a reader sees while copies disagree.
Logic gives you identity, authorization and state. These are rules rather than laws, which makes them easier to change and easier to get wrong. A request carries a token. A resource evaluates that token against policy. The policy hangs off a hierarchy of organisation, account or subscription, and project, which is how a rule written once applies to ten thousand resources.
Both families meet in the control plane.
Control plane and data plane
The Control planeThe part of a system that creates, changes, authorizes and configures things. Usually shared and often global, which is why the biggest outages start there.Control plane and data plane is the part of a system that creates, changes, authorizes and configures things. When you call an API to launch an instance, change a firewall rule or grant a role, you are talking to a control plane. The Data planeThe part of a system that does the actual work: serving the request, reading the object, forwarding the packet. It should keep working while the control plane is down.Control plane and data plane is the part that does the work those things exist for: serving the web request, reading the object, forwarding the packet.
The split matters because the two have very different failure profiles. A data plane is usually spread across many machines and zones, each of which can keep going on its own. A control plane is usually more centralised, often global, and shared by everyone who uses the service. When a control plane fails, the data plane behind it can often keep serving for hours on what it already knows. When it can't, the failure is designed in, and it is usually one of these:
- the data plane asks the control plane something on every request, such as introspecting a token or fetching a secret
- the data plane needs new capacity to absorb a failure, and launching capacity is a control-plane call
- the data plane's configuration has a short expiry and has to be refreshed
Clouds industrialise three things: placement across fault domains, a global control plane that turns API calls into state, and per-call authorization. Each is also a shared dependency that can fail globally.
Static stability
Static stabilityKeeping the data plane working, with what it already has, while the control plane is impaired. It usually costs spare capacity provisioned in advance.Static stability is the property that the data plane keeps working, without any control-plane action, while the control plane is impaired. A statically stable web tier already has enough instances running in each zone to lose one zone, so it never needs to launch anything during the incident. A statically stable service validates tokens locally against cached signing keys, so it keeps authenticating callers while the identity provider is down, at least until those tokens and keys expire.
Static stability costs money. To survive losing one of n zones without launching anything, each zone has to carry 1/(n−1) of peak load. With three zones that is 1.5 times the capacity you strictly need; with two it is double. The numbers page shows the arithmetic. It's a trade-off, not a rule, and the atlas marks it as one.
Failure domains are vectors, not boxes
It's tempting to think of an availability zone as a box: everything inside fails together, everything outside doesn't. That holds for physical faults such as power, cooling and a building's network. It doesn't hold for the others.
Zones in one region share the region's control plane, its regional endpoints and, often, its identity path. The AWS us-east-1 incident in October 2025 impaired a regional endpoint and instance launches across every zone in the region at once. Google's Service Control, in June 2025, ran as a regional service but read policy data that was replicated globally within seconds, so one bad row reached every region.
So a failure domain is better described as a vector with several components: physical, control plane, configuration, identity, data and supplier. Two components are independent for a given kind of fault only if they share none of the domains relevant to it. Two zones are independent for a power failure. They are not independent for a bad configuration push or an identity outage. The failure page turns this into a method for working out what a failure takes with it.
Time is a dependency
The last idea in the model is the one most designs leave implicit. Almost every safety property in a distributed system depends on a clock or a duration:
- a token lifetime decides how long a stolen credential works, and how long a service survives an identity outage
- a cache TTL decides how stale a permission or a DNS answer can be
- a lease decides how long a leader believes it is still the leader
- a propagation delay decides how long a policy change takes to reach the place it is enforced
- a certificate's validity period decides the moment, shared by every client at once, when a connection stops working
Each of those numbers is a design parameter, and each should have an owner who can say what it is and why. The atlas treats them as first-class architecture rather than as settings, and the identity page shows the most important one, the revocation window, worked through.