Skip to content

CONCEPT Cited by 1 source

Cross-partition authentication

Definition

The design problem of authenticating a workload across two or more AWS partitions, given that IAM credentials are bound to a single partition and don't carry across the partition boundary. "Because IAM credentials don't work across partitions, you need to create separate roles or use external identity providers." (Source: sources/2026-01-30-aws-sovereign-failover-design-digital-sovereignty)

Five tactics the AWS Sovereign Failover post names

  1. IAM roles with trust relationships and external IDs. Create separate roles in each partition, trust the other partition's principal via external-ID to defeat the confused-deputy problem. Classic cross-account-role shape extended across partitions.
  2. AWS STS regional endpoints. Use STS in each partition to mint short-lived credentials scoped to that partition.
  3. Resource-based policies. Attach policies to the resource (e.g. S3 bucket policies) granting access to principals in the other partition.
  4. Cross-account roles managed through AWS Organizations. Where Organizations topology permits (not all combinations do — AWS GovCloud can be invited into a commercial Organization, European Sovereign Cloud cannot).
  5. Federate from a centralized IdP to multiple partitions. "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." Canonical realization is patterns/centralized-identity-federation via IAM Identity Center; AWS points to a separate blog post for GovCloud ↔ standard configurations.

IAM-user 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." (Source: sources/2026-01-30-aws-sovereign-failover-design-digital-sovereignty)

This is explicitly framed as the fallback when IAM users can't be avoided. Three moving pieces:

  • Secrets Manager as the storage tier for the long-lived credential.
  • Lambda as the rotation engine.
  • Backup user — a second IAM user against which the same rotation flow runs, so a failed rotation of the primary user doesn't brick the cross-partition workload.

The backup-user detail is the "availability of a long-lived credential under an automated rotation policy" problem — same shape as any rotation-pattern book's "always keep N−1 keys live."

Composition with cross-partition API Gateway

"These patterns are often combined with standard access controls, such as Amazon API Gateway with authorizers, to secure cross-partition interactions." (Source: sources/2026-01-30-aws-sovereign-failover-design-digital-sovereignty)

API Gateway authorizers sit between the federated / role-assumed principal and the workload API, providing a second layer of authorization scoping per-operation.

Why this is harder than cross-region/cross-account

  • Cross-region, same partition: roles can be assumed transparently; Organizations applies uniformly.
  • Cross-account, same partition: canonical AWS cross-account role trust-policy pattern.
  • Cross-partition: same tactics plus partition-scoped STS endpoints, partition-scoped ARN namespaces, per-partition Organizations (in the European Sovereign Cloud case — strictly separate), and per-partition CA trust (see concepts/cross-signed-certificate-trust).

Seen in

Last updated · 200 distilled / 1,178 read