{"resourceId":"aws-iam-outbound-federation-cross-partition-govcloud-20261109","versions":[{"version":"external-634640bbc8712dafeacf4eee6047847aef8330cd501be10a6a2368479df5cd16","resource":{"id":"aws-iam-outbound-federation-cross-partition-govcloud-20261109","title":"AWS enables short-lived cross-partition credentials between GovCloud (US) and commercial Regions, while telling customers to treat cross-partition access as an exception","organization":"Amazon Web Services","sector":"Cross-SLED government cloud identity and security","geography":"United States and global AWS partitions (Commercial, GovCloud (US), China, European Sovereign Cloud)","publishedAt":"2026-11-09","publicationDate":"2026-11-09","eventDate":"2026-11-09","sourceName":"AWS Security Blog","sourceLabel":"Simplify cross-partition access with AWS IAM outbound identity federation","sourceUrl":"https://aws.amazon.com/blogs/security/simplify-cross-partition-access-with-aws-iam-outbound-identity-federation/","evidenceClass":"vendor-claim","outcomeClass":"emerging","topics":["infrastructure","data-security","governance-procurement"],"finding":"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.","sledRelevance":"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":"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.","architectureImplications":"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.","governanceImplications":"AWS explicitly places compliance responsibility on the customer and recommends treating cross-partition access as an exception requiring approval.","securityPrivacyImplications":"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.","caveats":"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.","streamIds":["aws"],"roles":{"sales":"Interpretation: lead with risk reduction, not with reaching commercial AI services. The customer problem is long-lived access keys used to bridge GovCloud and commercial accounts, which auditors dislike. Stakeholders are the cloud security architect, compliance officer and data owners. Discovery should ask how GovCloud and commercial workloads currently exchange data and whether any AI services are called across the boundary. A bounded engagement is a key-elimination review. Do not suggest that this makes sending regulated data to commercial-only AI services acceptable.","engineering":"Interpretation: the fit is strong for replacing static cross-partition keys. Engineers enable outbound federation in the source account, create an OIDC trust in the destination and restrict it with aud, sub and the new cross-partition condition keys. Prerequisites are an inventory of existing cross-partition credentials and CloudTrail in both partitions. Constraints include customer-owned compliance determination and same-partition federation not being supported. A proof of value is migrating one key-based integration and confirming correlated CloudTrail events.","delivery":"Interpretation: delivery work is a controlled migration with an approval gate. Dependencies are compliance sign-off for each cross-partition path and owners for the destination roles. Ownership belongs to the cloud platform team, with the compliance office approving exceptions. Governance checkpoints include a register of approved cross-partition trusts and periodic review of their use. Proposed acceptance criteria are zero long-term cross-partition keys for migrated workloads and complete CloudTrail correlation. Risks include approving AI data flows that breach residency rules."},"roleDetails":{"sales":{"customerProblem":"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"],"discoveryQuestions":["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?"],"valueHypothesis":"Short-lived, auditable credentials can remove static keys from cross-partition integrations.","potentialEngagement":"Cross-partition key-elimination review and one pilot migration.","unsupportedClaims":["That regulated data may now flow to commercial AI services","Any compliance approval for cross-partition use"]},"engineering":{"fit":"Strong for replacing static keys; narrow for AI use cases.","architectureIntegration":"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.","proofOfValue":["Migrate one key-based integration","Confirm correlated CloudTrail token IDs","Verify denied access from unapproved Regions"]},"delivery":{"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.","skillsAdoption":"Engineers need OIDC trust-policy and condition-key skills.","governanceCheckpoints":["Register of approved cross-partition trusts","Periodic usage review"],"acceptanceCriteria":["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"]}},"retrievedAt":"2026-11-10T04:05:43Z","enrichedAt":"2026-11-10T04:11:25Z","enrichmentBasis":"retrieved source","accessibilityWorkforceImplications":"Not addressed.","procurementImplications":"No additional charge.","operatingModelImplications":"Requires CloudTrail in both partitions and a process for approving and reviewing each cross-partition trust.","sourceVerification":{"openedUrl":"https://aws.amazon.com/blogs/security/simplify-cross-partition-access-with-aws-iam-outbound-identity-federation/","referenceExcerpt":"Treat cross-partition access as an exception and before you establish any, confirm it’s permitted under your regulatory, compliance, and security requirements.","promptVersion":"sled-research-v4.0","model":null,"basis":"agent-reported inspection"}}}]}