Build1 publisher2 min readPublished
Cognito's replica user pool rejects every attribute write with OperationNotEnabledException
AWS's multi-Region replication copies a Cognito pool's configuration, hashed credentials and IdP settings into one other Region with eventual consistency. Only the primary accepts writes, so failover planning becomes a per-path decision.
The Engineer · Build desk
What happened
- Amazon Cognito multi-Region replication creates a replica user pool in a second Region, copying app client IDs and secrets, user attributes, hashed credentials, group memberships and external IdP settings with eventual consistency.
- The replica handles sign-in, token generation and revocation, along with read-only calls such as listing users and groups and describing user pool configuration.
- Writes to pool configuration and user attribute updates run only in the primary, and the replica answers them with OperationNotEnabledException through an SDK or an "Action temporarily unavailable" error in managed login.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- decision Failover becomes a choice per authentication path. A consumer sign-up flow either queues its writes locally or keeps sending them to a Region you have just declared unhealthy, and that logic lives in the application.
- cost Key administration transfers to the customer before any resilience arrives: the key policy, the rotation schedule and the deletion decision on a multi-Region CMK are now the account's responsibility.
- constraint Coverage stops at two Regions, so anyone who needs a third still writes the custom synchronization code this feature was meant to retire.
- exposure A user whose credential or attribute change landed in the primary moments before a cutover can meet a replica that has not received it yet.
OperationNotEnabledException is a routing signal. Retrying the same call against the replica returns the same error, because the operation is disabled there [4][5]. In managed login the user gets an "Action temporarily unavailable" error instead [5].
The split sorts your traffic before you write any failover logic. A machine client that exchanges a client ID and secret for an access token needs replicated client configuration and token generation, and the replica has both [2][3]. A consumer sign-up creates a record and a self-service profile edit updates attributes, so both have to reach the primary [3][4]. Tenant administration in a B2B pool is writes as well [3][4].
The session layer is the part that genuinely gets easier. The replica shares the primary's user pool ID [1], app client IDs and client secrets replicate [2], and a refresh token issued in the primary is accepted in the replica to retrieve new ID and access tokens [6]. AWS describes the feature as near-real-time synchronization with built-in failover and seamless sign-in [13], and publishes reference architectures for B2C, B2B and M2M along with failover guidance [14]. The seamless part is sign-in; the writes the replica declines are the application's problem [3][4].
The prerequisite is where the adoption cost sits. A pool without MRR is encrypted at rest under an AWS owned KMS key [7]. Turning on replication requires converting it to a symmetric multi-Region customer managed key first [8], and from then on the key policy, the rotation schedule and the deletion decision are yours [10]. AWS's guidance scopes the key to a single pool with a condition on kms:EncryptionContext:aws:cognito-idp:<userpool-arn> [11].
Cognito supports one additional replica Region [9]. The ceiling is two Regions [16]. A three-Region design still needs the custom synchronization work AWS says MRR was built to replace [12]. The other preparation item is the token issuer: Cognito stamps a default iss claim into every ID and access token, OIDC dictates its format, and AWS lists choosing a multi-Region OIDC issuer as preparation work alongside the customer managed key [15].
What to watch
- Whether AWS raises the one-replica limit: that would change the design for anyone who needs three Regions of coverage.
- The supported API operations list for secondary Regions: any write that moves onto it removes failover logic from applications.
- What MRR costs per replicated user, and whether the customer managed key requirement adds KMS request charges at sign-in volume.