Why Accounts, Not Just VPCs, Are the Real Isolation Boundary
A VPC provides network-level isolation, but a surprising amount of AWS's security and operational surface — service quotas, many IAM policy evaluations, billing, and a compromised credential's practical reach — operates at the account level, not the VPC level. A credential compromised inside one VPC in a shared account frequently has an easier path to resources in a sibling VPC within that same account than it would to a resource in a genuinely separate AWS account, where crossing the boundary requires an explicit, auditable cross-account trust relationship. This is the foundational reason mature cloud architectures organize around multiple AWS accounts rather than one account with many VPCs.
The Landing Zone: A Standard Account Structure
A landing zone is the pre-built, governed multi-account structure new workloads land into, rather than each team improvising its own account setup. A common structure, built on AWS Organizations: a management account holding organization-wide billing and policy controls but no workloads itself; a set of foundational accounts for shared services — logging, security tooling, network transit — used by every workload account; a security/audit account with read-only visibility into every other account's activity, kept separate so a compromise elsewhere can't erase its own evidence; and workload accounts, typically one or more per team or application, where actual application infrastructure runs, each with a clear owner and a bounded set of permissions.
The landing zone's job is to make the secure, compliant path the easy path — organization-wide policies (service control policies restricting dangerous actions account-wide, mandatory logging, encryption defaults) applied automatically to every new account, rather than a central team manually reviewing and approving every workload team's request. This is what lets a platform scale governance across many teams without the platform team becoming a bottleneck every team has to wait on.
Cross-Account IAM: Assume, Don't Share
Workloads in one account that need to access resources in another do so through IAM role assumption — a role in the target account explicitly trusts the source account (or a specific role within it) and grants a narrowly scoped, time-limited set of permissions, rather than sharing long-lived credentials across account boundaries. This keeps every cross-account access path explicit, auditable in CloudTrail, and revocable independently — removing trust from one relationship doesn't affect any other account's access, which is a meaningfully different security posture than shared credentials that, once compromised, grant broad and hard-to-trace access.
Applying This to a Multi-Region, Active-Active Platform
For a system built on the patterns in this course, the account structure typically layers on top of, rather than replacing, the regional cell topology from Article 7: workload accounts commonly correspond to a bounded set of services or a cell grouping, each deployed into multiple regions following the organization's region strategy; shared foundational accounts (logging, network transit, security tooling) are themselves often deployed with their own multi-region resilience, since a platform-wide logging outage during a regional failover is exactly the kind of hidden single point of failure that undermines an otherwise well-designed active-active system; and IAM policies are written to be region-agnostic where possible, since a policy that hardcodes assumptions about a single region silently breaks or under-permissions during failover to another.
Governance That Scales With the Organization
Account structure alone doesn't guarantee consistent governance — it needs an explicit, lightweight process behind it. Two mechanisms that hold up well across growing teams: Architecture Decision Records (ADRs), short, versioned documents capturing significant architectural choices and their rationale, reviewable the same way code is; and reference architectures, a small number of pre-approved, well-documented patterns (a standard workload account setup, a standard multi-region deployment template) that new teams can adopt directly instead of designing their account and IAM structure from scratch each time. Together, these let architecture governance scale across many teams without every decision routing through a single central reviewer — a pattern this course revisits more broadly in the Enterprise Architecture pillar of governance content on this site.
Frequently Asked Questions
Why not just use one AWS account with separate VPCs for isolation?
Because an AWS account is a much harder security and blast-radius boundary than a VPC. Many service limits, IAM policies, and billing controls apply at the account level, and a misconfigured IAM policy or compromised credential inside one VPC can often still reach resources in another VPC within the same account far more easily than it could reach a genuinely separate account.
Should every application team get their own AWS account?
In most mature landing zone designs, yes — workload accounts scoped per team or per application are the norm, since it gives each team a genuinely isolated blast radius and its own cost visibility, without requiring central platform teams to manage fine-grained permissions inside a shared account. The overhead is managed centrally through automation, not by making the account structure coarser.
Does multi-account architecture apply per region or across all regions?
Accounts are a global construct in AWS, not tied to one region, but the workloads running inside a given account are typically deployed per region following the account's assigned regions in the organization's design. A common pattern pairs a fixed set of workload accounts with per-region deployment guardrails, rather than creating a fully separate account per region-workload combination.