# Enterprise Architecture Atlas

> A vendor-neutral guide to enterprise architecture across Azure, AWS, Google Cloud, Microsoft 365, Kubernetes and AI, built from primitives and real outages.

- Web page: https://www.alesanalytics.com/architecture
- Markdown: https://www.alesanalytics.com/architecture.md
- Pages: 26, listed under "Every page in the atlas" below
- Last verified: 13 October 2026
- Publisher: Ales Analytics

## What this atlas is for

Most cloud documentation teaches one vendor at a time. You learn what an Azure subscription is, then what an AWS account is, then a Google Cloud project, and you are left to work out for yourself which differences matter. This atlas goes the other way. It starts from the handful of things every enterprise system is made of, shows how Azure, AWS, Google Cloud, Microsoft 365, Kubernetes and on-premises estates each build on them, and then spends most of its length on how those systems fail.

It's written for architects, platform engineers, security engineers and the people who review their designs. If you already run production systems, the first page should give you the whole model in about ten minutes. The rest is there for when you need the detail: the evaluation order of an IAM request, the size of a KV cache, the window in which a revoked permission still works.

The atlas covers enterprise infrastructure and AI on the same footing, because they are the same problem. An AI assistant over company documents is a distributed system with an authorization problem in the middle of it, and it fails in the ways distributed systems fail.

## The model in one picture

Strip any enterprise estate back far enough and you reach a short list of forces. Two are physical: **latency**, because every 100 km of fibre adds about a millisecond to a round trip, and **partial failure**, because some part of any large system is always broken. Three are logical: **identity** (who is calling), **authorization** (what they may do) and **state** (what the system currently believes). Time sits underneath all five, because no two machines share a clock, and every token lifetime, cache TTL and lease is a bet about how far apart they have drifted.

Every cloud construct exists to manage one of those forces. Regions and availability zones manage partial failure. Replication and consistency levels manage state across distance. Accounts, subscriptions and projects give identity and authorization a boundary to work inside.

The clouds then add something of their own: a **control plane** that turns API calls into state, and a **data plane** that serves requests using that state. That split is the single most useful idea in the atlas.

**Figure: The model the whole atlas uses.** Two families of forces feed every system. Physics: latency (about 1 ms of round trip per 100 km of fibre), partial failure (fault domains such as zones, regions and providers) and time (no shared clock; every TTL and lease is a guess about it). Logic: identity (tokens and the issuer that signs them), authorization (policy evaluated per request) and state (a hierarchy of organisation, account and project). Both feed the control plane, which creates, changes, authorizes and configures, and is global and shared. Configuration propagates through it to every region in seconds, the dominant failure mode in the incidents studied. The data plane serves requests with what it already has, and should survive the control plane going down. Physics and logic both feed a control plane that turns API calls into state, which a data plane then serves. Configuration moves through the control plane fast and everywhere at once, which is why it caused the biggest outages of 2024 and 2025. Static stability is the property that the data plane keeps working while the control plane is down.

Running data planes usually survive an incident. What fails is the ability to change, launch, authorize or route. And because configuration moves through the control plane quickly and to every region at once, a bad configuration is the fastest way to break a large system. The design goal that follows is **static stability**: the data plane keeps working, with what it already has, while the control plane is down.

## Five things to take away

These are the findings the rest of the atlas supports. Each links to the page that argues it.

1. **Control planes are where large outages start.** In the five incidents studied here, running workloads mostly kept serving. What broke was the ability to make changes, launch capacity, sign in or route traffic. Design so that "keep running" and "can change" are separate properties, and test the first without the second. See [Failure architecture](https://www.alesanalytics.com/architecture/failure.md).

2. **Configuration is code with a faster blast radius.** All five incidents were bad data or configuration that spread faster than a code change would have been allowed to. Two of them came from a component whose code was regional while its data was replicated globally. See [Failure architecture](https://www.alesanalytics.com/architecture/failure.md) and [principle P8](https://www.alesanalytics.com/architecture/principles.md).

3. **Safety, independence and freshness are budgets, not absolutes.** Every check has to declare how it fails: closed, open, static or degraded. Every failure domain has to declare what it still shares. Every authorization path has to declare how stale it can be, a figure this atlas calls the revocation window. See [Identity](https://www.alesanalytics.com/architecture/identity.md) and the [fail-mode taxonomy](https://www.alesanalytics.com/architecture/failure.md).

4. **The three clouds do not evaluate permissions the same way.** AWS intersects layers of allow under an explicit deny. Google Cloud checks where a principal may act before it checks deny and allow, and fails closed on anything it cannot evaluate. Azure adds up role assignments, and the only deny assignments are ones Azure creates itself. A policy that means "nobody may do X" has to be built differently on each. See [Cloud providers compared](https://www.alesanalytics.com/architecture/cloud-providers.md).

5. **AI over enterprise data inherits the permission state of that data, and adds a second decision.** Microsoft 365 Copilot shows a user everything they can technically open, so years of oversharing become searchable overnight. A sensitivity label and a DLP policy can then stop the AI processing something the user is allowed to read. Retrieval is where AI meets data governance. See [Microsoft 365](https://www.alesanalytics.com/architecture/microsoft-365.md) and [Retrieval, MCP and agents](https://www.alesanalytics.com/architecture/ai-retrieval-and-agents.md).

## The incidents behind the model

The atlas leans on five public post-incident reports from 2024 and 2025. They were chosen because each provider published enough detail to see the mechanism, and because together they show the same shape five times.

| Incident | What propagated | What it teaches |
| --- | --- | --- |
| AWS us-east-1, 19–20 October 2025 | A race in DynamoDB's DNS automation left an empty record for the regional endpoint | Regional identity and control paths failed while multi-region data kept working. Recovery paths must not depend on the failed service |
| Google Cloud, 12 June 2025 | A policy row with blank fields, replicated globally within seconds, hit an unflagged code path | A regional service with globally replicated data is a global failure domain |
| Azure Front Door, 29 October 2025 | A configuration sequence across two control-plane versions produced incompatible metadata | Validate configuration with the real consumer, including its asynchronous stages |
| Cloudflare, 18 November 2025 | A database permission change doubled a generated feature file past a hard limit | A permission change upstream of generated configuration is a configuration change |
| CrowdStrike Channel File 291, 19 July 2024 | A content update read a 21st field that the integration code never supplied | Privileged, auto-updating agents are a fleet-wide dependency |

Three of the five also impaired the tools people needed to see or fix the problem: a status page, a management portal, a recovery path. That pattern has its own principle: observability has to be independent of what it observes.

## How the atlas is organised

The pages are meant to be read in roughly the order the left-hand menu lists them, but each stands on its own.

- **Foundations.** [From primitives to cloud constructs](https://www.alesanalytics.com/architecture/primitives.md) builds the model above in detail. [Distributed systems and time](https://www.alesanalytics.com/architecture/distributed-systems.md) covers timeouts, retries, quorum, fencing and clocks. [The numbers architects reason with](https://www.alesanalytics.com/architecture/numbers.md) works through availability, queueing, Little's law, KV-cache sizing and error budgets.
- **Cloud platforms.** [Azure, AWS and Google Cloud compared](https://www.alesanalytics.com/architecture/cloud-providers.md), then one page each on [networking and DNS](https://www.alesanalytics.com/architecture/networking.md), [identity and authorization](https://www.alesanalytics.com/architecture/identity.md), [data and storage](https://www.alesanalytics.com/architecture/data-and-storage.md), [compute and Kubernetes](https://www.alesanalytics.com/architecture/compute-and-kubernetes.md), [security, secrets and PKI](https://www.alesanalytics.com/architecture/security.md) and [observability and operations](https://www.alesanalytics.com/architecture/observability-and-operations.md).
- **The enterprise estate.** [Microsoft 365 as an authorization graph](https://www.alesanalytics.com/architecture/microsoft-365.md), and [hybrid, private cloud and on-premises](https://www.alesanalytics.com/architecture/hybrid-and-on-premises.md).
- **AI systems.** [Inference and the model gateway](https://www.alesanalytics.com/architecture/ai-serving-and-gateways.md), and [permission-aware retrieval, MCP and agents](https://www.alesanalytics.com/architecture/ai-retrieval-and-agents.md).
- **Failure and design.** [Failure architecture](https://www.alesanalytics.com/architecture/failure.md), [twenty-two principles](https://www.alesanalytics.com/architecture/principles.md), [trade-offs and second-order effects](https://www.alesanalytics.com/architecture/trade-offs.md), [28 reference scenarios](https://www.alesanalytics.com/architecture/scenarios.md) and [three worked examples](https://www.alesanalytics.com/architecture/worked-examples.md).
- **Practice.** [Misconceptions and false abstractions](https://www.alesanalytics.com/architecture/misconceptions.md), [exercises and design reviews](https://www.alesanalytics.com/architecture/exercises.md), and [technology lifecycle](https://www.alesanalytics.com/architecture/lifecycle.md).
- **Reference.** [Evidence and open questions](https://www.alesanalytics.com/architecture/evidence.md) and the [glossary](https://www.alesanalytics.com/architecture/glossary.md).

## How to read the evidence labels

Cloud services rename themselves, protocols publish breaking revisions and prices move. A document like this goes stale, so every claim that could go stale says how it was checked. You'll see small labels after some sentences:

| Label | Meaning |
| --- | --- |
| T1 | Checked against a primary source: official documentation, a specification, legal text, an official incident report or a peer-reviewed paper |
| T2 | A faithful mirror or direct quotation of a primary source |
| T3 | A reputable secondary source, such as a law firm's analysis or trade press quoting the original |
| Inference | Architectural reasoning from facts, which you should be able to reconstruct yourself |
| Open | The sources conflict or could not be checked |

Facts about AI services, Microsoft 365 and prices were verified in October 2026 and should be re-checked after 90 days. Facts about how the clouds work underneath change more slowly, and are good for about 180 days. The [evidence page](https://www.alesanalytics.com/architecture/evidence.md) lists what was checked, against what, and what is still unresolved.

> **Depth markers.**
>
> Some sections also say how to hold a concept. **Memorise** a few invariants, such as "explicit deny wins in AWS". **Understand** mechanisms, such as how a resource validates a token. **Derive** consequences you should be able to rebuild from first principles, such as why multi-region writes need conflict rules. **Recognise** patterns and smells, such as "regional service, global data". **Look up** SKUs, limits, prices and permission names, every time, because they change.

## Every page in the atlas

### Foundations

- [From Primitives to Cloud Constructs](https://www.alesanalytics.com/architecture/primitives.md): Why every cloud construct exists: the primitives underneath, the control plane and data plane split, static stability, and failure domains as vectors.
- [Distributed Systems and Time](https://www.alesanalytics.com/architecture/distributed-systems.md): Timeouts, retries, idempotency keys, quorum, leases, fencing tokens and clock skew: the distributed-systems mechanics behind every cloud failure.
- [The Numbers Architects Reason With](https://www.alesanalytics.com/architecture/numbers.md): Thirteen calculations behind architecture decisions: availability in series and parallel, queueing, Little's law, KV-cache sizing and cost per token.

### Cloud platforms

- [Azure, AWS and Google Cloud Compared](https://www.alesanalytics.com/architecture/cloud-providers.md): How Azure, AWS and Google Cloud differ where it matters: resource hierarchy, how IAM evaluates a request, policy engines, networking and equivalence.
- [Cloud Networking, DNS and Private Endpoints](https://www.alesanalytics.com/architecture/networking.md): How cloud networking really behaves: DNS caching, private endpoints as DNS overrides, NAT and MTU traps, and the VNet, VPC and global VPC differences.
- [Identity, Tokens and Authorization](https://www.alesanalytics.com/architecture/identity.md): How tokens are validated and revoked, what continuous access evaluation changes, why tokens are never forwarded, and how to state a revocation window.
- [Data, Storage and Databases](https://www.alesanalytics.com/architecture/data-and-storage.md): Sources of truth and derived copies, why replication is not backup, object storage across S3, Blob and GCS, choosing a database class, and CDC.
- [Compute and Kubernetes Architecture](https://www.alesanalytics.com/architecture/compute-and-kubernetes.md): VMs, containers and serverless compared, what keeps running when the Kubernetes control plane stops, DRA for GPUs, and the version skew policy.
- [Security, Secrets and PKI](https://www.alesanalytics.com/architecture/security.md): Envelope encryption and KMS control, certificate rotation, secrets sprawl, supply-chain signing, and what the CrowdStrike incident teaches about EDR.
- [Observability, Operations and Governance](https://www.alesanalytics.com/architecture/observability-and-operations.md): Why observability must be independent of what it observes, error budgets, progressive delivery for configuration, governance, and FOCUS cost data.

### The enterprise estate

- [Microsoft 365 as an Authorization Graph](https://www.alesanalytics.com/architecture/microsoft-365.md): Why Copilot inherits SharePoint's permission state, the two-decision model with Purview DLP, Sites.Selected, RCD, and Entra Agent ID blueprints.
- [Hybrid Cloud, Private Cloud and On-Premises](https://www.alesanalytics.com/architecture/hybrid-and-on-premises.md): What pulls workloads on-premises, licensing as an architectural force, the hard parts of hybrid identity, DNS and AI, and tenant-to-tenant migration.

### AI systems

- [AI Inference and the Model Gateway](https://www.alesanalytics.com/architecture/ai-serving-and-gateways.md): LLM inference explained for architects: prefill and decode, the KV cache, PagedAttention, GPU cost, and what a model gateway must do on every request.
- [Permission-Aware Retrieval, MCP and AI Agents](https://www.alesanalytics.com/architecture/ai-retrieval-and-agents.md): How to build permission-aware RAG, what the MCP 2026-07-28 revision changes, how identity travels through agents, and the OWASP agentic top 10.

### Failure and design

- [Failure Architecture: How Outages Propagate](https://www.alesanalytics.com/architecture/failure.md): How the AWS, Google, Azure Front Door, Cloudflare and CrowdStrike outages propagated, the five fail modes, a failure matrix and a blast-radius method.
- [Twenty-Two Architecture Principles](https://www.alesanalytics.com/architecture/principles.md): Twenty-two enterprise architecture principles, from a declared source of truth to time as a dependency, each traced to its second-order consequences.
- [Architecture Trade-Offs and Second-Order Effects](https://www.alesanalytics.com/architecture/trade-offs.md): The common architecture decisions compared, the second- and third-order effects each brings, and the joins where one domain's failure becomes another's.
- [28 Reference Architecture Scenarios](https://www.alesanalytics.com/architecture/scenarios.md): Twenty-eight reference architectures for AI, data, resilience and platforms, each with flows, trust boundaries, failure modes and the alternative.
- [Worked Architecture Examples](https://www.alesanalytics.com/architecture/worked-examples.md): Three designs worked through from requirements to an injected failure: an enterprise AI assistant, an order API that survives a region, a paying agent.

### Practice

- [Architecture Misconceptions and False Abstractions](https://www.alesanalytics.com/architecture/misconceptions.md): Twenty-four architecture misconceptions, from replication is backup to stateless MCP, and eleven abstractions that work until they quietly don't.
- [Architecture Exercises and Design Reviews](https://www.alesanalytics.com/architecture/exercises.md): Practise architecture: one question per domain, ten derivation exercises and eight design reviews from beginner to principal, with answers.
- [Technology Lifecycle and the Architecture Knowledge Graph](https://www.alesanalytics.com/architecture/lifecycle.md): How to design for protocol and product churn: the six lifecycle states, versioning and skew, replacement strategies, and an architecture knowledge graph.

### Reference

- [Evidence, Verification and Open Questions](https://www.alesanalytics.com/architecture/evidence.md): How every claim in the atlas was checked: the evidence scale, the verification ledger, the corrections made, the open questions and when facts expire.
- [Claim Verification Standard](https://www.alesanalytics.com/architecture/verification-standard.md): The rule every security and cloud provider claim in the atlas follows: an exact source, the date it was checked, the conditions it holds under and its tier.
- [Enterprise Architecture Glossary](https://www.alesanalytics.com/architecture/glossary.md): Plain definitions of the terms in the atlas: control plane, static stability, fail-static, revocation window, Tier-0, KV cache, MCP and more.

Should you have any questions regarding this page, please contact us at solutions@alesanalytics.com.

## Sources

1. [Summary of the Amazon DynamoDB Service Disruption in the Northern Virginia (US-EAST-1) Region](https://aws.amazon.com/message/101925/). Amazon Web Services, 2025. AWS's post-event summary for 19 and 20 October 2025: a race in DynamoDB's DNS automation left an empty record, with impact in three phases ending at 2:20 PM PDT on 20 October.
2. [Google Cloud Service Health incident report, 12 June 2025](https://status.cloud.google.com/incidents/ow5i3PPK96RduMcb1SsW). Google Cloud, 2025. A policy with blank fields, replicated globally, crashed an unflagged code path in Service Control in every region. Remediation: modularise, and fail open.
3. [Azure status history: Azure Front Door, tracking ID YKYN-BWZ](https://azure.status.microsoft/en-us/status/history/). Microsoft, 2025. Microsoft's post-incident review for 29 October 2025, 15:45 to 00:05 UTC: an invalid configuration state caused AFD nodes to fail to load, and changes were blocked while a last-known-good configuration rolled out.
4. [Cloudflare outage on November 18, 2025](https://blog.cloudflare.com/18-november-2025-outage/). Cloudflare, 2025. Cloudflare's postmortem. A database permission change doubled the Bot Management feature file past a limit of 200 features against normal use of about 60.
5. [Channel File 291 Incident: Root Cause Analysis](https://www.crowdstrike.com/wp-content/uploads/2024/08/Channel-File-291-Incident-Root-Cause-Analysis-08.06.2024.pdf). CrowdStrike, 2024. The external technical root cause analysis of 6 August 2024: a template type defined 21 input fields, the integration code supplied 20, and reading the 21st was an out-of-bounds memory read.
6. [Static stability using Availability Zones](https://aws.amazon.com/builders-library/static-stability-using-availability-zones/). Amazon Web Services, 2020. The Amazon Builders' Library account of designing data planes that keep working without control-plane action.

## Where to go next

- Next: [From Primitives to Cloud Constructs](https://www.alesanalytics.com/architecture/primitives.md)
- The whole site in one file: https://www.alesanalytics.com/llms-full.txt