Dos cuentas de AWS, una red local: ¿qué camino?

El planteamiento obvio es peering frente a VPN, y es el planteamiento equivocado. Una VPC emparejada no puede tomar prestada la conexión VPN de su vecina para enrutar de extremo a extremo, así que esa opción nunca estuvo sobre la mesa, diga lo que diga una tabla de rutas. Lo que realmente elige es entre un concentrador de red compartido, dos rutas VPN independientes y una entrada de aplicación estrecha. Cada una responde a una pregunta distinta sobre quién es dueño del enrutamiento.

Tres opciones y la que no es una opción

Empiece por borrar la idea del peering y luego compare lo que queda por la propiedad y no por la simplicidad del diagrama. La tabla siguiente es la decisión en forma comprimida.

Si la cuenta A necesita llegar a toda una red local, la fila del proxy tiene la forma equivocada. Si la cuenta A necesita una API, las dos primeras filas son más red de lo que pide el requisito.

Cuándo gana el Transit Gateway compartido

Un Transit Gateway conecta cada VPC y la VPN como redes separadas, y el uso compartido entre cuentas permite a los dueños de las VPC usar el concentrador sin fusionar cuentas. Ese es el atractivo: un lugar donde los prefijos locales se encuentran con las redes de AWS, y un lugar para razonar qué conexión aprende qué ruta.

Conectarlo todo no significa permitirlo todo. La asociación y la propagación deciden qué conexión usa qué tabla de rutas, así que dos prefijos de VPC pueden llegar cada uno a un servicio local mientras su acceso mutuo queda excluido por el diseño del concentrador. El lado local sigue necesitando rutas de retorno para los prefijos de AWS, y eso es un cambio de otro equipo.

El coste es organizativo tanto como financiero. El dueño del concentrador controla relaciones de enrutamiento de las que dependen otros equipos, así que un cambio en una conexión puede mover tráfico de un servicio del que el dueño del concentrador nunca ha oído hablar. Las horas de conexión y el procesamiento de datos se acumulan con cada red que conecta, y por eso los concentradores suelen crecer más rápido que el equipo que los gestiona.

Cuándo ganan las VPN separadas o un proxy estrecho

Dos VPN independientes encajan en un despliegue pequeño con límites operativos reales: cada cuenta cambia sus propios túneles y ninguna puede romper la otra editando una tabla de rutas. Los límites están en el lado local. La pasarela par necesita capacidad para los túneles adicionales, los planes de direcciones no deben solaparse y dos configuraciones que anuncian los mismos prefijos necesitan una preferencia deliberada en lugar de esperanza.

Un proxy es la interfaz más estrecha. Si la cuenta A necesita una base de datos o una API en la cuenta B, un intermediario acotado le da una entrada definida con su propia historia de autenticación, registro y disponibilidad. También es la opción más propensa a un uso indebido: un intermediario que reenvía a cualquier destino privado se ha convertido en un relé sin restricciones con pasos extra, y no se comportará como tránsito transparente de VPC a red local para nada más.

Conviene leer las restricciones del peering de VPC antes de todo esto, porque explican por qué la cuarta idea vuelve una y otra vez y por qué no puede funcionar.

Elija la interfaz más estrecha que cumpla el requisito

Ordene las preguntas: ¿necesita A una red, un conjunto de redes o un solo servicio? ¿El equipo local quiere una ruta o varias? ¿Quién puede cambiar el enrutamiento del tráfico del otro equipo? La primera respuesta que produce la interfaz más estrecha es la arquitectura, y todo lo demás es implementación.

Registre la respuesta con el plan de prefijos, la propiedad de las rutas, el inventario de túneles o conexiones y el modo de fallo que espera cada lado. Cuando alguien pregunte más adelante por qué la cuenta A no puede usar sin más la VPN de la cuenta B, ese registro es la respuesta, y le ahorra volver a discutir las mismas tres opciones en el próximo proyecto.