Lesson 182 · AWS Learning Path

AWS 182: Amazon Cognito and AWS Directory Service

· Published · 8 min read

Labelled process diagram for AWS 182: Human or application identity to User pool, identity pool, or directory to Token, temporary credentials, or domain service to Authorized workload and audit evidence, with...

Why this lesson matters

Separate customer identity for applications from managed Microsoft AD and directory integration for workforce or Windows workloads.

What you will be able to do

By the end, you can:

  • explain amazon cognito and aws directory service in plain language;
  • locate the current service controls in the AWS Management Console;
  • run the matching CloudShell or AWS CLI queries and explain every important field;
  • draw the identity, network, data, failure, and monitoring path;
  • choose the service from requirements and reject it when those requirements are absent;
  • diagnose a failed or misleading result from evidence;
  • state the cost owner and prove cleanup or a no-create result.

Before you start

  • Use a personal AWS account only when its owner has approved the lesson. Do not use the root user for daily work.
  • CloudShell is the default command environment. AWS028 explains CloudShell; AWS029 and AWS030 explain local AWS CLI installation and profiles.
  • The course example Region is ap-south-1. Global services and services with a required control Region are called out in their commands.
  • Run aws sts get-caller-identity privately. Redact the account number before sharing evidence.
  • Never paste access keys, passwords, secret values, private object data, presigned URLs, or full account-specific ARNs into a submission.
  • This is a no-create lesson. Every Console action and AWS CLI command is read-only. Create the practical artifact locally.
  • Console wording can change. Use the Console service search if a menu label has moved, then confirm the current field in the official documentation.

The core model

QuestionWhat it means in this lesson
PurposeSeparate customer identity for applications from managed Microsoft AD and directory integration for workforce or Windows workloads.
Scope and boundaryThe learner must identify the account and Region scope, resource boundary, identity path, data or network path, failure behavior, observability, and cleanup ownership for Amazon Cognito and AWS Directory Service.
Evidence of successSuccess means the Console fields, CLI result, workload behavior, monitoring evidence, and architecture claim agree. An available state alone is not enough for Amazon Cognito and AWS Directory Service.
Cost modelRequests, running capacity, storage, logs, data transfer, retained state, and optional features must be priced for the exact design.
Safe rejection ruleAvoid using an identity pool as a user database or exposing AWS credentials when an API authorization layer is enough.

How the request flows

+---------------------------------+
|  Human or application identity  |
+---------------------------------+
                |
                v
+------------------------------------------+
|  User pool, identity pool, or directory  |
+------------------------------------------+
                     |
                     v
+---------------------------------------------------+
|  Token, temporary credentials, or domain service  |
+---------------------------------------------------+
                         |
                         v
+------------------------------------------+
|  Authorized workload and audit evidence  |
+------------------------------------------+

Separate customer identity from directory workloads

NeedCorrect service boundary
Sign up/sign in application customers and issue OIDC/OAuth tokensCognito user pool
Exchange an authenticated or guest identity for temporary AWS credentialsCognito identity pool with tightly scoped IAM roles
Run Windows/AD-aware workloads against actual managed Microsoft ADAWS Managed Microsoft AD
Let AWS applications query an existing self-managed AD without storing users in AWSAD Connector, with reliable network/DNS to that directory
Basic low-scale Samba-compatible directorySimple AD, only after verifying its feature limitations
Workforce access to AWS accountsIAM Identity Center, not a customer user pool

Cognito request and token model

A user pool is an OIDC identity provider. An app client defines allowed flows, callback/logout URLs, token lifetimes and whether a client secret is appropriate. Browser/mobile public clients cannot safely hold a client secret. Prefer authorization code plus PKCE for interactive public clients; require exact HTTPS redirect URIs and reject open redirect patterns.

Managed login supplies the authorization server and UI. Current feature plans differ: managed login, choice-based USER_AUTH, passwordless options and passkeys depend on plan/configuration. Classic hosted UI has fewer capabilities. SDK flows require the application to implement challenges correctly; custom challenges are not the same as managed-login flows.

The ID token describes authentication and identity claims for the client. The access token carries scopes/groups for API authorization. Never authorize an API merely because an ID token is a valid JWT. Validate signature using the pool JWKS, issuer, audience/client, token use, expiry and required scopes; cache keys with rotation-aware refresh. Tokens are bearer credentials and must not appear in URLs or logs.

Refresh tokens create longer sessions. Rotation returns a new refresh token and limits replay windows, but clients must store and replace it atomically. Revocation does not instantly retract already-issued access tokens, so choose short access-token lifetime for risk. MFA, passkeys, account recovery, enumeration resistance, threat protection, Lambda triggers and federation all require abuse and failure-path testing.

An identity pool accepts trusted provider tokens and calls STS for temporary role credentials. Authenticated and guest roles must have least privilege and claim/role mapping must not let users choose an elevated role. User-pool groups are not authorization until the API or role policy enforces them.

Directory Service operating model

AWS Managed Microsoft AD runs actual AD domain controllers across at least two subnets/AZs. You own users, groups, GPOs, schema decisions, trusts, DNS integration, delegated administration and application compatibility; AWS operates the underlying hosts. Client VPCs need routes, DNS resolution and required ports. Snapshot/recovery behavior is not a substitute for business-data backup.

AD Connector is a proxy: an outage, DNS error or unreachable on-premises directory breaks authentication. Simple AD lacks important Microsoft AD capabilities including trusts, schema extensions and several integrations. Enterprise AWS Managed Microsoft AD can use supported Multi-Region replication; it creates regional domain controllers and native AD replication, with edition/Region and cost constraints.

Architecture decision table

SituationDirectionReason
Requirement matchesUse Cognito for application identity patterns and Directory Service for supported directory and Windows integration requirements.Select only after scope, behavior, security, recovery, operations, and price evidence agree.
Requirement does not matchAvoid using an identity pool as a user database or exposing AWS credentials when an API authorization layer is enough.Rejecting an attractive service is a valid architecture result.
No create permission or cost approvalUse supplied evidence and local design workLearning does not depend on creating an hourly resource.
Existing resource is unknown or unownedInspect only, then stopNever change or delete a resource merely because it resembles a course example.

AWS Management Console, step by step

Sign in with the normal non-root learning identity. Write the expected starting state before opening the service.

  1. Use the Console service search and open Cognito, User pools and Identity pools, then Directory Service, Directories; confirm the account and Region before reading the page.
  2. Inspect the supplied or owned resource's status, configuration, permissions, networking, encryption, monitoring, tags, and dependencies without changing it.
  3. Open the related metrics, logs, events, or history view and record one timestamped signal that would prove or disprove the expected behavior.
  4. Return to the resource list, clear filters, and record the final inventory. On the read-only track, do not choose Create, Save, or Delete.

CloudShell and AWS CLI, step by step

Start with a known caller and Region:

export AWS_DEFAULT_REGION="ap-south-1"
aws sts get-caller-identity --query Arn --output text
aws configure list

Redact the account part of the ARN in shared evidence. Now run the topic queries:

aws cognito-idp list-user-pools --max-results 20 --query 'UserPools[].{Name:Name,Id:Id,Status:Status,Created:CreationDate}' --output table
aws cognito-identity list-identity-pools --max-results 20 --output table
aws ds describe-directories --query 'DirectoryDescriptions[].{Name:Name,Type:Type,Stage:Stage,Vpc:VpcSettings.VpcId}' --output table

Expected interpretation

User pools authenticate application users, identity pools exchange identities for temporary AWS credentials, and Directory Service options meet different Microsoft directory needs.

Practical work

Choose identity for a consumer web app, temporary S3 access, EC2 Windows domain join, and on-premises AD trust. Map tokens or Kerberos, MFA, federation, groups, network, recovery, and cost.

Diagnose this topic from its own evidence

  • Cognito redirect error: compare app-client ID, exact callback URI, grant/flow, domain and Region.
  • JWT rejected: inspect issuer, token_use, audience/client, scope, expiry and JWKS kid; do not disable validation.
  • Identity-pool access denied: trace provider token, role mapping, trust policy, STS session and role permissions.
  • Domain join fails: test Directory DNS first, then routes, SG/NACL ports, time sync, credentials and computer-object permissions.
  • AD Connector intermittently fails: verify both connector endpoints and redundant network/DNS paths to self-managed domain controllers.

Cost and cleanup

Requests, running capacity, storage, logs, data transfer, retained state, and optional features must be priced for the exact design.

Knowledge check

  1. What operational purpose is this lesson solving?

Expected direction: Separate customer identity for applications from managed Microsoft AD and directory integration for workforce or Windows workloads.

  1. Which scope or ownership boundary must be proved first?

Expected direction: The learner must identify the account and Region scope, resource boundary, identity path, data or network path, failure behavior, observability, and cleanup ownership for Amazon Cognito and AWS Directory Service.

  1. What evidence is strong enough to accept the result?

Expected direction: Success means the Console fields, CLI result, workload behavior, monitoring evidence, and architecture claim agree. An available state alone is not enough for Amazon Cognito and AWS Directory Service.

  1. Which tempting design or shortcut must be rejected?

Expected direction: Avoid using an identity pool as a user database or exposing AWS credentials when an API authorization layer is enough.

  1. Which cost dimensions and retained resources need an owner?

Expected direction: Requests, running capacity, storage, logs, data transfer, retained state, and optional features must be priced for the exact design.

Lesson acceptance

  • Distinguish user pools, identity pools, IAM Identity Center and all three Directory Service choices.
  • Select OAuth/OIDC flow and validate ID versus access tokens correctly.
  • Design temporary AWS credentials without overprivileged guest or claim-selected roles.
  • Trace AD DNS, network, trust and domain-join paths across AZs.
  • Explain Cognito feature-plan/session costs and continuously running directory/replication costs.

Official sources

Advertisement