Transit Gateway compartilhado: quem possui as rotas no AWS RAM
O compartilhamento por RAM permite que outra conta anexe uma VPC, mas as tabelas de rotas, as associações e as propagações ficam com o proprietário do gateway. Aqui está o limite.
Compartilhar uma Transit Gateway com o Resource Access Manager faz uma coisa específica: permite que outra conta chame um conjunto definido de APIs de anexação contra um recurso que não possui. Não transfere o gateway, suas tabelas de rotas ou o direito de decidir como o tráfego é encaminhado. As pessoas presumem o contrário porque a anexação aparece no console do destinatário e funciona imediatamente, o que parece propriedade. O mecanismo por baixo é uma concessão de permissão sobre um recurso compartilhado, e cada objeto filho permanece dentro do limite da conta do proprietário. Essa separação explica a maioria dos tickets de acesso negado em torno do trânsito compartilhado.
O que o compartilhamento realmente delega
Um compartilhamento de recurso nomeia um recurso, um principal e uma permissão gerenciada. A permissão lista as ações que esse principal pode executar, e para uma Transit Gateway essa lista cobre as operações de anexação no recurso compartilhado.
Qualquer coisa fora da lista falha na API e não no console, por isso o erro costuma aparecer na primeira execução de um script.
As tabelas de rotas, as associações e as propagações ficam com o proprietário
O encaminhamento é decidido por três objetos filhos: a qual tabela de rotas uma anexação está associada, em quais tabelas ela propaga e quais rotas essas tabelas contêm. A documentação de compartilhamento da AWS afirma que um destinatário não pode criar, modificar ou excluir tabelas de rotas do gateway de trânsito nem suas associações e propagações por meio do compartilhamento. Essas chamadas pertencem à conta proprietária. Um destinatário que precisa de uma nova associação está pedindo uma mudança administrativa, não exercendo uma permissão que esqueceu de habilitar.
A tabela abaixo é a separação que coloco nos documentos de design, porque sobrevive a mudanças de equipe.
| Role | What it controls |
|---|---|
| Transit Gateway owner | The gateway, its route tables, associations and propagations; the Site-to-Site VPN attachment is created here. |
| VPC owner using the share | Its own attachment, subnet route tables and security policy for the workloads. |
| Shared-subnet participant | Workload traffic only, following routes the VPC owner already set. |
Leia a linha do meio com atenção: o proprietário da VPC controla as rotas da sua sub-rede, o proprietário do gateway controla a decisão central de encaminhamento, e um caminho funcional precisa das duas. Nenhuma das duas contas consegue concluir sozinha.
Um caminho, duas contas
Siga um pacote de uma VPC spoke até um prefixo local. A tabela de rotas da sub-rede spoke deve enviar esse prefixo para a anexação do gateway de trânsito, o que o proprietário da VPC pode alterar. Depois o gateway deve ter, na tabela associada da anexação, uma rota apontando para a anexação VPN, o que só o proprietário pode alterar. O tráfego de retorno precisa do espelho das duas. Se faltar qualquer um dos lados, você obtém um caminho meio instalado que parece um problema de firewall.
Escreva as duas mudanças em um único ticket com dois responsáveis, ou elas serão concluídas em semanas diferentes.
Use IDs de zona de disponibilidade quando o posicionamento importar
Os nomes de zona são aliases locais da conta. us-east-1a em uma conta não tem garantia de ser a mesma zona física que us-east-1a em outra. Quando o design exige uma anexação e uma carga de trabalho na mesma zona, compare os IDs de AZ e registre-os.
Comparar nomes produz um diagrama que parece correto e um perfil de latência que não é. Verifique isso enquanto o diagrama ainda está sendo desenhado, não depois de alguém medir a diferença.
Desfazer o compartilhamento não corta o caminho de dados
Remover o compartilhamento parece uma revogação, e não é uma parada imediata do tráfego. A AWS documenta que uma anexação continua funcional quando o gateway deixa de ser compartilhado. A permissão para gerenciar o recurso desaparece, enquanto a anexação existente continua encaminhando até alguém excluí-la ou desativá-la. Planeje a revogação em duas etapas: remova o compartilhamento e depois a anexação, com o proprietário executando a segunda.
Se o compartilhamento é o seu único controle, você não tem controle.
Mantenha o registro de compartilhamento e o registro de roteamento juntos
Dois artefatos respondem a duas perguntas diferentes. O registro de compartilhamento diz quem pode trabalhar com o recurso. As tabelas de rotas dizem quais redes podem realmente conversar. Guarde-os juntos com a mesma lista de proprietários, ou o próximo incidente começará com alguém provando uma permissão que nunca foi o problema.
Depois teste um fluxo em cada direção e um prefixo que deve permanecer inalcançável.