1.1 IAM Roles, Organizations & Service Control Policies
Design least-privilege access across complex multi-account enterprise AWS environments using IAM roles, IAM Identity Center, permission boundaries, and Organizations Service Control Policies.
Key AWS SAA-C03 Architectural Takeaways
- Service Control Policies (SCPs) define the maximum permission boundaries for member accounts under an OU; an explicit Deny in an SCP overrides all member account permissions, including the root user.
- SCPs never affect the AWS Organizations management (root) account; they only restrict member accounts.
- IAM Permission Boundaries prevent privilege escalation by setting the maximum ceiling of permissions an entity can grant when delegating role creation.
- Cross-account resource access with KMS Customer Managed Keys requires explicit allowances in three distinct policies: the caller identity policy, the target S3 bucket policy, and the target KMS key policy.
AWS Organizations simplifies multi-account management through hierarchical Organizational Units (OUs). Governance teams enforce mandatory security controls using Service Control Policies (SCPs). An SCP specifies the maximum permissions that identity-based and resource-based policies can grant to principals in member accounts. When an explicit Deny is defined in an SCP (such as denying ec2:CreateInternetGateway), no IAM principal within that member account—including the account root user—can perform the action.
For enterprise workforce access, AWS IAM Identity Center connects with corporate SAML 2.0 identity providers such as Microsoft Entra ID or Okta. Instead of managing static IAM users and long-lived access keys in 50 distinct accounts, administrators assign centralized permission sets linked to corporate AD groups. Automatic SCIM synchronization provisions and de-provisions access seamlessly as employee roles change.
When delegating IAM role creation to developers, security teams deploy IAM Permissions Boundaries. By conditioning iam:CreateRole with the iam:PermissionsBoundary condition key, developers can build custom service roles for Lambda and ECS without ever having the ability to grant themselves or their microservices AdministratorAccess or access to restricted billing data.
Cross-account data sharing requires careful coordination between resource policies and cryptographic key policies. If an EC2 instance in Account A writes to an S3 bucket in Account B encrypted with an Account B KMS key, the instance role must have s3:PutObject and kms:GenerateDataKey/kms:Decrypt permissions, the S3 bucket policy must allow Account A's role ARN, and the Account B KMS key policy must explicitly allow Account A's role ARN.
An enterprise governance team requires that member accounts within their AWS Organizations structure never create or attach an Internet Gateway (IGW) to any Amazon VPC, ensuring workloads remain strictly isolated within the corporate WAN. How should the solutions architect enforce this policy across all member accounts without restricting the administrative root organization account?