En la infraestructura basada en la nube de hoy en día, las empresas suelen implementar VPC endpoints para facilitar la comunicación segura y privada entre sus servicios y los de AWS. Un VPC endpoint es un túnel que nos permite comunicarnos sin la necesidad de salir a internet, manteniendo la seguridad en toda la comunicación. Es por eso que en Pomelo optamos por utilizarlos.
Sin embargo, siendo AWS nuestro proveedor de infraestructura, crear y mantener estos VPC endpoints puede generar costos significativos, especialmente si se utilizan numerosas cuentas, ya que se requiere un endpoint por servicio o componente (RDS, STS, IAM, SSM, SQS, etc) utilizado en cada VPC.
Por esta razón, les queremos contar los beneficios de implementar un enfoque centralizado de VPC endpoints, decisión que nos permite mantener la comunicación segura de punta a punta y optimizar los costos. ¡Una vez desplegado todo el proyecto, pudimos observar una disminución de costos de un 60% en el billing relacionado a networking de Pomelo!
¿Cómo era nuestra arquitectura previa a la centralización de endpoints?
En sus inicios, Pomelo contaba con más de 20 endpoints por VPC y resultaba muy costoso el mantenimiento de cada uno. Les mostramos a continuación un gráfico donde por cada VPC, existían VPC Endpoints por servicio, -Spoke A hace referencia a una VPC y Spoke N a múltiples VPC-:
Por lo tanto, nos propusimos realizar una optimización de estos recursos, reduciendo los endpoints de servicio utilizados en una única VPC centralizada. De esta manera, logramos que todas las VPC de Pomelo puedan consumir los endpoints utilizando el ruteo por Transit Gateway e inspeccionando el tráfico a través del Network Firewall.
Manos a la obra: ¿Cómo lo llevamos a cabo?
Para lograr que un microservicio de Spoke VPC pueda tener visibilidad de los endpoints centralizados, elegimos el camino de las Resolver rules de Route53.
Estas reglas permiten lograr cierto comportamiento al momento de resolver nombres de dominio, definiendo reglas particulares que se comparten con distintas VPC. Por ejemplo, podríamos definir una regla con dominio “development.internal” y en caso de que la Spoke VPC quiera consumir un registro que tenga ese dominio (“application.development.internal”) y no lo encuentre en el Resolver local de la VPC, procederá a resolverlo a través de la regla compartida.
La regla implementada, una vez compartida por RAM (Resource Access Manager) con la cuenta y VPC correspondiente, comienza a impactar en los servicios dentro de esa red:
- El comportamiento es similar al de todos los resolver dentro de AWS: el microservicio corriendo en la Instance EC2, al querer consumir un servicio de AWS (como puede ser sns.us-east-1.amazonaws.com) busca localmente el registro DNS.
- En caso de no encontrar el match, ingresa en la Rule compartida y definida en nuestro caso como “amazonaws.com”. Esta redirige el tráfico hacia el resolver centralizado mediante el Outbound endpoint de Route 53, que vive en la VPC de Shared Services (tal como se observa en la VPC del lado derecho de la imagen).
- El Outbound endpoint envía el tráfico al Resolver que tiene asociado la IP “10.1.0.2”, tomando como valor del cuarto octeto 2, ya que AWS reserva esta IP para la resolución DNS de consultas al Puerto 53.
De esta forma, el microservicio que origina la consulta recibe la IP de destino correspondiente para establecer la comunicación con el servicio de AWS requerido.
Para lograr nuestro objetivo utilizamos los siguientes servicios:
- Transit Gateway: Para comunicar dos o más VPC.
- Network Firewall: Para inspeccionar el tráfico a nivel Red.
- Resource Access Manager: Para compartir recursos de una cuenta de AWS a otras.
- Route 53 Outbound endpoints: Para recibir consultas DNS externas y redirigirlas hacia la VPC.
- Route 53 Resolver rules: Para resolver un dominio por su IP.
Para limitar problemas en la implementación de una arquitectura similar, hay que considerar algunos puntos importantes:
- Las tablas de ruteo de las VPC deben tener visibilidad del Transit Gateway.
- Si existe escaneo de Firewall interno, especial atención a la configuración de reglas y puertos habilitados.
- Security Groups asociados a los VPC endpoints deben permitir los CIDRs de origen.
- Solo se migraron los endpoints del tipo Interface, ya que los del tipo Gateway no tienen un costo asociado.
Conclusiones
Esta solución presenta una mejora en cuanto a la escalabilidad a futuro si se desean crear nuevas VPC: una vez realizado el ruteo entre ellas a través del Transit Gateway, solo es necesario asociar la Resolver Rule a la Spoke VPC que necesite consumir los endpoints centralizados.