Migração de Contas na AWS Organizations Como Não Perder os Shares do RAM e as Permissões do Lake Formation

O problema que ninguém vê até o terraform apply quebrar

Olha só isso: mover contas entre AWS Organizations parece tarefa administrativa… até um terraform apply em produção falhar com erro de permissão enquanto o tráfego continua fluindo normalmente. Esse é o sintoma clássico de um share do AWS RAM vinculado à organização quebrando: o data plane sobrevive, mas o control plane apaga.

Isso pega qualquer empresa passando por fusão, cisão ou arquitetura multi-org. O detalhe é sutil:

• Quando a conta produtora ativa o compartilhamento com AWS Organizations, o AWS RAM confia em cada principal através do vínculo com a organização, mesmo que o share cite um account ID.
• No instante em que a conta sai da organização de origem, o AWS RAM remove essa associação.
• Anexos, caminhos de DNS e certificados continuam funcionando — mas ninguém consegue mais alterar os recursos compartilhados.

Uma processadora global de pagamentos passou exatamente por isso numa migração de 382 contas. A solução foi um bridge share retido: uma associação externa temporária criada antes da mudança e removida depois de restaurar o share original. O estudo completo, com automação validada, está no post do AWS Architecture Blog.

Tipos de recurso afetados (confirmados em produção)

Alguns serviços exigem cuidado extra: políticas do Firewall Manager podem remover regras do Network Firewall (precisa redeploy), e StackSets integrados à organização podem deletar stacks se não estiverem configurados para retenção.

O padrão bridge-share: cinco passos por wave

O insight central é que o AWS RAM permite que um recurso pertença a mais de um resource share. Um share paralelo pode coexistir com o original, apontando para a mesma conta consumidora. Quando a consumidora aceita o convite antes da migração, a associação vira externa — não depende mais do vínculo com a organização, então sobrevive à mudança.

Por que restaurar o share original?

O bridge é uma cópia de continuidade só para a migração. O share original criado pelo Lake Formation continua sendo o objeto durável e gerenciado pelo serviço. Se alguém adicionar um grant ou alterar um recurso compartilhado durante a janela de migração, essa mudança vai para o original — não para o bridge. Manter os dois gera estado duplicado de permissão e drift.

Workflow validado

# 1. Inventário — AWS RAM é regional, repita por Region
aws ram list-resource-shares --region us-east-1 --resource-owner SELF

# 2. Crie um bridge share retido para o mesmo recurso + principals
aws ram create-resource-share \
  --name "bridge-tgw-prod" \
  --resource-arns arn:aws:ec2:us-east-1:111122223333:transit-gateway/tgw-xxxx \
  --principals 444455556666 \
  --allow-external-principals \
  --region us-east-1

# 3. A conta consumidora aceita o convite ANTES da migração
aws ram accept-resource-share-invitation \
  --resource-share-invitation-arn <invitation-arn> \
  --region us-east-1

# 4. Mova a conta (AWS Organizations suporta transferência direta entre orgs)
# 5. Restaure os account IDs migrados no share ORIGINAL como principals externos,
#    valide e só então delete os bridges totalmente cobertos pelos originais ativos

A flag que faz tudo funcionar

Em 27 de fevereiro de 2026, a AWS lançou o RetainSharingOnAccountLeaveOrganization para resource shares novos. Ele marca principals como externos depois que aceitam o convite. Detalhe importante: essa flag não retroage em shares existentes — por isso o cliente precisou de um share paralelo temporário para cada share pré-existente. Nos testes, allowExternalPrincipals sozinho não bastou; o bridge precisou das duas flags.

Guardrail de automação

O passo de delete só dispara quando a automação encontra um original (não-bridge) cujos recursos, principals e permissões cobrem o bridge e cujas associações estão todas em ASSOCIATED. Isso confirma que o original está ativo antes de remover o caminho temporário.

Limitações e cuidados

Esse padrão é poderoso, mas tem arestas:

• Teste em non-prod pode te enganar. As contas non-prod do cliente já estavam em outra organização, então 14 waves limpas validaram o processo, mas nunca cruzaram a fronteira de confiança de produção. Cada ambiente de validação precisa cruzar a mesma fronteira que produção.
• Account ID como principal não é rede de segurança. Mesmo quando o share cita um account ID, o que realmente concede a confiança é o vínculo com a organização. Citar o ID não torna a associação externa.
• Atrito com SCP. Uma service control policy bloqueando ram:AcceptResourceShareInvitation quebra silenciosamente o passo de aceite do bridge — o cliente teve que ajustar temporariamente durante as janelas de migração.
• Firewall Manager e StackSets exigem configuração explícita de retenção, senão você redeploya regras / perde stacks.
• Risco de drift do bridge. Se um grant for adicionado ao original durante a janela e o bridge for deletado antes da verificação, você perde acesso no meio da wave.

Monitorando o control plane

O AWS RAM emite eventos de mudança de estado de resource share direto no Amazon EventBridge, e o CloudTrail registra chamadas DisassociateResourceShare para auditoria. Uma varredura semanal pós-migração funciona como reconciliação para pegar shares obsoletos — é o seguro mais barato que você pode contratar.

Se você também está modernizando as cargas que dependem desses shares, os padrões em Beyond Demos: Building Production-Ready AI Agents with Gemini 3 & 6 Open-Source Frameworks mostram como arquiteturas de agentes em produção lidam com acesso cross-account e fronteiras de permissão na prática.

Conclusão: trate o acesso ao control plane como risco de migração de primeira classe

A migração das 382 contas deu certo porque o time parou de tratar shares do AWS RAM como configuração passiva e passou a tratá-los como dependências de produção com ciclo de vida. O bridge share é temporário por design — restaurar o original mantém as permissões do Lake Formation alinhadas com grants futuros e evita duas fontes de verdade.

Três lições para levar para a sua migração:

1. Alinhe as fronteiras de validação com produção. Uma org de teste que nunca cruza a fronteira real não prova nada.
2. Inventarie antes de planejar waves. A ferramenta Account Assessment for AWS Organizations mapeia dependências de RAM por Region; faça isso cedo.
3. Automatize com dry-run primeiro. Os scripts validados suportam dry-run e execução — rode dry, valide cada Region e conta, depois execute.

Se você está explorando como sistemas autônomos e pipelines de experimentação em ML estão sendo levados para produção em ambientes corporativos parecidos, o breakdown do agente autônomo Meta REA é uma leitura complementar útil sobre o mesmo tema de sair do demo para a infraestrutura durável.

Próximos passos de estudo: leia o guia oficial Transfer AWS accounts between AWS Organizations while preserving AWS Lake Formation permissions, revise o aws-samples/sample-aws-ram-org-migration no GitHub e acione seu time de conta AWS cedo sempre que Glue Data Catalog ou Lake Formation estiverem no escopo.