En este artículo analizamos un escenario técnico habitual en arquitecturas centralizadas sobre AWS, donde el tráfico de salida a internet genera costes inesperados. Exploramos cómo se puede abordar el problema, mejorar la visibilidad y reducir el gasto sin comprometer la escalabilidad ni la seguridad.
El síntoma: costes outbound elevados
En muchas organizaciones, al revisar los informes de costes de AWS, aparece un patrón recurrente: gastos altos en la transferencia de datos hacia internet.
Este tipo de costes suelen pasar desapercibidos hasta que crecen demasiado. El problema no sólo es el volumen de tráfico, sino también la falta de visibilidad: no se sabe con precisión qué workloads, ni desde qué VPCs, están generando ese tráfico.
Análisis técnico: identificar el origen del tráfico saliente
1. Activación de VPC Flow Logs
Una primera medida consiste en habilitar VPC Flow Logs tanto en la VPC de inspección como en otras VPCs conectadas al Transit Gateway.
- Los logs se envían a Amazon S3.
- Se analizan con Amazon Athena creando tablas externas.
2. Enriquecimiento con datos de ENIs
Para mapear el tráfico a workloads específicos, se correlacionan los ENIs (Elastic Network Interfaces) con instancias EC2, servicios o nodos EKS. Esto permite:
- Identificar qué ENIs están generando tráfico saliente
- Relacionar cada ENI con su workload y su cuenta de origen
3. Consultas específicas en Athena
Se ejecutan consultas filtrando:
- Tráfico con dstaddr fuera de los rangos reservados para IPs privadas.
- Flujos con action = ACCEPT y interface_id asociada a la VPC outbound
- Mostrar resultados agregados por srcaddr, account_id y tgw_src_vpc_id para entender los patrones
El análisis puede revelar tráfico de salida innecesario como:
- Automatismos mal diseñados
- Aplicaciones legacy que llaman periódicamente a APIs públicas de AWS
- Servicios internos mal configurados
Acciones correctivas
1. Uso de Endpoints Privados (Gateway Endpoints)
Se pueden sustituir accesos públicos por privados para servicios como:
- Amazon S3
- Amazon DynamoDB
- Servicios internos expuestos públicamente
Una forma directa de reducir tráfico outbound innecesario es crear VPC Gateway Endpoints para servicios como S3 o DynamoDB. Esto permite enrutar las peticiones a través de la red privada de AWS de una forma muy económica.
También es habitual encontrar servicios internos a los que se acceden usando DNS públicos.
Esto puede resolverse configurando las VPCs y las Private Hosted Zones para forzar la resolución interna y mantener el tráfico dentro de la red privada.
2. Establecimiento de límites y alarmas
Para evitar futuros escenarios similares, se pueden aplicar las siguientes medidas de control:
- Creación de un dashboard de networking para mejorar la visibilidad y poder comprobar el tráfico entrante y saliente de cada uno de los attachments del Transit Gateway.
- Creación de alarmas para notificar si alguno de los attachment del Transit Gateway está superando el umbral máximo esperado de tráfico entrante o saliente.
Resultado final
Aplicando este enfoque, una organización puede:
- Identificar con precisión qué workloads generan el tráfico de salida
- Eliminar tráfico público innecesario redirigiéndolo a rutas privadas mediante Gateway Endpoints y DNS interno
- Establecer una base técnica para el control y la previsión de costes de red.
Lecciones clave
- El tráfico a internet puede ser uno de los costes más difíciles de auditar si no se monitoriza adecuadamente.
- VPC Flow Logs y Athena permiten un análisis granular sin necesidad de herramientas externas.
- Los VPC Gateway Endpoints privados son una solución sencilla, efectiva y segura para reducir tráfico saliente.
- La gestión de costes no es solo una cuestión financiera: es una pieza clave del gobierno Cloud.
¿Tienes una arquitectura similar o estás viendo costes que no sabes explicar?
En Cloudner te ayudamos a detectar estos patrones de tráfico, mejorar la visibilidad y optimizar el diseño de red para reducir costes sin comprometer seguridad ni escalabilidad.