VPC Endpoints centralizados: qué son y cómo conectarse de forma segura.

En un post anterior, estuvimos viendo cómo centralizar la salida a internet en un modelo de Networking centralizado y comentamos que este tipo de centralización permite añadir más soluciones y features a nuestros entornos. Hoy vamos a ir un poco más allá, centralizando los VPC Endpoints y permitiendo que diferentes VPCs los consuman de forma transparente. Es un pequeño paso más en centralizar ciertos recursos de red y que tiene algunas ventajas interesantes.

¿Qué es un VPC Endpoint?

Un VPC Endpoint es un recurso que permite consumir servicios de AWS de forma privada, de forma que consumimos el servicio utilizando una ip privada en vez de conectarnos a las IPs Públicas del servicio.

VPC Endpoints utiliza AWS PrivateLink para generar esta conectividad privada y existen dos tipos de VPC Endpoints, siendo los de tipo interface endpoints los que vamos a poder centralizar.

Estos endpoints generan una interfaz de red dentro de las subnets que le indiquemos de nuestra VPC. Esto permite la conectividad utilizando una IP dentro de nuestro rango privado.

Este servicio tiene muchas ventajas, la primera y más clara es que la conectividad se produce dentro de la VPC, por tanto, no es necesario utilizar NAT Gateways u otra solución de Egress para comunicarnos con los servicios de AWS.

También a nivel seguridad es importante, ya que aunque no salimos de AWS, utilizar IPs públicas genera ciertas reticencias en los equipos de Seguridad y en ocasiones para cumplir ciertos niveles de Compliance es necesario que toda la comunicación sea privada.

Por último, también podemos obtener mejoras en cuanto a costes, ya que el coste por Datos procesados es mucho menor utilizando VPC Endpoints que NAT Gateway u otras soluciones.

Incluso si utilizamos Appliances para el Egress, reducir los datos que tiene que procesar el appliance hacia servicios AWS es interesante, ya que reducimos la carga y, por tanto, la computación (podemos utilizar instancias más pequeñas y económicas).

¿Por qué centralizar VPC Endpoint?

Ya hemos hablado de las bondades del servicio, pero a veces no es un servicio fácil de usar. Se trata de un servicio de Infraestructura, que requiere saber qué Endpoints de AWS voy a usar y muchas veces no se utiliza por desconocimiento del servicio. Además de esto, el servicio tiene coste por Endpoint desplegado, por lo que en compañías que utilizan múltiples Endpoints el coste de estos puede subir mucho.

Por este motivo, si disponemos de una solución centralizada de Egress o si ya tenemos Transit Gateway configurado, utilizar este servicio tiene muchas ventajas:

• Ahorramos costes, al tener menor número de Endpoints.
• Si ofrecemos el servicio como parte de una Baseline de Cuenta de AWS, todas las cuentas van a disponer del servicio de forma automática y transparente para los proyectos.
• Aumentamos el compliance de seguridad al utilizar comunicación totalmente privada con los servicios de AWS.

Arquitectura de VPC Endpoints centralizados

Esta arquitectura utiliza Transit Gateway de forma que pueda interconectar las VPCs con una VPC en la que se desplieguen los endpoints centralizados.

Es una solución centralizada que requiere de Transit Gateway, por lo que si no tienes un Transit Gateway en uso o planeas implementarlo para otros casos de uso, no tiene sentido.

Por otro lado, requiere de route 53 para que la resolución del nombre del Endpoint público resuelva una nuestro VPC Endpoint.

Para esto hay que generar una Hosted Zone con el nombre del endpoint público, asociada a la VPC donde tenemos los endpoints dentro de esta hosted zone se generan los registros dns requeridos.

Ahora vamos a ver la configuración un poco más en detalle.

Transit Gateway

A nivel de Transit Gateway, necesitamos que las VPCs vean la Red de Endpoints VPC y para ello simplemente necesitamos generar las rutas para comunicar nuestras VPCs con la Endpoints VPC.

En este caso tenemos 3 tablas de rutas, siendo la primera una tabla de rutas para VPC A y VPC B, que enruta entre ellas, bloquea el routing hacia VPC C y VPC D y tiene una ruta hacia la Endpoints VPC.

La siguiente tabla de rutas es igual, pero para las VPC C y D y, por último, tenemos la tabla de rutas de Endpoints VPC que permite el enrutamiento a todas las VPC para poder tener ruta de vuelta hacia estas.

VPC Endpoint

Una de las ventajas es que podemos generar tantos endpoints como necesitemos, lo cual es bastante sencillo como vamos a ver a continuación.

La primera parte de generar un endpoint es asignarle nombre y seleccionar el tipo de endpoint que en este caso será a un servicio de AWS.

Tenemos que seleccionar el endpoint y podemos filtrar por nombre. Vamos a generar un endpoint para s3 de tipo interface, ya que como hemos comentado, los endpoints de tipo Gateway no se pueden centralizar.

Nota: solamente S3 y DynamoDB tienen la opción de desplegar endpoints de tipo Gateway y estos solamente permiten su uso desde dentro de la misma VPC, de ahí que no se puedan centralizar.

Los endpoints son regionales, por tanto, solo veremos los endpoints de la región en la que estemos desplegados.

Seleccionamos la VPC donde vamos a desplegar. En este punto podemos generar el nombre DNS automáticamente, pero esta opción no es válida para centralizar endpoints, ya que no gestionaremos la Zona DNS (Se generaría fuera de nuestra cuenta). Por este motivo no marcamos esa opción.

Una vez seleccionada la VPC, seleccionamos las subnets en las que desplegamos los endpoints.

Además, tenemos que asignar un Security Group y este debe permitir el acceso al puerto 443, para que podamos acceder al servicio desde los orígenes que definamos.

Nota: las llamadas a un endpoint de AWS son al puerto 443.

Por último, podemos generar una Policy para definir quién puede utilizar el endpoint vía política, en un endpoint centralizado dejamos la policy como Full Access, ya que no vamos a restringir su uso.

Una vez terminado tendremos el endpoint disponible.

Hosted Zones

Ya tenemos un endpoint desplegado, pero aunque tengamos comunicación vía Transit Gateway con él, no vamos a poder acceder a no ser que ataquemos al nombre DNS del endpoint. Ya que queremos que todos los proyectos lo utilicen de forma transparente, tenemos que cambiar la resolución para que cuando ataquemos al nombre DNS del servicio, este apunte al endpoint que hemos generado.

La solución es generar zonas de DNS con los nombres de los endpoints de los servicios de AWS y crear registros que apunten a los VPC Endpoints que generemos.

En el caso de S3, para la región de eu-west-1 hay 4 nombres de DNS para este endpoint, por lo que tenemos que generar las 4 hosted zones:

• s3.eu-west-1.amazonaws.com
• s3.eu-west-1.amazonaws.com
• s3-control.eu-west-1.amazonaws.com
• s3-accesspoint.eu-west-1.amazonaws.com

Este proceso lo tenemos que repetir por cada endpoint que generemos.

Una Hosted Zone es bastante sencilla de generar y solamente necesitamos el nombre de la zona DNS a generar e indicar que es privada.

Si generamos zonas privadas, como en este caso, tenemos que especificar la VPC que vamos a asociar, que en nuestro caso es nuestra VPC donde hemos generado el Endpoint. Lo interesante aquí es que podemos asociar más VPCs como en este caso que asociamos todas las VPCs que tenemos.

Si queremos asociar VPCs que están en cuentas diferentes, primero tenemos que autorizar la asociación. Esto lo podemos hacer desde la cuenta donde hemos creado la Hosted Zone, utilizando el comando de CLI create-vpc-association-authorization o utilizando su acción homóloga vía API.

Una vez generada la asociación podemos realizar la asociación desde la cuenta donde esté la VPC desplegada con el comando de CLI associate-vpc-with-hosted-zone o utilizando su acción homóloga vía API.

Nota: no es posible realizar estas acciones desde la consola. Sí que es posible realizarlas utilizando IAC, pero nunca las vamos a ver en la consola desde la cuenta donde esté desplegada la VPC. Solamente es posible verlo desde API o CLI.

Una vez generada la zona, tenemos que generar los registros DNS. Para ello, realizamos los siguientes pasos:

• Primero, un registro al nombre de la Hosted Zone de tipo A apuntando al VPC Endpoint.

• Por último, generamos un registro wildcard de tipo A apuntando al VPC Endpoint.

Una vez generadas todas las hosted zones y todos los registros, desde las VPC resolveremos las IPs privadas de los VPC Endpoints y debido a que tenemos comunicación privada via Transit Gateway podremos conectarnos con estos endpoints de forma privada y segura.

Al haber generado zonas DNS con los nombres de los endpoints, no requerimos realizar ninguna tarea, ya que desde todas las VPC asociadas se resolverán los endpoints desplegados de forma privada. Así garantizamos que la solución es transparente para los diferentes proyectos, ya que no requiere ninguna modificación por su parte e inmediatamente tengamos desplegada la solución, van a utilizar los VPC Endpoints.

Conclusiones

Desplegar esta solución vía consola es un poco tediosa, si desplegamos muchos endpoints. Sin embargo, realizarla vía IaC es más sencillo y además la podemos integrar en la generación de nuevas cuentas, permitiendo que todos los proyectos tengan esta funcionalidad de base y de forma transparente.

Como pega, dentro de una cuenta distinta a donde se desplieguen los VPC Endpoints no es posible ver que los tenemos compartidos desde la consola (vía API o CLI si es posible). Esto quita bastante visibilidad dentro de un proyecto que utilice los endpoints, aunque si hacemos pruebas de resolución, vamos a ver que resuelven los endpoints de forma privada correctamente.

Puede pasar que algún servicio de AWS recomiende comunicación privada desplegando endpoints dentro de la cuenta, sin ser consciente que realmente estamos utilizando endpoints centralizados. Esto me ha pasado con Airflow, por ejemplo.

También es importante conocer que algunos endpoints no son compatibles con esta metodología. Por ejemplo, no es compatible con API Gateway o con SFTP, por ejemplo. Ya que estos servicios funcionan 1 a 1, es decir, el endpoint tiene que estar en la misma VPC donde tenemos el recurso desplegado.

Por lo demás, es una solución muy útil de cara a centralizar parte del Networking y simplificar los despliegues para los proyectos en entornos grandes.

Hay multitud de ejemplos, uno de ellos es desplegar el Endpoint de SSM de forma automatizada para todos los entornos que generemos y así no requerir acceso a internet para acceder a las instancias EC2 utilizando Session Manager o Fleet Manager.

Como ventaja adicional al centralizar también ahorramos costes al utilizar un menor número de endpoints. En eu-west-1 (Irlanda) un Endpoint en 2 AZs tiene un coste de unos 16$ al mes y de 24$ al mes en 3 AZs. Si desplegamos 10 endpoints en 100 cuentas, el coste puede dispararse a 16.000$ al mes o 24.000$ al mes dependiendo del número de AZs. En este tipo de casos centralizar puede reducir considerablemente nuestros costes.

Resumiendo, esta arquitectura es bastante útil en entornos donde tengamos desplegado Transit Gateway y necesitemos utilizar VPC Endpoints.