Single-account AWS estates work until they don't. The 'don't' is usually a regulatory event — a SOC 2 finding about access controls, a HIPAA inquiry about ePHI scope, a PCI auditor asking 'how is cardholder data segmented from non-PCI workloads'. Multi-account topology isn't optional at enterprise scale; it's the architecture that makes those questions answerable.
Account-of-purpose taxonomy
Every account in the org has one purpose. The taxonomy we ship as default:
- Management account — Organizations, billing, root of trust. Almost no workloads run here.
- Identity account — IAM Identity Center, central SSO, audit log aggregation.
- Network account — Transit Gateway, shared VPCs, network firewall, DNS.
- Audit / log archive — Centralized CloudTrail, Config, GuardDuty, AWS Audit Manager.
- Workload accounts — One per environment per workload (dev / staging / prod), or per major application.
- Sandbox accounts — Time-bounded experimentation with explicit cost ceilings and auto-shutdown.
Network topology
Hub-and-spoke through Transit Gateway in the network account. Workload VPCs route through the hub for inter-account traffic, internet egress, and on-prem connectivity. This gives you one place to enforce network policy (network firewall, NACLs, route table discipline) instead of duplicating across accounts. The trade-off is the extra hop; for most workloads it's negligible.
Identity model
AWS IAM Identity Center as the workforce identity provider, federated to your IdP (Microsoft Entra ID, Okta). Permission Sets defined as IaC. JIT elevated access via change-ticket-driven session escalation, time-bounded. No standing IAM users on production accounts; service-to-service auth through IAM roles with short-lived credentials.
# Permission Set for a workload account, defined in IaC
resource "aws_ssoadmin_permission_set" "developer" {
name = "WorkloadDeveloper"
instance_arn = data.aws_ssoadmin_instances.main.arns[0]
session_duration = "PT4H" # 4-hour session
managed_policies = [
"arn:aws:iam::aws:policy/PowerUserAccess",
]
inline_policy = data.aws_iam_policy_document.developer_deny.json
}Policy-as-code as deployment gate
Service Control Policies (SCPs) at the OU level enforce platform-wide rules (deny IAM user creation in prod, enforce S3 default encryption, restrict regions). Plan-time enforcement through Conftest / Checkov rules in CI catches IaC violations before merge. AWS Config rules audit drift continuously and feed Audit Manager evidence collection. The auditor's question 'how do you know all S3 buckets in prod are encrypted' has a one-line answer: SCP, plus Config rule, plus Audit Manager evidence pipeline.
Migration path from single account
Three waves over 6–10 months. Wave 1: stand up management, identity, network, audit accounts; migrate workforce auth to Identity Center. Wave 2: split production workloads into dedicated accounts via VPC peering or transit-gateway re-architecture. Wave 3: split dev / staging environments into per-account isolation; deprecate the original account or repurpose it. Documented rollback at every stage; most multi-account migrations land with no production downtime.