IAM Identity Center, Directory Services and Control Tower

By the end of this lesson you will be able to

• Tell workforce identity (people who build and run your AWS accounts) from customer identity (people who use your app), and pick IAM Identity Center or Amazon Cognito accordingly.
• Explain how IAM Identity Center works: one access portal, one identity source (its own directory, Active Directory, or an external IdP through SAML 2.0 and SCIM), permission sets that become AWSReservedSSO_ IAM roles in every assigned account, and assignments of users or groups to accounts.
• Use Identity Center beyond the console: the CLI with aws configure sso, business applications over SAML 2.0, ABAC with user attributes as session tags, organization vs account instances, delegated administration and session durations, and know what still limits it (SCPs) and what goes wrong (off-boarding, re-provisioning).
• Describe Microsoft Active Directory (domain controllers, objects, OUs, trees, forests, GPOs, Kerberos) well enough to read a directory question.
• Choose between AWS Managed Microsoft AD, AD Connector and Simple AD from the exam’s keywords, with their sizes, trusts, MFA options and the services each works with, and know the 2025–26 changes (Hybrid Edition, Simple AD closed to new customers).
• Explain what AWS Control Tower builds (a landing zone on Organizations, Identity Center, CloudTrail and Config, the Security OU with Log Archive and Audit accounts, Account Factory) and how its controls work: preventive, detective and proactive, with drift and its repair.

#Why: many accounts, many people, one front door

Lesson 20.1 split a company into many AWS accounts under AWS Organizations, and lesson 20.2 showed exactly which policy limits what. One question is left: how do people get into all those accounts?

The old answer was an IAM user per person per account. With 40 accounts and 300 engineers that is up to 12,000 users, 12,000 passwords, and access keys on laptops. When someone resigns, somebody must remember every account they had. Lesson 2.4 already gave the modern rule: people should get temporary credentials through federation, never long-term keys. This lesson covers the three AWS answers that make that rule work at company scale:

• IAM Identity Center: one sign-in and central permissions for the workforce across every account.
• AWS Directory Service: Microsoft Active Directory in AWS, for Windows workloads and as an identity source.
• AWS Control Tower: a ready-built, governed multi-account environment, with Identity Center and guardrails switched on from day one.

#Workforce identity versus customer identity

Two kinds of people sign in to things you build, and AWS has a different service for each. Lesson 15.7 promised this comparison.

#IAM Identity Center

AWS IAM Identity Center (the successor to AWS Single Sign-On, renamed in 2022; exam questions may say either) gives your workforce one sign-in for:

• every AWS account in your organization, through the AWS access portal, the console and the CLI;
• business cloud applications with built-in integrations (Microsoft 365, Salesforce, Box, Slack and many more);
• any custom application that speaks SAML 2.0 (or OAuth 2.0);
• EC2 Windows instances, through remote desktop in Systems Manager Fleet Manager, without sharing local administrator passwords.

It is deeply tied to AWS Organizations: the recommended setup is an organization instance, enabled in the management account, which can manage access to every member account. It is free; you pay only for the AWS resources people use.

#One identity source

Identity Center connects to exactly one identity source at a time:

SCIM (System for Cross-domain Identity Management) is what keeps the copies in step: when someone joins, changes team or leaves in the IdP, the change flows to Identity Center without anyone touching AWS. Switching the identity source later is possible but disruptive (it can remove existing users, groups and assignments), so decide it early.

#Permission sets, accounts and assignments

Three building blocks decide who can do what, where:

• A permission set is a template of permissions: AWS managed policies, customer managed policies (attached by name), an inline policy, optionally a permissions boundary, and a session duration (1 hour by default, up to 12 hours).
• An AWS account in the organization (or an OU you choose accounts from).
• An assignment joins them: a user or group + an account + a permission set.

When you make an assignment, Identity Center provisions the permission set into that account: it creates an IAM role named AWSReservedSSO_ followed by the permission set name and a random suffix (for example AWSReservedSSO_DevReadOnly_3f2a9c1d7b6e4a10), under the path /aws-reserved/sso.amazonaws.com/, trusted only by a SAML provider it also creates in the account. So a permission set is not just “like” a role, as the notes say: in each account it becomes a real IAM role. One role per permission set per account is shared by every user and group assigned that set there.

A few consequences that exam questions and real incidents both turn on:

• Editing a permission set does not change the roles by itself. The roles in the accounts update when the permission set is provisioned again (the console does this when you save; through the API you call provision-permission-set). Until then the accounts show it as outdated.
• Customer managed policies are attached by name. A policy with exactly that name (and path) must exist in every target account, or provisioning fails there.
• SCPs still apply. The role is an ordinary IAM role in a member account, so the SCPs of its OU cap it like any other principal, and the RCPs of the resource’s account still limit what it can do to those resources (lesson 20.2). An AdministratorAccess permission set in a Region-locked OU is still Region-locked.
• The management account is special. SCPs never limit it (lesson 20.1), and a delegated administrator cannot manage permission sets provisioned there. Keep human access to the management account to a minimum.

Try the matrix: every cell is one assignment, and the role it becomes depends on the permission set and the account.

#How a sign-in works

The portal flow with an external IdP, as on the slide’s login diagram:

1. Open the access portal

   The user opens the organization’s AWS access portal URL (for example https://d-1234567890.awsapps.com/start). With an external IdP, Identity Center redirects the browser there with a SAML request.

2. Authenticate at the IdP

   The IdP checks the password and MFA with its own rules and posts a signed SAML assertion back. AWS never sees the password.

3. Choose an account and a permission set

   The portal shows only the accounts and permission sets assigned to the user or their groups, plus any assigned applications.

4. Get role credentials

   Identity Center obtains temporary credentials for the AWSReservedSSO_ role in that account and opens the console (or hands the credentials to the CLI). The session lasts as long as the permission set’s session duration.

For the CLI, aws configure sso stores a profile (start URL, Region, account, permission set) and aws sso login gets a token through the browser; the CLI then fetches and refreshes short-lived role credentials itself. No access key is stored on the laptop.

#Applications and ABAC

Application assignments give single sign-on to business applications. For a catalogue app (Microsoft 365, Salesforce, Box…) the setup is guided; for a custom SAML 2.0 application you exchange metadata: the application’s sign-in URL and audience, Identity Center’s certificate and metadata file, and the attributes to send. Users then open the app from the same portal.

Attribute-based access control (ABAC) makes permissions follow user attributes instead of multiplying permission sets. You turn on attributes for access control, and Identity Center passes chosen user attributes (department, cost center, job title, locale…) from the identity store or the IdP as session tags. A single permission set can then say: allow access only when the resource’s tag matches the caller’s, using aws:PrincipalTag/department in a condition (lesson 20.2 covers the condition keys). When a person changes department, you change one attribute, not a policy.

#Instances, administration and Regions

• Organization instance (recommended): enabled in the management account; the only kind that offers multi-account permissions, access to AWS accounts in the portal, customer managed SAML 2.0 applications and a delegated administrator. It lives in one home Region.
• Account instance: bound to one account (a member account or a standalone account), visible only there, for application assignments only (for example a team trying an AWS managed application). It cannot grant access to AWS accounts.
• Delegated administrator: you can register a member account to administer Identity Center, so the security team does not work in the management account. It cannot manage permission sets provisioned to the management account.
• Session durations: the permission set’s duration controls the AWS account session (1 to 12 hours); the access portal session has its own setting (8 hours by default).
• Encryption: an organization instance can encrypt its data at rest with a customer managed KMS key (lesson 21.2).

#Microsoft Active Directory in one page

Many exam questions assume you know what Active Directory is. Microsoft Active Directory (AD), or more exactly AD Domain Services, runs on Windows Server and is the directory of most companies with Windows PCs:

• It is a database of objects: user accounts with passwords, computers, printers, file shares and security groups.
• It is served by domain controllers: servers that hold a copy of the database and check every sign-in, using Kerberos (a KDC on each domain controller issues tickets) and, as a fallback, the older NTLM. Applications also query it over LDAP (encrypted: LDAPS).
• It gives central security management: create an account once, put it in groups, and every server, share and app that trusts the domain uses it. Group Policy Objects (GPOs) push settings (screen lock, password rules, blocked USB drives) to all computers in a container.
• Objects live in organizational units inside a domain; domains form trees (a parent and its child domains under one DNS name), and a group of trees is a forest, the outer security boundary.
• Two forests can be linked by a trust, so users of one can use resources of the other. A trust can be one-way or two-way.

Lesson 12.2 used the 500-employee company example: without AD, each PC needs its own accounts; with AD, any employee signs in on any PC and all permissions are managed in one place. AWS offers three ways to bring that into the cloud.

#AWS Directory Service: three ways to run AD

AWS Directory Service provides directories for Windows and LDAP workloads in AWS. The notes, the slides and the exam all compare the same three options.

#AWS Managed Microsoft AD

AWS Managed Microsoft AD (formally AWS Directory Service for Microsoft Active Directory) is a real Microsoft Active Directory (Windows Server domain controllers) that AWS runs for you in your VPC:

• Highly available: two domain controllers in two Availability Zones, monitored, patched, snapshotted and replaced by AWS. You can add more domain controllers for load, and (Enterprise Edition) replicate the directory to other Regions.
• Editions: Standard (small and midsize businesses, up to about 30,000 objects, roughly 5,000 employees) and Enterprise (up to about 500,000 objects).
• Trusts: one-way or two-way forest trusts (and external trusts) with your on-premises AD or another AD, so users keep their existing accounts and the AWS directory hosts the resources (a “resource forest”).
• Real AD features: GPOs, schema extensions, LDAPS, fine-grained password policies, Windows PowerShell administration from a domain-joined instance.
• MFA through your RADIUS server.
• Works with: seamless domain join of EC2 Windows and Linux instances, RDS for SQL Server (Windows authentication; also RDS for Oracle and PostgreSQL Kerberos), FSx for Windows File Server, WorkSpaces, Amazon QuickSight, Amazon Connect, and Identity Center as its identity source. It can be shared with other accounts.
• It is also a full standalone directory: you can create users in it and manage everything in AWS.

#AD Connector

AD Connector is not a directory. It is a directory gateway (proxy) in your VPC that forwards sign-in and lookup requests to your on-premises domain controllers, and caches no credentials or directory data in AWS:

• Users and groups are managed only on premises, with the usual tools; your password, lockout and expiry rules apply unchanged.
• It needs a network path to the domain controllers: Site-to-Site VPN or Direct Connect (lessons 22.4 and 22.5), DNS that resolves the domain, and a service account with limited rights in AD.
• Sizes: Small and Large, sized by operations per second, with no fixed user limit; spread load across several connectors. One connector per domain.
• MFA: through your on-premises RADIUS server.
• Works with: WorkSpaces, QuickSight, WorkMail, the AWS Management Console with AD credentials, seamless domain join of EC2 instances into the on-premises domain, and Identity Center. It does not work with RDS for SQL Server, does not support transitive trusts, cannot be shared with other accounts, and serves only its own VPC.
• Weak spot: everything depends on the link. If the VPN or Direct Connect connection goes down, nobody can sign in to anything that uses the connector.

#Simple AD

Simple AD is an AD-compatible directory powered by Samba 4, standalone in AWS. It is not Microsoft AD:

• Sizes: Small, up to 500 users (about 2,000 objects) and Large, up to 5,000 users (about 20,000 objects).
• Supports: user accounts and groups, group policies, Kerberos-based single sign-on, LDAP, domain join of EC2 Linux and Windows instances, WorkSpaces and WorkMail, daily snapshots.
• Does not support: trust relationships with any other domain (so it cannot be joined with on-premises AD), MFA, schema extensions, LDAPS, PowerShell AD cmdlets, AD recycle bin, RDS for SQL Server, FSx, and Identity Center.

#Choosing a directory

The notes’ exam keywords, kept as they are:

• “Establish a trust relationship with on-premises AD” → AWS Managed Microsoft AD.
• “Company policy prohibits storing any AD credentials or passwords in the cloud” → AD Connector.
• “Low cost, basic AD features, standalone in the cloud, no trust needed” → Simple AD.

#Identity Center with Active Directory

The slide on the Identity Center AD setup shows the three ways to use AD as Identity Center’s source:

1. Connect to AWS Managed Microsoft AD: integration is out of the box; users and groups can live in it.
2. Self-managed AD through a two-way trust: users stay in the on-premises forest; Managed AD trusts it, and Identity Center connects to Managed AD.
3. Self-managed AD through AD Connector: Identity Center connects to the connector, which proxies to on-premises AD.

Simple AD cannot be used. Many companies that already sync AD to Microsoft Entra ID simply connect Identity Center to Entra ID as an external IdP instead.

#AWS Control Tower

Setting up a good multi-account environment by hand means creating the organization and its OUs, a log archive account, an audit account, organization-wide CloudTrail and Config, Identity Center, SCPs, and a process to create new accounts that already have all of that. AWS Control Tower does it for you, following AWS best practice, and keeps governing it afterwards.

#The landing zone

A landing zone is a well-architected multi-account environment. Setting one up in Control Tower (from the management account, in a home Region you choose) builds on existing services:

• AWS Organizations: Control Tower uses it to create OUs and accounts (lesson 20.1).
• A Security OU with two shared accounts: Log Archive (a central S3 bucket with the CloudTrail and Config logs of every account) and Audit (read and notification access for the security team, where Config findings are aggregated and notifications are sent).
• IAM Identity Center with preconfigured groups and permission sets (or your own IdP).
• An organization-wide CloudTrail trail (lesson 19.6) and AWS Config recording (lesson 19.7) for governed Regions.
• Controls (guardrails) on the OUs, and a dashboard that shows OUs, accounts, enabled controls and non-compliant resources.

Account Factory creates new accounts that are already enrolled: placed in the chosen OU, with logging, Config, Identity Center access and the OU’s controls from the first minute. It is a console wizard (backed by AWS Service Catalog) and an API. Account Factory for Terraform runs the same account vending from a Terraform pipeline, for teams that manage everything as code. Existing accounts can also be enrolled, and existing OUs registered.

#Controls (formerly guardrails)

AWS now calls guardrails controls (the documentation, console and slides use both words). A control is a rule in plain language applied to an OU, so every account in the OU is governed by it. Each control has a behaviour:

and a guidance level: mandatory (protect the resources Control Tower itself deployed; always on, and from landing zone 4.0 the set depends on the integrations you enable), strongly recommended (common best practices) and elective (lock down actions many enterprises restrict). Like SCPs, controls do not restrict the management account.

The slide’s detective example: a Config rule monitors member accounts for untagged resources; when a resource is NON_COMPLIANT, the control shows it on the dashboard, an SNS topic notifies the admins, and a Lambda function can remediate (add the missing tags). The notification and remediation are yours to build (for example with EventBridge on Config compliance changes); Control Tower reports.

#Drift

Drift is when the landing zone no longer matches what Control Tower set up, because someone changed it around Control Tower, typically in the Organizations console: moving an enrolled account out of a registered OU, deleting a Control Tower OU, detaching or editing a Control Tower SCP, or removing an account from the organization. Control Tower detects drift and notifies (through the Audit account’s topics and the console; from landing zone 4.0, as EventBridge events in the management account). You fix it in Control Tower: update the account, re-register the OU, or repair (reset) the landing zone. Rule: make organization changes through Control Tower, not beside it.

#What goes wrong

• A leaver keeps access for a while: the user was disabled in the IdP but role sessions already issued remain valid until they expire. Keep session durations short; add an explicit Deny for emergencies; check that SCIM provisioning is actually on.
• A permission set change “does nothing”: it was edited but not re-provisioned. Provision it again to all accounts that use it.
• Provisioning fails in one account: a customer managed policy named in the permission set does not exist there, or an SCP blocks Identity Center’s IAM actions. Create the policy in every account (Account Factory or CloudFormation stack sets can do it).
• Someone edited an AWSReservedSSO_ role in IAM: the change is overwritten at the next provisioning. Change the permission set instead.
• AdministratorAccess cannot do something: an SCP or RCP of the account’s OU denies it. That is working as designed.
• AD Connector sign-ins all fail: the VPN or Direct Connect link is down, DNS forwarding to the domain controllers is broken, the service account’s password expired, or security groups and on-premises firewalls block the AD ports (DNS 53, Kerberos 88, LDAP 389…). Use redundant links; for cloud-only resilience use Managed AD with a trust.
• A trust will not establish: Simple AD cannot do trusts at all; with Managed AD, check conditional DNS forwarders on both sides, open ports between the networks, and the trust direction (Identity Center over a trust needs two-way).
• RDS for SQL Server cannot use the directory: it was AD Connector or Simple AD; RDS needs Managed Microsoft AD.
• Control Tower shows drift: an account or SCP was changed in Organizations directly. Repair through Control Tower.
• A new account is not governed: it was created in Organizations, not through Account Factory, and never enrolled. Enroll it.

#Identity in system design

A typical well-governed AWS estate combines everything in chapter 20:

1. Control Tower builds the organization: Security OU (Log Archive, Audit), Workloads OUs per environment, a Sandbox OU, preventive and detective controls (lesson 20.1 explains the SCPs underneath).
2. Identity Center is the only way in for people: connected to the corporate IdP (or to AD through Managed AD or AD Connector), with permission sets per job (read-only, developer, database admin, administrator) assigned to groups per account, short sessions, MFA at the IdP, and ABAC where permissions follow attributes.
3. Workloads use IAM roles, never people’s credentials (lesson 2.4).
4. Windows workloads (EC2 Windows, RDS for SQL Server, FSx for Windows, WorkSpaces) join Managed Microsoft AD, trusting the corporate forest; or use AD Connector when nothing may be stored in AWS and the link is reliable.
5. App customers sign in through Cognito, completely separate from the workforce.

#Try it yourself

These commands use the AWS CLI v2. Identity Center commands run in the management account (or the delegated administrator account) in Identity Center’s Region. Directory and Control Tower resources cost money; delete them afterwards.

# 1. Find the Identity Center instance and its identity store
aws sso-admin list-instances
# { "Instances": [ { "InstanceArn": "arn:aws:sso:::instance/ssoins-72231a1b2c3d4e5f",
#                    "IdentityStoreId": "d-9067a1b2c3", "Status": "ACTIVE" } ] }
INST=arn:aws:sso:::instance/ssoins-72231a1b2c3d4e5f

# 2. Look up a group in the identity store (synced from the IdP by SCIM)
aws identitystore list-groups --identity-store-id d-9067a1b2c3 \
  --filters AttributePath=DisplayName,AttributeValue=Developers
# { "Groups": [ { "GroupId": "9a67a1b2-c3d4-70e5-f6a7-b8c9d0e1f2a3", "DisplayName": "Developers" } ] }
aws identitystore list-users --identity-store-id d-9067a1b2c3 --max-results 2

# 3. A permission set: ReadOnlyAccess, 4-hour sessions
aws sso-admin create-permission-set --instance-arn $INST \
  --name DevReadOnly --session-duration PT4H
# { "PermissionSet": { "PermissionSetArn": "arn:aws:sso:::permissionSet/ssoins-72231a1b2c3d4e5f/ps-1a2b3c4d5e6f7a8b", ... } }
PS=arn:aws:sso:::permissionSet/ssoins-72231a1b2c3d4e5f/ps-1a2b3c4d5e6f7a8b
aws sso-admin attach-managed-policy-to-permission-set --instance-arn $INST \
  --permission-set-arn $PS --managed-policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess

# 4. Assign the Developers group to the Dev account with this permission set
aws sso-admin create-account-assignment --instance-arn $INST \
  --target-id 111122223333 --target-type AWS_ACCOUNT \
  --permission-set-arn $PS \
  --principal-type GROUP --principal-id 9a67a1b2-c3d4-70e5-f6a7-b8c9d0e1f2a3
# { "AccountAssignmentCreationStatus": { "Status": "IN_PROGRESS", "RequestId": "..." } }

# 5. After editing the permission set later, provision it again everywhere it is used
aws sso-admin provision-permission-set --instance-arn $INST \
  --permission-set-arn $PS --target-type ALL_PROVISIONED_ACCOUNTS

# 6. In the Dev account, the role that the assignment created
aws iam list-roles --path-prefix /aws-reserved/sso.amazonaws.com/ --query 'Roles[].RoleName'
# [ "AWSReservedSSO_DevReadOnly_3f2a9c1d7b6e4a10" ]

# 7. As a user: configure a CLI profile once, then sign in
aws configure sso
# SSO session name (Recommended): hospital
# SSO start URL [None]: https://d-9067a1b2c3.awsapps.com/start
# SSO region [None]: ap-southeast-1
# ... There are 2 AWS accounts available to you. -> Dev (111122223333)
# ... Using the role name "DevReadOnly"
# CLI profile name [DevReadOnly-111122223333]: dev
aws sso login --profile dev
aws sts get-caller-identity --profile dev
# { "Account": "111122223333",
#   "Arn": "arn:aws:sts::111122223333:assumed-role/AWSReservedSSO_DevReadOnly_3f2a9c1d7b6e4a10/nusrat@example.com" }

# 8. Directory Service: a Managed Microsoft AD (Standard Edition) in two subnets of two AZs
aws ds create-microsoft-ad --name aws.corp.example.com --short-name AWSCORP \
  --password '<admin-password>' --edition Standard \
  --vpc-settings VpcId=vpc-0a1b2c3d4e5f67890,SubnetIds=subnet-0aa11bb22cc33dd44,subnet-0ee55ff66aa77bb88
# { "DirectoryId": "d-906a1b2c3d" }

# 9. A two-way forest trust with the on-premises domain corp.example.com
aws ds create-trust --directory-id d-906a1b2c3d \
  --remote-domain-name corp.example.com --trust-password '<trust-password>' \
  --trust-direction Two-Way --trust-type Forest \
  --conditional-forwarder-ip-addrs 10.20.0.10 10.20.0.11

# 10. An AD Connector (Small) pointing at the on-premises domain controllers
aws ds connect-directory --name corp.example.com --short-name CORP --size Small \
  --password '<service-account-password>' \
  --connect-settings VpcId=vpc-0a1b2c3d4e5f67890,SubnetIds=subnet-0aa11bb22cc33dd44,subnet-0ee55ff66aa77bb88,CustomerDnsIps=10.20.0.10,10.20.0.11,CustomerUserName=svc-adconnector

# 11. A Simple AD (Small): only for accounts that already use Simple AD
aws ds create-directory --name lab.example.com --password '<admin-password>' --size Small \
  --vpc-settings VpcId=vpc-0a1b2c3d4e5f67890,SubnetIds=subnet-0aa11bb22cc33dd44,subnet-0ee55ff66aa77bb88

aws ds describe-directories --query 'DirectoryDescriptions[].[DirectoryId,Name,Type,Edition,Size,Stage]'
# [ [ "d-906a1b2c3d", "aws.corp.example.com", "MicrosoftAD", "Standard", null, "Active" ],
#   [ "d-906a4e5f6a", "corp.example.com", "ADConnector", null, "Small", "Active" ] ]

# 12. Control Tower: enable a detective control on an OU and list what is enabled
aws controltower enable-control \
  --control-identifier arn:aws:controlcatalog:::control/<control-id> \
  --target-identifier arn:aws:organizations::111122223333:ou/o-a1b2c3d4e5/ou-ab12-cdef3456
# { "operationIdentifier": "a1b2c3d4-...", "arn": "arn:aws:controltower:ap-southeast-1:111122223333:enabledcontrol/..." }
aws controltower list-enabled-controls \
  --target-identifier arn:aws:organizations::111122223333:ou/o-a1b2c3d4e5/ou-ab12-cdef3456

# 13. Landing zones as code: create one from a manifest file, then check it
aws controltower create-landing-zone --landing-zone-version 4.0 --manifest file://manifest.json
aws controltower list-landing-zones

Also try in the console: in Identity Center, open Settings → Attributes for access control and map department; then in Control Tower open Controls and filter by behaviour (preventive, detective, proactive) to see how each is implemented.

#Summary

Key takeaways

• Workforce vs customers: employees into AWS accounts and business apps → IAM Identity Center; users of your app → Cognito.
• Identity Center (formerly AWS SSO): one portal for all accounts in AWS Organizations, SAML 2.0 apps (Microsoft 365, Salesforce…) and EC2 Windows; one identity source: its own directory, Active Directory (Managed AD or AD Connector) or an external IdP with SAML 2.0 + SCIM (Entra ID, Okta, Google Workspace).
• Permission set (policies + session duration 1–12 h) + account + user/group = assignment; provisioning creates a real IAM role AWSReservedSSO_… in each account. Edits need re-provisioning; SCPs still cap it; the management account is special.
• CLI: aws configure sso, aws sso login, short-lived credentials. ABAC: attributes for access control → session tags → aws:PrincipalTag. Organization instance (management account, multi-account) vs account instance (apps only). Off-boarding in the IdP + SCIM removes access everywhere; issued sessions last until they expire.
• AD basics: domain controllers, objects, OUs, domains, trees, forests, GPOs, Kerberos, trusts.
• Managed Microsoft AD: real AD, two domain controllers in two AZs, Standard (~30,000 objects) / Enterprise (~500,000), forest trusts with on-premises AD, MFA via RADIUS, works with RDS for SQL Server, FSx, WorkSpaces, seamless EC2 domain join. Hybrid Edition (2025) extends your own domain.
• AD Connector: proxy, nothing cached in AWS, needs VPN or Direct Connect, Small/Large, MFA via on-prem RADIUS, no RDS for SQL Server; link down → sign-ins fail.
• Simple AD: Samba 4, Small ≤ 500 / Large ≤ 5,000 users, no trusts, no MFA, no RDS for SQL Server; closed to new customers since July 2026.
• Control Tower: landing zone on Organizations, Identity Center, CloudTrail and Config; Security OU with Log Archive and Audit; Account Factory (and for Terraform); controls: preventive (SCP/RCP), detective (Config rules), proactive (CloudFormation hooks); mandatory / strongly recommended / elective; drift detection and repair; dashboard.

Self-check: Identity Center, Directory Service and Control Tower32 questions