AWS Multi-Account Architecture — Overview
A multi-account strategy is the foundation of enterprise AWS deployments. It provides security isolation (blast radius containment), billing separation, workload independence, and governance at scale. This architecture is heavily tested on SAP-C02 and SCS-C03 exams — nearly every scenario-based question assumes multiple accounts.
SCPs | Consolidated Billing | Account Factory | CloudTrail (org-wide)
CloudTrail
Config logs
VPC Flow Logs
GuardDuty (delegated)
Security Hub
Detective
Transit Gateway
Route 53
Direct Connect
AD / Identity Center
CI/CD Tooling
Container Registry
App A
App B
App C
App A
App B
App C
App A
App B
App C
Experimentation
Budget limits
Auto-cleanup
Architecture Components
Management Account
The root account that owns the Organization. Should contain minimal resources — only org-wide management:
- AWS Organizations — Manages OUs, accounts, and SCPs
- AWS Control Tower — Automated landing zone setup with guardrails (preventive + detective)
- Account Factory — Standardized new account provisioning via Service Catalog
- Consolidated Billing — Single payer, volume discounts, cost allocation tags
⚠️ Best practice: Never deploy workloads in the management account. Limit access to a small number of administrators.
Security OU
| Account | Purpose | Key Services |
|---|---|---|
| Log Archive | Centralized, immutable log storage for all accounts | CloudTrail (org trail), Config, VPC Flow Logs, S3 access logs, ALB logs |
| Security Tooling | Delegated admin for security services | GuardDuty, Security Hub, Detective, Inspector, IAM Access Analyzer, Macie |
Infrastructure OU
| Account | Purpose | Key Services |
|---|---|---|
| Network | Centralized networking — hub for all VPC connectivity | Transit Gateway, Route 53 (hosted zones), Direct Connect, VPN, Network Firewall |
| Shared Services | Common tools shared across all workload accounts | IAM Identity Center, Active Directory, CI/CD pipelines, ECR, artifact storage |
Workloads OU
Separate accounts per environment (Prod/Staging/Dev) and optionally per application. This provides:
- Blast radius containment — A compromised dev account can’t reach production
- Independent billing — Charge-back per team/project
- Separate IAM boundaries — Dev teams get admin in their dev accounts, restricted in prod
- Resource limit isolation — One app hitting EC2 limits doesn’t affect others
Governance Controls
Service Control Policies (SCPs)
SCPs set maximum permissions boundaries for all accounts in an OU. They don’t grant permissions — they restrict what’s possible.
- Deny-list approach (recommended): Allow everything by default, deny specific dangerous actions
- Common SCPs:
| SCP | Effect |
|---|---|
| Deny region restriction | Prevent resource creation outside approved regions |
| Deny leaving organization | Prevent accounts from removing themselves from the org |
| Deny root user actions | Block root user except for specific account-level tasks |
| Deny disabling CloudTrail | Prevent tampering with audit logs |
| Deny public S3/RDS | Prevent accidental public exposure of data |
Control Tower Guardrails
- Preventive (SCP-based): Block non-compliant actions before they happen
- Detective (Config Rules): Detect non-compliance and alert/remediate
- Proactive (CloudFormation Hooks): Check templates before deployment
Cross-Account Access — IAM Identity Center
IAM Identity Center (successor to AWS SSO) provides centralized authentication:
- Users authenticate once → Assume roles in any account via Permission Sets
- Permission Sets = IAM policies attached to an Identity Center group for specific accounts
- Integrates with external IdPs (Okta, Azure AD, Google Workspace) via SAML/SCIM
- No long-term credentials — Temporary STS tokens only
Networking — Hub-and-Spoke
The Network account acts as a hub using Transit Gateway:
- Transit Gateway — Central router connecting all VPCs + on-premises via single attachment point
- Route Tables — Segregate traffic (prod VPCs can’t route to dev VPCs)
- Shared VPC (RAM) — Share subnets from Network account to workload accounts (optional)
- Centralized egress — NAT Gateways + Network Firewall in Network account (cost savings vs per-VPC NATs)
- Centralized ingress — ALB/NLB in Network account, forward to workload accounts via PrivateLink
- DNS — Route 53 Private Hosted Zones shared across accounts via RAM
Security Architecture Across Accounts
- GuardDuty — Delegated admin in Security Tooling account, auto-enabled for all member accounts
- Security Hub — Aggregates findings from GuardDuty, Inspector, Macie, Config, Firewall Manager across all accounts
- CloudTrail — Organization trail in management account → logs to Log Archive S3 bucket (with bucket policy preventing deletion)
- AWS Config — Organization-wide rules + conformance packs, aggregated to Security Tooling account
- IAM Access Analyzer — Detects resources shared externally (cross-account or public)
Exam Tips by Certification
| Exam | Focus Areas |
|---|---|
| SAP-C02 | OU structure design, SCP inheritance, cross-account networking (TGW vs peering vs PrivateLink), Account Factory automation, cost allocation strategy |
| SCS-C03 | SCPs for security enforcement, delegated admin pattern, centralized logging (immutable), GuardDuty/Security Hub cross-account, IAM Identity Center vs cross-account roles |
AWS Certification Exam Practice Questions
Question 1:
A company with 200 AWS accounts needs to ensure no account can launch EC2 instances in any region outside of us-east-1 and eu-west-1. Some accounts are in different OUs. What is the MOST scalable enforcement mechanism?
- IAM policies attached to every role in every account
- SCP attached to the Organization root denying ec2:RunInstances outside approved regions
- AWS Config rule detecting non-compliant instances with auto-remediation
- Control Tower detective guardrail with notification
Show Answer
Answer: B – An SCP attached to the Organization root applies to ALL accounts in ALL OUs (except the management account). It’s preventive — the action is blocked before it happens. IAM policies would require updating every role across 200 accounts. Config rules are detective (after the fact). SCPs are the scalable, preventive solution.
Question 2:
A security team needs to ensure that CloudTrail logs from all accounts cannot be deleted or modified by anyone, including administrators in the workload accounts. How should this be architected?
- Enable CloudTrail log file validation in each account
- Organization trail writing to a Log Archive account S3 bucket with bucket policy denying delete + SCP preventing CloudTrail modification
- CloudTrail logs to CloudWatch Logs with a retention policy
- S3 Object Lock on the CloudTrail bucket in each individual account
Show Answer
Answer: B – Organization trail centralizes all account logs into the Log Archive account (which workload account admins can’t access). The S3 bucket policy denies deletions. An SCP prevents any member account from disabling or modifying the organization trail. This creates immutable, tamper-proof logging that no workload account administrator can circumvent.
Question 3:
An enterprise wants to provide developers with self-service AWS account creation while ensuring every new account automatically has VPC connectivity, security controls, and compliance baselines. Which service automates this?
- AWS Organizations CreateAccount API with a Lambda trigger
- AWS Control Tower Account Factory with customizations (AFC)
- AWS Service Catalog with a CloudFormation product
- AWS CloudFormation StackSets with auto-deployment to new accounts
Show Answer
Answer: B – Control Tower Account Factory provides self-service account provisioning that automatically applies landing zone guardrails, baseline configurations, and network connectivity. Account Factory Customizations (AFC) allows additional templates to run post-creation for VPC setup, security tools enrollment, and compliance baselines. StackSets can supplement but AFC provides the integrated workflow.
Question 4:
A company uses Transit Gateway for hub-and-spoke networking. They need to ensure production VPCs cannot communicate with development VPCs, but both need access to shared services (DNS, AD, CI/CD). How should they configure this?
- Separate Transit Gateways for prod and dev
- Transit Gateway route tables — prod and dev in separate route tables, both with routes to shared services route table
- Security Groups on Transit Gateway attachments
- NACLs on the shared services subnets
Show Answer
Answer: B – Transit Gateway route tables provide network segmentation. Create separate route tables for Prod, Dev, and Shared Services. Prod route table has routes only to Shared Services (not Dev). Dev route table has routes only to Shared Services (not Prod). Shared Services route table has routes to both. This achieves isolation while maintaining shared access.
Question 5:
A company’s security policy requires that all cross-account access uses temporary credentials, integrates with their Okta identity provider, and provides a single sign-on experience. What should they implement?
- Cross-account IAM roles with external ID in each account
- IAM Identity Center with Okta as external IdP and permission sets per account
- Cognito User Pool federated with Okta for AWS Console access
- IAM users in the management account with AssumeRole to member accounts
Show Answer
Answer: B – IAM Identity Center integrates with external IdPs (Okta via SAML/SCIM), provides SSO across all org accounts, uses permission sets (which create roles with temporary credentials in each target account), and provides a unified portal. It meets all requirements: temporary credentials, Okta integration, and SSO experience.
Frequently Asked Questions
How many accounts should I have?
At minimum: Management, Log Archive, Security Tooling, Network, Shared Services, and separate accounts per workload per environment. A typical enterprise has 50-500+ accounts. The cost of accounts is zero — the benefit is isolation.
What’s the difference between SCPs and IAM policies?
SCPs set the maximum permissions boundary for an entire account or OU — they restrict what’s possible. IAM policies grant specific permissions to users/roles within an account. An action must be allowed by both the SCP AND the IAM policy to succeed. SCPs cannot grant permissions, only deny them.
Should I use Control Tower or build my own landing zone?
Use Control Tower for most cases — it automates account provisioning, applies security baselines, and manages guardrails. Build custom only if you have requirements Control Tower can’t meet (very rare). You can customize Control Tower with Account Factory Customizations and CfCT (Customizations for Control Tower).