AWS IAM vs Cognito Identity Comparison for Exams

For AWS certification exams, distinguishing between IAM and Cognito is crucial to correctly answer questions on authentication and authorization. These services operate at different layers—IAM secures access to AWS resources, while Cognito manages end-user identities for applications. Confusing them can lead to incorrect architectural choices, so mastering their differences is key to excelling in scenario-based exam questions.

Core Purposes: IAM for AWS Services, Cognito for Applications

AWS Identity and Access Management (IAM) is the foundational service for controlling access to AWS resources within an account. It defines who (or what) can perform actions on services like Amazon S3, EC2, or Lambda. IAM manages users, groups, roles, and policies to enforce least-privilege permissions for AWS administrators, applications, or services. For example, you might use an IAM role to allow a Lambda function to read from a DynamoDB table.

In contrast, Amazon Cognito is designed for authentication and user management in web and mobile applications. It handles the entire lifecycle of end-user identities—sign-up, sign-in, and profile management—scaling to millions of users. Cognito is the go-to service when your scenario involves customers logging into an application, not accessing the AWS Management Console directly. On exams, if a question describes end-users interacting with a customer-facing app, Cognito is typically involved; if it focuses on internal AWS resource access by services or employees, think IAM.

Exam strategy: Pay attention to the actor in the scenario. Keywords like "application users," "mobile app login," or "customer registration" point to Cognito. Terms like "AWS service permissions," "cross-account access," or "principals within the account" indicate IAM. A common trap is suggesting IAM users for a publicly scalable app, which is inefficient and not best practice.

Cognito Components: User Pools vs. Identity Pools

Cognito consists of two main components that serve distinct functions, and understanding their interplay is vital for exams.

Cognito User Pools are user directories that handle authentication flows. They provide built-in, customizable sign-up and sign-in pages, store user attributes, and can integrate with social identity providers like Facebook or Google. Upon successful login, a User Pool issues JSON Web Tokens (JWTs) that your application can use to authenticate user sessions. Essentially, User Pools answer "Is this user who they claim to be?" and manage identity data.

Cognito Identity Pools (formerly Federated Identities) are about authorization to AWS resources. They enable authenticated users to obtain temporary, limited-privilege AWS credentials (e.g., from AWS Security Token Service) to access services like S3 or API Gateway directly. An Identity Pool uses an identity provider—such as a User Pool, social login, or SAML—to authenticate a user, then maps that identity to an IAM role to define what AWS resources they can access.

Here’s a classic exam scenario: A mobile app lets users upload photos. Users sign in via a User Pool (authentication). The app then uses the Identity Pool to get temporary credentials, allowing the user to upload directly to an S3 bucket (authorization). If a question mentions "temporary AWS credentials for app users," Identity Pools are involved. For "user sign-in with email/password," think User Pools.

Federation with SAML and OIDC: Bridging External Identities

Both IAM and Cognito support federation, which allows users to authenticate with external identity providers using standards like SAML 2.0 or OpenID Connect (OIDC). However, they federate for different purposes.

In IAM, federation is used to grant AWS console or API access to users from corporate directories (e.g., Active Directory). You configure IAM to trust a SAML or OIDC provider, and when users log in via their company credentials, they assume an IAM role with defined permissions. This is common for enterprise scenarios where employees need access to AWS resources without having IAM user accounts.

In Cognito, federation integrates external providers into your application’s authentication flow. A User Pool can act as an identity broker, federating with SAML for enterprise logins or OIDC for social logins. Cognito then unifies these identities, allowing you to use them with Identity Pools for AWS resource access. For example, users could log in with their Google account (OIDC) via Cognito, then get credentials to post to a DynamoDB table.

Exam indicators: When the scenario involves "enterprise single sign-on (SSO)" for accessing the AWS Management Console, IAM federation is likely. For "social login in a mobile app" or "corporate credentials for an application," Cognito federation is the fit. Watch for red herrings: IAM federation is for AWS access, while Cognito federation is for app access, even if both use SAML/OIDC.

Authorization: IAM Roles versus Cognito Groups

Authorization—deciding what an authenticated identity can do—is handled differently in IAM and Cognito, a frequent exam focus.

IAM roles are the primary authorization mechanism within AWS. They define a set of permissions via policies and can be assumed by IAM users, AWS services, or federated identities. Roles are essential for granting least-privilege access to resources, such as allowing an EC2 instance to call an SNS topic.

Cognito groups, part of User Pools, are used to organize users (e.g., "Admin," "Premium") and map them to IAM roles via Identity Pools. When a user authenticates, their group membership can determine which IAM role the Identity Pool assumes on their behalf, thus controlling their AWS resource access. This allows you to implement fine-grained authorization for app users without managing individual IAM policies.

When to use each? Use IAM roles directly for service-to-service authorization (e.g., Lambda to S3) or for IAM users/groups within your account. Use Cognito groups when you have application users with varying levels of access to AWS backend services. For instance, in a photo-sharing app, "free" users might get a role allowing uploads to a specific S3 folder, while "premium" users get a role with additional permissions.

Exam tip: If a question describes user segmentation within an app that requires different AWS resource permissions, the solution often involves Cognito groups with role mapping. For defining permissions for an AWS service principal, IAM roles are correct. Beware of answers that suggest using IAM groups for app users—IAM groups are for IAM users within AWS, not for Cognito-managed identities.

Exam Scenario Indicators and Decision Framework

On exams, you’ll face scenarios that require choosing between IAM and Cognito, or using them together. Here’s a quick-reference guide to key indicators:

• Choose IAM when: The scenario involves AWS service principals (e.g., Lambda, EC2), cross-account access, AWS Management Console login for employees, or policy management for AWS resources. Keywords: "service role," "resource policy," "AWS account permissions."

• Choose Cognito when: The scenario involves end-user authentication for web/mobile apps, social or enterprise logins, user profile management, or issuing temporary AWS credentials to app users. Keywords: "user registration," "app sign-in," "mobile backend," "federated identities."

• Use Cognito User Pools for: Sign-up/sign-in flows, storing user attributes, email verification, multi-factor authentication (MFA), and issuing JWTs.

• Use Cognito Identity Pools for: Granting temporary AWS credentials to authenticated users to access AWS services directly from client-side code.

A simple decision framework: First, identify if the access is for AWS resources or application users. Then, choose IAM for the former and Cognito for the latter, using User Pools for authentication and Identity Pools for AWS credentials when needed.

Common Pitfalls

• Confusing IAM users with Cognito user pools for customer-facing applications, which can lead to scalability and management issues.
• Overlooking the need for Cognito Identity Pools when application users require direct access to AWS resources like S3 or DynamoDB.
• Misapplying IAM federation for application authentication instead of leveraging Cognito's built-in federation capabilities for web and mobile apps.

Summary

• IAM is used for controlling access to AWS resources within an account, ideal for service principals, cross-account access, and employee console login.
• Cognito manages end-user identities for web and mobile applications, handling sign-up, sign-in, and user profile management.
• Cognito User Pools handle authentication flows and issue JWTs, while Identity Pools provide temporary AWS credentials for authorized resource access.
• Federation with SAML and OIDC allows external identities; IAM federation is for AWS console access, while Cognito federation is for application login.
• Use IAM roles for service-to-service authorization and Cognito groups to map app users to IAM roles for fine-grained AWS resource access.
• Exam scenarios key on keywords: "service role" or "resource policy" for IAM, and "user login" or "temporary credentials" for Cognito.