From the AWS edition of November 9, 2026
AWS enables short-lived cross-partition credentials between GovCloud (US) and commercial Regions, while telling customers to treat cross-partition access as an exception
Amazon Web Services · Cross-SLED government cloud identity and security · United States and global AWS partitions (Commercial, GovCloud (US), China, European Sovereign Cloud)
- Publisher
- AWS Security Blog
- Original publication
- 2026-11-09
- Source retrieved
- 2026-11-10
- Event date
- 2026-11-09
What happened
AWS announced on November 9, 2026 that IAM outbound identity federation now works across partitions: a workload in GovCloud (US) can obtain a short-lived signed JWT with sts:GetWebIdentityToken and exchange it for temporary credentials in a commercial-partition role via sts:AssumeRoleWithWebIdentity, replacing long-term access keys. It is off by default, enabled per account, free of charge, and auditable in CloudTrail in both partitions. AWS advises consulting compliance teams (citing FedRAMP, ITAR and DoD CC SRG), initiating access from the more restrictive partition, and treating cross-partition access as an exception.
Why it matters
Many SLED organizations split workloads between GovCloud and commercial Regions, sometimes because a needed AI service or model is only in commercial Regions. This removes the long-lived-key workaround, but it also makes cross-boundary data movement easier, so data-residency and CJIS/ITAR rules must be checked first. The AI link is interpretation; the post's example is S3 data access.
Evidence and measured results
Vendor launch post and What's New announcement (https://aws.amazon.com/about-aws/whats-new/2026/11/aws-sts-cross-partition/, also opened). No customer deployments or independent review.
Limitations and uncertainty
Vendor documentation. Applicability to AI workloads (e.g., calling commercial-only Bedrock models from GovCloud) is our interpretation and may be prohibited by an agency's data rules.
Put this evidence to work
Lighthouse Advisory interpretation, grounded in this source. Enriched 2026-11-10; this does not change the original publication date. Each role follows the same checklist so takeaways compare across sources.
Sales
Role takeaway
- Customer problem
- GovCloud and commercial workloads are often bridged with long-lived IAM user keys that are hard to audit.
- Stakeholders
- Cloud security architect
- Compliance officer
- Data owners
- Discovery questions
- How do GovCloud and commercial accounts exchange data today?
- Are any AI services or models called across the partition boundary?
- Which data classes are prohibited from leaving GovCloud?
- Value hypothesis
- Short-lived, auditable credentials can remove static keys from cross-partition integrations.
- Potential engagement
- Cross-partition key-elimination review and one pilot migration.
- Unsupported claims
- That regulated data may now flow to commercial AI services
- Any compliance approval for cross-partition use
Pre-sales engineering
Role takeaway
- Fit
- Strong for replacing static keys; narrow for AI use cases.
- Architecture and integration
- Outbound federation in GovCloud source; OIDC trust with aud/sub and aws:CrossPartitionSourceRegion conditions in the destination.
- Prerequisites
- Inventory of cross-partition credentials
- CloudTrail in both partitions
- Compliance determination per path
- Constraints
- Off by default
- Same-partition federation not supported
- Customer owns compliance determination
- Security
- Short-lived tokens and session revocation; risk of data egress from GovCloud if trusts are too broad.
- Proof of value
- Migrate one key-based integration
- Confirm correlated CloudTrail token IDs
- Verify denied access from unapproved Regions
Delivery
Role takeaway
- Work
- Migrate key-based cross-partition integrations under an approval gate.
- Dependencies
- Compliance sign-off
- Destination role owners
- Ownership
- Cloud platform team; compliance office approves exceptions.
- Skills and adoption
- Engineers need OIDC trust-policy and condition-key skills.
- Governance checkpoints
- Register of approved cross-partition trusts
- Periodic usage review
- Acceptance criteria
- Proposed: zero long-term cross-partition keys for migrated workloads
- Proposed: 100% CloudTrail correlation for cross-partition sessions
- Risks
- Approving data flows that breach residency rules
- Over-broad trust policies
Implementation considerations
Lighthouse Advisory interpretation across the operating dimensions a public-sector buyer must settle before this evidence becomes a design. Each note answers the question under its heading for this specific source.
Architecture and integration
What must connect, and where does the AI sit in the workflow?
Source account enables outbound federation and gets an issuer URL; the destination role trusts it via an OIDC provider with aud/sub conditions. New condition keys (aws:FederatedProvider, aws:CrossPartitionSourceRegion) restrict origins; session revocation is supported.
Governance
Who approves, reviews and stays accountable for outcomes?
AWS explicitly places compliance responsibility on the customer and recommends treating cross-partition access as an exception requiring approval.
Security and privacy
What data, permissions and controls need testing?
Replaces non-expiring IAM user keys with short-lived tokens and correlated CloudTrail records, but widens the potential path for data to leave GovCloud if misconfigured.
Accessibility and workforce
Who is affected, and what skills or accommodations follow?
Not addressed.
Procurement
What should contracts, pricing and exit terms secure?
No additional charge.
Operating model
Which teams own the service once it runs?
Requires CloudTrail in both partitions and a process for approving and reviewing each cross-partition trust.
Publication history
- 2026-11-09AWS · Issue 118 resources
Stable resource ID: aws-iam-outbound-federation-cross-partition-govcloud-20261109