AWS IAM Identity Center (SSO) & Control Tower
Key concepts
Centralized access management
Permission sets
Integration with external IdPs
Control Tower for multi-account governance
Landing zones and guardrails
The Morning of Six Passwords
Trailbase is not a one-account startup anymore. The account Dana rebuilt after the Theo incident has split into six: production, development, staging, a data account for Mara's pipelines, a sandbox where Theo can delete things legally, and a security account that almost nobody touches. Every split was the right call on its own. A mistake in development can no longer reach production, and each team's bill is finally readable.
Then Mara tries to start her workday. Six accounts means six IAM users, six passwords, six separately registered MFA devices, and a browser folder of console bookmarks labeled things like "prod (the real one)". She keeps a text file mapping which password belongs to which account, which is precisely the kind of habit lesson 1 existed to kill.
Onboarding is worse. When a new engineer named Jonas joins, Dana spends an entire day creating an IAM user in every account, adding group memberships, and emailing six temporary passwords. Offboarding is worse still: miss one account when someone leaves, and an ex-employee quietly keeps access to it.
The root of the problem is a boundary you already know. IAM is global across regions, but it is scoped to a single account, so every new account is its own identity island. Cross-account roles bridge islands, and they are perfect for one outsider like Priya the auditor, but assuming a workforce of humans into six accounts by hand does not scale. This lesson covers the two services built for the many-account world: AWS IAM Identity Center gives everyone at Trailbase one sign-in that opens every account they are entitled to, and AWS Control Tower is how Dana would have built the whole account estate in the first place if she had known it was coming.
Two Services, Two Jobs
IAM Identity Center manages WHO can access WHAT: one identity source, one portal, permissions projected into every account. Control Tower manages HOW accounts are created and governed: an automated landing zone with guardrails and an Account Factory. Most exam questions on this topic reduce to deciding which of the two jobs the scenario is describing.
Keyword-match ruthlessly. Phrases like centralized access management across multiple AWS accounts or single sign-on for workforce users point to IAM Identity Center. Phrases like automated multi-account setup, landing zone, or guardrails point to Control Tower.
One Sign-In for Every Account
Start with the fix for Mara's mornings. Single sign-on (SSO) means a person authenticates once, against one identity, and gains access to many systems without entering credentials again. IAM Identity Center, the successor to a service literally named AWS Single Sign-On, is the AWS-recommended way to give a workforce SSO across many AWS accounts and cloud applications.
After Dana enables it, Mara's six passwords collapse into one. She signs in at a single portal URL with one password and one MFA device, and the portal shows her a tile for every account and access level she has been granted. Clicking a tile drops her into that account's console with the right permissions already in place.
IAM Identity Center
IAM Identity Center is the successor to AWS SSO and provides centralized identity management for AWS access.
It gives you single sign-on (one login for all AWS accounts and applications), multi-account permissions (assign access to many accounts from one place), application assignments (grant access to SAML 2.0 applications alongside AWS accounts), and identity source flexibility (use its built-in directory or plug in an external provider).
Three moving parts make it work. The user portal is the web interface where users open their assigned accounts and apps. Permission sets define what users can do inside each account. The identity source is where the user identities themselves come from.
Where the Identities Live
The first decision when enabling Identity Center is choosing the identity source: the system that stores your people and checks their passwords. Trailbase is small, so Dana uses the built-in directory and creates Mara, Theo, and Jonas exactly once. A larger company almost always already has an identity system, and Identity Center is designed to plug into it rather than replace it.
Two terms matter here. Active Directory (AD) is Microsoft's directory service, the identity backbone of most Windows-centric enterprises. An external identity provider (IdP) is any third-party identity system, such as Okta, Azure AD, Google Workspace, or Ping Identity, that speaks SAML 2.0, the standard protocol for passing a signed "this user is authenticated" assertion between systems.
Identity Source Options
IAM Identity Center supports three identity source types.
1. IAM Identity Center Directory (built-in): create and manage users directly in Identity Center, with support for groups, MFA, and user attributes. Best for small organizations and proofs of concept. This is Trailbase today.
2. Active Directory: connect to AWS Managed Microsoft AD or a self-managed AD, using AD Connector or a direct trust relationship. Best for organizations with existing AD infrastructure.
3. External identity provider (SAML 2.0): integrate Okta, Azure AD, Google Workspace, Ping Identity, and similar. Users authenticate against the external IdP, which then vouches for them to AWS. Best for organizations that have already invested in an IdP.
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 |
What is the recommended AWS service for providing single sign-on access to multiple AWS accounts?
Permission Sets: Define Once, Project Everywhere
One sign-in solves authentication, but Dana still has to say what Mara may do in each account, and she refuses to hand-edit IAM in six places ever again. A permission set is her answer: a named collection of IAM policies, defined once in Identity Center and stamped into every account where it is assigned.
The mechanics reuse machinery you already know from the roles lesson. Dana creates a permission set, assigns it to a user or group for specific accounts, and Identity Center automatically creates a corresponding IAM role in each of those accounts. When Mara clicks a portal tile, she assumes that role and works on temporary credentials, the same short-lived, self-expiring kind Priya uses for her audits. No permanent keys, no per-account users.
Permission Sets
Permission sets define what permissions users have when they access an AWS account through IAM Identity Center.
The flow has four steps: create a permission set (a collection of IAM policies), assign it to users or groups for specific accounts, let Identity Center create an IAM role in each assigned account, and users then assume that role when they enter the account.
They come in two types. Predefined permission sets are AWS managed (AdministratorAccess, ViewOnlyAccess, and friends). Custom permission sets are ones you build from AWS managed or customer managed policies.
Each permission set also carries a session duration (1 to 12 hours), an optional relay state (the console page users land on), and tags for organization.
Here is what Dana's setup looks like from the command line, starting with confirming the service is on:
# 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 > Enable# 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/PowerUserAccess# 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-12345678abcdNotice the --principal-type GROUP in that last command. Dana assigns permission sets to groups, never to individuals, so onboarding Jonas is now one action: add him to the Developers group, and every account assignment that group holds becomes his. The full day of account-by-account IAM work shrinks to about a minute.
IAM Identity Center Best Practices
Use an external IdP for production so identities live where the rest of the company already manages them. Create permission sets by job function, never per individual, which keeps you aligned with least privilege. Assign groups, not users, so membership changes drive access changes. Require MFA through the IdP or Identity Center itself. Set session durations that balance security against re-login fatigue. And for fine-grained control, use attribute-based access control (ABAC), where permissions key off user attributes such as team or cost center instead of ever-multiplying permission sets.
Control Tower: How Dana Would Have Started
Trailbase built its six accounts the hard way: creating each one by hand, wiring up AWS Organizations, copying logging configuration, and hoping nothing was forgotten. Watching Dana do this a sixth time, Priya asked a pointed audit question: who guarantees that account number six is configured like account number one? The honest answer was nobody.
AWS Control Tower exists so that answer is never "nobody" again. It automates the setup of a secure, well-architected multi-account environment called a landing zone: a pre-configured account structure, wired to AWS Organizations, with logging, auditing, and governance rules in place from day one. Had it existed in Trailbase's greenfield days, Dana would have started here and the six accounts would have provisioned themselves.
AWS Control Tower
AWS Control Tower automates the setup of a secure, well-architected multi-account environment.
A landing zone has four structural components. The management account is where Control Tower is deployed. The Log Archive account holds centralized logging for every account in the organization. The Audit account gives security and compliance teams their monitoring perch. Organizational units (OUs) are logical groupings of accounts within AWS Organizations, and Control Tower pre-configures foundational ones such as Security and Sandbox.
On top of that structure it provides automated account provisioning through Account Factory, centralized logging and monitoring, and built-in guardrails for governance.
Setting up the landing zone is a console-driven flow: open Control Tower, choose "Set up landing zone," and configure the home region, the foundational OU names, and the email addresses for the Log Archive and Audit accounts. Control Tower creates those accounts and the Security OU for you.
Which Control Tower component automatically creates the Log Archive and Audit accounts?
Guardrails: Rules the Whole Estate Obeys
With six accounts and more coming, Dana cannot personally review every configuration in every account. She needs rules that apply everywhere without her enforcing them by hand. Guardrails, which AWS now calls Controls, are exactly that: high-level governance rules that Control Tower enforces across the accounts in an OU.
Each control type maps to an enforcement mechanism you have already met or will meet shortly. Preventive controls block a non-compliant action before it happens, and under the hood they are service control policies, the organization-level outer fence from lesson 1. Detective controls find non-compliance after the fact using AWS Config rules, where AWS Config is the service that continuously records and evaluates resource configurations. Proactive controls check resources during provisioning, implemented as CloudFormation hooks that inspect a template's resources before they are created.
Guardrails/Controls
Guardrails (now called Controls) are high-level rules that enforce governance policies across accounts.
By mechanism, there are three types: preventive controls stop non-compliant actions (implemented via SCPs), detective controls identify non-compliance (implemented via AWS Config rules), and proactive controls check resources before provisioning (implemented via CloudFormation hooks).
By guidance category, there are also three levels: mandatory controls are always enforced and cannot be disabled, strongly recommended controls encode security best practices, and elective controls are optional based on your 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 |
This is also how regulated companies stay compliant at scale. A healthcare company facing HIPAA requirements deploys Control Tower, enables detective controls that flag unencrypted resources, adds preventive controls that block the non-compliant actions outright, and lets the security team watch everything from the Audit account. Trailbase, more modestly, enables the strongly recommended set and a preventive control that stops anyone, in any account, from disabling CloudTrail. Even Dana's admin permission set cannot get around it, which is the point.
What type of Control Tower guardrail uses Service Control Policies (SCPs)?
Account Factory: The Seventh Account in Minutes
Mara wants a dedicated account for machine learning experiments. The old way costs Dana a day of setup and an uneasy feeling about what she forgot. The Control Tower way is Account Factory: automated account provisioning where every new account is born with the pre-approved baseline, already enrolled in the guardrails, and already wired into IAM Identity Center. Mara's ML account exists before lunch, configured identically to its six siblings.
Account Factory
Account Factory automates new account creation with pre-approved configurations, automatic guardrail enrollment, an optional network baseline (VPC), and IAM Identity Center integration.
You can create accounts through the Control Tower console, through Service Catalog, or through APIs when you want to automate provisioning end to end.
Enabling additional controls on an OU is scriptable too:
# 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-hijklmnoControl Tower Best Practices
Leave mandatory guardrails alone (you cannot disable them anyway) and enable the strongly recommended set. Keep a test OU so you can trial new guardrails before they hit production accounts. Route every new account through Account Factory so the baseline stays consistent. Treat the Log Archive account as read-only and never run workloads in it. And watch for drift: manual changes in member accounts that diverge from the Control Tower baseline, which the dashboard detects and reports.
A company wants to automatically create new AWS accounts with a baseline security configuration. Which Control Tower feature should they use?
Trailbase at Scale
The pattern Trailbase runs at six accounts is the same one enterprises run at six hundred. A company with 100+ AWS accounts and 500 employees on Azure AD connects Azure AD to Identity Center as an external SAML identity provider, builds permission sets for each job function (Admin, Developer, ReadOnly), and assigns Azure AD groups to accounts. Nobody creates an IAM user anywhere.
The portal stretches beyond AWS, too. Because Identity Center handles SAML 2.0 application assignments, the same sign-in that opens the production account can open Salesforce and ServiceNow, giving the workforce one portal for everything. And since Control Tower centralizes every account's CloudTrail into the Log Archive account, Priya now audits the whole estate from a single place instead of assuming a role into each account one by one.
SAA-C03 loves pairing these services in one scenario: a company adopting multiple accounts that needs both governance and workforce access. Read carefully whether the question asks how accounts are set up and governed (Control Tower) or how people sign in and get permissions (IAM Identity Center). Distractors usually offer IAM users, Cognito, or plain cross-account roles for workforce SSO; at multi-account workforce scale those are wrong.
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
IAM Users in Every Account
Creating IAM users in each account instead of using IAM Identity Center recreates Mara's morning of six passwords: credential sprawl, no central place to audit or revoke access, and no single sign-on. Use Identity Center for all human users, define permission sets for the access levels you need, and manage everything centrally rather than per account.
The AdministratorAccess Shortcut
Handing everyone a permission set built on AdministratorAccess is convenient for exactly as long as nothing goes wrong. It violates least privilege, widens the blast radius of any compromised credential, and makes audits useless. Build job-function-specific permission sets, start restrictive, and assign multiple permission sets to the same account when different levels of access are genuinely needed.
Touching the Log Archive Account
Running workloads in the Log Archive account, or modifying its configuration, compromises the integrity of the audit trail, can violate compliance requirements, and causes Control Tower drift. Treat it as read-only for compliance purposes, deploy nothing there, and restrict access to the security and audit teams.
Fighting Mandatory Guardrails
Mandatory guardrails cannot be disabled, and that is deliberate: they protect the core integrity of the landing zone. Attempting to work around them just creates security gaps. Design workloads to comply with them, and use elective guardrails when you need room to customize.
Quick Reference
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 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 |
# 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>Related Services
AWS Config
Powers detective guardrails in Control Tower to identify non-compliant resources