Solución de problemas comunes de conectividad y errores de instancias EC2

Conectarse a una instancia de Amazon Elastic Compute Cloud (EC2) es fundamental para gestionar sus recursos en la nube. Ya sea que esté utilizando SSH para instancias Linux o el Protocolo de Escritorio Remoto (RDP) para instancias Windows, los fallos de conectividad son comunes y a menudo frustrantes. Esta guía proporciona un enfoque sistemático, paso a paso, para diagnosticar y resolver las razones más frecuentes por las que podría no poder acceder a su instancia EC2.

Comprender los fallos de conectividad requiere mirar más allá de la propia instancia. Los problemas suelen deberse a configuraciones incorrectas en las capas de seguridad (Security Groups, NACLs), una configuración de red errónea (enrutamiento VPC) o problemas de autenticación. Al verificar metódicamente estos componentes en orden, puede aislar rápidamente la causa raíz y restaurar el acceso.

Fase 1: Comprobaciones Iniciales y Estado de la Instancia

Antes de sumergirse en configuraciones de red complejas, asegúrese de que la instancia se esté ejecutando correctamente y sea accesible a un nivel fundamental.

1. Comprobaciones de Estado de la Instancia

Utilice la Consola de administración de AWS o la AWS CLI para verificar el estado general de la instancia. Dos comprobaciones cruciales deben pasar:

Comprobaciones de estado del sistema (System Status Checks): Los fallos aquí generalmente indican problemas de hardware o infraestructura subyacentes que requieren la intervención de AWS o la terminación/recreación de la instancia.
Comprobaciones de estado de la instancia (Instance Status Checks): Los fallos aquí a menudo se relacionan con problemas de arranque del sistema operativo, corrupción del sistema de archivos o problemas de controladores. Si esto falla, es probable que la instancia no esté lo suficientemente saludable como para rechazar las conexiones de red.

Acción: Si falla alguna de las comprobaciones, considere detener e iniciar la instancia (lo que la mueve a hardware nuevo si falla la comprobación del sistema) o revise el Registro del Sistema (System Log) en busca de pistas.

2. Verificación de la Dirección IP Pública y el Nombre DNS

Asegúrese de que está intentando conectarse a la dirección correcta. Si su instancia se encuentra en una subred pública, requiere una Dirección IPv4 pública o una IP elástica (Elastic IP). Si está en una subred privada, debe conectarse a través de un Bastion Host (Host de Salto) o usar AWS Systems Manager Session Manager.

Consejo: Si la instancia se detuvo y se inició, su dirección IP pública puede haber cambiado a menos que le haya asignado una IP elástica.

3. Comprobación de la Configuración del Cliente (SSH/RDP)

Los errores de conectividad son a veces locales. Verifique que su software cliente esté funcionando correctamente.

Para SSH (Linux/macOS): Asegúrese de que está utilizando el archivo de clave privada correcto (.pem o .ppk) y que los permisos están configurados correctamente (chmod 400 /path/to/key.pem).
Para RDP (Windows): Asegúrese de que está utilizando la contraseña correcta obtenida al descifrar la contraseña del administrador usando el archivo de clave privada en la consola EC2.

Fase 2: Diagnóstico de las Capas de Seguridad (Los Fallos Más Comunes)

Las configuraciones incorrectas de seguridad son la causa principal de los problemas de conectividad. Tanto los Security Groups como las Network ACLs actúan como firewalls, y ambos deben permitir el tráfico necesario.

4. Reglas de Entrada (Ingress) del Security Group (SG)

Los Security Groups son firewalls con estado (stateful) adjuntos directamente a la Interfaz de Red Elástica (ENI) de la instancia.

Requisitos de Linux (SSH):

Protocolo: TCP
Rango de Puertos: 22
Origen: Su dirección IP pública (Mi IP) o 0.0.0.0/0 (para todas las IP, aunque esto se desaconseja por seguridad).

Requisitos de Windows (RDP):

Protocolo: TCP
Rango de Puertos: 3389
Origen: Su dirección IP pública o 0.0.0.0/0.

Paso de Solución de Problemas: Cambie temporalmente el origen de la regla de entrada requerida a 0.0.0.0/0 para el puerto relevante (22 o 3389). Si puede conectarse, el problema fue que su dirección IP de cliente específica estaba bloqueada o no se identificó correctamente.

Advertencia: Nunca deje los grupos de seguridad abiertos a 0.0.0.0/0 para puertos de administración (22/3389) en entornos de producción. Utilice IP de origen específicas o puntos de enlace de VPC siempre que sea posible.

5. ACL de Red (NACLs)

Las ACL de Red son firewalls sin estado (stateless) a nivel de subred. Verifican el tráfico entrante y saliente de forma independiente. Si se permite el tráfico de entrada, también se debe permitir el tráfico de retorno saliente.

Requisitos de NACL para la Conectividad:

Dirección	Protocolo	Rango de Puertos	Acción de la Regla
Entrada (Inbound)	TCP	22 (SSH) o 3389 (RDP)	Permitir (Allow)
Salida (Outbound)	TCP	Puertos Efímeros (1024-65535)	Permitir (Allow)

Los puertos efímeros son críticos. Cuando su cliente se conecta (por ejemplo, desde el puerto 54321), el servidor responde en un puerto efímero de numeración alta. Si la NACL bloquea el tráfico saliente en estos puertos altos, el servidor no puede enviarle la respuesta, lo que resulta en un tiempo de espera agotado de la conexión.

Paso de Solución de Problemas: Verifique que tanto el puerto de entrada (22/3389) como los puertos efímeros de salida (1024-65535) tengan una regla de Permitir en la NACL asociada.

Fase 3: Enrutamiento y Configuración de VPC

Si se confirma que las capas de seguridad están abiertas, el problema radica en cómo se enruta el tráfico hacia y desde la subred de la instancia.

6. Tipo de Subred y Tablas de Enrutamiento

La conectividad depende completamente de si su instancia se encuentra en una Subred Pública o en una Subred Privada.

Conectividad de Subred Pública

Para el acceso directo a internet (SSH/RDP desde el mundo exterior):

A la instancia se le debe asignar una dirección IPv4 pública o una IP elástica.
La Tabla de Enrutamiento asociada debe tener una ruta para 0.0.0.0/0 que apunte a un Internet Gateway (IGW).

Conectividad de Subred Privada

Las instancias en subredes privadas no pueden ser alcanzadas directamente desde internet. La conexión requiere una ruta de salto múltiple:

Conexión a través de Bastion Host (Host de Salto): Usted se conecta por SSH a una instancia EC2 pública y luego se conecta por SSH desde el Bastion Host a la instancia privada (utilizando su IP privada).
Conexión a través de VPN/Direct Connect: Si utiliza AWS Site-to-Site VPN o Direct Connect, el enrutamiento debe estar configurado para dirigir el tráfico a su red local, que luego enruta a la subred privada.

7. Problemas de Firewall a Nivel del SO

Si las comprobaciones de seguridad de AWS pasan, el sistema operativo que se ejecuta en la propia instancia EC2 podría estar bloqueando la conexión. Esto es común si instaló o configuró manualmente firewalls locales (como iptables en Linux o Windows Defender Firewall).

Diagnóstico (si es posible a través de la Consola o Session Manager):

Linux: Verifique iptables -L o use firewall-cmd --list-all. Asegúrese de que el puerto 22 esté permitido explícitamente.
Windows: Verifique la configuración de Windows Defender Firewall para reglas de entrada en el puerto 3389.

Consejo de Recuperación: Si ha perdido toda la conectividad, considere detener la instancia, separar el volumen raíz, adjuntarlo a una instancia de recuperación en funcionamiento, modificar los archivos de configuración del SO para deshabilitar el firewall y luego volver a adjuntar el volumen al ID de instancia original.

Resumen del Flujo de Solución de Problemas

Cuando falla la conectividad, siga esta lista de verificación priorizada:

Estado de la Instancia: ¿Están pasando las comprobaciones de estado del Sistema/Instancia?
Autenticación del Cliente: ¿Es el archivo de clave correcto y tiene los permisos adecuados (SSH)?
Security Group: ¿Permite el SG el tráfico de entrada en el Puerto 22/3389 desde su IP?
NACLs: ¿Permite la NACL el tráfico de entrada (22/3389) Y el tráfico de salida (1024-65535)?
Enrutamiento: ¿Apunta la Tabla de Enrutamiento a un IGW para subredes públicas?
Firewall del SO: ¿Está permitiendo la conexión el firewall local en la instancia EC2?