AWS aquí. Tengo un servidor de aplicaciones simple que se ejecuta en instancias EC2 que se encuentran en un grupo de escalado automático ("destino") que está encabezado por un equilibrador de carga de aplicaciones (ALB). El nombre de dominio del ALB está asignado mediante CNAME en DNS a mi subdominio de desarrollo, por ejemplo, dev.myapp.example.com. Por lo tanto, puedo usar curl, wgetPostMan, etc. para activar solicitudes HTTP enhttp://dev.myapp.example.com y obtener respuestas de ellas, y esas solicitudes se equilibran de carga en cualquier instancia EC2 que esté detrás del ALB (en el grupo de escalado automático).
El servidor de aplicaciones que se ejecuta en esas instancias EC2 debe conectarse a una base de datos como servicio de terceros. Llamaremos a esta nube DB "MyCloudDB " a los efectos de esta pregunta.
Cuando aprovisiono una instancia EC2 manualmente e implemento mi servidor de aplicaciones allí, para que se comunique conMyCloudDB , necesito iniciar sesión en la MyCloudDBconsola web y acceder a la lista de IP pública de la instancia EC2 con una subred /32 (Sinceramente, no estoy seguro de por qué en la subred /32). Entonces, por ejemplo, si AWS asigna una IP pública para la instancia como, digamos, 1.2.3.4entonces necesito iniciar sesión MyCloudDBy agregar una entrada a la lista de acceso para 1.2.3.4/32. Entonces, y sólo entonces, el servidor de aplicaciones (que se ejecuta en la nueva instancia EC2) podrá conectarse a MyCloudDB.
Estoy tratando de descubrir cómo hacer que esta configuración de lista de permisos/acceso sea compatible con mi ALB y su grupo de escalado automático. Obviamente, las instancias EC2 en el grupo de escalado automático son efímeras y se activarán y desactivarán dependiendo de mis reglas de escalado automático. Dado que necesitamos que esto sea dinámico/elástico, necesito una forma de indicar MyCloudDBque "confíe" en cualquier solicitud proveniente de instancias EC2 detrás de mi ALB. Y obviamente, no relajar tanto la seguridad que me cree dolores de cabeza.
Ofrece MyCloudDB3 tipos de opciones de acceso a la red:
- Lista de acceso IP (_lo que estoy usando actualmente, exclusivamente)
- Interconexión de VPC
- esto permite emparejar la VPC de mi aplicación con la
MyCloudDBVPC
- esto permite emparejar la VPC de mi aplicación con la
- Punto final privado
- permite que AWS PrivateLink se conecte a
MyCloudDB
- permite que AWS PrivateLink se conecte a
- API REST de gestión
- me permite administrar la Lista de Acceso IP pero vía API RESTful (servicio web)
- entonces podría crear un enlace del ciclo de vida de la instancia EC2 para ejecutar un script que agregue la dirección IP de la instancia a la
MyCloudDBlista de acceso IP a travéscurlde alguna otra herramienta.
Entonces, desde el punto de vista de la automatización, las 3 opciones que tengo son en realidad: VPC Peering, punto final privado (PrivateLink) o llamadas API. Puedo separar los pros y los contras de la opción de llamada API, pero me cuesta "ver el bosque a través de los árboles" en la opción VPC Peering vs PrivateLink.
Allamada importanteAquí está: eventualmente tendré plantillas de CloudFormation que administrarán la implementación de este ALB en entornos nuevos (efímeros). Entonces, no solo necesito que esta solución de conexión funcione para instancias EC2 ubicadas detrás de ALB, sino que también necesito que funcione con ALB que se aprovisionarán a través de CloudFormation.
Dada mi situación, contexto y necesidades, ¿cuáles son las ventajas/desventajas de VPC Peering vs PrivateLink?
Respuesta1
Esto es exactamente para lo que se creó PrivateLink. Efectivamente colocan una interfaz de red en su VPC, usted accede a ella. Por su parte, llega a un NLB y luego va a su base de datos. Esto es lo menos privilegiado y es lo que yo haría.
El emparejamiento de VPC abre más de su red a más de su red. Si sus rangos de IP chocan, se vuelve más difícil. No veo ninguna ventaja aquí en esta situación.
Si la Lista de acceso de IP fuera la única opción, necesitaría IP estáticas para su grupo de escalado automático. Esto se lograría creando una puerta de enlace NAT en cada subred e incluyendo en la lista blanca sus IP elásticas.