Transit Gateway compartido: quién posee las rutas en AWS RAM
Compartir por RAM permite que otra cuenta adjunte una VPC, pero las tablas de rutas, las asociaciones y las propagaciones se quedan con el propietario de la pasarela. Aquí está el límite.
Compartir una Transit Gateway con Resource Access Manager hace una cosa concreta: permite que otra cuenta llame a un conjunto definido de API de adjunción contra un recurso que no posee. No transfiere la pasarela, sus tablas de rutas ni el derecho a decidir cómo se reenvía el tráfico. La gente asume lo contrario porque la adjunción aparece en la consola del receptor y funciona de inmediato, lo que se siente como propiedad. El mecanismo subyacente es una concesión de permiso sobre un recurso compartido, y cada objeto hijo permanece dentro del límite de la cuenta del propietario. Esa separación explica la mayoría de los tickets de acceso denegado en torno al tránsito compartido.
Qué delega realmente el uso compartido
Un uso compartido de recursos nombra un recurso, un principal y un permiso administrado. El permiso enumera las acciones que ese principal puede realizar, y para una Transit Gateway esa lista cubre las operaciones de adjunción sobre el recurso compartido.
Cualquier cosa fuera de la lista falla en la API y no en la consola, por eso el error suele aparecer la primera vez que se ejecuta un script.
Las tablas de rutas, las asociaciones y las propagaciones se quedan con el propietario
El reenvío lo deciden tres objetos hijos: con qué tabla de rutas se asocia una adjunción, a qué tablas se propaga y qué rutas contienen esas tablas. La documentación de uso compartido de AWS indica que un receptor no puede crear, modificar ni eliminar tablas de rutas de la pasarela de tránsito ni sus asociaciones y propagaciones mediante el uso compartido. Esas llamadas pertenecen a la cuenta propietaria. Un receptor que necesita una asociación nueva está pidiendo un cambio administrativo, no ejerciendo un permiso que olvidó habilitar.
La tabla de abajo es la separación que pongo en los documentos de diseño, porque sobrevive a los cambios de personal.
| 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 la fila central con atención: el propietario de la VPC controla las rutas de su subred, el propietario de la pasarela controla la decisión central de reenvío, y un camino funcional necesita ambas. Ninguna de las dos cuentas puede completarlo sola.
Un camino, dos cuentas
Siga un paquete desde una VPC spoke hasta un prefijo local. La tabla de rutas de la subred spoke debe enviar ese prefijo a la adjunción de la pasarela de tránsito, lo que el propietario de la VPC puede cambiar. Luego la pasarela debe tener en la tabla asociada de la adjunción una ruta que apunte a la adjunción VPN, lo que solo el propietario puede cambiar. El tráfico de retorno necesita el espejo de ambas. Si falla cualquiera de los dos lados, obtiene un camino medio instalado que parece un problema de firewall.
Escriba ambos cambios en un solo ticket con dos asignados, o se terminarán en semanas distintas.
Use ID de zona de disponibilidad cuando la ubicación importe
Los nombres de zona son alias locales de la cuenta. us-east-1a en una cuenta no tiene garantizado ser la misma zona física que us-east-1a en otra. Cuando el diseño necesita una adjunción y una carga de trabajo en la misma zona, compare los ID de AZ y anótelos.
Comparar nombres produce un diagrama que parece correcto y un perfil de latencia que no lo es. Compruébelo mientras el diagrama aún se está dibujando, no después de que alguien mida la diferencia.
Dejar de compartir no corta la ruta de datos
Quitar el uso compartido se siente como una revocación, y no es una parada inmediata del tráfico. AWS documenta que una adjunción sigue funcionando cuando la pasarela deja de estar compartida. El permiso para administrar el recurso desaparece, mientras que la adjunción existente sigue reenviando hasta que alguien la elimine o la desactive. Planifique la revocación en dos pasos: quite el uso compartido y luego la adjunción, con el propietario realizando el segundo.
Si el uso compartido es su único control, no tiene ningún control.
Mantenga el registro de uso compartido y el registro de enrutamiento juntos
Dos artefactos responden a dos preguntas distintas. El registro de uso compartido dice quién puede trabajar con el recurso. Las tablas de rutas dicen qué redes pueden hablar realmente. Guárdelos juntos con la misma lista de propietarios, o el próximo incidente empezará con alguien demostrando un permiso que nunca fue el problema.
Luego pruebe un flujo en cada dirección y un prefijo que deba permanecer inalcanzable.