Enterprise & Cloud Security Architecture
Reference architectures that hold up in production — not a diagram that looked great in a steering committee deck and started drifting the week after launch.
"Architecture" gets used loosely in security conversations — sometimes it means a diagram, sometimes it means a tool list, sometimes it just means whatever the last audit asked for. The actual job is narrower and harder: decide, before the first workload is deployed, what is structurally impossible, what requires an exception, and what is simply allowed — then encode that decision so it survives contact with a team that's moving fast and didn't read the diagram.
Done well, cloud security architecture is mostly invisible. Teams ship inside guardrails they never had to think about, because the platform made the secure path the easy path.
The Five Layers, Bottom to Top
Each layer constrains the one above it — a workload can only be as secure as the identity boundary and guardrails it was deployed inside of.
Where AWS and Azure Building Blocks Land
Different vendor, same five layers — the Well-Architected Framework and NIST CSF describe the same discipline from two different angles.
| Layer | AWS | Azure | What It Enforces |
|---|---|---|---|
| Guardrails | Service Control Policies, AWS Organizations | Azure Policy, Management Groups | What no account can ever do, regardless of who is in it |
| Identity boundary | IAM Identity Center, account-per-workload | Entra ID, subscription-per-workload | Who can touch what, and where the blast radius stops |
| Network segmentation | VPC hub-and-spoke, PrivateLink | Hub-spoke VNet, Private Endpoints | Containment — a compromise in one spoke stays there |
| Workload patterns | Landing zone account vending, reference templates | Azure Landing Zones, deployment templates | Consistency — the same secure pattern every time, not a one-off |
| Continuous assurance | AWS Config, Security Hub | Defender for Cloud, Azure Monitor | Drift caught in days, not discovered in next year’s audit |
Common Workload Patterns, and What Actually Changes
The five layers above are the floor every workload stands on — but the workload's own type still drives the one or two decisions that matter most.
| Workload | Key Decision | Why |
|---|---|---|
| Public-facing web app | Ingress control at the edge | WAF and DDoS protection in front of a load balancer, with compute kept private — the internet touches the edge, never the workload directly |
| Internal line-of-business app | No public IP, ever | Reachable only through private networking and identity-aware access — if it doesn’t need the internet, it shouldn’t be routable from it |
| Data platform / lakehouse | Access control at the data layer | Fine-grained, row- and column-level permissions — network access to the account was never the real control here |
| AI / ML training & inference | Provenance over the model and its data | What data trained it, what it’s allowed to call at inference — the workload boundary now includes the model’s own behavior |
| Hybrid / OT-connected | One-way data flow through a DMZ | IT and OT segmented deliberately, with no direct path from OT to the internet — availability there outranks patch speed |
Landing Zone vs. a Pile of Accounts — the Distinction That Actually Matters
Most organizations don't lack accounts or subscriptions — they lack a factory that produces them consistently. A landing zone isn't a single account, it's the combination of an account-vending process, a baseline set of guardrails applied automatically to every new account, and a small number of shared services (logging, identity, networking) every workload account plugs into. Without that factory, every new account is architected from a blank page by whoever happens to be building it — which is how a company ends up with two hundred accounts, no two configured quite the same way, and no one who can say with confidence what any of them actually allow.
How I'd Build It, Not Just Diagram It
- Make the guardrail the default, not a request. A control that requires a team to opt in gets skipped under deadline pressure; a control baked into the account-vending process doesn't.
- Design for the account that doesn't exist yet. The pattern has to work for the fiftieth workload someone stands up next year, not just the first three that got the architect's personal attention.
- Segment by blast radius, not by org chart. Network and account boundaries should reflect what needs to be contained if compromised — not which team happens to own the budget line.
- Keep the guardrail list short and non-negotiable. A hundred loosely enforced policies erode faster than twenty that nobody can talk their way around.
- Treat drift as the normal case. Cloud environments change daily; posture management has to run continuously, not as a project every eighteen months.
Where These Architectures Actually Fail
- The diagram and the deployed environment diverge. Reference architectures reviewed once at design time, then never checked against what's actually running.
- Guardrails with too many exceptions. Every exception is a hole in the floor — enough of them and the guardrail stops meaning anything.
- Flat networking "for now." Segmentation deferred until "after launch" almost never gets retrofitted once workloads depend on the flat topology.
- One account for everything. No identity boundary between environments means a compromise in dev can reach production.
- Security architecture as a gate, not a service. If the fastest way to ship is around the architecture team instead of through them, teams will find the way around.
The Well-Architected Framework and NIST CSF are both just checklists for the same underlying question: if this account were compromised tomorrow, what exactly would stop it from spreading?