Module Objective: Design identity and access management for both AWS account users and an application's own end users.

Builds on Modules 3–7: With storage, compute, database, and networking layers in place, this module secures who and what can reach them.

Identity in AWS: Two Different Problems

Securing access actually covers two related but distinct problems: controlling which AWS account users and roles can manage the infrastructure itself, and controlling which end users of the application can access it — the café's staff versus the café's customers.

🔵 Note Conflating these two identity problems is a common architectural mistake — the tools that manage AWS account access (IAM) are not the same tools typically used to manage an application's own end-user accounts.

IAM Users, Groups, Roles, and Policies Revisited

Building on AWS Academy Cloud Foundations Module 4, this module applies IAM design in the context of a growing architecture — for example, assigning an IAM role (not long-term credentials) to the EC2 application tier so it can read from S3 or write to DynamoDB without embedded access keys.

✅ Tip — Instance Roles Are the Default Pattern Attaching an IAM role to an EC2 instance or Auto Scaling launch template, rather than storing access keys on the instance, is the standard, recommended way for compute resources to access other AWS services.

Federation and Identity Providers

Rather than creating individual IAM users for every person who needs AWS access, identity federation lets users authenticate with an existing identity provider — such as a corporate directory or a social login — and receive temporary AWS credentials.

Federation ApproachTypical Use
SAML 2.0 federationEnterprise single sign-on with an existing corporate identity provider
AWS IAM Identity CenterCentralized workforce access across multiple AWS accounts
Amazon Cognito federationEnd users signing in with social or third-party identity providers to an application
🔵 Note Federation avoids duplicating and maintaining separate credentials in AWS for every user — a significant operational and security benefit as an organization grows.

AWS Organizations and Service Control Policies

As introduced in AWS Academy Cloud Foundations Module 4, AWS Organizations and Service Control Policies extend access governance across multiple accounts — relevant here as the café's architecture might separate development, staging, and production into distinct accounts under one Organization.

✅ Tip — Multi-Account Is a Common Architecture Pattern Rather than one AWS account holding every environment, many organizations use separate accounts per environment (or per team), governed centrally through AWS Organizations — isolating blast radius if something goes wrong.

Securing Application-Level Access

For the café's own end users — its customers logging into an ordering app — Amazon Cognito provides user sign-up, sign-in, and access control for web and mobile applications, separate from the AWS account's own IAM identities.

Cognito ComponentWhat It Provides
User poolsA managed user directory for application sign-up and sign-in
Identity poolsTemporary AWS credentials for authenticated (or guest) users to access AWS resources directly
⚠️ Warning — Don't Use IAM Users for Application End Users Creating an IAM user for every customer of an application doesn't scale and mixes two different identity concerns. Amazon Cognito (or a similar identity service) is the standard-practice alternative for application-level users.

Key Terms for Module 8

identity federation
Letting users authenticate with an existing identity provider and receive temporary AWS credentials
instance role
An IAM role attached to an EC2 instance, allowing it to access AWS services without embedded credentials
multi-account strategy
Separating environments or teams into distinct AWS accounts, governed centrally through AWS Organizations
Amazon Cognito
A managed service providing sign-up, sign-in, and access control for an application's own end users

Review Questions

  1. What is the difference between securing AWS account access and securing an application's end-user access?
  2. Why is attaching an IAM role to an EC2 instance preferred over storing long-term access keys on it?
  3. What problem does identity federation solve for an organization with many AWS users?
  4. Why is Amazon Cognito, rather than IAM users, the standard approach for managing an application's own customers?