Skip to main content

Whitepaper

Multi-Account AWS Architecture for Regulated Workloads

Reference topology for SOC 2 / HIPAA / PCI-DSS workloads on AWS: account-of-purpose taxonomy, transit-gateway network, IAM Identity Center, policy-as-code, audit-evidence pipeline. With migration path from single-account.

Published
March 30, 2026
Length
42 pages
AWSCloud ArchitectureComplianceWhitepaper

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

  1. 01

    Why single-account estates fail at audit

  2. 02

    Account-of-purpose taxonomy

  3. 03

    Network topology: transit gateway, hub-and-spoke, segmentation

  4. 04

    Identity model: AWS IAM Identity Center, JIT elevated access

  5. 05

    Policy-as-code: SCPs, Config rules, Audit Manager

  6. 06

    Centralized audit & log architecture

  7. 07

    Workload patterns: PCI scope minimization, HIPAA scope segmentation

  8. 08

    Migration path from single-account in three waves

  9. 09

    FinOps and cost-shape considerations

  10. 10

    Appendix: SCP examples and Permission Set patterns