Skip to content

PATTERN Cited by 1 source

Centralized identity federation

Shape

Operate one external identity provider (an IdP — SAML / OIDC / IAM Identity Center / ADFS / Okta / corporate AD) and federate identities from it into every target — multiple AWS accounts, multiple AWS Regions, and crucially multiple AWS partitions. Avoid creating long-lived IAM users in each target.

The AWS Sovereign Failover framing

"A modern best practice is to federate identities from a single, centralized identity provider to multiple partitions, avoiding the need for IAM users wherever possible." (Source: sources/2026-01-30-aws-sovereign-failover-design-digital-sovereignty)

The post references a separate AWS blog post for the concrete GovCloud ↔ standard-Regions recipe: IAM Identity Center for AWS environments spanning AWS GovCloud (US) and standard Regions.

Why federation beats per-partition IAM users

Property Per-partition IAM users Centralized federation
Credential lifetime Long-lived static keys Short-lived STS tokens
Rotation Must be operated (Secrets Manager + Lambda + backup user) Automatic on each assume-role
Offboarding Per-partition revoke sequence Revoke at IdP, propagates
Compliance evidence Per-partition access records One centralized audit trail
Sovereignty Each partition holds its own credential store Credential store is the IdP, outside any single partition
New-partition onboarding Duplicate the IAM-user rotation pipeline Federate the new partition to the existing IdP

The last row — onboarding a new partition — is what makes federation load-bearing for sovereignty-evolving workloads. When a customer decides to add the European Sovereign Cloud to a previously standard-Regions-only topology, adding it to the existing IdP federation is a configuration change; creating a parallel IAM-user-with-Lambda-rotation stack is multi-quarter engineering.

The IAM-user fallback (when federation isn't possible)

Some environments still require IAM users. The post names the best-practice fallback: "If IAM users are still used, credentials can be stored in AWS Secrets Manager, rotated using Lambda, and a backup user can improve availability."

This is explicitly the fallback, not the recommendation. The backup user detail is there because an automated rotation failure on the only user locks the cross-partition workload out.

Relationship to sovereignty

Federation externalizes the credential store from any single partition. This is structurally the right shape for sovereignty-driven architectures — the IdP can be a customer-owned, customer-operated identity system that neither AWS partition has privileged access to. The customer's sovereign position on "who authorizes access to my workloads" is preserved across partition changes.

Seen in

Last updated · 200 distilled / 1,178 read