IAM Solutions for Multi-Account and Complex Organizations

This guide covers the advanced implementation of Identity and Access Management (IAM) within AWS Organizations, focusing on Service Control Policies (SCPs), cross-account role assumption, and governance at scale for the AWS Certified DevOps Engineer Professional exam.

Learning Objectives

After studying this guide, you should be able to:

• Design an AWS Organization hierarchy using Organizational Units (OUs) for security isolation.
• Implement Service Control Policies (SCPs) to establish centralized security guardrails.
• Configure cross-account IAM roles to allow secure access between member accounts.
• Differentiate between Identity-based policies, Resource-based policies, and SCPs in the evaluation logic.
• Automate account provisioning and governance using AWS Control Tower and AWS Config.

Key Terms & Glossary

• Management Account: The central account that creates the organization, manages billing, and invited other accounts.
• Member Account: An AWS account (other than the management account) that is part of an organization.
• Organizational Unit (OU): A container for accounts within a root. OUs can contain other OUs, creating a hierarchy.
• Service Control Policy (SCP): An organization policy used to manage permissions in your organization, acting as a filter for what actions are possible.
• Trust Policy: A resource-based policy attached to an IAM role that defines which principals (accounts, users, or services) can assume the role.
• Permission Boundary: An advanced feature in which you use a managed policy to set the maximum permissions that an identity-based policy can grant to an IAM entity.

The "Big Idea"

In a single-account environment, security is managed via IAM Users and Groups. However, as an enterprise scales to hundreds or thousands of accounts, individual IAM management becomes impossible. The "Big Idea" is Centralized Governance with Decentralized Operation. We use AWS Organizations to group accounts, SCPs to set high-level "guardrails" (e.g., "No one in the Dev OU can delete CloudTrail logs"), and IAM Roles to allow DevOps engineers to move between accounts securely without managing multiple sets of credentials.

Formula / Concept Box

IAM Policy Evaluation Logic

Hierarchical Outline

• I. AWS Organizations Infrastructure
  • Organization Root: The parent container.
  • Organizational Units (OUs): Logical groupings (e.g., Prod, SDLC, Security).
  • Account Management: Centralized billing and tax management.
• II. Service Control Policies (SCPs)
  • Inheritance: Policies apply to the node and all children (OUs and accounts).
  • Filtering: SCPs define the maximum available permissions; they do not grant them.
  • Management Account Exception: SCPs do not affect the Management account.
• III. Cross-Account Access
  • Trust Relationship: Established in the target account.
  • AssumeRole API: Used by the source principal to gain temporary credentials.
  • STS (Security Token Service): The engine providing short-term access.
• IV. Governance at Scale
  • AWS Control Tower: Orchestrates account creation (Account Factory).
  • AWS Config: Audits and records resource configurations across accounts.

Visual Anchors

Organization Hierarchy & SCP Flow

Cross-Account Role Assumption Process

Definition-Example Pairs

• Trust Policy: A policy that defines which entities can assume a role.
  • Example: Account B creates a role named CrossAccountAdmin and adds a trust policy allowing arn:aws:iam::111122223333:root (Account A) to assume it.
• Implicit Deny: A request is denied by default if no explicit Allow is found.
  • Example: If an IAM user has no policies attached, they cannot launch an EC2 instance, even if the account has no SCPs.
• Attribute-Based Access Control (ABAC): Scaling permissions based on tags rather than individual names.
  • Example: Allowing a developer to stop an EC2 instance only if the user's tag Project matches the instance's tag Project.

Worked Examples

Scenario: Restricting Regions via SCP

Goal: Ensure that no member account in the "Europe-Office" OU can create resources outside of the eu-central-1 region.

The Solution:

1. Identify the OU ID for the European accounts.
2. Create an SCP with a Deny effect on all actions ("*") but use a Condition to exempt the specific region.
3. Apply the policy to the OU.

Policy Snippet:

Note: Global services like IAM and Route53 must be excluded from region restrictions to function.

Checkpoint Questions

1. Does a Service Control Policy (SCP) attached to an account grant permissions to a user within that account?
2. What happens if a user has an AdministratorAccess IAM policy, but the account's SCP has an explicit Deny on dynamodb:*?
3. Can an SCP restrict the Root user of a member account?
4. Why does a cross-account role need both a Trust Policy and a Permissions Policy?

▶Click to see answers

1. No. SCPs only define the maximum boundary. Permissions must still be granted via IAM policies.
2. Access is Denied. Explicit Deny in an SCP overrides any Allow in an IAM policy.
3. Yes. SCPs affect all users and roles in a member account, including the root user.
4. Trust Policy defines who can use the role; Permissions Policy defines what they can do once they assume it.

Muddy Points & Cross-Refs

• SCPs vs. Management Account: One of the most common exam traps. SCPs do not affect the Management account. Ensure your management account is used only for billing and administrative tasks, not running workloads.
• SCP vs. Permission Boundary: While both are "filters," SCPs are applied at the Account/OU level (Organization-wide), whereas Permission Boundaries are applied at the User/Role level (Individual identity).
• Resource-Based Policies: Remember that S3 Bucket Policies or KMS Key Policies can grant access to principals in other accounts directly without the need to assume a role, though Role Assumption is the preferred pattern for cross-account management access.

Comparison Tables

Access Control Mechanisms

---