Abstract
Single-account AWS estates work until they hit a regulatory wall. The wall is usually a SOC 2 finding about access controls, a HIPAA inquiry about ePHI scope, or a PCI auditor asking how cardholder data is segmented from non-PCI workloads. Multi-account topology isn't optional at enterprise scale; it's the architecture that makes those questions answerable in days rather than months.
This whitepaper documents the multi-account topology we ship to enterprise clients: account-of-purpose taxonomy, transit-gateway hub-and-spoke network, AWS IAM Identity Center with JIT elevated access, policy-as-code with SCPs and Config rules, and the centralized audit pipeline that produces the evidence regulators actually pull from. With a documented migration path from single-account in three waves.
Table of contents
- 01
Why single-account estates fail at audit
- 02
Account-of-purpose taxonomy
- 03
Network topology: transit gateway, hub-and-spoke, segmentation
- 04
Identity model: AWS IAM Identity Center, JIT elevated access
- 05
Policy-as-code: SCPs, Config rules, Audit Manager
- 06
Centralized audit & log architecture
- 07
Workload patterns: PCI scope minimization, HIPAA scope segmentation
- 08
Migration path from single-account in three waves
- 09
FinOps and cost-shape considerations
- 10
Appendix: SCP examples and Permission Set patterns