AWS IAM Identity Center (SSO) & Control Tower
Overview
AWS IAM Identity Center (formerly AWS Single Sign-On) is the recommended service for managing workforce access to multiple AWS accounts and applications. It provides a centralized portal where users can sign in once and access all their assigned AWS accounts and cloud applications without re-authenticating.
AWS Control Tower extends this capability by providing an automated way to set up and govern a secure, multi-account AWS environment called a landing zone. Together, these services form the foundation of enterprise-scale AWS governance.
For the SAA-C03 exam, understanding how IAM Identity Center integrates with AWS Organizations and Control Tower is essential. These services appear frequently in questions about multi-account strategies and centralized access management.
Key Distinction
IAM Identity Center: Manages WHO can access WHAT (authentication & authorization) Control Tower: Manages HOW accounts are governed (guardrails & compliance)
When a question mentions 'centralized access management across multiple AWS accounts' or 'single sign-on for workforce users,' the answer is almost always IAM Identity Center. For 'automated multi-account setup' or 'guardrails,' think Control Tower.
Architecture Diagram
Key Concepts
AWS IAM Identity Center
IAM Identity Center
IAM Identity Center is the successor to AWS SSO, providing centralized identity management for AWS access.
Key Capabilities:
- Single Sign-On: One login for all AWS accounts and applications
- Multi-Account Permissions: Assign access to multiple accounts from one place
- Application Assignments: Grant access to SAML 2.0 applications
- Identity Source Flexibility: Use built-in directory or external IdPs
Components:
- User Portal: Web interface where users access assigned accounts/apps
- Permission Sets: Define what users can do in AWS accounts
- Identity Source: Where user identities come from
Identity Sources
Identity Source Options
IAM Identity Center supports three identity source types:
1. IAM Identity Center Directory (Built-in):
- Create and manage users directly in IAM Identity Center
- Best for: Small organizations, proof of concepts
- Supports: Groups, MFA, user attributes
2. Active Directory:
- Connect to AWS Managed Microsoft AD or self-managed AD
- Use AD Connector or direct trust relationship
- Best for: Organizations with existing AD infrastructure
3. External Identity Provider (SAML 2.0):
- Integrate with Okta, Azure AD, Google Workspace, Ping Identity, etc.
- Users authenticated by external IdP
- Best for: Organizations with existing IdP investments
Identity Source Comparison
| Source | User Management | Best For | Setup Complexity |
|---|---|---|---|
| IAM Identity Center Directory | Managed in AWS | Small orgs, testing | Low |
| AWS Managed Microsoft AD | Managed in AD | Windows-centric enterprises | Medium |
| Self-Managed AD via AD Connector | On-premises AD | Hybrid environments | Medium |
| External IdP (SAML) | Managed in IdP | Existing IdP investment | Low-Medium |
Permission Sets
Permission Sets
Permission Sets define what permissions users have when they access an AWS account through IAM Identity Center.
How They Work:
- Create a Permission Set (collection of IAM policies)
- Assign it to users/groups for specific accounts
- IAM Identity Center creates an IAM role in each assigned account
- Users assume this role when accessing the account
Permission Set Types:
- Predefined: AWS managed permission sets (AdministratorAccess, ViewOnlyAccess, etc.)
- Custom: Create your own using AWS managed policies or custom policies
Key Attributes:
- Session duration (1-12 hours)
- Relay state (landing page URL)
- Tags for organization
AWS Control Tower
AWS Control Tower
AWS Control Tower automates the setup of a secure, well-architected multi-account environment.
Landing Zone Components:
- Management Account: Where Control Tower is deployed
- Log Archive Account: Centralized logging for all accounts
- Audit Account: Security and compliance monitoring
- Organizational Units: Logical grouping of accounts
Key Features:
- Pre-configured OUs (Security, Sandbox, etc.)
- Automated account provisioning via Account Factory
- Centralized logging and monitoring
- Built-in guardrails for governance
Control Tower Guardrails (Controls)
Guardrails/Controls
Guardrails (now called Controls) are high-level rules that enforce governance policies.
Types of Controls:
- Preventive: Stop non-compliant actions (implemented via SCPs)
- Detective: Identify non-compliance (implemented via AWS Config rules)
- Proactive: Check resources before provisioning (implemented via CloudFormation hooks)
Guidance Categories:
- Mandatory: Always enforced, cannot be disabled
- Strongly Recommended: Security best practices
- Elective: Optional based on requirements
Control Types Comparison
| Type | Implementation | When Applied | Example |
|---|---|---|---|
| Preventive | Service Control Policies | Before action | Deny root user access |
| Detective | AWS Config Rules | After resource creation | Detect unencrypted S3 buckets |
| Proactive | CloudFormation Hooks | During provisioning | Validate resource configurations |
How It Works
IAM Identity Center Authentication Flow
Setting Up IAM Identity Center
Step 1: Enable IAM Identity Center
# IAM Identity Center is typically enabled via Console
# But you can check its status with:
aws sso-admin list-instances
# Enable via Organizations (if not enabled)
# Navigate to: IAM Identity Center Console > EnableStep 2: Choose Identity Source
Configure where user identities come from:
- Built-in directory: Manage users in IAM Identity Center
- External IdP: Configure SAML 2.0 connection
- Active Directory: Connect via AWS Directory Service
Step 3: Create Permission Sets
# Create a permission set
aws sso-admin create-permission-set \
--instance-arn arn:aws:sso:::instance/ssoins-1234567890abcdef0 \
--name "DeveloperAccess" \
--description "Access for development team" \
--session-duration "PT8H"
# Attach AWS managed policy to permission set
aws sso-admin attach-managed-policy-to-permission-set \
--instance-arn arn:aws:sso:::instance/ssoins-1234567890abcdef0 \
--permission-set-arn arn:aws:sso:::permissionSet/ssoins-1234567890abcdef0/ps-1234567890abcdef0 \
--managed-policy-arn arn:aws:iam::aws:policy/PowerUserAccessStep 4: Assign Users to Accounts
# Create account assignment
aws sso-admin create-account-assignment \
--instance-arn arn:aws:sso:::instance/ssoins-1234567890abcdef0 \
--target-id 123456789012 \
--target-type AWS_ACCOUNT \
--permission-set-arn arn:aws:sso:::permissionSet/ssoins-1234567890abcdef0/ps-1234567890abcdef0 \
--principal-type GROUP \
--principal-id 94482488-3041-7026-6a84-12345678abcdSetting Up Control Tower
Step 1: Launch Landing Zone
- Navigate to Control Tower console
- Click "Set up landing zone"
- Review and configure:
- Home region
- Foundational OU names
- Log archive account email
- Audit account email
Step 2: Account Factory Configuration
Account Factory
Account Factory automates new account creation with:
- Pre-approved configurations
- Automatic guardrail enrollment
- Network baseline (optional VPC)
- IAM Identity Center integration
Create accounts via:
- Control Tower console
- Service Catalog
- APIs (for automation)
Step 3: Enable Additional Guardrails
# Enable a detective control on an OU
aws controltower enable-control \
--control-identifier arn:aws:controltower:us-east-1::control/AWS-GR_ENCRYPTED_VOLUMES \
--target-identifier arn:aws:organizations::123456789012:ou/o-abc123/ou-defg-hijklmno
# List enabled controls
aws controltower list-enabled-controls \
--target-identifier arn:aws:organizations::123456789012:ou/o-abc123/ou-defg-hijklmnoUse Cases
Use Case 1: Enterprise Multi-Account Access
Scenario: Large enterprise with 100+ AWS accounts needs centralized access for 500+ employees using existing Azure AD.
Solution:
- Set up IAM Identity Center
- Configure Azure AD as external SAML identity provider
- Create permission sets for different roles (Admin, Developer, ReadOnly)
- Assign groups from Azure AD to accounts with appropriate permission sets
Use Case 2: Startup Growing Into Multi-Account
Scenario: Startup outgrowing single account needs proper multi-account setup with governance.
Solution:
- Deploy Control Tower to create landing zone
- Use Account Factory to create Production, Development, and Staging accounts
- Enable recommended guardrails for security
- Use IAM Identity Center for team access
Use Case 3: Compliance-Driven Organization
Scenario: Healthcare company needs to ensure all accounts meet HIPAA requirements.
Solution:
- Deploy Control Tower with custom guardrails
- Enable detective controls for encryption compliance
- Enable preventive controls to block non-compliant actions
- Use Audit account for centralized compliance monitoring
Use Case 4: Application Access Management
Scenario: Company needs SSO access to both AWS accounts and third-party SaaS apps.
Solution:
- Configure IAM Identity Center with external IdP
- Add SAML applications (Salesforce, ServiceNow, etc.)
- Assign users to both AWS accounts and applications
- Single user portal for all access
Best Practices
IAM Identity Center Best Practices
- Use External IdP for Production - Leverage existing identity infrastructure
- Create Permission Sets by Job Function - Not by individual, aligns with least privilege
- Use Groups, Not Individual Assignments - Easier to manage at scale
- Enable MFA - Require MFA for all users through IdP or IAM Identity Center
- Set Appropriate Session Durations - Balance security and usability
- Use Attribute-Based Access Control (ABAC) - For fine-grained permissions
Control Tower Best Practices
- Start with Mandatory Guardrails - Don't disable them
- Enable Strongly Recommended Guardrails - Security best practices
- Create Test OU - Test guardrails before applying to production
- Use Account Factory for All New Accounts - Ensures consistent baseline
- Centralize Logging in Log Archive Account - Never modify or delete
- Regular Drift Detection - Monitor for configuration drift
Common Exam Scenarios
Exam Scenarios
| Scenario | Solution | Why |
|---|---|---|
| Centralized access for 50 AWS accounts | IAM Identity Center with permission sets | Single sign-on, centralized management |
| Automate secure multi-account setup | AWS Control Tower | Landing zone with built-in governance |
| Enforce encryption across all accounts | Control Tower detective guardrail | AWS Config rule detects non-compliance |
| Prevent users from disabling CloudTrail | Control Tower preventive guardrail (SCP) | Blocks the action before it happens |
| Single sign-on with existing Okta | IAM Identity Center + SAML federation | External IdP integration |
| Create new accounts with baseline security | Control Tower Account Factory | Automated provisioning with guardrails |
| Audit access across all accounts | CloudTrail in Log Archive account | Centralized audit trail |
| Different permissions for dev vs prod accounts | Multiple permission sets assigned per account | Same user, different access levels |
Common Pitfalls
Pitfall 1: Using IAM Users Instead of IAM Identity Center
Mistake: Creating IAM users in each account instead of using IAM Identity Center.
Why it's problematic:
- No centralized access management
- Password/credential sprawl
- Difficult to audit and revoke access
- No single sign-on experience
Correct Approach:
- Use IAM Identity Center for all human users
- Create permission sets for different access levels
- Manage access centrally, not per-account
Pitfall 2: Overly Broad Permission Sets
Mistake: Creating permission sets with AdministratorAccess for convenience.
Why it matters:
- Violates least privilege
- Increases blast radius if credentials compromised
- Makes auditing difficult
Correct Approach:
- Create job-function-specific permission sets
- Start restrictive, add permissions as needed
- Use multiple permission sets per account if needed
Pitfall 3: Modifying Log Archive Account
Mistake: Using the Log Archive account for workloads or modifying its configuration.
Why it's dangerous:
- Compromises audit trail integrity
- May violate compliance requirements
- Can cause Control Tower drift
Correct Approach:
- Treat Log Archive as read-only for compliance
- Never deploy workloads there
- Only security/audit teams should have access
Pitfall 4: Disabling Mandatory Guardrails
Mistake: Attempting to disable mandatory Control Tower guardrails.
Why it fails:
- Mandatory guardrails cannot be disabled
- They protect core landing zone integrity
- Attempting to bypass creates security gaps
Correct Approach:
- Understand mandatory guardrails protect critical functions
- Design workloads to comply with them
- Use elective guardrails for customization
Test Your Knowledge
What is the recommended AWS service for providing single sign-on access to multiple AWS accounts?
Which Control Tower component automatically creates the Log Archive and Audit accounts?
What type of Control Tower guardrail uses Service Control Policies (SCPs)?
A company wants to automatically create new AWS accounts with a baseline security configuration. Which Control Tower feature should they use?
Related Services
AWS Config
Powers detective guardrails in Control Tower to identify non-compliant resources
Quick Reference
IAM Identity Center Key Components
IAM Identity Center Components
| Component | Purpose |
|---|---|
| User Portal | Web interface for users to access assigned resources |
| Permission Sets | Collections of policies defining access levels |
| Identity Source | Where user identities are stored/managed |
| Account Assignments | Links users/groups to accounts with permission sets |
| Application Assignments | Links users/groups to SAML applications |
Control Tower Key Components
Control Tower Components
| Component | Purpose |
|---|---|
| Landing Zone | Pre-configured multi-account environment |
| Account Factory | Automated account provisioning |
| Guardrails/Controls | Governance rules (preventive, detective, proactive) |
| Log Archive Account | Centralized CloudTrail and Config logs |
| Audit Account | Security team access for compliance monitoring |
| Dashboard | Compliance status and drift detection |
CLI Commands Reference
# List IAM Identity Center instances
aws sso-admin list-instances
# List permission sets
aws sso-admin list-permission-sets --instance-arn <instance-arn>
# List account assignments
aws sso-admin list-account-assignments \
--instance-arn <instance-arn> \
--account-id <account-id> \
--permission-set-arn <permission-set-arn>
# Get permission set details
aws sso-admin describe-permission-set \
--instance-arn <instance-arn> \
--permission-set-arn <permission-set-arn># List enabled controls for an OU
aws controltower list-enabled-controls \
--target-identifier <ou-arn>
# Enable a control
aws controltower enable-control \
--control-identifier <control-arn> \
--target-identifier <ou-arn>
# Disable a control (elective only)
aws controltower disable-control \
--control-identifier <control-arn> \
--target-identifier <ou-arn>
# Get landing zone status
aws controltower get-landing-zone --landing-zone-identifier <lz-id>