Directory Services & Federation (SAML, OIDC)
Overview
AWS provides multiple ways to integrate identity management into your cloud architecture. AWS Directory Service allows you to run Microsoft Active Directory (AD) in the cloud or connect to your on-premises directory. Federation enables users to access AWS resources using credentials from external identity providers via SAML 2.0 or OpenID Connect (OIDC).
Understanding when to use each directory type and federation method is critical for the SAA-C03 exam. Questions often present scenarios where you must choose between AWS Managed Microsoft AD, AD Connector, Simple AD, or federation services like Cognito and IAM Identity Center.
Key Decision Points
Need AD features in AWS? → AWS Managed Microsoft AD Need to connect to on-premises AD? → AD Connector Need basic AD on a budget? → Simple AD Need mobile/web app authentication? → Amazon Cognito Need workforce SSO? → IAM Identity Center
Know the limitations of each directory type. Simple AD doesn't support trust relationships or MFA. AD Connector doesn't cache credentials - it's just a proxy. AWS Managed Microsoft AD is the only one that supports trust relationships with on-premises AD.
Architecture Diagram

Key Concepts
AWS Directory Service Options
AWS Managed Microsoft AD
AWS Managed Microsoft AD is a fully managed Microsoft Active Directory running on Windows Server.
Key Features:
- Full Windows Server AD (not emulated)
- Trust relationships with on-premises AD
- Multi-AZ deployment for high availability
- Automated backups and patching
- Supports MFA (RADIUS integration)
- Schema extensions supported
Best For:
- Windows workloads needing full AD
- Trust relationships with on-premises
- Applications requiring LDAP
- RDS for SQL Server authentication
AD Connector
AD Connector is a directory gateway that proxies requests to your on-premises Microsoft AD.
Key Features:
- No data stored in AWS (proxy only)
- Low latency to on-premises AD
- Supports MFA via RADIUS
- Works with WorkSpaces, WorkDocs, WorkMail
Limitations:
- Requires VPN or Direct Connect to on-premises
- Cannot be shared across AWS accounts
- Not multi-VPC aware
- No caching - dependent on connectivity
Best For:
- Organizations with existing on-premises AD
- When you don't want to replicate AD to cloud
Simple AD
Simple AD is a Samba 4-based directory compatible with Microsoft AD.
Key Features:
- Lower cost than Managed Microsoft AD
- Basic AD features (users, groups, policies)
- Kerberos-based SSO
- Two sizes: Small (500 users) or Large (5,000 users)
Limitations:
- No trust relationships
- No MFA support
- No schema extensions
- No PowerShell AD cmdlets
- No DNS dynamic updates
- Not compatible with RDS SQL Server
Best For:
- Small organizations with basic AD needs
- Linux workloads needing LDAP
- Cost-sensitive environments
Directory Service Comparison
| Feature | Managed Microsoft AD | AD Connector | Simple AD |
|---|---|---|---|
| Type | Full Windows AD | Proxy to on-prem | Samba-based AD |
| Trust Relationships | Yes | Via on-prem AD | No |
| MFA Support | Yes (RADIUS) | Yes (RADIUS) | No |
| Schema Extensions | Yes | Via on-prem AD | No |
| Users Supported | Unlimited | Depends on on-prem | 500 or 5,000 |
| Multi-AZ | Yes | Yes | Yes |
| Share Across Accounts | Yes | No | No |
| RDS SQL Server | Yes | Yes | No |
| Pricing | Highest | Medium | Lowest |
Federation Protocols
SAML 2.0 Federation
Security Assertion Markup Language (SAML) is an XML-based standard for exchanging authentication data.
How It Works:
- User authenticates with Identity Provider (IdP)
- IdP generates SAML assertion (signed XML)
- User presents assertion to AWS
- AWS validates assertion and provides access
AWS Services Supporting SAML:
- IAM (direct federation)
- IAM Identity Center
- Amazon Cognito (Identity Pools)
Common SAML IdPs:
- Okta, Azure AD, Ping Identity
- ADFS (Active Directory Federation Services)
- Google Workspace
OpenID Connect (OIDC) Federation
OpenID Connect is a modern authentication protocol built on OAuth 2.0.
How It Works:
- User authenticates with OIDC provider
- Provider issues ID token (JWT format)
- Application exchanges token for AWS credentials
- AWS STS validates and issues temporary credentials
AWS Services Supporting OIDC:
- IAM (web identity federation)
- Amazon Cognito (User Pools & Identity Pools)
- EKS (for pod IAM roles)
Common OIDC Providers:
- Google, Facebook, Amazon (social)
- Okta, Auth0, Azure AD
- GitHub (for EKS IRSA)
Amazon Cognito
Amazon Cognito
Amazon Cognito provides authentication for web and mobile applications.
Two Components:
User Pools:
- User directory for app authentication
- Sign-up and sign-in functionality
- Social and SAML/OIDC federation
- MFA support
- JWT token generation
Identity Pools (Federated Identities):
- Exchange tokens for AWS credentials
- Supports authenticated and guest access
- Maps users to IAM roles
- Fine-grained access control
Use Together: User Pool authenticates → Identity Pool provides AWS credentials
Cognito User Pools vs Identity Pools
| Aspect | User Pools | Identity Pools |
|---|---|---|
| Purpose | Authentication (who are you) | Authorization (what can you access) |
| Output | JWT tokens | AWS credentials |
| Federation | SAML, OIDC, social | User pool tokens, SAML, social |
| User Storage | Yes (directory) | No (maps identities) |
| MFA | Yes | Via User Pool |
| Best For | App sign-in | AWS resource access |
How It Works
Federation Architecture

SAML Federation with IAM
Step 1: Configure SAML Identity Provider in IAM
# Create SAML provider with metadata from your IdP
aws iam create-saml-provider \
--name ExampleOktaProvider \
--saml-metadata-document file://metadata.xmlStep 2: Create IAM Role for Federated Users
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::123456789012:saml-provider/ExampleOktaProvider"
},
"Action": "sts:AssumeRoleWithSAML",
"Condition": {
"StringEquals": {
"SAML:aud": "https://signin.aws.amazon.com/saml"
}
}
}
]
}Step 3: Map IdP Groups to IAM Roles
Configure your IdP to include role ARN in SAML assertions:
- Attribute:
https://aws.amazon.com/SAML/Attributes/Role - Value:
arn:aws:iam::123456789012:role/FederatedRole,arn:aws:iam::123456789012:saml-provider/ExampleOktaProvider
OIDC Federation with Cognito
Step 1: Create Cognito User Pool
aws cognito-idp create-user-pool \
--pool-name MyAppUserPool \
--policies "PasswordPolicy={MinimumLength=8,RequireUppercase=true,RequireLowercase=true,RequireNumbers=true}" \
--auto-verified-attributes email \
--mfa-configuration OPTIONALStep 2: Create Identity Pool
aws cognito-identity create-identity-pool \
--identity-pool-name MyAppIdentityPool \
--allow-unauthenticated-identities \
--cognito-identity-providers \
ProviderName=cognito-idp.us-east-1.amazonaws.com/us-east-1_abc123,ClientId=1234567890abcdefStep 3: Configure IAM Roles for Identity Pool
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "cognito-identity.amazonaws.com"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"cognito-identity.amazonaws.com:aud": "us-east-1:12345678-1234-1234-1234-123456789012"
},
"ForAnyValue:StringLike": {
"cognito-identity.amazonaws.com:amr": "authenticated"
}
}
}
]
}Directory Service Setup
AWS Managed Microsoft AD
aws ds create-microsoft-ad \
--name corp.example.com \
--short-name CORP \
--password 'ComplexPassword123!' \
--edition Standard \
--vpc-settings VpcId=vpc-12345678,SubnetIds=subnet-11111111,subnet-22222222AD Connector
aws ds connect-directory \
--name corp.example.com \
--short-name CORP \
--password 'ServiceAccountPassword!' \
--size Small \
--connect-settings VpcId=vpc-12345678,SubnetIds=subnet-11111111,subnet-22222222,CustomerDnsIps=10.0.0.10,10.0.0.11,CustomerUserName=svc_adconnectorUse Cases
Use Case 1: Enterprise Windows Workloads
Scenario: Company migrating Windows servers to AWS needs AD integration for authentication.
Solution:
- Deploy AWS Managed Microsoft AD
- Establish trust with on-premises AD
- Join EC2 instances to domain
- Use existing AD credentials
Use Case 2: Hybrid Identity with Existing AD
Scenario: Company wants to use existing on-premises AD for AWS services without replicating data.
Solution:
- Deploy AD Connector
- Configure VPN or Direct Connect
- Configure WorkSpaces/WorkMail to use AD Connector
- Users authenticate with on-premises credentials
Use Case 3: Mobile App with Social Login
Scenario: Mobile app needs Google/Facebook login with access to S3 for user data.
Solution:
- Create Cognito User Pool with social IdP federation
- Create Identity Pool linked to User Pool
- Configure IAM role with S3 access (scoped to user ID)
- App uses Cognito SDK for authentication
Use Case 4: Workforce SSO to AWS Console
Scenario: 500 employees need console access using corporate Okta credentials.
Solution:
- Configure IAM Identity Center
- Set up Okta as external SAML IdP
- Create permission sets for different roles
- Assign users/groups to accounts
Use Case 5: B2B Partner Access
Scenario: External partners need temporary access to specific AWS resources.
Solution:
- Create SAML federation with partner's IdP
- Create IAM role with limited permissions
- Partner users authenticate via their IdP
- Receive temporary AWS credentials
Best Practices
Directory Service Best Practices
- Choose Based on Requirements - Don't over-provision; Simple AD may be enough
- Deploy Multi-AZ - All directory types support Multi-AZ for resilience
- Use Separate Subnets - Deploy directory in dedicated subnets
- Monitor with CloudWatch - Track directory health and performance
- Regular Snapshots - Enable automated backups for recovery
- Secure Service Accounts - Use strong passwords, rotate regularly
Federation Best Practices
- Use IAM Identity Center for Workforce - Preferred over direct IAM SAML
- Use Cognito for Customer Identity - Purpose-built for app authentication
- Implement MFA - Require MFA at IdP level
- Short Session Durations - Minimize credential lifetime
- Audit Federation Events - Monitor with CloudTrail
- Map Groups to Roles - Don't create individual role assignments
Common Exam Scenarios
Exam Scenarios
| Scenario | Solution | Why |
|---|---|---|
| Windows EC2 instances need domain join | AWS Managed Microsoft AD | Full AD features for Windows workloads |
| Use existing on-premises AD without sync | AD Connector | Proxy to on-prem, no data in cloud |
| Small team needs basic user directory | Simple AD | Cost-effective for basic needs |
| Mobile app needs Facebook/Google login | Cognito User Pool with social IdP | Built-in social federation |
| App users need S3 access based on identity | Cognito Identity Pool | Exchange tokens for AWS credentials |
| Enterprise employees need AWS Console SSO | IAM Identity Center with SAML | Workforce SSO solution |
| Trust relationship between cloud and on-prem AD | AWS Managed Microsoft AD | Only option supporting AD trusts |
| Third-party SaaS needs temporary AWS access | IAM SAML federation | Cross-organization federation |
Common Pitfalls
Pitfall 1: Choosing Simple AD When You Need Trusts
Mistake: Selecting Simple AD when trust relationships are required.
Why it fails:
- Simple AD does not support trust relationships
- Cannot connect to on-premises AD forest
- Limited to standalone directory
Correct Approach:
- Use AWS Managed Microsoft AD for trust relationships
- Or use AD Connector to proxy to on-premises AD
Pitfall 2: AD Connector Without Redundant Connectivity
Mistake: Using AD Connector with single VPN connection.
Why it's risky:
- AD Connector is a proxy - no caching
- If connectivity fails, authentication fails
- Single point of failure
Correct Approach:
- Deploy redundant VPN or Direct Connect
- Consider AWS Managed Microsoft AD with trust for resilience
- Monitor connectivity health
Pitfall 3: Confusing Cognito User Pools and Identity Pools
Mistake: Using Identity Pool for authentication or User Pool for AWS credentials.
Why it causes issues:
- User Pools = authentication (JWT tokens)
- Identity Pools = authorization (AWS credentials)
- Using wrong one won't achieve goal
Correct Approach:
- Use User Pool for sign-in/sign-up
- Use Identity Pool to exchange tokens for AWS credentials
- Often used together in sequence
Pitfall 4: Embedding Federation Credentials in Apps
Mistake: Hardcoding IdP metadata or secrets in application code.
Why it's dangerous:
- Credentials can be exposed
- Difficult to rotate
- Violates security best practices
Correct Approach:
- Use AWS Secrets Manager for sensitive data
- Use Cognito SDK which handles token management
- Store IdP configuration in environment variables
Test Your Knowledge
Which AWS Directory Service option supports trust relationships with on-premises Active Directory?
A mobile application needs to allow users to sign in with their Facebook accounts and then access user-specific data in S3. What AWS services should be used?
What is the key difference between AD Connector and AWS Managed Microsoft AD?
Which federation protocol uses XML-based assertions for authentication?
Related Services
Quick Reference
Directory Service Sizing
Directory Service Sizing
| Service | Size | Users | Use Case |
|---|---|---|---|
| Simple AD | Small | Up to 500 | Small teams, testing |
| Simple AD | Large | Up to 5,000 | Medium organizations |
| AD Connector | Small | Up to 500 | Small hybrid deployments |
| AD Connector | Large | Up to 5,000 | Large hybrid deployments |
| Managed AD | Standard | Up to 5,000 | Most production workloads |
| Managed AD | Enterprise | Up to 100,000+ | Large enterprises |
Federation Method Selection
When to Use Each Federation Method
| Scenario | Recommended Service | Protocol |
|---|---|---|
| Workforce SSO to AWS Console | IAM Identity Center | SAML 2.0 |
| Mobile app with social login | Cognito User Pool | OIDC |
| App users need AWS credentials | Cognito Identity Pool | OIDC/SAML |
| Third-party vendor AWS access | IAM SAML Provider | SAML 2.0 |
| Kubernetes pod IAM roles (EKS) | IAM OIDC Provider | OIDC |
| Enterprise SSO to AWS Console | IAM Identity Center | SAML 2.0 |
CLI Commands Reference
# List directories
aws ds describe-directories
# Create Microsoft AD
aws ds create-microsoft-ad --name corp.example.com --password 'Password' --edition Standard --vpc-settings VpcId=vpc-xxx,SubnetIds=subnet-xxx
# Create trust relationship
aws ds create-trust --directory-id d-xxx --remote-domain-name onprem.example.com --trust-password 'TrustPassword' --trust-direction Two-Way
# Create AD Connector
aws ds connect-directory --name corp.example.com --password 'Password' --size Small --connect-settings VpcId=vpc-xxx,SubnetIds=subnet-xxx,CustomerDnsIps=10.0.0.10
# Delete directory
aws ds delete-directory --directory-id d-xxx# Create User Pool
aws cognito-idp create-user-pool --pool-name MyPool
# Create User Pool Client
aws cognito-idp create-user-pool-client --user-pool-id us-east-1_xxx --client-name MyAppClient
# Create Identity Pool
aws cognito-identity create-identity-pool --identity-pool-name MyIdentityPool --allow-unauthenticated-identities
# List User Pools
aws cognito-idp list-user-pools --max-results 10
# Get Identity Pool roles
aws cognito-identity get-identity-pool-roles --identity-pool-id us-east-1:xxxSAML Attributes for AWS
# Role attribute (required)
Name: https://aws.amazon.com/SAML/Attributes/Role
Value: arn:aws:iam::ACCOUNT:role/ROLE,arn:aws:iam::ACCOUNT:saml-provider/PROVIDER
# Session duration (optional)
Name: https://aws.amazon.com/SAML/Attributes/SessionDuration
Value: 3600 (seconds, max 43200)
# Role session name (optional but recommended)
Name: https://aws.amazon.com/SAML/Attributes/RoleSessionName
Value: user@example.com