Hola comunidad,
Seguramente te has encontrado en la necesidad de acceder a una instancia EC2 que se encuentra en una subred privada. Tradicionalmente, la solución implicaba configurar un Bastion Host (o Jumpbox), o peor aún, asignarle una IP pública y abrir puertos en los Security Groups. Además, la administración requería lidiar con la gestión de llaves SSH o pares de claves (Key Pairs) de Windows, lo que añade una capa extra de complejidad operativa y riesgos de seguridad.
Si te interesa simplificar esto y garantizar un acceso 100% privado y seguro, sin depender de reglas de entrada o salida a internet en tus instancias ni gestión de contenedores de llaves, este artículo es para ti. En este post estaré revisando:
- Qué es AWS PrivateLink y qué son los VPC Endpoints
- Cómo conectarnos a EC2 sin necesidad de Access Keys o Key Pairs
- Cómo mantener la comunicación privada sin acceso a internet
- Un ejemplo de la arquitectura y despliegue
¿Qué es AWS PrivateLink y qué son los VPC Endpoints?
Para entender la solución, primero debemos hablar de dos conceptos fundamentales, que juntos forman la base de la comunicación interna segura en AWS:
AWS PrivateLink
Es una tecnología altamente disponible y escalable que proporciona conectividad privada entre Virtual Private Clouds (VPC), servicios compatibles de AWS y tus redes on-premises. La magia de PrivateLink radica en que el tráfico de red no atraviesa la Internet pública, reduciendo significativamente la exposición a amenazas de ciberseguridad. En lugar de salir a internet, todo viaja directamente a través de la red troncal (backbone) privada de Amazon.
VPC Endpoints
Para poder utilizar PrivateLink, necesitas un punto de entrada en tu red. Existen dos tipos principales de endpoints de VPC, pero para este caso nos enfocaremos en los Interface VPC Endpoints. Estos actúan como interfaces de red elásticas (ENI) virtuales con direcciones IP privadas dentro de tus propias subredes. Su propósito es servir como la puerta de enlace que enruta de manera local el tráfico dirigido hacia un servicio de AWS.
La Solución: Acceso a la instancia sin bastions o key Pairs usando vpc endpoints y ssm
El enfoque moderno y recomendado por AWS para administrar instancias es utilizar AWS Systems Manager (SSM) Session Manager, y para entornos gráficos como Windows de manera unificada desde la consola, su función de Fleet Manager.
La arquitectura segura para lograrlo funciona de la siguiente manera:
Instancia Completamente Privada: Desplegamos nuestra instancia EC2 en una subred privada, sin asignarle una IP Pública y en una VPC que no necesita tener configurado ni un Internet Gateway (IGW) ni un NAT Gateway.
Cero Key Pairs: No asociamos ningún Key Pair al momento de crear la instancia para conectarnos. En su lugar, le adjuntamos a la instancia un IAM Role (Instance Profile) que le otorga los permisos necesarios al agente (SSM Agent) para comunicarse de forma segura con AWS Systems Manager.
VPC Endpoints para SSM: Para que el SSM Agent instalado en nuestra instancia EC2 pueda hablar con el servicio de Systems Manager (cuyos servidores están fuera de nuestra VPC) sin usar internet, aprovisionamos VPC Endpoints de interfaz principales como
ssm,ssmmessagesyec2messages.Security Groups Restrictivos: Todo ocurre localmente. Como la comunicación es mediante los Endpoints dentro de la misma red local (VPC), no dependes de reglas de entrada o salida hacia/desde el exterior (0.0.0.0/0). La EC2 no necesita abrir un puerto 22 (SSH) o 3389 (RDP) para tu IP. Solo necesitas que el Security Group permita el tráfico interno en tu subred hacia el puerto HTTPS (443) de los Endpoints.
Acceso Dinámico y Justo a Tiempo (JIT) vía SSM: Aquí es donde la solución destaca. Como no utilizamos Key Pairs iniciales, cuando necesitas entrar a la instancia puedes enviar un comando remoto con SSM (Run Command) de forma segura para preconfigurar al usuario e inyectar su respectiva contraseña. Luego, una vez terminada la sesión o tu tarea, podrías enviar otro comando para eliminar o deshabilitar ese usuario nuevamente. Esto te faculta para crear accesos al momento en que se necesitan y removerlos posterior al uso, evitando la perdurabilidad de contraseñas.
Al final de esta arquitectura, logramos nuestra misión:
✅ Cero exposición a internet: Al no requerir IGW ni NAT, la máquina es invisible desde el exterior.
✅ Cero administración de llaves estáticas: El acceso es auditado y autenticado mediante políticas de IAM, y permitimos accesos dinámicos configurables al vuelo con SSM, fácilmente revocables.
✅ Comunicación 100% privada: Todo el tráfico entre tu EC2 y la consola de Systems Manager está asegurado por la red troncal de AWS.
¿Dónde puedo ver un ejemplo de implementación?
He subido un demo completo a mi repositorio público. Allí encontrarás las plantillas de CloudFormation (en las carpetas de vpc, vpce e instance) y todo el laboratorio necesario para poner esto a prueba en tu propia cuenta.
Repositorio:
https://github.com/pangoro24/aws-privatelink-private-instance-ssm
Si te diriges a la guía de despliegue dentro del repositorio, podrás ver un paso a paso para:
- Desplegar una VPC y subredes verdaderamente privadas.
- Desplegar los Endpoints de VPC con sus reglas de red para permitir PrivateLink. Sin estos vpc endpoints, recibirás error al intentar conectarse a la instancia.
- Desplegar un Windows Server configurado con el Instance Profile de IAM.
- Establecer una nueva clave interactiva al sistema sin usar RDP externo y acceder usando Fleet Manager de Systems Manager directamente desde tu navegador.
Si el despliegue de los recursos se realiza exitosamente, al intentar conectarte a la instancia de ec2 podrás ver un status para Session Manager connection de "Connected". De lo contrario, verás un mensaje de "No connected"
Al conectarse a fleet manager, podremos ver la pantalla de windows pero sin acceso a internet porque obviamente, la instancia vive en la red privada.
Conclusión
Utilizar AWS PrivateLink y VPC Endpoints en conjunto con Systems Manager elimina una enorme carga operativa asociada a la rotación de llaves, el mantenimiento de Bastion Hosts y los costos de gateways. A la vez, mejora radicalmente la postura de seguridad de nuestras aplicaciones al eliminar el uso de puertos de administración expuestos a la internet.
¿Ya utilizas SSM y Endpoints de VPC en tu organización para administrar tu infraestructura de manera unificada, o sigues utilizando VPNs tradicionales o Jumpboxes? Cuéntamelo en los comentarios.
En el próximo post, veremos otro uso de los vpc endpoints y reutilizaremos los componentes que hemos desplegado en este post. Importante recordar que los vpc endpoints y las instancias tienen un costo por hora por lo que si ya no los requieres, debes eliminar los recursos.
Gracias por leer.
Top comments (0)