Author: Subhro

In our first article, we established that the AWS Account is a hard boundary for security.

We also discovered a major hurdle for architects: every AWS account has its own isolated IAM database.

If every account has its own IAM database, does that mean my users need a separate login for every account? If I have 50 accounts, does an engineer need 50 sets of credentials?

The answer is No.

While you could create individual IAM Users in every account, that is a major security anti-pattern for an enterprise. Instead, you use the Identity Store within AWS IAM Identity Center.

1. The AWS Identity Store : Your Native Source of Truth

Instead of relying on an external provider like Azure or Okta, AWS provides a built-in directory called the Identity Store. It lives within the IAM Identity Center and serves as your single source of truth for the entire Organization.

• • Centralized Management: You create your users and groups once in this central store. You no longer touch the “IAM Users” section in individual accounts.

• • Groups are Everything: In an enterprise, you don’t manage permissions for “John Doe.” You create a group in the Identity Store—like Platform-Engineers or Security-Audit—and add John to it.

• • The Access Portal: Users get a single, unique URL (the AWS Access Portal). They log in there once and see every account they are authorized to enter.

Okay, I have a central list of users and groups. But how do I actually give those groups permission to do things in the member accounts?

2. Permission Sets : The Policy Templates

This is where AWS separates “who you are” from “what you can do.” In the Identity Center, you create Permission Sets.

• • What they are: A Permission Set is essentially a template for an IAM Role. It contains the standard IAM policies (either AWS-managed or your own custom JSON) that define access.

• • Provisioning: When you assign a Permission Set to a group for a specific account, the Identity Center “provisions” that role into the target account automatically.

• • The “Magic” of Managed Roles: You don’t have to manually create roles in your target accounts. AWS handles the “plumbing” of injecting the role and attaching the policies for you.

In Azure, if I assign a role at the Top Level, it inherits down. Does AWS work the same way?

3. Account Assignments : Explicit vs. Inherited

This is a critical “Deep Dive” fact: AWS does not have RBAC inheritance. *

The Explicit Rule: Even if you have 10 accounts in a “Production” OU, assigning a group to the OU doesn’t automatically grant access. You must create an Assignment that links the [User/Group] + [Permission Set] + [Specific Account].

Why IaC tool like Terraform is recommended : Because there is no native inheritance, managing these assignments manually in the console is impossible at scale. You should use IaC tool like Terraform to define your assignments as code, ensuring that every time a new account is “vended” into the Org, the right groups are mapped to it automatically.

4. Cross-Account Roles : Handling the “Non-Humans”

Identity Center handles your people, but what about your automation? Your CI/CD pipelines or third-party monitoring tools also need to move between accounts.

• • Trust Relationships: You create a role in your “Production” account that “trusts” your “Tooling” account.

• • Assuming the Role: Your automation server in the Tooling account uses the AssumeRole API call to temporarily act as an admin in the Production account. It gets short-lived security tokens that expire automatically, which is far more secure than using static keys.

Recommended Best Practices for Enterprise Identity

1. Shift to Group-Based Access : Never assign Permission Sets to individual users. By mapping permissions to Groups within the Identity Store, you ensure that onboarding and offboarding are handled at the directory level. When a user leaves a team, removing them from one group instantly revokes their access across the entire AWS Organization.

2. Use Identity Store over Local IAM Users : Eliminate the use of individual IAM users within member accounts. Local IAM users often rely on static, long-lived access keys which are a primary security risk. By using the Identity Store, you force all human traffic through a centralized portal that provides temporary, short-lived credentials.

3. Create Reusable Permission Sets : Avoid writing unique inline policies for every account. Define standardized Permission Sets (e.g., ReadOnly, SecurityAudit, Developer) at the Organization level. These templates can be reused across hundreds of accounts, ensuring that a “Developer” has the exact same guardrails in the Network account as they do in the App account.

4. Leverage Trust Relationships for Non-Human Identities : For automation, such as CI/CD pipelines or monitoring tools, use IAM Roles with Trust Relationships. Instead of hardcoding credentials, the “Tooling” account is “trusted” to assume a role in a “Target” account. This allows for seamless cross-account movement using temporary security tokens.

5. Implement Least Privilege via Permission Boundaries : While Permission Sets define what a user can do, use IAM Permission Boundaries for power users. This allows you to delegate the ability to create roles to developers without allowing them to escalate their own privileges or bypass security controls.

---

This video provides a practical look at the difference between the old way (IAM Users) and the modern enterprise way (Identity Center). AWS IAM vs IAM Identity Center

---

What’s Next ?

Now that we’ve solved Identity—our users are in the Identity Store and they can log into their accounts securely—we have a new problem. How do we prevent an “Account Admin” from doing something dangerous, like opening a database to the public or deleting the central audit logs?

In our next article, we will deep dive into Guardrails and SCPs. We’ll look at how Service Control Policies act as the ultimate “Deny” filter that sits above all the permissions we just discussed.

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.