AWS

AWS IAM Identity Center adds cross-Region trusted identity propagation

Trusted identity propagation now carries user identity across AWS Regions, removing the single-Region constraint for fine-grained access control and auditing.

E

Everything Cloud

Everything Cloud

AWS IAM Identity Center adds cross-Region trusted identity propagation

AWS IAM Identity Center now supports cross-Region trusted identity propagation, letting a user's identity travel with requests to services in different AWS Regions. This removes the previous requirement that all services consuming the identity reside in the same Region, enabling fine-grained permissions and audit logging across multi-Region architectures at no extra cost.

An abstract image

An abstract image

What changed with cross-Region propagation

Trusted identity propagation carries a user's identity and group memberships with each request so downstream AWS services can authorize based on who the user is rather than relying on broad IAM roles. Until now, this identity context could only reach services deployed in the same AWS Region as the identity source, forcing teams to either consolidate workloads or accept coarse-grained access. The new cross-Region capability automatically extends that identity context to services in other Regions without additional configuration.

The feature works with existing IAM Identity Center setups and requires no code changes in calling applications. When a request originates in one Region and targets a service in another, the identity token travels with the request through AWS internal channels. Services such as Amazon Redshift, Amazon Athena, and AWS Lake Formation can now evaluate the original user's group memberships for fine-grained access decisions regardless of where they run.

Pricing remains unchanged: cross-Region trusted identity propagation is available at no additional charge in every Region where IAM Identity Center operates. Teams can verify Region availability through the AWS Capabilities by Region page and enable the capability through the IAM Identity Center console or API. Existing single-Region deployments continue to work without modification.

Architectural implications for multi-Region workloads

Organizations distributing compute and data across Regions for latency, capacity, or disaster recovery can now maintain consistent identity-based authorization. A query from a business intelligence tool in us-east-1 can reach an Amazon Redshift cluster in eu-west-1 while preserving the analyst's identity and group associations, so row-level security policies apply uniformly. This eliminates the need for cross-Region IAM role assumptions that obscure the actual user.

Audit trails become more accurate because CloudTrail logs in the target Region record the original user identity rather than a shared service role. Security teams can trace exactly who accessed which dataset across Region boundaries, simplifying compliance reporting. The identity context flows through AWS service-to-service paths, so there is no need to build custom token-passing infrastructure.

Teams can adopt a hub-and-spoke model where IAM Identity Center runs in a primary Region while analytical workloads span multiple Regions. The identity provider stays centralized, but the authorization context follows each request. This reduces operational overhead compared to replicating identity stores or federating separate identity providers per Region.

Operational considerations and next steps

Enable cross-Region trusted identity propagation in the IAM Identity Center console under the trusted identity propagation settings. The toggle applies globally to the identity store, so all connected applications gain cross-Region reach immediately. Verify that target services in destination Regions support trusted identity propagation; the documentation lists supported services and any Region-specific caveats.

Review existing IAM policies that grant broad cross-Region access through assumed roles. Many of these can be replaced with identity-based policies that reference the user's group memberships, reducing the attack surface. Test with a non-production workload first to confirm that group mappings and attribute-based access controls behave as expected across the Region boundary.

Monitor CloudTrail logs in both source and destination Regions to validate that the principalArn field reflects the original user identity. Set up alerts for any unexpected role assumptions that might indicate legacy access paths still in use. The IAM Identity Center user guide provides detailed troubleshooting steps for cross-Region propagation scenarios.

What to do next

Turn on cross-Region trusted identity propagation in your IAM Identity Center console, then audit cross-Region IAM roles that can be replaced with identity-based policies. Test with a single analytics workload spanning two Regions before rolling out broadly.

Source: AWS IAM Identity Center now supports cross-Region trusted identity propagation (AWS).

Share:TwitterLinkedIn

Related Articles