TECH **AWS Directory Service, Cognito, and Federation: Zero-Fluff Study Guide**

AWS Directory Service, Cognito, and Federation: Zero-Fluff Study Guide

For AWS Solutions Architect – Associate (SAA-C03) & Real-World Deployments

1. What This Is & Why It Matters

You’re a cloud engineer at a mid-sized company migrating from on-prem Active Directory (AD) to AWS. Your CTO demands: - Single sign-on (SSO) for 500 employees across AWS, Salesforce, and internal apps.
- Seamless access to EC2 Windows instances without managing local passwords.
- Compliance (HIPAA/SOC2) requiring centralized identity logs.

If you ignore this subtopic:
- Employees juggle 10+ passwords → security risks (password reuse) and helpdesk tickets.
- EC2 Windows instances become unmanageable (no AD integration → manual local accounts).
- AWS IAM becomes a bottleneck (no group-based access for non-AWS apps).

If you master it:
- One identity for AWS, SaaS apps, and on-prem resources.
- Automated user provisioning (e.g., new hire gets access to everything on Day 1).
- Cost savings (no need to run your own AD servers in EC2).

Real-world scenario:
You inherit a legacy AWS environment where developers use IAM users for everything. Your task: Replace this with federated access (Okta → AWS) and AD integration for Windows workloads.

2. Core Concepts & Components

? AWS Directory Service (AWS Managed Microsoft AD)

• What it is: A managed Active Directory (AD) service running in AWS, compatible with Microsoft AD.
• Production insight: If you don’t enable Multi-AZ, a single AZ outage takes down your entire directory. Always deploy in 2+ AZs.
• Key use case: Join EC2 Windows instances to a domain without running your own AD servers.

? Simple AD

• What it is: A lightweight, Samba-based AD-compatible directory (cheaper than Managed AD but lacks some features).
• Production insight: Doesn’t support trust relationships with on-prem AD. Use only for simple use cases (e.g., Linux instances with LDAP).
• Key use case: Small teams needing basic AD features without Microsoft licensing.

? AD Connector

• What it is: A proxy that forwards directory requests to your on-prem AD (no data stored in AWS).
• Production insight: If your on-prem AD goes down, AWS apps lose authentication. Always have a backup AD server.
• Key use case: Lift-and-shift migrations where you can’t move AD to AWS yet.

? Amazon Cognito

• What it is: A managed identity provider (IdP) for web/mobile apps (supports OAuth 2.0, SAML, and social logins like Google/Facebook).
• Production insight: User Pools store user data (like a database), while Identity Pools grant AWS credentials (e.g., temporary IAM roles).
• Key use case: A React app where users sign in with Google and get temporary AWS permissions.

? Federation (SAML/OIDC)

• What it is: Letting users log in via an external IdP (e.g., Okta, Azure AD) to access AWS.
• Production insight: SAML 2.0 is for enterprise SSO (e.g., Okta → AWS), while OIDC is for mobile/web apps (e.g., Cognito → AWS).
• Key use case: Employees log in to Okta and get one-click access to AWS Console.

? IAM Roles for Federated Users

• What it is: Temporary IAM roles assigned to federated users (instead of long-term IAM users).
• Production insight: Never hardcode IAM user credentials in apps. Use roles + federation.
• Key use case: A contractor logs in via Okta and gets a 1-hour IAM role to access S3.

? AWS Single Sign-On (AWS SSO)

• What it is: A managed SSO service that connects to AWS accounts, AD, or external IdPs (e.g., Okta).
• Production insight: Replaces IAM users for human access (simpler than SAML federation for AWS Console).
• Key use case: Employees log in once to AWS SSO and access all their AWS accounts.

3. Step-by-Step Hands-On: Deploy AWS Managed AD + Cognito + Federation

Prerequisites

• AWS account with admin IAM permissions.
• A VPC with 2+ private subnets (for Multi-AZ AD).
• A domain name (e.g., example.com) for AD (can be a subdomain like corp.example.com).

Task: Deploy AWS Managed AD + Cognito User Pool + Federate with Okta

Goal: Employees log in to Okta → get AWS Console access via SAML.

Step 1: Deploy AWS Managed AD

1. Go to AWS Directory Service → Directories → Set up directory.
2. Choose AWS Managed Microsoft AD.
3. Configure:
4. Directory DNS name: corp.example.com
5. NetBIOS name: CORP
6. Admin password: SecurePassword123! (use a secrets manager in production)
7. VPC: Select your VPC with 2+ private subnets.
8. Enable Multi-AZ: ✅ (critical for HA)
9. Click Next → Create directory (takes ~30 mins).

Verify success:

aws ds describe-directories --directory-ids <YOUR_DIRECTORY_ID>

Look for "Stage": "Active".

Step 2: Create a Cognito User Pool

1. Go to Amazon Cognito → Manage User Pools → Create a user pool.
2. Configure:
3. Pool name: EmployeeUserPool
4. Step through settings (accept defaults for now).
5. App clients: Create one named WebAppClient (no client secret).
6. Note the User Pool ID (e.g., us-east-1_abc123).

Verify success:

aws cognito-idp list-user-pools --max-results 10

Step 3: Set Up SAML Federation with Okta

1. In Okta Admin Console:
2. Go to Applications → Create App Integration → SAML 2.0.
3. App name: AWS SSO
4. Single sign-on URL: https://signin.aws.amazon.com/saml
5. Audience URI (SP Entity ID): urn:amazon:webservices
6. Attribute statements:
   • https://aws.amazon.com/SAML/Attributes/Role → arn:aws:iam::<ACCOUNT_ID>:role/OktaSSORole,arn:aws:iam::<ACCOUNT_ID>:saml-provider/Okta
   • https://aws.amazon.com/SAML/Attributes/RoleSessionName → user.email
7. Download Okta’s SAML metadata XML (save as okta-metadata.xml).

Step 4: Create IAM SAML Provider & Role

1. Create SAML Provider:
   bash
aws iam create-saml-provider \
--saml-metadata-document file://okta-metadata.xml \
--name Okta
   Note the ARN (e.g., arn:aws:iam::123456789012:saml-provider/Okta).

2. Create IAM Role for Okta:
   ```bash
   cat > trust-policy.json <<EOF
   {
   "Version": "2012-10-17",
   "Statement": [
   {
   "Effect": "Allow",
   "Principal": { "Federated": "arn:aws:iam::123456789012:saml-provider/Okta" },
   "Action": "sts:AssumeRoleWithSAML",
   "Condition": { "StringEquals": { "SAML:aud": "https://signin.aws.amazon.com/saml" } }
   }
   ]
   }
   EOF

aws iam create-role --role-name OktaSSORole --assume-role-policy-document file://trust-policy.json
3. Attach permissions (e.g., `ReadOnlyAccess` for testing):bash
aws iam attach-role-policy --role-name OktaSSORole --policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess
```

Step 5: Test Federation

1. In Okta, assign the AWS SSO app to a test user.
2. Log in to Okta → Click the AWS SSO app.
3. You should land in the AWS Console with the OktaSSORole permissions.

Verify success:

aws sts get-caller-identity

Output should show the assumed role (not an IAM user).

4. ? Production-Ready Best Practices

Security

• Least privilege: Assign IAM roles to federated users (never IAM users).
• MFA: Enforce MFA in Okta/Cognito (not just in AWS).
• AD security groups: Use them to control access to EC2 instances (e.g., AWS-DevTeam group gets RDP access).
• Secrets: Store AD admin passwords in AWS Secrets Manager (not in code).

Cost Optimization

• Simple AD is cheaper than Managed AD (~$0.10/hr vs ~$0.40/hr).
• Cognito pricing: Free for first 50K MAUs (monthly active users). Use User Pools for auth, Identity Pools for AWS credentials.
• AD Connector avoids running AD in AWS (but adds latency).

Reliability & Maintainability

• Multi-AZ AD: Always enable for production.
• Backup AD: Use AWS Backup to snapshot AD (even though it’s managed).
• Tagging: Tag AD with Environment=Prod, Owner=DevOps.
• Idempotency: Use AWS CloudFormation or Terraform to deploy AD (avoid manual steps).

Observability

• CloudWatch Logs: Enable Directory Service logs (for AD login attempts).
• Cognito logs: Stream to CloudWatch for failed logins.
• Alerts: Set up SNS alerts for:
• AD replication failures.
• Cognito failed logins (>5 in 5 mins).

5. ⚠️ Common Mistakes & Traps

6. ? Exam/Certification Focus (SAA-C03)

Typical Question Patterns

1. "Which service lets you join EC2 Windows instances to a domain?"
2. ✅ AWS Managed Microsoft AD (not Simple AD or AD Connector).

3. ❌ "IAM" (trick answer).

4. "How do you give temporary AWS access to a contractor via Okta?"

5. ✅ SAML federation + IAM role.

6. ❌ "Create an IAM user" (wrong for contractors).

7. "Which Cognito feature stores user data?"

8. ✅ User Pool.
9. ❌ "Identity Pool" (grants AWS credentials, doesn’t store users).

Key ⚠️ Trap Distinctions

Scenario-Based Question

"You need to give 100 employees SSO access to AWS Console and Salesforce. Which service do you use?"
- ✅ AWS SSO (simplest for AWS + SaaS apps).
- ❌ "Cognito" (overkill for enterprise SSO).
- ❌ "IAM users" (scalability nightmare).

7. ? Hands-On Challenge (with Solution)

Challenge:

You have a React app where users sign in with Google. After login, they should get temporary AWS credentials to upload files to S3. How do you set this up?

Solution:

1. Create a Cognito User Pool (for Google login).
2. Create a Cognito Identity Pool (to get AWS credentials).
3. Configure the Identity Pool to use the User Pool as an IdP.
4. Attach an IAM role to the Identity Pool (e.g., S3UploadRole).

Why it works:
- User Pool handles Google auth.
- Identity Pool exchanges the Google token for AWS credentials.

8. ? Rapid-Reference Crib Sheet

9. ? Where to Go Next

1. AWS Directory Service Docs – Official guide for AD in AWS.
2. Cognito Developer Guide – Deep dive into User/Identity Pools.
3. AWS SSO Setup Guide – Step-by-step for enterprise SSO.
4. Okta + AWS SAML Guide – Okta’s official AWS SAML setup.