Hola comunidad,
En mi post anterior, exploramos cómo conectarnos a instancias EC2 completamente privadas utilizando AWS Systems Manager (SSM) y VPC Endpoints, logrando eliminar la necesidad de exponer puertos a internet o lidiar con Bastion Hosts y Key Pairs. Si no lo has leído, te invito a revisarlo primero: https://dev.to/pangoro24/aws-privatelink-acceso-a-instancias-ec2-privadas-con-y-ssm-en-espanol-sencillo-2kg3
Hoy continuamos con la segunda parte de esta serie. Aprovechando la infraestructura que ya construimos, vamos a abordar una duda de diseño muy común: ¿Cuál es la diferencia entre los VPC Endpoints de tipo Gateway y de tipo Interface?, y en qué casos usar cada uno.
Para hacerlo fácil de entender, usaremos como ejemplo el acceso a uno de los servicios más populares: Amazon S3. Además, he actualizado el repositorio del demo para que veamos la teoría aplicada a la práctica.
VPC Endpoints: Gateway vs Interface (El caso de S3)
Cuando tienes una instancia privada (sin salida a internet vía Internet Gateway o NAT Gateway) y necesitas leer o escribir archivos en un bucket de S3 de forma segura a través de la red interna, necesitas un VPC Endpoint para acceder al servicio. Actualmente tienes dos opciones principales y aquí te resumo de manera sencilla sus diferencias fundamentales:
Gateway VPC Endpoint:
Cómo funciona: No crea una interfaz de red física virtual (ENI) ni consume direcciones IP de tu subred. En su lugar, agrega automáticamente una ruta (mediante un Prefix List) en la Tabla de Rutas (Route Table) de tu VPC. Todo el tráfico dirigido hacia S3 es enrutado internamente por ahí.
Costo: ¡Es totalmente gratuito! No hay cargo por hora de uso ni por procesamiento de datos.
Limitación principal: El acceso está estrictamente limitado a los recursos que viven dentro de esa VPC. No puedes usar un Gateway Endpoint para acceder a S3 directamente desde tu red on-premises (vía VPN o Direct Connect) ni desde otras VPCs conectadas.
Imagen de referencia de: https://docs.aws.amazon.com/vpc/latest/privatelink/gateway-endpoints.html
Interface VPC Endpoint (AWS PrivateLink):
Cómo funciona: Este fue el tipo de endpoint que usamos en el primer post para SSM. Crea una Interfaz de Red Elástica (ENI) dentro de la subred que elijas, asignándole una dirección IP privada. El tráfico se dirige hacia esa IP de manera local.
Costo: Tiene un costo asociado por hora por Zona de Disponibilidad, más un cargo por cada GB de datos procesado.
Ventaja principal: Al estar representado por una IP privada dentro de tu red, permite el acceso a S3 desde redes on-premises (mediante AWS Direct Connect o Site-to-Site VPN) o desde entornos multi-cuenta centralizados.
La Regla de Oro para S3:
Si el tráfico hacia tus buckets nace exclusivamente desde instancias EC2 u otros recursos alojados dentro de esa misma VPC, opta siempre por el Gateway Endpoint para ahorrar costos y simplificar el enrutamiento. Si requieres acceso desde on-premises o arquitecturas hub-and-spoke complejas, el Interface Endpoint es el camino a seguir.
La Solución: Acceso a S3 en nuestro Demo
Para no quedarnos solo en la teoría, he aplicado estos conceptos en la misma arquitectura base que desplegamos anteriormente.
En esta actualización, he modificado las plantillas de infraestructura en el repositorio para incluir el aprovisionamiento de un VPC Endpoint para S3, dejándote el código listo para que despliegues el de tipo Gateway o el de tipo Interface, para que puedas usar el que mejor se adapte a tu caso de uso. Si optas por desplegar el Gateway, CloudFormation se encarga de inyectar las reglas necesarias en la tabla de rutas de nuestra subred privada; si optas por el Interface, se aprovisionará una interfaz de red local. De cualquier manera, la instancia a la que accedemos vía Fleet Manager ahora tiene el camino despejado para interactuar con Amazon S3 sin tocar en ningún momento el internet público, manteniendo el esquema de "Zero Trust" a nivel de red externa.
¿Dónde puedo ver un ejemplo de implementación?
He subido los cambios a las plantillas de CloudFormation en el mismo repositorio público. Allí encontrarás el código necesario en la carpeta de vpce para ver cómo se declara un Gateway Endpoint y se asocia a las tablas de enrutamiento.
Repositorio:
https://github.com/pangoro24/aws-privatelink-private-instance-ssm
Si sigues la guía de despliegue actualizada en el Readme:
Desplegarás la VPC privada.
Desplegarás los Endpoints de interfaz (para SSM) y el nuevo Endpoint para S3.
Desplegarás la instancia EC2.
Al conectarte a tu instancia mediante Systems Manager Fleet Manager (sin internet), podrás abrir la consola y ejecutar comandos contra el CLI de AWS S3 (por ejemplo, listar buckets o descargar archivos) y verás que la comunicación es completamente exitosa.
Bonus: te dejo también la plantilla de un bucket de s3 mantener todo por infraestructura como código :)
Nota: Como siempre, no olvides eliminar el stack de CloudFormation cuando termines el laboratorio para evitar cobros de los Endpoints de Interfaz y la instancia EC2 si no los vas a necesitar.
Conclusión
Entender la diferencia entre un Gateway y un Interface Endpoint es clave para diseñar arquitecturas en la nube que sean seguras, escalables y costo-efectivas. Mientras que la flexibilidad de las IPs de un Interface Endpoint (PrivateLink) nos salva la vida en arquitecturas híbridas, los Gateways siguen siendo los reyes indiscutibles para el acceso interno hacia Amazon S3 y DynamoDB con un costo de $0.00.
En la próxima entrega, presentaré un caso de uso muy interesante y común sobre los VPC Endpoints de tipo Interface; algo que todo ingeniero de nube debería conocer, ya que puede que te toque implementarlo.
Gracias por leer.
Top comments (0)