Transit Gateway compartido: quen posúe as rutas en AWS RAM
Compartir por RAM permite que outra conta conecte unha VPC, pero as táboas de rutas, as asociacións e as propagacións quedan co propietario da pasarela. Aquí está o límite.
Compartir unha Transit Gateway con Resource Access Manager fai unha cousa concreta: permite que outra conta chame un conxunto definido de API de conexión contra un recurso que non posúe. Non transfire a pasarela, as súas táboas de rutas nin o dereito a decidir como se reenvía o tráfico. A xente asume o contrario porque a conexión aparece na consola do destinatario e funciona de inmediato, o que se sente como propiedade. O mecanismo subxacente é unha concesión de permiso sobre un recurso compartido, e cada obxecto fillo permanece dentro do límite da conta do propietario. Esa separación explica a maioría dos tickets de acceso denegado arredor do tránsito compartido.
Que delega realmente a compartición
Unha compartición de recursos nomea un recurso, un principal e un permiso xestionado. O permiso enumera as accións que ese principal pode realizar, e para unha Transit Gateway esa lista cobre as operacións de conexión sobre o recurso compartido.
Calquera cousa fóra da lista falla na API e non na consola, por iso o erro adoita aparecer a primeira vez que se executa un script.
As táboas de rutas, as asociacións e as propagacións quedan co propietario
O reenvío decídeno tres obxectos fillo: con que táboa de rutas se asocia unha conexión, a que táboas se propaga e que rutas conteñen esas táboas. A documentación de compartición de AWS indica que un destinatario non pode crear, modificar nin eliminar táboas de rutas da pasarela de tránsito nin as súas asociacións e propagacións mediante a compartición. Eses chamamentos pertencen á conta propietaria. Un destinatario que necesita unha asociación nova está pedindo un cambio administrativo, non exercendo un permiso que esqueceu habilitar.
A táboa de abaixo é a separación que poño nos documentos de deseño, porque sobrevive aos cambios de persoal.
| 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. |
Lea a fila central con atención: o propietario da VPC controla as rutas da súa subrede, o propietario da pasarela controla a decisión central de reenvío, e un camiño funcional necesita ambas. Ningunha das dúas contas pode completalo soa.
Un camiño, dúas contas
Siga un paquete desde unha VPC spoke ata un prefixo local. A táboa de rutas da subrede spoke debe enviar ese prefixo á conexión da pasarela de tránsito, o que o propietario da VPC pode cambiar. Despois a pasarela debe ter na táboa asociada da conexión unha ruta que apunte á conexión VPN, o que só o propietario pode cambiar. O tráfico de retorno necesita o espello das dúas. Se falla calquera dos dous lados, obtén un camiño medio instalado que parece un problema de firewall.
Escriba ambos os cambios nun só ticket con dous asignados, ou terminaranse en semanas distintas.
Use ID de zona de dispoñibilidade cando a localización importe
Os nomes de zona son alias locais da conta. us-east-1a nunha conta non ten garantido ser a mesma zona física que us-east-1a noutra. Cando o deseño necesita unha conexión e unha carga de traballo na mesma zona, compare os ID de AZ e anóteos.
Comparar nomes produce un diagrama que parece correcto e un perfil de latencia que non o é. Comprobe iso mentres o diagrama aínda se está debuxando, non despois de que alguén mida a diferenza.
Deixar de compartir non corta o camiño dos datos
Quitar a compartición sente como unha revocación, e non é unha parada inmediata do tráfico. AWS documenta que unha conexión segue funcionando cando a pasarela deixa de estar compartida. O permiso para xestionar o recurso desaparece, mentres que a conexión existente segue reenviando ata que alguén a elimine ou a desactive. Planifique a revocación en dous pasos: quite a compartición e despois a conexión, co propietario facendo o segundo.
Se a compartición é o seu único control, non ten ningún control.
Manteña o rexistro de compartición e o rexistro de enrutamento xuntos
Dous artefactos responden a dúas preguntas distintas. O rexistro de compartición di quen pode traballar co recurso. As táboas de rutas din que redes poden falar realmente. Gárdeos xuntos coa mesma lista de propietarios, ou o próximo incidente comezará con alguén demostrando un permiso que nunca foi o problema.
Despois probe un fluxo en cada dirección e un prefixo que deba permanecer inalcanzable.