Eliminación de la gestión de claves SSH con EC2 Instance Connect - Conexión segura desde el navegador y la CLI

Explicamos la conexión SSH sin claves con EC2 Instance Connect, el control de acceso basado en IAM y el uso del Endpoint.

Unos 6 min de lecturaÚltima actualización: 2026-10-31

Descripción general de EC2 Instance Connect

EC2 Instance Connect es un servicio para conectarse de forma segura a instancias EC2 sin distribuir claves SSH de antemano. En las conexiones SSH tradicionales, la creación, la distribución y la rotación de los pares de claves, así como la respuesta ante su pérdida, suponían una carga operativa, pero Instance Connect utiliza claves públicas temporales y hace innecesaria la gestión de claves.

Endpoint y conexión privada

EC2 Instance Connect Endpoint es un endpoint que se crea dentro de una VPC y permite conectarse a instancias de subredes privadas sin una IP pública ni un servidor bastión. Con las políticas de IAM se controla la acción ec2-instance-connect:OpenTunnel y se restringe la conexión a instancias y subredes concretas. En el momento de la conexión, se coloca una clave pública SSH temporal en los metadatos de la instancia durante 60 segundos, por lo que no queda ninguna clave permanente en la instancia.

EC2 Instance Connect Endpoint

Con EC2 Instance Connect Endpoint (EIC Endpoint), puede conectarse por SSH/RDP a instancias de subredes privadas sin una dirección IP pública ni un servidor bastión. Se crea un EIC Endpoint dentro de la VPC y, con las políticas de IAM, se controlan los usuarios a los que se permite conectarse y las instancias de destino. Como la conexión se tuneliza a través de AWS PrivateLink, no es necesario abrir el puerto SSH de entrada en el grupo de seguridad de la instancia. Con CloudTrail se puede auditar quién se conectó a qué instancia y cuándo, y tampoco es necesaria la gestión de claves SSH. Con un solo EIC Endpoint se puede conectar a instancias de varias subredes de la VPC, y no se cobran cargos adicionales.

Comparación y selección de métodos de conexión

Hay 3 métodos de conexión a EC2: EC2 Instance Connect, Systems Manager Session Manager y los pares de claves SSH tradicionales. Instance Connect inyecta una clave pública temporal a través del servicio de metadatos, por lo que no es necesario gestionar claves SSH permanentes. Session Manager se basa en un agente y no usa el protocolo SSH, por lo que puede conectarse sin abrir puertos de entrada. Los pares de claves SSH tradicionales se pueden usar con los flujos de trabajo existentes tal cual, y la rotación y la distribución de las claves las gestiona el propio usuario. Qué método usar en cada entorno se decide según los requisitos de auditoría y si se pueden abrir puertos o no.

Precios de EC2 Instance Connect

EC2 Instance Connect se puede usar de forma gratuita. No se cobran cargos adicionales por la conexión SSH desde el navegador, la conexión desde la CLI ni el uso de Instance Connect Endpoint. Las conexiones de Session Manager (Systems Manager) se pueden usar sin cargos adicionales. Con Instance Connect Endpoint, puede conectarse a instancias de subredes privadas sin dirección IP pública sin colocar un NAT Gateway ni un servidor bastión.

Requisitos previos y entornos compatibles

EC2 Instance Connect se puede usar en los sistemas operativos y regiones compatibles. Las AMI estándar de Amazon Linux y Ubuntu incluyen de antemano el paquete necesario, por lo que Instance Connect se puede usar sin configuración adicional. En otras distribuciones, el paquete para aceptar conexiones se instala manualmente. Como los permisos de IAM se evalúan en el momento de la conexión, se permiten de antemano las acciones necesarias en el rol del usuario. Como el mecanismo inyecta una clave pública temporal a través de los metadatos solo durante un breve tiempo, no es necesario distribuir claves de antemano en el lado de la instancia. Antes de la implantación, se comprueban estos requisitos previos.

Prácticas recomendadas de diseño de seguridad

El control de acceso se diseña con detalle mediante políticas de IAM. Las acciones que permiten la conexión se limitan por instancia de destino, etiqueta o subred, y se define con mínimos privilegios quién puede conectarse a dónde. Si utiliza Instance Connect Endpoint, el tráfico se controla con el grupo de seguridad del endpoint y se evita abrir puertos de entrada en el lado de la instancia. Como los registros de conexión quedan en CloudTrail, se puede auditar quién entró en qué instancia y cuándo. Con este método no se gestionan la distribución ni la revocación de claves y, en su lugar, la operación se centra en el diseño de permisos y la auditoría de registros.

Uso en la operación y combinación con otros métodos

Como EC2 Instance Connect permite conectarse desde el navegador o la línea de comandos, se puede usar en situaciones de desarrollo e investigación. Por otro lado, para el trabajo operativo habitual o los requisitos en los que no se pueden abrir puertos de entrada, se puede usar Systems Manager Session Manager. Ambos no son excluyentes, y se pueden usar juntos según el propósito. Por ejemplo, una forma de operar es concentrar las operaciones diarias en Session Manager y usar Instance Connect para investigaciones concretas. Si prepara varios medios como rutas de conexión alternativas para emergencias, puede conectarse a la instancia cuando uno de ellos no está disponible.

Resumen

EC2 Instance Connect es un servicio que hace innecesaria la gestión de claves SSH y ofrece un control de acceso basado en IAM. Con EIC Endpoint puede conectarse a instancias de subredes privadas sin una IP pública ni un servidor bastión, y CloudTrail guarda los registros de auditoría de las conexiones. Si lo usa junto con Session Manager según el caso, puede elegir el método de conexión adecuado para cada propósito.

Referencias (recursos oficiales de AWS)

Las fuentes primarias de esta página son el sitio web y la documentación oficiales de AWS. Consulta las páginas oficiales siguientes para conocer las especificaciones y los precios más recientes.

Si esta página y la documentación oficial difieren, prevalece la documentación oficial.

Por qué Auto Scaling escala rápido hacia afuera y es cauteloso al reducir - Intención de diseño de la lógica de decisión asimétricaExplica la razón del diseño asimétrico de EC2 Auto Scaling que ejecuta el scale-out inmediatamente mientras establece un período de enfriamiento para el scale-in, el mecanismo de prevención de flapping y la lógica interna del Target Tracking Scaling.Infraestructura adaptable a la demanda con AWS Auto Scaling - Diseño y optimización de políticas de escaladoPresenta cómo utilizar los 3 tipos de políticas (Target Tracking, Predictive y Scheduled) y lograr la optimización de costos con instancias Spot mediante Mixed Instances Policy.Diseño de dominios de fallo en AWS - El mecanismo de disponibilidad protegido por la estructura de 3 capas AZ, región y particiónExplicamos por qué la infraestructura de AWS está diseñada en 3 capas: AZ (aislamiento de fallos), región (separación geográfica) y partición (separación política), y hasta dónde se propagan los fallos en cada capa con ejemplos concretos.Principios de sistemas distribuidos aprendidos de las interrupciones de AWS - Arquitecturas transformadas por grandes incidentesUsando como material los informes de incidentes publicados por AWS, como la interrupción de S3 (2017), la interrupción de Kinesis (2020) y la particularidad de us-east-1, explicamos principios de diseño como Shuffle Sharding, Static Stability y Cell-based Architecture.Por qué AWS construye regiones allí - Los criterios desconocidos de selección de ubicación de centros de datosExplicamos los criterios de decisión que AWS considera al determinar la ubicación de regiones, como suministro eléctrico, riesgo geopolítico, legislación de soberanía de datos, conectividad de red y riesgo de desastres naturales, con ejemplos concretos de regiones.Por qué los Availability Zone ID de AWS difieren por cuenta - La intención de diseño detrás del mapeo de AZExplicamos el mecanismo por el que us-east-1a apunta a una AZ física distinta en cada cuenta, el contexto en el que se introdujeron los AZ ID (use1-az1), la intención de diseño de distribuir la capacidad de forma uniforme y los puntos a tener en cuenta al especificar AZ entre cuentas.Infraestructura de computación por lotes - Procesamiento paralelo a gran escala con AWS BatchExplicamos cómo construir procesamiento por lotes a gran escala con AWS Batch. Cubrimos el diseño de colas de trabajos, auto-escalado de entornos de cómputo, optimización de costos con instancias Spot y la construcción de infraestructura de lotes ideal para computación científica y procesamiento de datos a gran escala.Streaming en vivo con calidad broadcast - Construcción de una plataforma de distribución a gran escala con AWS Elemental MediaLive y MediaPackageExplicamos una plataforma de streaming en vivo con calidad broadcast basada en AWS Elemental MediaLive y MediaPackage. Presentamos la transcodificación en tiempo real, DRM, la inserción de anuncios y la distribución multi-CDN.