VPC Endpoints

Por defecto, cuando un recurso dentro de una VPC necesita comunicarse con un servicio AWS (como S3, SSM, STS, CloudWatch), el tráfico sale por internet pasando por un NAT Gateway o Internet Gateway. El VPC Endpoint es un recurso que permite esta comunicación de forma privada, sin que el tráfico salga de la red de AWS.

Por Qué Usar VPC Endpoints

Existen tres motivaciones principales:

• Entornos sin acceso a internet: Subnets privadas que no tienen NAT Gateway no pueden alcanzar servicios AWS por el camino público. Los VPC Endpoints son la única forma de comunicación en estos casos.
• Seguridad y compliance: En entornos regulados, es común exigir que el tráfico nunca pase por internet pública, aunque esté encriptado. Los VPC Endpoints garantizan que la comunicación permanece dentro del backbone de AWS.
• Costo: El tráfico que pasa por un NAT Gateway tiene costo por GB procesado. Los VPC Endpoints (especialmente los Gateway Endpoints) eliminan este costo para servicios de alto volumen como S3 y DynamoDB.

Tipos de VPC Endpoints

AWS ofrece dos tipos de endpoints, con mecanismos de funcionamiento diferentes:

Interface Endpoint (PrivateLink)

El Interface Endpoint crea una ENI (Elastic Network Interface) dentro de tu subnet con una IP privada. Cuando el recurso hace una llamada al servicio AWS, el tráfico se dirige a esta ENI en lugar de salir por internet.

Características:

• Crea una ENI con IP privada en la subnet elegida.
• Soporta la mayoría de los servicios AWS (SSM, STS, CloudWatch, ECR, Secrets Manager, KMS, etc.).
• Puede ser protegido con security groups (controlas qué recursos pueden acceder al endpoint).
• Soporta DNS privado: cuando está habilitado, las llamadas al endpoint público del servicio (ej: ssm.us-east-1.amazonaws.com) se resuelven automáticamente a la IP privada de la ENI, sin necesidad de alterar el código o la configuración de los clientes.
• Tiene costo: cobrado por hora de operación (~$0.01/hora por AZ) + costo por GB procesado.

Ejemplo de creación vía CLI:

# Crear Interface Endpoint para SSM
aws ec2 create-vpc-endpoint \
  --vpc-id vpc-0abc123 \
  --service-name com.amazonaws.us-east-1.ssm \
  --vpc-endpoint-type Interface \
  --subnet-ids subnet-0def456 \
  --security-group-ids sg-0ghi789 \
  --private-dns-enabled

Gateway Endpoint

El Gateway Endpoint funciona de forma diferente — agrega una ruta en la route table de la subnet que dirige el tráfico hacia el servicio AWS por el backbone interno, sin crear ENIs.

Características:

• Funciona vía route table — no crea ENIs ni IPs privadas.
• Disponible solo para S3 y DynamoDB.
• Sin costo adicional — no cobra por hora ni por tráfico.
• No soporta security groups (el control se hace vía endpoint policy y route tables).
• No necesita DNS privado (el ruteo es transparente).

Ejemplo de creación vía CLI:

# Crear Gateway Endpoint para S3
aws ec2 create-vpc-endpoint \
  --vpc-id vpc-0abc123 \
  --service-name com.amazonaws.us-east-1.s3 \
  --vpc-endpoint-type Gateway \
  --route-table-ids rtb-0jkl012

Comparación

Aspecto	Interface Endpoint (PrivateLink)	Gateway Endpoint
Mecanismo	ENI con IP privada en la subnet	Ruta en la route table
Servicios soportados	Mayoría de los servicios AWS	Solo S3 y DynamoDB
Costo	~$0.01/hora por AZ + GB procesado	Gratuito
Security groups	Sí	No
DNS privado	Sí (opcional)	No necesario
Control de acceso	Security groups + endpoint policy	Endpoint policy + route table

Para S3, AWS ofrece los dos tipos. El Gateway Endpoint es gratuito y suficiente en la mayoría de los casos. Usa el Interface Endpoint para S3 solo si necesitas acceder al S3 desde redes on-premise vía VPN/Direct Connect (el Gateway Endpoint solo funciona dentro de la VPC).

Cómo AWS Implementa Esto por Debajo

La diferencia entre los dos tipos de endpoint no es solo funcional — son fundamentalmente diferentes en la capa de infraestructura.

El Interface Endpoint está sustentado por Hyperplane, una plataforma distribuida interna de AWS que también es el motor detrás del NAT Gateway, Network Load Balancer y Transit Gateway. Cuando creas un Interface Endpoint, AWS aprovisiona una ENI en tu subnet usando el Nitro System (el hypervisor de AWS con chips dedicados para I/O de red). Esta ENI recibe una IP privada real en tu subnet. El tráfico que llega a esta ENI es encaminado por nodos Hyperplane distribuidos por las AZs que funcionan como proxies internos hasta el servicio AWS de destino, todo por el backbone privado de AWS. En términos simples: el Interface Endpoint es un proxy de red gestionado por AWS que vive dentro de tu VPC.

El Gateway Endpoint es más simple — no crea ningún componente físico nuevo. Opera puramente en la capa de SDN (Software Defined Networking) de la VPC. Cuando creas un Gateway Endpoint, AWS modifica el mapping service (el sistema que traduce IPs virtuales de la VPC a ubicaciones físicas) y agrega una ruta en la route table apuntando el prefijo del servicio al backbone interno. El tráfico es interceptado por el router virtual de la VPC y redirigido sin intermediario — sin ENI, sin proxy. Por eso el Gateway Endpoint es gratuito: no consume recursos adicionales, es solo una regla de ruteo.

DNS Privado

Uno de los aspectos más importantes del Interface Endpoint es el DNS privado. Cuando está habilitado, hace que el nombre público del servicio (ej: ssm.us-east-1.amazonaws.com) resuelva a la IP privada de la ENI del endpoint dentro de la VPC.

Esto significa que ninguna alteración es necesaria en los clientes — el SDK de AWS, la CLI y cualquier herramienta que use el hostname estándar del servicio automáticamente pasan a usar el endpoint privado.

Sin DNS privado:

ssm.us-east-1.amazonaws.com → 52.94.x.x (IP pública, internet)

Con DNS privado habilitado:

ssm.us-east-1.amazonaws.com → 10.0.1.47 (IP privada, ENI del endpoint)

El DNS privado requiere que la VPC tenga enableDnsSupport y enableDnsHostnames habilitados. Estas configuraciones son estándar en VPCs nuevas, pero vale verificar en VPCs más antiguas.

Endpoint Policy

Tanto Interface como Gateway Endpoints soportan endpoint policies, que es un documento JSON en formato IAM policy que controla qué acciones y recursos pueden ser accedidos a través del endpoint. Esto funciona como una capa adicional de seguridad.

Por ejemplo, para restringir un Gateway Endpoint de S3 a solo un bucket específico:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::mi-bucket-privado/*"
    }
  ]
}

Esta policy impide que cualquier recurso en la subnet use el endpoint para acceder a otros buckets — una protección importante contra data exfiltration (un atacante con acceso a la EC2 no puede copiar datos a un bucket externo a través de este endpoint).

La endpoint policy es una restricción adicional que no reemplaza los permisos IAM del recurso. El acceso solo se permite si ambos lo permiten: la policy IAM del recurso/usuario Y la endpoint policy.

Ejemplo Práctico: SSM sin Internet

El escenario más común de VPC Endpoints es habilitar el SSM Session Manager en instancias que no tienen acceso a internet. Para esto, son necesarios tres Interface Endpoints:

Endpoint	Service Name	Función
SSM	com.amazonaws.<región>.ssm	API principal del Systems Manager
SSM Messages	com.amazonaws.<región>.ssmmessages	Canal de comunicación de sesiones interactivas
EC2 Messages	com.amazonaws.<región>.ec2messages	Canal de comandos para el SSM Agent

Los tres deben estar en la misma VPC y ser accesibles por las subnets donde las instancias EC2 corren. El security group de los endpoints debe permitir tráfico de entrada en el puerto 443 (HTTPS) proveniente de las instancias.

Si la instancia también necesita acceder a S3 (por ejemplo, para que SSM grabe logs de sesión), agrega un Gateway Endpoint para S3 — es gratuito y solo necesita ser asociado a la route table de la subnet.

Costos

El costo es un factor importante en la decisión de usar VPC Endpoints:

Tipo	Costo por hora (por AZ)	Costo por GB	Observación
Gateway Endpoint	Gratuito	Gratuito	Solo S3 y DynamoDB
Interface Endpoint	~$0.01/hora	~$0.01/GB	Varía por región
NAT Gateway	~$0.045/hora	~$0.045/GB	Para comparación

Para servicios de alto volumen de tráfico (como acceso frecuente a S3), el Gateway Endpoint es la mejor opción por ser gratuito. Para servicios como SSM, STS o KMS donde el volumen de tráfico es bajo, el costo del Interface Endpoint es mínimo y generalmente inferior al de mantener un NAT Gateway.

La cuenta es simple: si ya necesitas un NAT Gateway para otros fines, el tráfico de servicios AWS va a pasar por él de cualquier forma. Los VPC Endpoints tienen más sentido económico cuando puedes eliminar el NAT Gateway completamente o cuando el volumen de tráfico a un servicio específico es suficientemente alto para justificar el endpoint dedicado.

Una buena práctica recomendada por AWS para organizaciones que usan AWS Organizations es tener una cuenta de red separada (Network Account). En esa cuenta se centralizan los recursos de conectividad — Transit Gateway, VPCs compartidas (vía AWS RAM), NAT Gateways y los propios VPC Endpoints. Esto evita que cada cuenta de la Organization cree sus propios endpoints y NAT Gateways, reduciendo costos y simplificando la gestión. La decisión de dónde colocar VPC Endpoints cambia significativamente cuando existe una cuenta de red centralizada, pero ese es un tema de arquitectura multi-account que merece un artículo dedicado.