AWS Multi-Account Strategy for Exam Scenarios

A robust multi-account strategy is a cornerstone of AWS governance, security, and cost management. For certification exams, you aren't just tested on how to set up multiple accounts, but more critically, on why and when to apply specific patterns to solve complex governance, isolation, and operational problems. Mastering these concepts means understanding the architecture, the tools, and the decision-making process behind them.

Foundational Structure: AWS Organizations and Control Tower

The journey begins with AWS Organizations, the service that allows you to centrally manage and govern multiple AWS accounts. Think of it as the administrative backbone. Within Organizations, you create a hierarchy of organizational units (OUs), which are logical groupings of accounts. A typical structure might have OUs for Production, Development, and Sandbox, enabling you to apply policies at the appropriate level.

For large-scale, standardized setups, AWS Control Tower is the prescribed solution. It automates the creation of a secure, multi-account landing zone, which is a well-architected, pre-configured environment. When an exam question mentions "setting up a new company on AWS with best practices for governance" or "enforcing guardrails across many accounts," Control Tower is almost always the correct answer. It bundles Organizations, centralized identity, and predefined guardrails into a single service.

The primary governance tool within this structure is the service control policy (SCP). SCPs are JSON policies attached to OUs or accounts that define the maximum permissions for entities in those OUs. Crucially, an SCP never grants permissions; it only acts as a guardrail that overrides even an account administrator's permissions. For example, an SCP attached to a Development OU could explicitly deny access to production-grade EC2 instance types or certain AWS Regions.

Security & Operations: Cross-Account Access and Centralized Monitoring

With accounts isolated for security and billing, you need secure ways for them to interact. This is achieved through cross-account IAM roles. The standard pattern involves a trusting account (where the resource lives) and a trusted account (where the user or service originates). The trusting account defines an IAM role with specific permissions and establishes a "trust policy" specifying which trusted account (or specific user/role within it) is allowed to assume it. A user in the trusted account then uses the AWS Security Token Service (STS) to temporarily assume that role and gain access. Exam questions love to test your understanding of this trust relationship and the direction of the policy setup.

Operational visibility is non-negotiable. Centralized logging is achieved by aggregating data from all accounts into a single, dedicated audit or logging account. For AWS CloudTrail, which logs API activity, you configure each member account to write its trails to an S3 bucket in the central account. Similarly, AWS Config uses an aggregator—a resource you configure in a central account that collects configuration and compliance data from specified source accounts (which can be individual accounts, an entire OU, or all accounts in the organization). When a scenario describes "a single pane of glass for compliance" or "tracking resource changes across all environments," think centralized CloudTrail and Config aggregators.

Network Design: Shared VPC Patterns

Not every account needs its own isolated network. A shared VPC pattern allows you to centralize network infrastructure (like NAT gateways, VPC endpoints, and firewall appliances) in a single "network hub" account. Other "spoke" accounts can then create their own VPCs and use AWS Resource Access Manager (RAM) to share subnets from the hub VPC. Alternatively, they can create VPCs and peer them to the hub VPC. Exam scenarios will contrast this with a simpler, fully isolated VPC-per-account model. The shared VPC pattern is ideal for enforcing consistent network policies, reducing costs on shared resources, and simplifying connectivity to on-premises data centers via a single VPN or Direct Connect.

Decision Framework: Multi-Account vs. Single-Account

This is the most critical analytical skill for exams. You must identify the triggers in a scenario that mandate a multi-account approach over a complex single-account setup. Here is the decision framework:

• Choose Multi-Account for: Isolation (e.g., separating production and development environments to prevent accidental disruption), governance boundary (applying different SCPs and budgets per business unit), billing separation (for chargeback or showback to different departments), and service quota management (as many quotas, like the number of VPCs, are applied per account).
• A Single-Account (with multiple VPCs/OUs) might suffice for: Simpler environments, projects with tight integration requirements where cross-account complexity is unnecessary, or when the primary need is logical network isolation only.

The exam will present a business requirement—such as "Department A must not be able to access any resources of Department B" or "We need separate bills for each product team." Your job is to map "isolation" and "billing separation" directly to the multi-account strategy.

Common Pitfalls

1. Confusing SCPs with IAM Policies: An IAM policy grants permissions to users/roles within an account. An SCP defines the guardrails for what is possible in an account or OU. An SCP can deny an action even if an IAM policy allows it. Remember: IAM policies are for enabling, SCPs are for containing.
2. Misconfiguring Cross-Account Trust: A classic trap is reversing the trust relationship. The IAM role (with its permissions) must be created in the account that owns the resource (the trusting account). The trust policy on that role specifies who can assume it (the trusted account). If you create the role in the wrong account, access will fail.
3. Overlooking Centralized Logging Requirements: In a scenario describing forensic analysis or compliance audits, failing to specify that CloudTrail logs should be sent to an S3 bucket in a separate, secured audit account is a critical oversight. Logs in the source account can be deleted or modified by a compromised admin in that account, breaking the audit trail.
4. Defaulting to Multi-Account Unnecessarily: Not every problem requires multiple accounts. If the scenario only mentions needing separate development and production environments but with shared underlying services and a single budget, using separate VPCs and IAM policies within one account might be the simpler, more appropriate solution. Always match the tool to the specific requirement.

Summary

• AWS Organizations and Control Tower provide the hierarchical structure (OUs) and automated landing zone for governing multiple accounts at scale.
• Service Control Policies (SCPs) are the primary governance tool, acting as permission guardrails for OUs and accounts, not granting permissions.
• Secure cross-account access is implemented via IAM roles with trust policies, requiring you to correctly identify the trusting (resource) and trusted (user) accounts.
• Operational best practice mandates centralized logging using CloudTrail to a central S3 bucket and AWS Config aggregators for a unified compliance view.
• Shared VPC patterns via RAM allow for cost-effective and consistent network management from a central hub account.
• Your key exam skill is scenario analysis: choose a multi-account strategy for hard isolation, governance boundaries, and billing separation; a single-account may suffice for logical separation without those stringent requirements.