VPC Endpoints: Gateway vs Interface en AWS explicado

En pocas palabras: Los gateway endpoints de S3 y DynamoDB son gratis y evitan el NAT gateway; los interface endpoints, usados para el resto de servicios AWS vía PrivateLink, cobran por hora y por GB procesado, según el análisis técnico publicado el 28 de septiembre de 2026 en dev.to.

El tráfico de una subred privada de AWS hacia S3 rutea por el NAT gateway por defecto y se factura por GB procesado, aunque existe una alternativa gratuita desde hace años. Los VPC endpoints resuelven esto dándole a S3 y DynamoDB una ruta privada dentro de la VPC, sin pasar por internet, según describe el análisis técnico publicado el 28 de septiembre de 2026 en dev.to.

Un VPC endpoint es un mecanismo de AWS que conecta una VPC directamente con servicios como S3, DynamoDB o Secrets Manager sin salir a internet. Existen dos tipos bien distintos: el gateway endpoint, que es una entrada en la tabla de rutas solo para S3 y DynamoDB, y el interface endpoint, una ENI real respaldada por AWS PrivateLink para el resto de los servicios compatibles. Entender la diferencia entre VPC endpoints gateway vs interface cambia directamente qué servicios te conviene conectar y cuáles no — y, como vamos a ver, la respuesta correcta casi nunca es “todos”.

¿Por qué el tráfico de una subred privada a S3 pasa por el NAT gateway?

Porque una instancia en subred privada que llama a s3.ap-south-1.amazonaws.com hace exactamente lo mismo que haría llamando a cualquier host de internet: rutea al NAT gateway, traduce la IP de origen, sale por el internet gateway y vuelve por el mismo camino. Ambos extremos están dentro de AWS. El tráfico nunca necesitó salir de la red de Amazon.

Ahí está el problema que resuelven los VPC endpoints. Ponele que tenés una app en subred privada haciendo miles de requests a S3 por hora: cada uno de esos requests cruza el NAT gateway, se factura por GB, y en ningún momento sale realmente a “internet” en el sentido físico del término (las comillas son porque el propio diseño de AWS lo trata como si lo fuera). Lo explicamos a fondo en los fundamentos de AWS y sus security groups.

¿Qué es un gateway endpoint y cómo funciona?

Un gateway endpoint no es un dispositivo de red, es una entrada en la tabla de rutas que existe únicamente para S3 y DynamoDB. AWS inyecta automáticamente una ruta con una prefix list administrada; el tráfico que matchea los rangos de IP de S3 rutea directo al endpoint en lugar de ir al NAT.

resource "aws_vpc_endpoint" "s3" {
 vpc_id = aws_vpc.main.id
 service_name = "com.amazonaws.ap-south-1.s3"
 vpc_endpoint_type = "Gateway"
 route_table_ids = [aws_route_table.private.id]
}

Nada más que eso. Tres líneas de Terraform y una ruta que aparece sola en la tabla.

¿Cuánto cuesta el gateway endpoint de S3?

Cero. Sin cargo por hora, sin cargo por GB procesado. Esto lo hace casi un upgrade sin costo para cualquier VPC con subredes privadas que tocan S3: no hay motivo real para no agregarlo, salvo que directamente no uses S3 desde subred privada. Cubrimos ese tema en detalle en elegir un API Gateway en Rust o Go.

Eso sí, hay una limitación que conviene tener anotada en algún checklist. Los gateway endpoints se asocian a tablas de rutas específicas, no a toda la VPC. Subís el gateway endpoint a una VPC, la ruta se inyecta sola en la tabla de rutas que asociaste, probás desde una instancia en subred privada y confirmás que ya no sale por el NAT, pero si la semana que viene creás una subred nueva con su propia tabla de rutas, esa subred cae en NAT en silencio hasta que la asocies vos mismo al endpoint. ¿Y si te olvidás? Exacto, vuelve a facturarte por GB sin que nadie lo note hasta la próxima factura.

¿Qué es un interface endpoint y en qué se diferencia del gateway?

Un interface endpoint es una ENI real, provisionada en una subred que vos elegís, con IP privada de esa subred, respaldada por AWS PrivateLink. A diferencia del gateway endpoint, cubre prácticamente todos los demás servicios de AWS que soportan VPC endpoints: Secrets Manager, STS, SNS, ECR y varios más.

resource "aws_vpc_endpoint" "secretsmanager" {
 vpc_id = aws_vpc.main.id
 service_name = "com.amazonaws.ap-south-1.secretsmanager"
 vpc_endpoint_type = "Interface"
 subnet_ids = [aws_subnet.private_a.id, aws_subnet.private_b.id]
 security_group_ids = [aws_security_group.vpce_sm.id]
 private_dns_enabled = true
}

El control de acceso acá no pasa por la tabla de rutas, pasa por el security group de esa ENI. Con private_dns_enabled = true, AWS pisa el DNS público del servicio para que resuelva a la IP privada del endpoint dentro de la VPC, así que no hace falta tocar el SDK ni la configuración de la app. El costo es la contracara exacta del gateway endpoint: se factura por hora por cada zona de disponibilidad más un cargo por GB procesado, así que “agregar interface endpoints para todo” no es automáticamente una buena idea sin datos reales de uso detrás. En reducir costos de CloudWatch Logs con este gateway profundizamos sobre esto.

Característica	Gateway Endpoint	Interface Endpoint
Mecanismo	Entrada en tabla de rutas	ENI respaldada por PrivateLink
Servicios	Solo S3 y DynamoDB	La mayoría de los demás servicios AWS
Costo	Gratis	Por hora por AZ más por GB procesado
Control de acceso	Security group/NACL de la instancia	Security group propio del endpoint
DNS	No requiere cambios	Override de DNS privado si está habilitado
Multi-subred	Asociar la tabla de rutas por subred	Desplegar una ENI por cada AZ

¿Qué servicios de AWS justifican un interface endpoint?

STS, CloudWatch Logs y ECR son los tres candidatos que suelen justificar el costo por hora rápido en cualquier cuenta con cómputo relevante en subredes privadas. STS se llama para asumir roles IAM muchísimo más seguido de lo que parece a simple vista, CloudWatch Logs recibe el envío continuo de logs de apps con tráfico real, y ECR maneja los pulls de imágenes durante autoscaling o despliegues frecuentes de CI/CD.

Servicios de bajo tráfico son otra historia. Secrets Manager llamado una sola vez al arrancar, o SNS para notificaciones ocasionales, conviene evaluarlos con datos reales de Cost Explorer antes de aprovisionar por las dudas.

aws ce get-cost-and-usage \
 --time-period Start=2026-07-01,End=2026-08-01 \
 --granularity MONTHLY \
 --filter file://nat-gateway-filter.json \
 --metrics "UsageQuantity" "BlendedCost"

Corré algo así antes de decidir, no después.

Ejemplo hipotético: ¿cuándo el interface endpoint se paga solo?

Nota: lo que sigue es un ejemplo hipotético para ilustrar el razonamiento, no una cifra real de AWS ni un caso documentado. Imaginemos un equipo con una API en subred privada que hace un llamado a STS por cada request entrante para asumir un rol, y otro llamado a Secrets Manager una sola vez, al arrancar la instancia. Los dos servicios necesitan un interface endpoint si querés que ese tráfico deje de pasar por el NAT — pero la pregunta de “¿me conviene?” no tiene la misma respuesta para los dos.

Para STS, si el volumen de requests entrantes es alto, el tráfico que hoy cruza el NAT y se factura por GB probablemente ya supera, a lo largo de un mes, el cargo fijo por hora del interface endpoint (multiplicado por la cantidad de AZs donde lo despliegues). Ahí el endpoint tiende a pagarse solo. Para Secrets Manager, en cambio, si solo se llama una vez por instancia al iniciar, el volumen de datos que cruza el NAT es mínimo — y mantener una ENI corriendo 24/7 en cada AZ puede terminar costando más que lo que ahorrás. En ese caso hipotético, el gateway (gratis, porque hablamos de S3/DynamoDB) no aplica, así que la alternativa real es simplemente dejar que ese tráfico puntual siga por NAT y no complicarse con un endpoint que casi nunca se usa.

Un criterio simple para decidir sin perder una tarde

Más allá de la lista de STS, CloudWatch Logs y ECR que menciona la fuente original, sirve armar una regla propia por cuenta antes de correr Cost Explorer para cada servicio uno por uno: si un servicio se llama con una frecuencia comparable a la de las requests de la aplicación (en cada request entrante, en cada ciclo de autoscaling, en cada deploy), es candidato natural a interface endpoint. Si se llama una vez por vida de la instancia —al arrancar, en un cron semanal, en un job batch mensual— es más probable que el cargo por hora del endpoint nunca se recupere con el ahorro en NAT.

Este criterio no reemplaza el análisis con datos reales que sugiere la fuente original, pero sirve para descartar candidatos obvios antes de perder tiempo armando un filtro de Cost Explorer para cada servicio de la cuenta. Total, si el servicio se llama una vez cada mil años, ¿para qué vas a mantener una ENI prendida las 24 horas?

¿Qué errores de configuración rompen un VPC endpoint en producción?

El error más frecuente es un security group demasiado angosto en el endpoint, que produce un timeout indistinguible de una falla de ruteo pero en realidad es un problema de reglas en la ENI del endpoint, no en la instancia que llama. Relacionado: la migración de Ingress NGINX a Gateway API.

• Conflictos de DNS privado en diseños Transit Gateway o VPC peered: si dos VPCs conectadas tienen interface endpoints para el mismo servicio con DNS privado habilitado, una instancia en la VPC A puede terminar resolviendo hacia la ENI del endpoint en la VPC B. Hay que probarlo explícitamente en diseños hub-and-spoke.
• Endpoint desplegado en la AZ equivocada: sigue funcionando cross-AZ, pero suma cargo por transferencia entre zonas encima del costo por GB del endpoint. Hay que desplegarlo en cada AZ que tenga instancias llamando.
• DHCP option set o regla de Route 53 Resolver personalizada: si la VPC tiene resolución DNS custom, esa configuración puede pisar el override de la zona privada del endpoint y el tráfico vuelve a NAT aunque el endpoint esté bien configurado.

Qué significa esto para equipos que operan en Latinoamérica

Si administrás cuentas AWS desde Argentina, Chile o México, el NAT gateway suele ser una línea silenciosa en la factura que nadie revisa hasta fin de mes. Agregar el gateway endpoint de S3 esta semana, sin costo, es de las pocas optimizaciones que no tienen contra. Si además gestionás sitios web tradicionales fuera de AWS, con hosting VPS o dedicado en un proveedor como donweb.com, la misma lógica de mantener el tráfico interno sin salir a internet aplica igual, aunque el mecanismo técnico sea distinto.

Preguntas Frecuentes

¿Cuál es la diferencia entre gateway endpoint e interface endpoint en AWS?

El gateway endpoint es una entrada en la tabla de rutas, gratis, y solo existe para S3 y DynamoDB. El interface endpoint es una ENI real respaldada por PrivateLink, cubre casi todos los demás servicios y se cobra por hora por AZ más por GB procesado.

¿El VPC endpoint de S3 es gratis?

Sí, el gateway endpoint de S3 no tiene cargo por hora ni por GB procesado. La única condición es asociarlo manualmente a cada tabla de rutas nueva que crees, porque no se aplica a toda la VPC en forma automática.

¿Por qué mi tráfico a S3 pasa por el NAT gateway?

Porque sin un gateway endpoint configurado, una instancia en subred privada trata a S3 como cualquier host de internet: rutea al NAT, se traduce la IP y sale por el internet gateway aunque los dos extremos estén dentro de AWS.

¿Qué servicios de AWS necesitan interface endpoint?

Cualquier servicio de AWS que no sea S3 o DynamoDB y que necesites alcanzar sin salir a internet, como Secrets Manager, STS, ECR, CloudWatch Logs o SNS. STS, CloudWatch Logs y ECR suelen ser los que más rápido justifican el costo.

¿Cuánto cuesta un interface endpoint en AWS?

Se factura por hora por cada zona de disponibilidad donde despliegues la ENI, más un cargo por GB de datos procesados. Conviene revisar el uso real con Cost Explorer antes de desplegarlo en servicios de bajo tráfico.

Conclusión

La decisión entre VPC endpoints gateway vs interface no es simétrica: el gateway endpoint de S3 y DynamoDB es una acción de esta semana, sin análisis de costo necesario, mientras que cada interface endpoint requiere mirar datos reales de tráfico antes de sumarlo. Si tenés cómputo en subred privada llamando a S3 y todavía no agregaste el gateway endpoint, ese es el primer paso, hoy. Para el resto de los servicios, empezá por STS, CloudWatch Logs y ECR, aplicá el criterio de frecuencia de llamada antes de complicarte con Cost Explorer, y dejá que los números reales decidan el resto.

Fuentes

• VPC Endpoints: Gateway vs Interface, and the AWS Traffic That Shouldn’t Touch the Internet – análisis técnico original en dev.to