Federação outbound do AWS IAM passa a permitir acesso entre partições da AWS

A AWS trata partições (Commercial, China, GovCloud (US) e European Sovereign Cloud) como fronteiras de isolamento rígido, cada uma com sua instância independente do IAM. Por isso uma credencial emitida numa partição não vale em outra, sts:AssumeRole direto não funciona e resource policies não referenciam principals de outra partição. A federação outbound resolve isso reaproveitando o mecanismo de JWT que já existia para autenticar em serviços externos.

O fluxo é este: o workload chama sts:GetWebIdentityToken na partição de origem e recebe um JWT assinado, de curta duração, com claims como conta, ARN do principal e Região de origem. Depois chama sts:AssumeRoleWithWebIdentity no destino, que valida a assinatura e avalia a trust policy da role. No passo a passo, a conta de origem habilita a federação outbound (uma vez, é configuração da conta inteira), e a de destino registra o issuer como provedor OIDC e cria uma role condicionada a aud, sub, source_region e org_id. O exemplo de política de origem limita a duração do token a 300 segundos e fixa o algoritmo ES384. A trilha no CloudTrail traz o ARN de origem e um ID de token que se liga ao evento de origem. Sessões já emitidas podem ser revogadas por origem ou com deny na role de destino. A AWS recomenda falar com o time de compliance antes, por causa de obrigações como FedRAMP, ITAR, DoD CC SRG e GDPR.

Para quem opera ambientes multipartição, isso tende a substituir access keys de longo prazo guardadas entre partições por credenciais que expiram sozinhas. A leitura editorial é que o ganho real está na trust policy: condicionar por org_id e Região de origem permite um escopo bem mais estreito do que "o token é válido". Já o ponto regulatório não é detalhe. Tecnicamente funcionar não significa que o fluxo de dados entre partições é permitido.