Conexión de varios VPC con el mismo bloque CIDR a un VPC compartido

En la nube AWS de mi empresa tenemos 4 VPCs, uno para cada uno de nuestros principales entornos API (dev, test, stage, prod). Con el fin de hacer que estos entornos sean lo más parecidos posible entre sí, todos ellos tienen su bloque CIDR establecido en 10.0.0.0/16.

Ahora ha surgido la necesidad de crear un service interno compartido entre estos entornos. Por razones de argumento, digamos que este nuevo service almacena los datos de logging de todos estos entornos. Este service existe en su propio VPC con un bloque CIDR de 10.1.1.0/24.

Al principio pensé que sería capaz de simplemente agregar conexiones de peering de todos los VPCs de entorno en el VPC de logging. Me encontré con un obstáculo cuando empecé a configurar las tablas de ruta. Hice una tabla de routes desde Dev -> Logging que enruta todo el tráfico con destino 10.1.1.0/24. Pero aún no puedo conectarme a mi server de logging desde dentro de dev. Parece que necesito agregar una tabla de routes para Logging -> Dev que enruta todo el tráfico con destino 10.0.0.0/16. Esto me permite conectarme al server de logging desde un server dev, pero ahora no puedo conectar ninguno de mis otros entornos al VPC de logging.

El server de logging nunca ha iniciado una connection con mis serveres de API, sólo necesita recibir y responder a las conexiones. Así que mi siguiente pensamiento fue que podría utilizar una puerta de enlace NAT en cada uno de los VPCs de entorno y, a continuación, la ruta de los que el logging de VPC. Desafortunadamente, parece que NAT Gateways están conectados directamente a Internet, y no quiero que mi logging de VPC esté conectado a Internet.

Siento que debe haber una manera de hacer este trabajo, pero no puedo pensar en uno. Por el momento siento que mi única opción es crear 4 VPCs de logging y ejecutar serveres de logging separados en cada uno de ellos, pero desde una perspectiva de costos esto realmente no me atrae.

    One Solution collect form web for “Conexión de varios VPC con el mismo bloque CIDR a un VPC compartido”

    En primer lugar, debo mencionar: se ha cometido un grave error al duplicar las subnetworkinges en los VPC. Incluso si hay casi cero oportunidad tendrá que la ruta de tráfico entre ellos, el espacio de direcciones RFC1918 es lo suficientemente grande como para dar a cada VPC una subnetworking única. Consulte con varias empresas sobre temas de AWS y mantengo una spreadsheet de "list de subnetworkinges maestras" para registrar subnetworkinges en uso al asignar VPCs a los clientes, para asegurar que no tenga subnetworkinges superpuestas.

    La respuesta obvia a su pregunta es volver a numerar sus VPC superpuestos. Esto va a ser doloroso, pero es la respuesta correcta a este problema, y ​​resolverá este problema para usted de una vez por todas.

    Si eso no es una opción, puedo pensar en un par de otras opciones:

    1. Utilice SQS para sus loggings: envíe loggings desde sus VPCs de aplicación a una queue SQS, anote con una ID de origen para cada uno de los VPC de su aplicación y luego consum los loggings de SQS de su VPC de logging. Además de resolver su problema declarado, esto pone un buffer altamente disponible entre los productores de loggings y los consumidores de logging. Esto le protege de la pérdida de loggings si su infraestructura de hipo, o si es necesario llevarlo hacia abajo para el mantenimiento.
    2. Exponga su punto final de logging mediante un IP público (ELB, EIP, etc.), firewall para que solo los IPs públicos de sus serveres de aplicaciones puedan golpearla y hacer que envíen sus loggings de esta manera. El tráfico permanecerá en la networking de AWS, y mientras esté encriptado y autenticado, no es un problema de security. Sin embargo, pagarás más por el ancho de banda.
    El linux y los temas del servidor de Windows, como ubuntu, centos, apache, nginx, debian y consejos de red.