Amazon Cognito Multi-Region Replication - What Only the Primary Accepts, Which Issuer Your Tokens Carry, and What Validators Must Assume

First Published: 2026-11-01
Last Updated: 2026-11-01

Enabling multi-Region replication (MRR) in Amazon Cognito user pools allows you to create two user pools with the same user pool ID, located in two different AWS Regions. However, these two pools are not identical. The primary pool accepts configuration changes and user writes. The replica pool can accept sign-ins and token issuance when its status is ACTIVE. The APIs receiving tokens may not necessarily be able to validate tokens issued by either pool. Whether validation succeeds depends on the issuer format in the token, the issuer value the validator expects, and the location from which the validator retrieves the public key.

This article organizes these three key aspects into columns for what moves, what stays, and who acts. It covers what only the primary pool accepts, the two possible issuer formats carried by tokens, and what validators (such as Amazon API Gateway JWT Authorizers, Application Load Balancer authentication actions, aws-jwt-verify, or custom validation) must assume. It also distinguishes between the entities that shift traffic to the replica pool and those that return it. For each aspect, it indicates which document and which sentence it is described in, or whether no statement was found in the sources read.

This article does not provide a step-by-step guide on how to enable MRR, nor does it compare feature plans or discuss pricing. The information presented was verified on October 29, 2026.

Related articles on this site:

1. Scope and Assumptions
2. How to Read the Tables
3. Same ID, Separate Pools
4. Which Issuer a Token Carries
5. What Each Validator Must Assume
6. Who Moves Traffic to the Replica, and Who Moves It Back
7. What Stops During Failover
8. What This Setup Showed
9. Where the Sources Disagree, Count Differently, or Are Silent
10. Failure Modes
11. Frequently Asked Questions About Cognito MRR
12. Summary
13. References

1. Scope and Assumptions

This section defines the intended audience for this article, the scope of the discussion, the relevant documentation, the prerequisites for enabling MRR, and clarifies distinctions between similarly named entities. The core conclusions are as follows:

MRR involves creating a separate user pool in a different AWS Region, using the same user pool ID. The primary user pool handles configuration changes and user writes (sign-ups, administrator-created users, attribute updates, and password resets). The replica pool allows only Region-specific configuration of seven settings and limited administrative operations.
The replica is initially created in an INACTIVE state. It only begins accepting sign-ins, token refreshes, and token revocation after being transitioned to an ACTIVE state, a process initiated by an operator.
Tokens have two possible issuer formats. The original format includes the hostname cognito-idp and places JWKS and OIDC discovery documents within a single Region. The updated format includes the hostname issuer-cognito-idp and distributes the same JWKS across multiple Regions. In the updated format, the Region specified in the URL refers to the primary Region; for the original format, this article's setup observed the same (Section 8.2).
When Cognito documentation and blog posts state that tokens are valid across Regions, this refers to acceptance by Cognito endpoints. Whether your API's validator accepts tokens from the replica depends on your validator's issuer configuration and how you manage public keys.
Managed login, federation, and domain-based OAuth 2.0 endpoints are managed by Cognito, which transitions them to and from the replica pool, using a Route 53 health check that you set on the domain. SDK and API calls are determined by the application itself. In the AWS GovCloud (US) Regions, there is no automatic failover or automatic return to the primary pool.
The documentation differentiates between pages that recommend setting the issuer to updated and those that state it as a requirement. Furthermore, the launch date varies depending on the type of documentation, with three dates specified: May 28, 2026; June 3, 2026; and June 4, 2026.

1.1 Intended Audience

The intended audience for this article includes developers and platform engineers who are looking to run applications using Cognito user pools across multiple Regions, or who have already enabled Multi-Region Replication (MRR). Specifically, it targets readers who hold one of the following four concepts:

Users can continue to operate seamlessly even in the event of a regional outage, thanks to the availability of replicas.
Tokens issued in any Region should be valid across all Regions.
No changes are required to configurations for services like API Gateway or Application Load Balancer.
Sign-ups and attribute updates should be possible even when using replicas.

Whether each of these four concepts holds depends on factors such as the state of the replicas, the handling of the issuer and public keys for validation, and the authority responsible for write operations. Sections 3 through 7 will detail these dependencies and potential limitations, providing specific examples.

1.2 Scope and Exclusions

This article addresses the following topics: what each of the primary and replica pools accepts, the state of the replicas, the two formats of token issuers, the location of public keys, assumptions for each validator, the entities that move traffic to and from the replicas, what stops during failover, discrepancies and omissions in the documentation.

This article does not cover the following. These topics are addressed in other articles on this site, or in other articles in the same series.

The acceptance of the alg parameter by each JWT recipient, as well as the general rules for inspecting iss, aud, and timestamps, are covered in "JWT Signing Algorithms on AWS Endpoints." This article only describes what changes when iss takes on two formats in an MRR environment.
The default alg settings in JWT libraries, and how to handle unknown keys in JWKS, are covered in "Which alg a JWT Library Accepts When You Do Not Say."
Procedures for integrating with external IdPs are covered in "Amazon Cognito Federation Complete Implementation Guide."
Overall multi-Region configurations and database replication are covered in "AWS Multi-Region Active-Active Architecture Guide."
Designing multi-Region keys in KMS is covered in "AWS KMS Envelope Encryption and Data Key Caching Patterns."
Potential pitfalls with Route 53 health checks are covered in "Route 53 Health Check and Failover."
A historical overview of Amazon Cognito features is covered in "AWS History and Timeline regarding Amazon Cognito."
What happens and what remains when traffic is shifted away from a single Availability Zone for several days is covered in a related article, Draining an Availability Zone for Days.
What happens when a replica leaves an Amazon DynamoDB global table is covered in a related article, Leaving an Amazon DynamoDB Global Table.

Cognito's identity pools (federated identities) are outside the scope of this article. MRR is a feature of user pools. This article will not cover pricing, feature plan comparisons, or a list of Regions where MRR is available. Refer to the "What's New" announcements in the References section for information on supported Regions.

1.3 The Check Date and the Sources Read

The information was verified on October 29, 2026. The materials reviewed are as follows:

Cognito Developer Guide (the UG in this article): Multi-Region replication for user pools, identity provider and relying party endpoints (regarding Amazon Cognito user pools as an OIDC issuer), Verifying JSON web tokens, Data protection, Quotas, Document history.
Cognito console help panel: Multi-Region replication, Issuer.
Cognito API Reference: CreateUserPoolReplica, UpdateUserPoolReplica, DeleteUserPoolReplica, ListUserPoolReplicas, UserPoolReplicaType, IssuerConfigurationType, KeyConfigurationType, CreateUserPool, UpdateUserPool, UpdateUserPoolDomain, AdminUpdateUserAttributes, GetTokensFromRefreshToken, RevokeToken, GetClientToken.
AWS CloudFormation Template Reference: AWS::Cognito::UserPoolReplica, AWS::Cognito::UserPoolRegionalConfigurationAttachment.
API Gateway Developer Guide: Control access to HTTP APIs with JWT authorizers, Troubleshooting issues with HTTP API JWT authorizers, Control access to REST APIs using Amazon Cognito user pools as an authorizer, x-amazon-apigateway-authorizer object, API Gateway V2 API Reference – Authorizer.
Elastic Load Balancing: Authenticate users using an Application Load Balancer, AuthenticateCognitoActionConfig.
AWS KMS Developer Guide: Deleting AWS KMS keys (regarding deleting multi-Region keys).
AWS Blogs: AWS Security Blog – Architecting resilient authentication with Amazon Cognito multi-Region replication (September 15, 2026), AWS News Blog – Improve your application resilience with Amazon Cognito multi-Region replication (June 3, 2026), AWS Security Blog – Amazon Cognito unlocks advanced capabilities with next-generation infrastructure (June 4, 2026).
What's New: Announcement regarding Multi-Region Replication (June 4, 2026), Announcement regarding expansion to AWS GovCloud (US) (October 21, 2026), Announcements regarding Cognito (August 26 and August 31, 2026) (dates refer to the postDateTime in the What's New API).
aws-jwt-verify: GitHub README, src/cognito-verifier.ts, package.json, Releases page.

This article will separate the text from Security Blog and News Blog from the text in the documents. When it references text from a blog, it indicates which blog it is from.

The record in Section 8 is based on observations made by creating a small configuration within an AWS account, specifically for the purpose of this article. This is not based on existing documentation, but rather on the setup itself and the records from that day.

1.4 Prerequisites for Enabling MRR

The "Things to know" section of the UG states that the user pool must be on the Essentials or Plus feature plan, and that MRR is not supported on the Lite plan. This article considers feature plans only as a requirement.

You can't enable MRR on user pools with the Lite feature plan.

The same section also describes KMS keys as follows:

You must configure your user pool with a multi-Region customer managed key from AWS KMS before enabling
replication. The key must be available in all AWS Regions that have user pool replicas.

The KeyConfigurationType in the API Reference, in the description for CUSTOMER_MANAGED_KEY, states that multi-Region keys are required for MRR. The "Data protection" page in the UG specifies that only symmetric keys can be used for user pool encryption, and that these keys must be located in the same Region as the user pool. The keys must be specified using their ARN, not an alias. The Security Blog indicates that users are responsible for managing this key (including key policies, rotation, and deletion). For key design guidance, refer to the AWS KMS Envelope Encryption and Data Key Caching Patterns on this site.

The handling of the "issuer" varies across documentation. In the same section of the UG, it recommends the following:

For consistent token validation across Regions, we recommend that you configure your
user pool with an updated issuer.

The "Multi-Region replication" page in the console's help panel lists it as one of the conditions required to enable MRR. These differences will be outlined in Section 9.

To enable MRR, your user pool must be on the Essentials or Plus feature plan, use a
multi-Region customer managed AWS KMS key, and have a multi-Region OIDC issuer configured.

1.5 Words with the Same or Similar Spelling, Different Meanings

This article discusses terms that share the same or similar spellings but refer to different concepts.

Replica: In this article, "replica" refers specifically to a user pool within Cognito. It is distinct from replicas of DynamoDB global tables, replica keys of KMS multi-Region keys, or read replicas in Amazon RDS. This article calls a KMS replica key a key, to differentiate it.
Primary: The "primary" user pool in Cognito and the "primary" key in a KMS multi-Region key are distinct. In Section 8 of this article, both are configured in the same Region.
Secondary: UG sometimes refers to a replica pool as a "secondary" user pool. The Role value in the API's UserPoolReplicaType can be either PRIMARY or SECONDARY. Throughout this article, the text uses "replica" to refer to a pool, and reserves secondary for regional designations (e.g., "secondary Region") and for the specific values in the API.
Issuer: The "issuer" (the value of the iss claim in tokens) within a Cognito user pool, the issuer of an external Identity Provider (IdP) integrated with Cognito, and the "issuer" setting within an API Gateway JWT authorizer are all distinct. In this article, "original" and "updated" refer to the Type values ORIGINAL and UPDATED in the API's IssuerConfigurationType.
Failover: In this article, "failover" refers to shifting traffic from a primary pool to a replica pool. It is separate from database failover or the routing records used in Route 53 failover.

2. How to Read the Tables

This section defines the columns in the tables from Section 3 through Section 9, as well as how to describe the condition of the materials. These columns and terms will be used consistently throughout the series.

2.1 Five Columns

The tables in Sections 3.4, 6.4, and 7 have the following five columns; the tables in Sections 3.3, 5.6, 8.2, and 9 use their own columns. Some tables add a first column for what the row is about, and a failback column after Who Acts.

What Moves: Items that apply across Regions, are replicated, or are transferred.
What Stays: Items that remain in the primary or original Region.
Who Acts: The entity that initiates the action. This could be Cognito, an application, an operator, or the owner of the validator. In the prose, "you" means the operator or the owner of the application.
Where It Is Written: The source of the statement in that row. For blog posts, it names which blog the statement originates from.
No Statement Found: Instances where, despite searching the materials referenced in Section 1.3, using different search terms and material categories, no relevant statement was found. If there is nothing, the cell shows —.

A non-empty No Statement Found entry does not indicate that the item or event does not exist or will not occur.

2.2 Four States

The condition of the information is described using the following four terms:

No statement was found: This indicates that the information was not found in the examined material. The text writes no statement was found and adds the scope of the search.
The documentation does not list: This means that the item is not included in the lists or tables. The text writes the documentation does not list.
The sources disagree: The text writes the sources disagree and lists both statements and their sources. This article does not definitively identify either as incorrect.
Inference: This refers to a conclusion drawn by this article, rather than a statement found in any specific source. The same sentence states that it is this article's reading.

2.3 The Word for Authority

This article refers to the role of the primary pool as its "write authority." UG designates the primary pool as follows:

The primary user pool serves as the authoritative source for administrative configuration and write operations
such as password resets and user sign-up. Secondary user pools can't create users.

Write authority defines the scope of writes that only the primary pool can accept. Settings that can be written using replicas are configured on a Region-by-Region basis (see Section 3.2). When referring to requirements, this article uses the term "requirement," and when referring to recommendations, it uses the term "recommendation," ensuring that these two terms are not mixed.

3. Same ID, Separate Pools

This section details the relationship between the two pools created by MRR, outlines Region-specific configurations, describes the status of replicas, and lists the operations that replicas can accept based on their respective states.

3.1 Two User Pools That Share One User Pool ID

UG describes the MRR as follows:

When you configure MRR, Amazon Cognito creates separate user pools with a shared user pool ID.
Each replica user pool hosts authentication services for a shared user directory.

The two pools have the same user pool ID but different ARNs. In UG's example of CreateUserPoolReplica, the primary pool is located in us-east-1 and the replica pool is in us-west-2. The replica pool's ARN is returned as follows. The Region in the ARN reflects the replica pool's Region, while the prefix for the user pool ID remains associated with the primary pool's Region.

arn:aws:cognito-idp:us-west-2:111122223333:userpool/us-east-1_EXAMPLE

The Security Blog describes what is replicated to the replica pool as follows:

The primary user pool (the user pool in your primary Region) remains authoritative, and its configurations
(app client IDs, client secrets), user data (attributes, hashed credentials, group memberships), and external
identity provider (IdP) settings are replicated to the replica with eventual consistency.

UG also states that the replication results in eventual consistency, and that a short delay may occur. The magnitude of this delay is not specified in the material in Section 1.3; the What's New announcement and the Security Blog say "near real-time" without a figure.

Data replication between Regions might introduce brief delays. The primary user pool
syncs settings and user-directory updates to the secondary, and this process is
eventually consistent.

3.2 Seven Per-Region Settings

UG lists seven items that can be configured independently for replicas, while other settings are configured in the primary and then synchronized to the replicas. These seven items are: email settings, threat protection notification email settings, SMS settings, Lambda triggers, tags, log export settings, and AWS WAF web ACLs.

Regional configurations can differ between replicas. You can configure the following
settings independently in replicas. All other settings are set in the primary user pool
and automatically synchronized to the secondary.

The API's UpdateUserPool documentation explains how to configure these settings for replicas. When calling UpdateUserPool within a replica's Region, you can update only the Region-specific settings. For common settings, you must pass existing values.

In secondary regions for user pools with multi-region replication, regional
configurations for email, SMS, Lambda functions, and tags can be updated. Both global
and regional settings must be provided as inputs, with global settings required to match
existing values to maintain consistency across replicas.

The same documentation states that for secondary Regions, the issuer configuration (IssuerConfiguration) and encryption key settings (KeyConfiguration) must match existing values and cannot be changed. In AWS CloudFormation, you create an AWS::Cognito::UserPoolRegionalConfigurationAttachment resource in the replica's Region. This resource holds the email, SMS, Lambda trigger, tag, and replica status information. The documentation specifies that this resource should be created after the replica has reached an ACTIVE or INACTIVE state.

The Security Blog notes that services like Lambda, AWS WAF, Amazon SNS, Amazon SES, and Amazon CloudWatch are Region-specific and must be configured separately within each replica's Region. For example, a Lambda trigger should have its function located in the replica's Region and connected to the replica's user pool.

3.3 Replica States

The API's UserPoolReplicaType describes the replica's Status using four possible values:

`Status`	API Reference Description
`CREATING`	The replica is being created.
`INACTIVE`	The replica has been created, but is not accepting requests for end-users. Administrator configuration operations are supported.
`ACTIVE`	The replica is available for both end-user and administrator operations.
`DELETING`	The replica is being deleted.

The UG states that new replicas begin in the INACTIVE state and that after verifying Region-specific settings, they should be activated for production use. The transition between ACTIVE and INACTIVE is performed using the UpdateUserPoolReplica operation. The API documentation indicates that this operation accepts two possible values for its Status: ACTIVE and INACTIVE, and that the operation can be called from both the primary and secondary Regions.

This request can be made in both primary and secondary regions of the user pool.

Even when a replica is set to ACTIVE, traffic will not automatically be routed to it. ACTIVE simply indicates that the replica is ready to accept requests from end-users; the actors described in Section 6 determine the routing of traffic.

3.4 Operations a Replica Accepts in Each State

The UG section "Supported API operations in secondary Regions" lists the operations available for INACTIVE replicas and those added for ACTIVE replicas, outlining the following rule.

Operations that aren't listed here are only available in the primary Region.

When categorized by type, the information is summarized in the following table.

Operation Group	Examples from the UG List	`INACTIVE` Replica	`ACTIVE` Replica	Primary
Read user pool configuration and users	`DescribeUserPool`, `DescribeUserPoolClient`, `ListUsers`, `AdminGetUser`, `ListGroups`	Yes	Yes	Yes
Set per-Region settings and replica state	`UpdateUserPool`, `SetLogDeliveryConfiguration`, `AssociateWebACL`, `TagResource`, `UpdateUserPoolReplica`	Yes	Yes	Yes
Other configuration listed for replicas	`SetUserPoolMfaConfig`, `SetRiskConfiguration`, `CreateUserPoolDomain`, `UpdateUserPoolDomain`	Yes	Yes	Yes
Sign-in and token issue	`InitiateAuth`, `RespondToAuthChallenge`, `AdminInitiateAuth`, `GetTokensFromRefreshToken`	No	Yes	Yes
Sign-out and revocation	`RevokeToken`, `GlobalSignOut`, `AdminUserGlobalSignOut`	No	Yes	Yes
Read the signed-in user	`GetUser`, `GetUserAuthFactors`, `ListDevices`, `ListWebAuthnCredentials`	No	Yes	Yes
Create users	`SignUp`, `AdminCreateUser` (not in the UG list)	No	No	Yes
Change user attributes and passwords	`UpdateUserAttributes`, `AdminUpdateUserAttributes`, `ForgotPassword`, `ChangePassword` (not in the UG list)	No	No	Yes
App clients and groups	`CreateUserPoolClient`, `UpdateUserPoolClient`, `CreateGroup` (not in the UG list)	No	No	Yes
Operations the UG list does not include	`GetClientToken` (2026-08-31), `AdminDeleteSoftwareToken` (2026-08-26)	The documentation does not list	The documentation does not list	Yes

The two operations in the last row are not listed in the UG. GetClientToken is an operation to obtain machine-to-machine (M2M) access tokens without using the user pool domain, as announced in the What's New section dated August 31, 2026. AdminDeleteSoftwareToken is an operation where an administrator deletes a user's TOTP (Time-based One-Time Password) settings, as announced in the What's New section dated August 26, 2026. Read literally, the UG rule that operations not listed are only available in the primary Region makes these two primary-only; whether the list has been updated for them is not stated (no statement was found). The UG list carries no date of its own, and the dates of GetClientToken differ by source: the UG Document history dates its entry July 29, 2026, and the What's New postDateTime is August 31, 2026 (the sources disagree).

The Security Blog describes the response when attempting a write operation on a replica as follows:

Amazon Cognito returns an `Action temporarily unavailable` error when using managed login, or an
`OperationNotEnabledException` when using an AWS SDK for those operations.

OperationNotEnabledException is not a dedicated exception for replicas. The API Reference describes this exception as follows:

This exception is thrown when an operation is not available in the current region or for the current user pool
configuration. This can occur when attempting to perform operations that are not supported in secondary replica
regions.

This description appears on pages for GetTokensFromRefreshToken and RevokeToken, which are available on ACTIVE replicas, as well as on pages for GetClientToken and AdminUpdateUserAttributes, which are not listed. It is not possible to determine whether an operation is available on a replica based on the error list on the API pages. The UG list is the place to check.

The following table organizes the content of this section into five columns.

Item	What Moves	What Stays	Who Acts	Where It Is Written	No Statement Found
Users, hashed credentials, group memberships, app client IDs and secrets, external IdP settings	Replicated to the replica with eventual consistency	Created and changed only in the primary	Cognito replicates; writes go to the primary	UG introduction and Things to know; AWS Security Blog (2026-09-15)	Replication delay values
Seven per-Region settings	Nothing; each Region keeps its own	Set separately in each Region	Operator, in the replica Region (for example `UpdateUserPool` there, or the CloudFormation attachment)	UG Things to know (seven); `UpdateUserPool` API page (email, SMS, Lambda functions, and tags)	—
Issuer and encryption key configuration	Synchronized from the primary	Cannot be modified in a secondary Region	Operator, in the primary	`UpdateUserPool` API page	—
Sign-in, token issue, refresh, and revocation	Accepted by the replica while it is `ACTIVE`	—	Operator sets `ACTIVE` with `UpdateUserPoolReplica`	UG Supported API operations in secondary Regions	How a revocation in one Region reaches the other
Sign-up, admin user creation, attribute updates, password reset	—	Primary only	—	UG Limitations; AWS Security Blog	—
Operations the UG list does not include	The documentation does not list	Primary only, by the UG rule	—	UG list; UG Document history (2026-07-29); What's New (2026-08-26, 2026-08-31)	Whether the list will add them

4. Which Issuer a Token Carries

This section outlines the two formats of the token's iss (issuer) value, specifies the locations where the corresponding JWKS and discovery documents are stored, and describes what gets mixed when the format is changed.

4.1 Two Formats

The API's IssuerConfigurationType can be defined in two formats: ORIGINAL and UPDATED. This article lists these two formats as follows. In the updated format, region is the primary Region (for original, see Section 4.3).

ORIGINAL: https://cognito-idp.<region>.amazonaws.com/<userPoolId>
UPDATED:  https://issuer-cognito-idp.<region>.amazonaws.com/<userPoolId>

Regarding the updated format, the API documentation states:

Updated issuers have the format of
`https://issuer-cognito-idp.[region].amazonaws.com/[userPoolId]`, where region is the
primary AWS Region of your user pool.

The section on UG's Amazon Cognito user pools as an OIDC issuer describes the original format as the current default, and the updated format as the recommended option. The former is referenced in the "Original issuer" section, while the latter is referenced in the "Updated issuer" section.

The current default issuer configuration for user pools. The issuer
URL is hosted in the user pool's Region and provides OIDC endpoints specific to that Region.

Recommended for all user pools, including for multi-Region
replication. Updated issuers host the same JWKS content in multiple Regions,
resulting in improved resilience and efficiency.

The Security Blog states that MRR can be enabled even when using the original format. The format of the issuer is determined by the primary CreateUserPool or UpdateUserPool's IssuerConfiguration (as described in Section 3.2, it cannot be changed in replica Regions).

4.2 Where the JWKS and Discovery Documents Live

The Security Blog states that discovery documents are located at <iss>/.well-known/openid-configuration and JWKS are located at <iss>/.well-known/jwks.json, noting the difference lies in where these URLs are provided. Regarding the original configuration, the Security Blog writes:

The `original` issuer type follows the format as `https://cognito-idp.<region>.amazonaws.com/<userpool_id>`.
However, this issuer URL format and the OIDC well-known metadata are regional resources.

Concerning configurations that use MRR with the original issuer, the Security Blog states:

However, in this configuration the OIDC discovery endpoint and JWKS endpoint are tied to a single Region and
might be unavailable during a regional impairment. Your multi-Region application might not be able to fetch
public keys dynamically and validate token signatures.

The same blog recommends, as a mitigation strategy in this scenario, caching signature keys at the validation layer according to the Cache-Control header, and continuing validation with the cached keys even when the JWKS endpoint is unavailable. Regarding the updated configuration, it states that both the JWKS and discovery documents are consistently accessible regardless of which Region processes the request.

When Cognito documentation and blogs discuss cross-Region functionality, it is important to confirm the subject being referenced. The Security Blog writes:

JSON web tokens (JWTs) and active sessions are interoperable between Regions; for example, a refresh token issued
by the primary Region is accepted in the replica Region to retrieve new ID and access tokens.

The example provided in this passage refers to a scenario where the entity accepting the refresh token is a Cognito endpoint. The News Blog also states that both Regions recognize access tokens issued from either Region. Neither passage states that the validator, which the user has placed in front of their own API, will accept tokens issued by replicas. The conditions outlined in Section 5 determine whether the validator accepts tokens.

4.3 What Gets Mixed When You Change the Format

The issuer's format can be changed, both before and after MRR is enabled. The Security Blog states that after changing the format, newly issued tokens will have the new format, while tokens with the old format remain valid at the Cognito endpoint until their expiration.

You can change the issuer type at any stage in your MRR journey, and the newly issued tokens, including those
generated by refresh tokens, will reflect the most current issuer type configurations.

Plan this as a coordinated deployment; existing ID and access tokens with the `original` issuer `type` remain
valid and accepted by Amazon Cognito endpoints until they expire.

In other words, for a period after changing from the original to the updated format, the validator will receive iss values in both the old and new formats. Tokens with the old format will continue to be delivered until their expiration date. Tokens issued through refresh will have the new format. If the validator only accepts a single issuer value, it will reject tokens in one of the two formats. The Security Blog suggests planning this transition as a coordinated rollout alongside updates to the validator.

The News Blog, describing how to change the issuer's format in the console, writes the following. However, the blog does not specify whether the new endpoints it mentions are the discovery and JWKS URLs or other URLs, or what "no longer be routed correctly" means. In this article's setup, the cognito-idp discovery document still answered after the switch (Section 8.2).

I make sure to update my client applications with these new endpoints. This is a required change that will need
a redeployment of server-side applications and an update submission for mobile apps on the App Store and Google
Play. If I don't update the endpoints, my users will experience disruptions because requests to the old endpoints
will no longer be routed correctly.

The sources in Section 1.3 do not provide information (no statement was found) regarding whether the iss value of tokens issued by a replica, while still in the original format, points to the URL of the primary Region or the replica Region. No statement was found either on whether the primary and replica use the same signing key. The only clue is the statement that the updated format places the same JWKS across multiple Regions. In this article's setup, the iss was the primary Region's URL and the kid values were the same (Section 8.2).

Which Issuer a Token Carries, and Where the Validator Fetches Keys

5. What Each Validator Must Assume

This section will outline, for each validator, the issuer configuration, how to obtain the public key, and what information the validator's page contains regarding MRR and the updated format. For general rules regarding JWT inspection, refer to the JWT Signing Algorithms on AWS Endpoints article on this site.

5.1 Amazon API Gateway HTTP API JWT Authorizers

The HTTP API JWT Authorizer in API Gateway compares the token's iss value with the issuer configured for the authorizer.

`iss` – Must match the `issuer` that is configured for the authorizer.

In the API Gateway V2 API Reference, the JWTConfiguration section specifies that issuer is a single string, while audience is an array of strings. The example provided for issuer only shows the original format.

The base domain of the identity provider that issues JSON Web Tokens. For example,
an Amazon Cognito user pool has the following format:
`https://cognito-idp.{region}.amazonaws.com/{userPoolId}`.

Regarding public keys, the JWT authorizer page states that they are retrieved from the issuer's jwks_uri and cached for up to 2 hours.

API Gateway caches the public key for up to two hours on a best-effort basis. On a cache miss, API Gateway fetches
the public key from the issuer over the network, which adds latency to the request that triggers it.

None of the pages – this page, the JWTConfiguration page, the troubleshooting page, or the page describing the OpenAPI extension (x-amazon-apigateway-authorizer) – contain any mention of MRR or the updated format. The example on the OpenAPI extension page, which detects the issuer using openIdConnectUrl, also only shows the original format.

Based on these three points, a single authorizer compares against a single issuer value. Therefore, a single authorizer cannot accept both the original and the updated format while you move from one to the other (this article's reading; no API Gateway statement about this combination was found). Furthermore, no statement was found in the API Gateway documentation on whether it is permissible to set the updated value for the issuer, or on the Region from which the public keys should be retrieved. The Cognito UG page on verifying JSON web tokens does say that for an API Gateway HTTP API JWT authorizer you set the issuer to your user pool endpoint in the cognito-idp form, which is also the value of the issuer field in the pool's discovery document; it does not mention the updated form (no statement was found there). In this article's setup, the cognito-idp discovery document kept the original issuer after the switch (Section 8.2), so this article reads that sentence as describing the original form only (this article's reading). This article does not state that API Gateway rejects the updated format.

5.2 API Gateway REST API Cognito Authorizers

REST APIs with the COGNITO_USER_POOLS authorizer type are configured by specifying a user pool. No information regarding MRR, replicas, or the updated format was found on this page.

5.3 Application Load Balancer Authentication Actions

Application Load Balancer offers two authentication actions: authenticate-cognito, which specifies a Cognito user pool, and authenticate-oidc, which specifies a generic OIDC Identity Provider (IdP). Regarding the updated format and the authenticate-cognito action, the Cognito UG describes it as follows:

The updated issuer type isn't compatible with the native Amazon Cognito
integration for Application Load Balancer authentication (the
`authenticate-cognito` action). To use an updated
issuer with an Application Load Balancer, configure the generic OIDC
integration (the `authenticate-oidc` action) instead, and
provide your user pool's OIDC endpoints.

This note is in the Cognito UG. However, a review of the Elastic Load Balancing documentation on "Authenticate users using an Application Load Balancer" and the API Reference documentation for AuthenticateCognitoActionConfig reveals no mention of MRR or the updated format. The authenticate-cognito action requires specifying the user pool using its ARN and the domain using either a prefix or a fully qualified name. Similarly, no statement was found describing the behavior when specifying the ARN of a replica.

The token included in the x-amzn-oidc-data header, which the Application Load Balancer passes to the backend, is signed by the load balancer itself and is distinct from the concept of a Cognito issuer.

5.4 aws-jwt-verify

AWS Labs' aws-jwt-verify README describes the CognitoJwtVerifier's userPoolId as follows:

`userPoolId` (mandatory): the Cognito User Pool ID. The issuer (`iss`) and `jwksUri` will be determined from this.
There is seamless support to check both the original and updated OIDC issuer required for user pools with
multi-Region replication.

On the GitHub releases page, support for two formats is documented in the release notes for version 5.2.0 of aws-jwt-verify, under the item support both region and global Cognito issuer URLs (published on June 5, 2026, at 00:14 UTC). Version 5.2.1 of aws-jwt-verify was also released on the same day, and its release notes highlight a fix for CognitoJwtVerifier.hydrate(). The Security Blog recommends using version 5.2.1 or later. On the check date, the version in package.json was 5.2.1.

The source code, located in src/cognito-verifier.ts, constructs the two formats of issuer URLs from the Region in the user pool ID prefix. Both the original and updated formats of the issuer URL include the primary Region. Comments in the source code refer to these two formats as Region format and Global format. These two names are specific to the library and are not used in Cognito's documentation.

const globalFormatIssuer = `https://issuer-cognito-idp.${p.userPoolId.split("_")[0]}.amazonaws.com/${p.userPoolId}`;

The URL for the JWKS (JSON Web Key Set) also includes /.well-known/jwks.json appended to the issuer value. aws-jwt-verify retrieves the JWKS for the original format tokens from the primary Region's cognito-idp endpoint. In this article's setup (Section 8.2), the iss claim of the tokens issued by the replica used a URL from the primary Region, which aligns with this construction.

5.5 Your Own Validation

The Cognito UG page on verifying JSON web tokens specifies that the iss claim should match the user pool, and provides examples formatted as original.

The issuer (iss) claim must match your user pool. For example, a user pool created in the
us-east-1 Region has the following iss value: https://cognito-idp.us-east-1.amazonaws.com/<userpoolID>.

The same page also details that the JWKS URI should be formatted as cognito-idp, and that public keys should be cached using the kid as a key. If a token arrives with a valid issuer but an unrecognized kid, the JWKS should be refreshed. This page does not include any descriptions related to MRR or the updated format. The introductory table on the UG page regarding Identity Provider and Relying Party endpoints also lists discovery and JWKS URLs using only the cognito-idp format. A later section on the same page does, however, describe the updated format.

For your own validation to support the updated format, it must add the updated format to the issuer values it accepts, and either construct the JWKS URL from the token's iss claim, or require URLs for both formats (this article's reading). During the transition period, it will be necessary to support both formats.

5.6 The Validator Table

Validator	Issuer Setting	Where It Gets Keys	What It Must Assume Under MRR	Where It Is Written	No Statement Found
API Gateway HTTP API JWT authorizer	One `issuer` string; `iss` must match it	Issuer's `jwks_uri`; cached up to two hours	Accepts one issuer format per authorizer (this article's reading)	API Gateway Developer Guide; API Gateway V2 API Reference	Whether `updated` may be set as `issuer`; MRR in any API Gateway page
API Gateway REST API `COGNITO_USER_POOLS` authorizer	User pool chosen in the authorizer	—	—	API Gateway Developer Guide	MRR, replicas, and `updated`
ALB `authenticate-cognito`	User pool ARN, client ID, and domain	—	Not compatible with `updated`	Cognito UG, OIDC issuer section	MRR in ELB pages; behavior with a replica ARN
ALB `authenticate-oidc`	Issuer and endpoints entered by the operator	IdP endpoints you provide	The path the Cognito UG names for `updated`	Cognito UG, OIDC issuer section	MRR in ELB pages
aws-jwt-verify `CognitoJwtVerifier`	Both formats, built from the user pool ID prefix	`<iss>/.well-known/jwks.json`	Use version 5.2.1 or later (AWS Security Blog)	README; `src/cognito-verifier.ts`; release notes	—
Your own code following the UG	`iss` must match your user pool	JWKS URI; cache by `kid`	Add the `updated` format and accept both during the change (this article's reading)	Cognito UG, Verifying JSON web tokens	MRR and `updated` in that page

To check the format by reading the iss value, you can use the JWT Decoder Tool on this site to open the token's payload.

6. Who Moves Traffic to the Replica, and Who Moves It Back

This section lists, for each traffic path, the entities responsible for migrating traffic to replicas and the entities responsible for returning traffic to the primary.

6.1 Paths Through the User Pool Domain

The UG's section on Failover in multi-Region user pools describes the failover process for managed login, federation, and M2M authorization, specifically when traffic routes through a user pool's domain. This domain can be a custom domain or a prefix domain. The domain provides OAuth 2.0 resources, including the authorize and token endpoints, and receives responses from external Identity Providers (IdPs).

To enable failover, create a Route 53 health check and pass it to the Routing configuration of the domain. In the API, pass the SecondaryRegion and PrimaryRoute53HealthCheckId to the Failover setting in the Routing section of the UpdateUserPoolDomain call. The UG details the switchover and failback processes.

To enable failover, set up a health check in Route 53
and set the `Routing` field on your domain. You determine what triggers a
healthy or unhealthy state. When the health check is in an unhealthy state, Amazon Cognito serves
managed login pages and authentication operations from the secondary replica user pool.
When the health check enters a healthy state, Amazon Cognito begins routing traffic back to the
primary replica.

In this routing path, Cognito is responsible for shifting and reverting traffic. Cognito monitors the health check status, and you determine how that status is defined. The Security Blog provides examples, including connecting the health check to a CloudWatch Synthetics canary alarm and attempting a switchover by inverting the health check status during maintenance windows. For detailed information on designing health checks, refer to the Route 53 Health Check and Failover article on this site.

The UG notes that it is not possible to configure a different custom domain for the replica.

You can't configure a different custom domain with replica user pools.

The Security Blog explains that, because a single domain receives traffic from both Regions, you can avoid changing the redirect URIs registered with external IdPs or the SAML ACS URLs. If M2M client credentials traffic also passes through the domain's /oauth2/token endpoint, it will be routed through this path as well.

6.2 SDK and API Paths

Regarding applications that directly call Cognito using the SDK or API, the UG states the following:

If you use the Amazon Cognito APIs or SDKs, there's no usage of a custom domain and your
application is responsible for routing traffic to the Amazon Cognito service regional endpoint to
handle authentication and other API calls.

In this path, the application is responsible for shifting traffic and shifting it back. The UG says that if using both managed login and the API, the same Route 53 health check should be used to determine the API endpoint Region. The Security Blog suggests configuring a custom endpoint for SDK requests, which then routes traffic to the appropriate regional endpoint.

The UG's Limitations section advises stopping password resets and profile changes in the user interface during failover, and re-enabling them once the health check redirects traffic back to the primary Region. In the SDK path, the application determines whether to send write requests to the primary Region or to halt them (this article's reading).

The M2M path using GetClientToken does not use a domain. As Section 3.4 notes, this operation is not listed in the UG (the documentation does not list it).

6.3 AWS GovCloud (US) Regions

As of October 21, 2026, MRR support was expanded to the AWS GovCloud (US) Regions. The UG states that these Regions do not offer automatic failover using Route 53 health checks.

Amazon Cognito doesn't currently support automatic failover with a Route 53 health check in the
AWS GovCloud (US) Regions. You can't set the `Routing` field on a user pool
domain, and custom domains aren't available.

The UG further explains that within these Regions, a unique prefix domain must be created for each replica, and traffic between these domains must be managed manually. When configuring external Identity Providers (IdPs), it is necessary to include the redirect URL for the secondary domain. Before routing traffic to the secondary Region, ensure that the replica is set to the ACTIVE state. The UG details the handling of passkeys and failback in this section.

Passkeys – Passkeys that users registered on the
primary domain don't work on the secondary domain, because the relying party ID is
different for each domain.

Failback – Amazon Cognito doesn't route traffic back to
the primary Region. When the primary Region is available again, update your
application to send traffic to the primary domain.

These two paragraphs pertain to the GovCloud section. In commercial Regions, as described in Section 6.1, Cognito will begin routing traffic back to the primary Region once health checks return to a normal state. Refer to this site's article "Passkeys and WebAuthn in Practice" for information on the relying party ID for passkeys.

6.4 The Path Table

Path	What Moves	What Stays	Who Acts	Failback	Where It Is Written	No Statement Found
Managed login, federation, and OAuth 2.0 endpoints through the user pool domain (commercial Regions)	Requests on the same domain go to the replica while the health check is unhealthy	The domain name and IdP redirect settings	Cognito, following a Route 53 health check that you define	Cognito begins routing back when the health check is healthy	UG Failover section; `UpdateUserPoolDomain` API	—
Client credentials through the domain's `/oauth2/token`	Same as above	Same as above	Cognito, following the health check	Same as above	UG Failover section; AWS Security Blog	—
SDK and API calls to Regional endpoints	Whatever your routing sends to the replica Region	—	Your application	Your application	UG Failover for APIs and SDKs	—
`GetClientToken` for M2M without a domain	The documentation does not list it for replicas	—	Your application	Your application	What's New (2026-08-31); UG list	Whether it runs in a replica
AWS GovCloud (US)	Traffic you send to the replica's own prefix domain	—	You	You (Cognito does not route back)	UG Failover in the AWS GovCloud (US) Regions	—
Replica state	—	—	Operator, with `UpdateUserPoolReplica` from either Region	Operator	`UpdateUserPoolReplica` API	—

7. What Stops During Failover

This section lists the things that become unavailable to users and applications while traffic is routed to a replica.

The UG's "Limitations" section states that it is not possible to create new users through the replica. This applies whether it is a sign-up or creation by an administrator. The same section describes federated users as follows:

Federated users can only sign in to a secondary user pool in the failover state if they have previously signed
in to the primary user pool.

The Security Blog states that when a federated user signs in to the primary for the first time, Cognito creates the user, and if the user already exists, it updates the user's attributes. The blog also states that creating users and updating attributes within a replica pool will fail until the health check returns to normal and traffic is routed back to the primary. This aligns with the limitations described in the UG (this article's reading).

TOTP-based MFA is not available on replicas. The UG states:

TOTP MFA is not supported in secondary replicas. Users with TOTP MFA configured must
authenticate when the user pool in the primary Region is servicing requests.

The Security Blog advises applications that use TOTP as a second factor to provide alternative MFA methods, such as SMS OTP, email OTP, or passkeys. The ability for an administrator to delete a TOTP configuration using AdminDeleteSoftwareToken is also not listed in the UG (as detailed in Section 3.4).

The number of password failures before lockout is not synchronized across Regions. The UG states that the replica counts the number of failures individually.

Quotas are also Region-specific. The Security Blog notes that activating a replica assigns a different default quota to the replica's Region, and quota increases made on the primary are not propagated to the replica. The UG Quotas page states that quota increases are regional configurations and that you request them in each Region separately.

Previously reserved higher quotas for your user pool in the primary Region aren't carried over to the replica
Region.

Lambda triggers, AWS WAF web ACLs, and SES and SNS configurations are Region-specific, as detailed in Section 3.2. If you are adding claims to a request using the pre-token generation trigger, the claims in the tokens issued by the replica will differ from those issued by the primary, unless the replica's Region trigger provides the same claims. This could lead to different authorization decisions made by APIs that rely on those claims, depending on the Region (this article's reading). No statement was found in the material from Section 1.3 regarding whether the trigger event includes an indicator of which Region's pool initiated the request.

Item	What Moves	What Stays	Who Acts	Where It Is Written	No Statement Found
Sign-up and admin user creation	—	Primary only	—	UG Limitations	—
First sign-in of a federated user	—	Needs the primary	—	UG Limitations; AWS Security Blog	—
Password reset and profile changes	—	Primary only	Your application disables them in the UI during failover (UG)	UG Limitations	—
TOTP MFA	—	Primary only	Your application offers another MFA (AWS Security Blog)	UG Limitations; AWS Security Blog	—
Lockout counts	—	Counted per replica	—	UG Limitations	—
Raised quotas	—	Not carried over to the replica Region	Operator, in the replica Region	UG Quotas; AWS Security Blog	—
Lambda triggers, AWS WAF, SES, SNS	—	Configured per Region	Operator, in the replica Region	UG Things to know; AWS Security Blog	A Region field in trigger events

8. What This Setup Showed

This section documents observations made using a small setup created specifically for this article, within an AWS account. It is a record of this particular setup and the events of this day, rather than a statement from the sources. It is not used for performance comparisons or evaluations.

8.1 Setup

The primary is located in us-east-1, and the replica is in us-west-2. A multi-Region symmetric key was created in us-east-1 using KMS, and a replica key was created in us-west-2. The user pool is configured with the Essentials feature plan, and data is encrypted using this key. The issuer type was original. One application client (without a secret) and one test user were created. This setup did not create any domains, Route 53 health checks, Lambda triggers, or AWS WAF configurations. Observations were conducted between 10:34 AM and 10:53 AM (UTC) on October 29, 2026. Tokens were decoded on the spot, and only the iss, kid, and token_use values were retained; the tokens themselves were not stored. Account IDs, user pool IDs, client IDs, ARNs, and key IDs have been redacted. The kid values are not included; only whether or not they matched is recorded.

8.2 What Was Observed

The following table lists observations made in this article's setup, along with corresponding descriptions from the relevant materials. Here, "kid" refers to the key for the ID token as "K1" and the key for the access token as "K2."

Observation	Result in This Setup	What the Sources Say
`Status` in the `CreateUserPoolReplica` response	`CREATING`	UG and API examples show `PENDING_CREATE`; `UserPoolReplicaType` lists `CREATING`, `ACTIVE`, `INACTIVE`, `DELETING`
Replica state over time	`CREATING`, then `INACTIVE` about 4.5 minutes later; `ACTIVE` at the first poll after `UpdateUserPoolReplica` (polled every 20 seconds)	New replicas start in `INACTIVE` (UG)
`ListUserPoolReplicas`	Two entries: the primary (`PRIMARY`, `ACTIVE`) and the replica (`SECONDARY`)	Lists both primary and secondary replicas (API)
`KeyConfiguration` returned by `DescribeUserPool` in the replica Region	The ARN of the primary key in `us-east-1`, not the replica key	No statement was found (the UG Data protection page says the key is in the same Region as the user pool)
`InitiateAuth` against the `INACTIVE` replica	`OperationNotEnabledException`: `This operation is not enabled in this region for this User Pool`	Sign-in operations are added only in `ACTIVE` (UG)
`AdminUpdateUserAttributes` against the replica (`INACTIVE` and `ACTIVE`); `AdminCreateUser` against the `ACTIVE` replica	`OperationNotEnabledException` with the same message	Not in the UG list for replicas
`UpdateUserPool` in the replica Region with `IssuerConfiguration` changed	`InvalidParameterException`: `The following settings can only be modified in the primary user pool: issuerConfiguration`	Cannot be modified in secondary Regions (`UpdateUserPool` API page)
`iss` of ID and access tokens issued by the replica, `original` issuer	`https://cognito-idp.us-east-1.amazonaws.com/<userPoolId>`, the same value as tokens issued by the primary	No statement was found
`kid` of tokens from the primary and the replica	Same in both Regions (`K1` for ID tokens, `K2` for access tokens)	No statement was found
Refresh across Regions	A primary refresh token worked at the replica and a replica refresh token worked at the primary; no new refresh token was returned	Refresh tokens from the primary are accepted in the replica Region (AWS Security Blog)
`https://cognito-idp.us-west-2.amazonaws.com/<userPoolId>/.well-known/jwks.json`	HTTP 200 with `K1` and `K2`	Not listed as an endpoint in the sources read
`https://cognito-idp.us-west-2.amazonaws.com/<userPoolId>/.well-known/openid-configuration`	HTTP 400	—
`issuer-cognito-idp.us-east-1` JWKS and discovery while the issuer was still `original`	HTTP 200; `issuer` in the `updated` format; `K1` and `K2`	No statement was found
`issuer-cognito-idp.us-west-2` with the same user pool ID	HTTP 403 for JWKS and discovery	—
After switching the primary to `UPDATED`	The replica's `DescribeUserPool` showed `UPDATED` within 120 seconds; tokens from both Regions carried `https://issuer-cognito-idp.us-east-1.amazonaws.com/<userPoolId>`; `kid` values unchanged	New tokens carry the current issuer format (AWS Security Blog)
A refresh token obtained under `original`, used after the switch	New ID and access tokens in both Regions carried the `updated` format	Tokens generated by refresh tokens reflect the current issuer type (AWS Security Blog)
`cognito-idp.us-east-1` discovery document after the switch	HTTP 200; `issuer` still in the `original` format	—
`DeleteUserPoolReplica` called first in the replica Region, after setting the replica to `INACTIVE`	From the replica Region: `ResourceNotFoundException` (`Replica not found in the requested region`). From the primary Region: accepted; `DELETING`, then gone from the list about 5 minutes later	The API page says to call it from the primary Region; the UG lists it for `INACTIVE` secondary Regions

Five observations follow from this record, all specific to this setup and this day:

The iss (issuer) value of the tokens issued by the replica, under the original issuer, corresponded to the URL of the primary Region. The kid values were also identical across both Regions. In this setup, a validator configured with the primary Region's original issuer and JWKS would find a matching iss value and a known kid in tokens issued by the replica (this setup did not verify signatures). However, as noted in the Security Blog, the original's JWKS is tied to a single Region, and this setup has not been tested under circumstances where the primary Region is unavailable.
A JWKS URL in the format cognito-idp.us-west-2 also returned the same keys. This URL is not listed as an endpoint in the sources in Section 1.3. Whether the validator can rely on this URL cannot be determined from the sources (this article's reading).
The URL for the updated issuer only responded from hostnames that included the primary Region's name, while URLs in the format issuer-cognito-idp.us-west-2 returned a 403 error. Based on the documentation, the statement about placing the same JWKS across multiple Regions could be interpreted as providing the JWKS from multiple Regions behind the same hostname (this article's inference). This setup does not verify which Region is responding.
Even after changing the issuer, the kid (key ID) remained unchanged. Only the value of iss changed. Prior to changing the issuer, URLs in the format issuer-cognito-idp were already returning both JWKS and discovery documents. In this article's reading, this setup would therefore have allowed a validator to be configured for the updated value before the issuer was changed (no validator was run in this setup).
Operations that the replica could not perform consistently returned the same exception and message, regardless of the state. The exception name and message do not allow for distinguishing whether the replica's state is the cause, or whether the operation itself is simply unsupported by the replica. Changing the issuer resulted in a different exception (InvalidParameterException).

8.3 What This Setup Does Not Show

This record does not show:

Switching and reverting of paths as traffic traverses domains. This setup does not include domain routing or health checks.
Combinations of different Regions, different accounts, or activity on different days.
How revocation propagates between Regions.

9. Where the Sources Disagree, Count Differently, or Are Silent

This section lists discrepancies in the data from Section 1.3, including instances where descriptions disagree with each other, where the same items are counted differently, and information that is not included. This section aims to identify these differences without assuming that any one source is definitively incorrect.

9.1 Is the `updated` Issuer a Recommendation or a Requirement

Source	What It Says About the Issuer
UG, Multi-Region replication	`we recommend that you configure your user pool with an updated issuer`
UG, OIDC issuer section	Updated issuer: `Recommended for all user pools, including for multi-Region replication.`
API Reference, `IssuerConfigurationType`	`UPDATED`: `Recommended for all user pools, including for multi-Region replication.`
Console help panel, Issuer	Updated issuer: `Recommended for all user pools, including for multi-Region replication.`
Console help panel, Multi-Region replication	Lists `have a multi-Region OIDC issuer configured` among what MRR needs
AWS Security Blog (2026-09-15)	Recommends adopting the `updated` issuer type; states that MRR can also be enabled while the issuer stays `original`
AWS News Blog (2026-06-03)	The console step for the issuer is shown as `Step 2 – optional`

Among the sources in Section 1.3, only the Multi-Region replication help panel states that using an updated issuer is a requirement; outside them, the Cognito pricing page also says that MRR requires a multi-Region OIDC issuer configuration "(if applicable)". The other documentation refers to it as a recommendation, and the Security Blog indicates that MRR can also function with the original issuer (the sources disagree).

9.2 Launch Dates

Source	Date	What the Date Is
Cognito UG Document history	2026-05-28	Date of the documentation entry `Multi-Region replication for user pools.`
AWS News Blog	2026-06-03	Publication date of the launch post
What's New	2026-06-04	`postDateTime` of `Amazon Cognito now supports multi-Region replication`
AWS Security Blog (next-generation infrastructure)	2026-06-04	Publication date; lists MRR among the new capabilities
What's New	2026-10-21	`postDateTime` of the expansion to AWS GovCloud (US) Regions

This website's timeline for Cognito lists the MRR entry as May 28, 2026, which corresponds to the date in the UG Document history. The announcement dates are June 3 and June 4, representing different types of dates. As of October 29, 2026, the UG Document history does not include entries for the updated issuer or the expansion to GovCloud.

9.3 The Number of Replicas

The "Limitations" section of the UG, as well as the console's help panel, describe the number of replicas as follows:

You can have at most one secondary replica in an additional Region per user
directory.

You can create a maximum of 2 total replicas per user directory.

The Security Blog states that MRR can only have one additional replica Region. The help panel, on the same page, refers to the primary as The primary replica. The ListUserPoolReplicas API returns a list that includes both primary and secondary replicas, and in the example response, the primary itself is returned as an element with the Role set to PRIMARY. This can be read as the help panel's total including the primary replica, and the UG's count being of secondary replicas. This reading is this article's inference; the help panel does not explicitly state the counting method. The Cognito "Quotas" page does not list the number of replicas (the documentation does not list).

9.4 Which Region Calls `DeleteUserPoolReplica`

The DeleteUserPoolReplica API page states:

Deletes a secondary replica user pool. You can only delete replicas that are in the
INACTIVE status. This operation must be called from the primary Region.

The section on "Supported API operations in secondary Regions" lists DeleteUserPoolReplica as an operation that can be used in secondary Regions that are INACTIVE (the sources disagree). Both sources agree that the replica must be returned to an INACTIVE state before it can be deleted. In this article's setup, when called from the replica's Region, the API returns a ResourceNotFoundException; however, when called from the primary Region, the request is accepted (see Section 8.2). This behavior aligns with the description on the API page.

9.5 State Values

In both the UG example for CreateUserPoolReplica and the API example for CreateUserPoolReplica, the Status in the response immediately after creation is indicated as PENDING_CREATE. The Status values for UserPoolReplicaType in the API are four: CREATING, ACTIVE, INACTIVE, and DELETING, and do not include PENDING_CREATE (the sources disagree). In this article's setup, the Status in the response was CREATING (see Section 8.2).

The descriptions of what a replica does also differ. The News Blog says that both primary and secondary regional endpoints "remain active and ready to serve your traffic at all times" and that the secondary Region "operates in read-only mode". The API Reference describes an INACTIVE replica as not accepting requests for end-users, and the UG lists administrator writes for the seven per-Region settings on the replica (the sources disagree).

9.6 What Is Not Written

Despite searching for information using the resources outlined in Section 1.3, varying search terms and exploring different documentation categories (including the UG, API Reference, CloudFormation, pages for API Gateway and Elastic Load Balancing, blogs, and AWS documentation search), no statement was found regarding the following:

Which Region's URL is in the iss (issuer) of tokens issued by the replica under the original issuer. (Observations from this article are detailed in Section 8.2.)
Whether the primary and replica use the same signing key. (Same as above.)
Which ARN (Amazon Resource Name) for which key the DescribeUserPool call returns for the replica's Region. (Same as above.)
Whether it is permissible to configure an API Gateway JWT authorizer with the updated issuer, and if so, from where to obtain the public key (the Cognito UG note on API Gateway names only the cognito-idp form).
How API Gateway's REST API Cognito authorizer and Application Load Balancer's authenticate-cognito handle replicas.
How token revocation (using RevokeToken or GlobalSignOut) in one Region is propagated to the other Region.
Whether Lambda trigger events include a field indicating which Region's pool was invoked.
The magnitude of replication latency.

The following items are not listed in the documentation (the documentation does not list):

Whether GetClientToken and AdminDeleteSoftwareToken can be used with replicas.
The quota for the number of replicas.

10. Failure Modes

This section outlines the potential outcomes that can arise when designing based on the assumptions discussed in Section 1.1.

10.1 Assuming a Replica Takes Over by Itself During a Regional Outage

The replica is initially created in an INACTIVE state. An INACTIVE replica does not accept sign-ins or token refreshes. Even if traffic is shifted to it, authentication will not be granted until an operator activates it. Even when activated, shifting traffic involves Cognito, following the health check, on the domain's routing path, and the application itself on the SDK's routing path.

10.2 Assuming Tokens Work in Any Region

Cognito endpoints will accept refresh tokens issued from other Regions. However, whether your own API's validator accepts them is a separate matter. If your validator only accepts tokens from a single issuer, it will reject one of the two kinds of tokens while the issuer formats are mixed. If the original value remains unchanged, the JWKS (JSON Web Key Set) is tied to a single Region. When that Region cannot be reached and a token with a kid (Key ID) that is not in the cache is received, it cannot be validated.

10.3 Assuming API Gateway and the Application Load Balancer Need No Changes

The issuer setting for the API Gateway's JWT authorizer accepts a single string, and the examples use original. If the issuer is changed to updated, the authenticate-cognito action will no longer be usable, and it will be necessary to switch to authenticate-oidc (Cognito UG). Neither validator's pages reference MRR.

10.4 Assuming a Change of Issuer Format Takes Effect Everywhere at Once

Existing tokens remain valid until their expiration date, and tokens issued through refresh will transition to a new format. During this process, the validator will receive two different formats. The Security Blog suggests planning for deployment in conjunction with updates on the validator's side.

10.5 Assuming Nothing Can Be Written in a Replica

In replicas, while you cannot write everything, you can modify certain settings: the seven Region-specific configurations, the replica's status, and some components (SetUserPoolMfaConfig, SetRiskConfiguration, and the domain). You cannot, however, modify global settings, issuer and key configurations, user creation, user attributes, or passwords. If you forget to configure Lambda triggers or SES in the replica's Region, the authentication behavior will differ from the primary environment (this article's reading).

10.6 Treating `OperationNotEnabledException` as a Sign of a Replica

This exception is returned when attempting an operation that is not supported in a particular Region or configuration. The list of errors in the API documentation includes the same description for operations that are available in a replica. To confirm whether an operation is supported in a replica, refer to the list of supported operations in the UG. In this article's setup, attempting to change the issuer in a replica resulted in an InvalidParameterException rather than this exception (see Section 8.2).

10.7 Assuming Cognito Moves Traffic Back in AWS GovCloud (US)

In the AWS GovCloud (US) Regions, automatic failover based on Route 53 health checks does not occur, and Cognito does not route traffic back to the primary. Furthermore, each domain is separate, meaning passkeys registered with the primary domain cannot be used with the secondary domain.

10.8 Assuming New Users Can Still Be Accepted During Failover

Both sign-up and administrator creation are available only in the primary. Users who are signing in for the first time through an external Identity Provider (IdP), and who have never signed in to the primary, will not be able to sign in to the replica.

11. Frequently Asked Questions About Cognito MRR

Q1. If you create a replica, can users keep working during an outage?

If the replica is in the ACTIVE state and traffic is being routed to it, registered users can sign in and refresh their tokens, with the exceptions below and as long as the per-Region settings their sign-in depends on are configured in the replica Region (Section 3.2). The replica is initially created in the INACTIVE state, so it is necessary for an operator to set it to ACTIVE. Sign-ups, attribute updates, password resets, TOTP-based MFA, and first sign-ins of federated users are not supported on the replica.

Q2. Does your API accept tokens issued by the replica as they are?

This depends on the validator. Cognito endpoints accept tokens across Regions. For your own API, the issuer check passes only when the iss claim matches an issuer you have configured and the JWKS for that issuer is reachable; the validator still checks the signature, the expiry, and the audience or client ID. During issuer format changes, both formats may be present. In this article's setup, the replica, under the original issuer, issued tokens with an iss claim that used the primary Region's URL, and the kid was also the same (Section 8.2). No statement was found in the sources on this detail.

Q3. Must the issuer be `updated`?

The wording varies depending on the documentation. The UG, API Reference, the Issuer page in the help panel, and the Security Blog recommend it. The Security Blog also states that the original issuer can still be used with MRR. The Multi-Region replication page in the help panel lists it among the conditions for enabling MRR. With the original issuer, the JWKS and discovery documents are associated with a single Region.

Q4. Can the Application Load Balancer `authenticate-cognito` action be used with MRR?

The Cognito UG states that the updated issuer is not compatible with authenticate-cognito and that you should use authenticate-oidc. No statement was found in the Elastic Load Balancing pages regarding using the original issuer or combining it with replicas.

Q5. After a failover, who moves traffic back to the primary?

It depends on the path. For paths through the user pool domain in commercial Regions, Cognito will begin returning traffic to the primary once health checks return to normal. For paths using the SDK and API, the application is responsible for returning traffic. In AWS GovCloud (US) Regions, Cognito does not initiate the return; instead, your application must redirect traffic back to the primary domain.

Q6. How many replicas can you create?

The UG and the Security Blog state that there can be one replica in an additional Region. The help panel indicates a maximum of 2 total replicas. The ListUserPoolReplicas API includes the primary replica in the list, suggesting that the maximum of 2 in the help panel counts the primary as well (this article's inference).

Q7. Does aws-jwt-verify accept both issuer formats?

Yes, from version 5.2.0. The README states that it verifies both original and updated issuers. The AWS Security Blog recommends using version 5.2.1 or later of aws-jwt-verify. aws-jwt-verify constructs the issuer and JWKS URLs from the Region in the user pool ID prefix, specifically the primary Region.

12. Summary

MRR (Multi-Region Replication) creates another pool in a different Region, using the same user pool ID. Write authority stays with the primary; replicas can only modify a limited number of settings (seven per Region), replica status, and a subset of configurations listed in the UG.
Replicas are initially created in an INACTIVE state. Sign-ins, refreshes, and token revocations are only accepted when the replica is in the ACTIVE state. An operator activates the replica, and traffic is shifted to it via Cognito following the health check (for domain routing outside the AWS GovCloud (US) Regions; in those Regions, you route between the domains yourself) and by the application itself (for SDK and API routing).
The issuer can take two formats: original and updated. The updated format's URL points to the primary Region (the original format's did too in this article's setup). The original format's JWKS and discovery documents are associated with a single Region, while the updated format distributes the same JWKS across multiple Regions.
Statements that tokens work across Regions are about Cognito endpoints. Whether a validator accepts tokens depends on its own issuer configuration and how it handles public keys. The API Gateway and Application Load Balancer pages read for this article do not mention MRR.
Changing the issuer format means that older token formats will remain valid until their expiration date. Validators will receive both formats.
During failover, the creation of new users, modification of user attributes and passwords, TOTP MFA, and first sign-ins of federated users are temporarily suspended.
Whether the issuer is recommended or required, the three dates related to initial availability, the number of replicas, and the Region from which DeleteUserPoolReplica is called are described differently across various documents. It is recommended to review these details alongside their respective sources.

All information is current as of October 29, 2026.

13. References

Amazon Cognito Developer Guide: Multi-Region replication for user pools
Amazon Cognito Developer Guide: Identity provider and relying party endpoints
Amazon Cognito Developer Guide: Verifying JSON web tokens
Amazon Cognito Developer Guide: Data protection in Amazon Cognito
Amazon Cognito Developer Guide: Quotas in Amazon Cognito
Amazon Cognito Developer Guide: Document history for Amazon Cognito
Amazon Cognito console help panel: Multi-Region replication
Amazon Cognito console help panel: Issuer
Amazon Cognito User Pools API Reference: CreateUserPoolReplica
Amazon Cognito User Pools API Reference: UpdateUserPoolReplica
Amazon Cognito User Pools API Reference: DeleteUserPoolReplica
Amazon Cognito User Pools API Reference: ListUserPoolReplicas
Amazon Cognito User Pools API Reference: UserPoolReplicaType
Amazon Cognito User Pools API Reference: IssuerConfigurationType
Amazon Cognito User Pools API Reference: KeyConfigurationType
Amazon Cognito User Pools API Reference: UpdateUserPool
Amazon Cognito User Pools API Reference: UpdateUserPoolDomain
Amazon Cognito User Pools API Reference: GetClientToken
AWS CloudFormation Template Reference: AWS::Cognito::UserPoolReplica
AWS CloudFormation Template Reference: AWS::Cognito::UserPoolRegionalConfigurationAttachment
Amazon API Gateway Developer Guide: Control access to HTTP APIs with JWT authorizers in API Gateway
Amazon API Gateway Developer Guide: Troubleshooting issues with HTTP API JWT authorizers in API Gateway
Amazon API Gateway Developer Guide: Control access to REST APIs using Amazon Cognito user pools as an authorizer
Amazon API Gateway Developer Guide: x-amazon-apigateway-authorizer object
Amazon API Gateway V2 API Reference: Authorizer
Elastic Load Balancing: Authenticate users using an Application Load Balancer
Elastic Load Balancing API Reference: AuthenticateCognitoActionConfig
AWS Key Management Service Developer Guide: Delete an AWS KMS key
AWS Security Blog: Architecting resilient authentication with Amazon Cognito multi-Region replication
AWS News Blog: Improve your application resilience with Amazon Cognito multi-Region replication
AWS Security Blog: Amazon Cognito unlocks advanced capabilities with next-generation infrastructure
What's New: Amazon Cognito now supports multi-Region replication
What's New: Amazon Cognito extends multi-Region replication to AWS GovCloud (US) Regions
What's New: Amazon Cognito adds admin API operation to reset user TOTP configurations
What's New: Amazon Cognito now supports machine-to-machine authorization without a user pool domain
aws-jwt-verify: README
aws-jwt-verify: src/cognito-verifier.ts
aws-jwt-verify: Releases

References:
Tech Blog with curated related content

Written by Hidekazu Konishi