The Isolation Challenge
In any enterprise architecture, the first question is always: How do we separate our workloads to ensure security and stability?
In AWS, the primary answer is the Account.
Unlike Azure, where a single tenant often shares an identity plane, an AWS Account is a hard boundary. This is not just a logical folder; it is a dedicated environment with its own resources and settings.
-
- Isolated IAM Database: Every account has its own private IAM instance. If you create a user in a “Development” account, they simply do not exist in the “Production” account. There is no native “inheritance” of users between accounts.
-
- Total Resource Isolation: By default, there is no cross-account access. A VPC in Account A cannot see a VPC in Account B without explicit networking (like Peering or Transit Gateway).
-
- Quota Management: Service limits are applied per account. This prevents a “noisy neighbor” (like a runaway script in a Test account) from exhausting the EC2 instance limits needed for your Production workload.
If these accounts are totally isolated, how does an enterprise manage hundreds of them centrally? There must be a mechanism to avoid managing them one by one.
The Mechanism: AWS Organizations
The mechanism is AWS Organizations. It acts as a central control plane that bridges these isolated accounts. It allows you to manage billing, security, and compliance across your entire estate from a single point.
-
- Organizational Units (OUs): Just like Azure Management Groups, OUs allow you to group accounts by function (e.g., Security, Networking, App-Team-Alpha). You can nest OUs up to five levels deep to create a hierarchy that matches your governance needs.
-
- Service Control Policies (SCPs): This is where you implement “Guardrails.” You can attach a policy to an OU that restricts what anyone—even the root user or an Admin—can do inside those member accounts.
Example: An SCP can block any account in the “Sandbox” OU from launching expensive high-end GPU instances, or ensure that no one can disable logging in a “Production” account.
Where does this hierarchy start? Is there a “Master” account that holds everything together ?
The Management Account (The Root)
Every Organization starts with one specific account designated as the Management Account. It is the absolute root of your tree and the most critical asset in your cloud environment.
-
- Permanence: You cannot change this later. The account you use to click “Create Organization” becomes the permanent Management Account for the life of that Org.
-
- Consolidated Billing: This is the “Payer” account. It aggregates every charge from every member account into one single, unified invoice.
-
- Security Responsibility: Because SCPs do not apply to the Management Account, it is highly privileged. A common “Anti-Pattern” is running production workloads or shared services (like a VPN or CI/CD server) here.
-
- Important : If the Management Account is compromised, an attacker can delete the entire Organization or remove security guardrails. It must be kept “clean” and used only for billing and organization-level configuration.
If the Management Account is so sensitive, does that mean my Security and Ops teams need access to it every day to manage the platform?
Scaling with Delegated Administration
The answer is No. AWS uses a concept called Delegated Administration to decentralize power without compromising the “Master Key.”
-
- Functional Delegation: You can pick a standard member account (such as a dedicated “Security” account) and designate it as the administrator for specific services.
Example: You delegate AWS Security Hub and Amazon GuardDuty to your Security Account.
-
- Separation of Duties: Your Security team can now view findings from all accounts in the organization from their own Security Account. They never need to log into the Management Account, and they don’t have access to billing or account creation tools. This follows the principle of Least Privilege at the account level.
Enterprise Patterns vs. Anti-Patterns
Enterprise Pattern :
-
- Security OU: Hosting a “Log Archive” account (for central audit logs) and a “Security Tooling” account (as the Delegated Admin for security services).
-
- Infrastructure OU: For shared network services like Transit Gateways or Firewall management.
-
- Workloads OU: Segmented further into Prod and Non-Prod accounts for hard isolation of production data.
Anti-Pattern :
- The Monolithic Account Trying to save overhead by putting Dev, Test, and Prod together. This leads to impossible-to-audit IAM policies and a massive blast radius. If someone makes a configuration error in “Dev,” it can easily take down “Prod.”
- Root User Usage Using the Root user email of any account for daily tasks. In an enterprise, you should use AWS IAM Identity Center to log in with federated corporate credentials, leaving the Root user locked away.
This video provides a technical walkthrough of how these organizational units and accounts are structured to create a secure enterprise landing zone. Multi Account Structure in AWS with AWS Organizations
This video is relevant because it visually maps out the OUs and account types we just discussed, showing how they fit together in a real-world enterprise deployment.
What’s Next in the Series?
Establishing this organizational structure is only step one. Now that we have a neighborhood of isolated accounts, the next challenge is managing Identity.
In the next section, we will deep dive into Identity and Access Management (IAM). We will answer the architect’s biggest headache: How do we give users access across 50 different accounts without creating 50 different usernames? We’ll explore IAM Identity Center (the successor to SSO), Permission Sets, and how to bridge your existing Azure AD (Entra ID) into this AWS world.
Subhro.blog 