What is Amazon Cognito? A plain-English explainer
Amazon Cognito is AWS’s service for handling sign-up, sign-in and access control for the users of your own applications — the people using the app you have built, not the people managing your AWS account. Building authentication yourself means storing passwords safely, issuing and refreshing tokens, wiring up "sign in with Google" buttons, and getting all of it right against constantly evolving security practice. Cognito exists so a development team does not have to build and maintain that machinery from scratch for every app. Here is what it actually does, how it differs from AWS IAM, and where it fits into an architecture.
What Cognito actually does
Cognito gives an application two related things: a place to store and manage its users (a "user pool" — sign-up, sign-in, password resets, multi-factor authentication) and a way to grant those signed-in users temporary, limited access to other AWS resources their app needs, such as an S3 bucket or an API (an "identity pool"). Together they cover the two halves of the problem: proving who a user is, and then deciding what that user is allowed to touch.
Once a user signs in, Cognito issues tokens that the application uses to confirm the user’s identity on subsequent requests, rather than the app having to check a password against a database on every action.
Cognito vs AWS IAM — the distinction that matters most
This is the point people new to AWS most often mix up. AWS IAM controls who can administer your AWS account — the engineers, services and roles allowed to create an S3 bucket, launch a server or change a configuration. Cognito manages the end-users of the application you have built on top of AWS — the customers signing up for your app, who have no need for, and should never be given, access to your AWS account itself.
Our what is AWS IAM and what is identity and access management explainers cover the account-administration side in depth. The short version to keep separate: IAM answers "who can operate this AWS account," and Cognito answers "who can log into this application."
Common uses
The most common use is simple app login: a mobile or web application that needs its own sign-up and sign-in screens, with Cognito handling the user directory and the security work behind the scenes. A close second is social and enterprise sign-in — letting users log in with an existing Google, Facebook or corporate identity-provider account rather than creating yet another password.
Cognito is also used to secure APIs: an API Gateway endpoint can require a valid Cognito token before it will process a request, so only signed-in users of the application can call it.
How it fits into an architecture
Cognito typically sits in front of the rest of an application’s backend. A user signs in through Cognito, receives a token, and that token is then presented to the application’s APIs and services as proof of identity — those services trust Cognito to have already done the work of verifying who the user is, rather than reimplementing authentication themselves.
Pricing model, in one line
Cognito follows the standard cloud consumption model — you are charged based on usage, such as the number of active users, rather than paying a fixed licence fee upfront; check AWS’s own pricing page for current figures.
Where Cognito appears in certification study
Cognito features in the AWS Certified Developer Associate, where adding authentication to an application is core material, and in the AWS Certified Security Specialty, where the distinction between application-user identity and AWS-account identity is a recurring exam theme. It also comes up in the Solutions Architect Associate when a design calls for a managed identity layer in front of an app.
As with the other services covered here, this article stays at the concept level — the exam-depth detail on configuring user pools, identity pools and federation belongs in our /revision study material.
Original practice questions, timed mock exams and revision notes. No card, nothing to pay.