As a company grows, so does its number of AWS accounts. The development team has an account, the operations team has an account, the security team has an account, the data analytics team has an account. How do you manage all of these systematically and share resources safely? This guide explains the core concepts of multi-account environments for beginners.
AWS Organizations — Uniting Multiple Accounts
AWS Organizations is like a company's organizational chart. Picture a large corporation. Below headquarters you have the marketing department, engineering department, and finance department. Below each department are individual teams. AWS Organizations has the same structure.
The Management Account is the headquarters of your organization. It creates and manages all member accounts, and billing is consolidated here. There is only one management account per organization, and SCPs do not apply to it.
Organizational Units (OUs) are the departments. You group accounts logically into OUs like a development OU, production OU, and security OU. OUs can contain other OUs, creating a hierarchy.
Member Accounts are the individual teams. These are the accounts where actual AWS resources are created and used.
Consolidated Billing is one of the biggest advantages of Organizations. All member accounts' costs appear on a single bill in the management account. More importantly, usage from all accounts is combined to reach higher volume discount tiers. Reserved Instances can also be shared across accounts in the organization, amplifying cost savings.
Exam tip: "Consolidate billing across multiple accounts and benefit from volume discounts" — the answer is Organizations Consolidated Billing.
SCPs — Enforcing Rules Across the Entire Organization
SCP stands for Service Control Policy. Think of it as the access control system in a building. "Everyone on this floor cannot enter that restricted zone" — that kind of rule, applied at the AWS service level.
The most important thing to understand about SCPs is what they do not do. SCPs do not grant permissions. They only restrict permissions that IAM has already allowed. Even if a developer account's IAM user has full administrator access, an SCP blocking a specific service means that service is completely unavailable, regardless of IAM.
SCPs do not apply to the management account. Applying an SCP to an OU automatically inherits down to all member accounts and child OUs within it.
There are two SCP strategies. The allow-list strategy says "only explicitly listed services are usable," which is for environments requiring strict security control. The deny-list strategy says "only specifically blocked services or regions are off-limits," which allows flexibility while restricting specific things.
Practical examples: If company policy requires using only the us-east-1 and us-west-2 regions, create an SCP that denies all actions in every other region. If you want to block cryptocurrency mining services across the entire organization, create an SCP that denies all actions for that service.
Exam tip: "Restrict specific regions or services across the entire organization" — the answer is SCP.
AWS RAM — Safely Sharing Resources
Imagine multiple accounts all need to use the same network infrastructure. Creating a separate VPC for every account increases complexity and cost. AWS RAM (Resource Access Manager) lets you safely share resources across accounts.
Think of a shared conference room. The room belongs to the company, but multiple teams can reserve and use it. AWS RAM works similarly. The account that owns a resource shares it with other accounts through RAM. Those accounts can then use the shared resource.
The most frequently tested shared resource is VPC subnets. A dedicated networking account owns the VPC and subnets, and shares them via RAM with development, production, and analytics accounts. Each of those accounts can then launch EC2 instances, RDS databases, and other resources into the shared subnets.
There is an important limitation. The accounts that receive shared subnets can deploy resources into them but cannot modify the VPC itself or change subnet settings. Network management authority stays exclusively with the owning account.
Other resources commonly shared with RAM include: Transit Gateway, Route 53 Resolver rules, Aurora DB clusters, AWS License Manager configurations, and AWS CodeBuild projects.
Exam tip: "Multiple accounts need to deploy resources into the same subnet" — the answer is AWS RAM subnet sharing.
Cross-Account IAM Role — Accessing Another Account's Resources Safely
A development account application needs to read files from a production account's S3 bucket. How do you set this up? Creating an IAM user in the production account and sharing those credentials with the development team is extremely risky. Cross-Account IAM Roles are the right solution.
Think of a hotel key card. When a guest from another floor needs temporary access to your room, the front desk issues a temporary key card rather than copying yours. That temporary key card expires after a set time.
Cross-Account IAM Role works the same way. The process has three steps. First, in the production account (B), create an IAM role and specify the development account (A) in the Trust Policy. Second, the development account (A) application calls the AWS STS AssumeRole API, and temporary credentials are issued. Third, the application uses those temporary credentials to access the production account (B)'s S3 bucket. Temporary credentials typically expire between one and twelve hours.
External ID is an additional security measure used when delegating a role to a third party. Imagine you hire an external security audit company. You give them a role to analyze your account. But that same audit company serves many clients. If a bad actor tricks the audit company into assuming your role while thinking they are accessing a different client, that is called the "Confused Deputy Problem." Adding an External ID condition to the Trust Policy means the role can only be assumed when the correct External ID is provided, preventing that confusion.
Exam tip: "Delegate a role to a third party while preventing accidental access to the wrong account" — the answer is External ID.
AWS Control Tower — Automated Multi-Account Setup
A new company is adopting AWS and wants to set up a proper multi-account environment from the start. Following AWS best practices for account structure, security settings, and logging configurations manually is time-consuming and error-prone. Control Tower automates all of this.
Control Tower is built around three core concepts.
Landing Zone automatically sets up a multi-account environment following AWS best practices. It creates the recommended account structure including a log archive account, an audit account, and a sandbox account automatically.
Guardrails are automated governance rules applied across the organization. Preventive guardrails are based on SCPs and outright block certain actions. Detective guardrails are based on AWS Config rules and detect policy violations, sending notifications when they occur.
Account Factory automates the creation of new accounts with standardized settings. When a new team joins, Account Factory can generate a fully configured account — with all company policies applied — in just a few clicks.
Exam tip: "Quickly set up a new multi-account environment following AWS best practices" — the answer is Control Tower.
Multi-Account Strategy
What criteria should guide account separation?
| Separation Basis | Purpose | Examples | |-----------------|---------|---------| | Environment | Completely isolate dev from prod | dev OU, staging OU, prod OU | | Department | Cost tracking and permission separation | Marketing OU, Engineering OU | | Compliance | Meet regulatory requirements | HIPAA account, PCI account | | Function | Specialized purpose accounts | Log archive account, Security account, Network account |
More accounts means more complexity, but good separation limits the blast radius of a security incident to a single account.
!4 cross-account sharing tools
Trusted Access — Letting Services Operate Across the Organization
For AWS services like CloudFormation StackSets, AWS Config, and CloudTrail to operate across all accounts in an organization, you must enable Trusted Access. This allows those services to use the Organizations API to automatically access member accounts.
For example, to apply CloudTrail organization-wide, enable Trusted Access for CloudTrail. Then from the management account you can configure centralized log collection from all member accounts.
Exam Key Points
"Consolidate billing and apply volume discounts across multiple accounts" -- Organizations Consolidated Billing
"Allow only specific regions or block specific services organization-wide" -- SCP
"Multiple accounts share the same VPC subnet" -- AWS RAM subnet sharing
"Access another account's resources without sharing credentials" -- Cross-Account IAM Role with AssumeRole
"Prevent confused deputy problem when delegating to a third party" -- External ID
"Automatically set up a new multi-account environment using best practices" -- Control Tower Landing Zone
SCPs do not apply to the management account
Receiving a shared subnet via RAM does not allow modification of the VPC itself
Reserved Instances can be shared across accounts within an organization