Saltar al contenido principal

Lab: Escenarios de Resolución de Problemas EC2

Objetivos del Lab​

Este laboratorio le enfrenta a escenarios de fallo realistas. Para cada escenario, deberá:

  • Analizar los síntomas
  • Formular hipótesis
  • Proponer pruebas de diagnóstico
  • Identificar la solución
Ejercicio Teórico

Este laboratorio es un ejercicio de análisis. No necesita acceso a AWS: trabaje en papel o en un documento.

Duración Estimada​

1h30 a 2h

Escenario 1: El Sitio Web No Es Accesible​

Contexto​

Situación:
- Instancia EC2 lanzada hace 1 hora
- AMI: Amazon Linux 2023
- Tipo: t3.micro
- Apache instalado y arrancado
- Puede conectarse por SSH
- Pero http://52.1.2.3 no responde (timeout)

Configuración actual:
- VPC: vpc-default
- Subnet: pública (con IGW)
- Security Group: sg-web

Información Disponible​

Estado de la instancia: running
Status checks: 2/2 passed

Security Group sg-web:
Reglas de entrada:
- SSH (22): 0.0.0.0/0
- HTTP (80): 10.0.0.0/8

Reglas de salida:
- Todo el tráfico: 0.0.0.0/0

Preguntas​

  1. ¿Cuál es el síntoma preciso?

  2. Enumere 3 hipótesis por orden de probabilidad

  3. ¿Cuál es la causa más probable?

  4. ¿Qué comando/acción corrige el problema?

  5. ¿Cómo validar que está resuelto?

📋 Ver la solución

1. Síntoma: Timeout HTTP hacia 52.1.2.3 puerto 80, mientras que SSH funciona.

2. Hipótesis:

  1. El Security Group no permite HTTP desde Internet (ALTA)
  2. Apache no escucha en el puerto correcto (MEDIA)
  3. Firewall iptables en la instancia (BAJA)

3. Causa: El Security Group permite HTTP (puerto 80) solo desde 10.0.0.0/8 (red privada), no desde Internet (0.0.0.0/0).

4. Correctivo:

aws ec2 authorize-security-group-ingress \
    --group-id sg-web \
    --protocol tcp \
    --port 80 \
    --cidr 0.0.0.0/0

5. Validación:

curl http://52.1.2.3
# o
Abrir http://52.1.2.3 en un navegador

Escenario 2: SSH Imposible​

Contexto​

Situación:
- Nueva instancia lanzada
- Ha descargado la clave .pem
- Instancia: running, status checks OK
- IP pública: 52.2.3.4

Comando ejecutado:
$ ssh -i clave.pem ec2-user@52.2.3.4
ssh: connect to host 52.2.3.4 port 22: Connection timed out

Información Disponible​

Detalles de la instancia:
- ID: i-0123456789
- Estado: running
- IP pública: 52.2.3.4
- Subnet: subnet-abc123 (10.0.2.0/24)
- Security Group: sg-default

Security Group sg-default:
Reglas de entrada:
- (ninguna regla)

Reglas de salida:
- Todo el tráfico: 0.0.0.0/0

Subnet subnet-abc123:
- Route Table: rtb-main
- Rutas:
  - 10.0.0.0/16 → local
  - (ninguna otra ruta)

Preguntas​

  1. Identifique TODOS los problemas en esta configuración

  2. Ordénelos por prioridad de corrección

  3. Proponga los comandos para corregir cada problema

📋 Ver la solución

1. Problemas identificados:

Problema A - Security Group: Ninguna regla de entrada = puerto 22 bloqueado

Problema B - Route Table: Sin ruta hacia Internet Gateway = sin acceso a Internet

2. Prioridad:

  1. Route Table (sin ruta, aunque el SG esté bien, no funcionará)
  2. Security Group

3. Correctivos:

# 1. Crear/adjuntar un Internet Gateway (si no está hecho)
aws ec2 create-internet-gateway
aws ec2 attach-internet-gateway --vpc-id vpc-xxx --internet-gateway-id igw-xxx

# 2. Añadir la ruta hacia IGW
aws ec2 create-route \
    --route-table-id rtb-main \
    --destination-cidr-block 0.0.0.0/0 \
    --gateway-id igw-xxx

# 3. Añadir regla SSH al Security Group
aws ec2 authorize-security-group-ingress \
    --group-id sg-default \
    --protocol tcp \
    --port 22 \
    --cidr 0.0.0.0/0

Escenario 3: Instancia que Termina Inmediatamente​

Contexto​

Situación:
- Lanza una instancia
- Pasa de "pending" a "running" y luego "terminated"
- Todo en menos de 30 segundos
- Ha intentado 3 veces, mismo resultado

Configuración:
- AMI: ami-custom-xyz (AMI personalizada)
- Tipo: t3.large
- Región: us-east-1

Información Disponible​

Consola EC2 → State transition reason:
"Client.VolumeLimitExceeded: Volume limit exceeded"

Sus volúmenes EBS actuales:
- 45 volúmenes de 100 GB cada uno
- Total: 4.5 TB

Su AMI ami-custom-xyz:
- Creada hace 6 meses
- Volumen raíz: 200 GB
- Usa el snapshot snap-olddata

Preguntas​

  1. ¿Cuál es la causa de la terminación?

  2. ¿Cómo verificar los límites de su cuenta?

  3. ¿Cuáles son las soluciones posibles? (al menos 3)

📋 Ver la solución

1. Causa: El mensaje "Volume limit exceeded" indica que ha alcanzado la cuota de almacenamiento EBS para su cuenta.

2. Verificar los límites:

aws service-quotas get-service-quota \
    --service-code ebs \
    --quota-code L-D18FCD1D

# O vía la consola:
# Service Quotas → Amazon Elastic Block Store (EBS)

3. Soluciones:

Solución A - Eliminar volúmenes no utilizados:

# Listar los volúmenes no adjuntos
aws ec2 describe-volumes \
    --filters "Name=status,Values=available"

# Eliminar
aws ec2 delete-volume --volume-id vol-xxx

Solución B - Solicitar un aumento de cuota:

aws service-quotas request-service-quota-increase \
    --service-code ebs \
    --quota-code L-D18FCD1D \
    --desired-value 10000

Solución C - Usar otra región: Las cuotas son por región. Lanzar en eu-west-1 por ejemplo.

Solución D - Usar un tipo de instancia con instance store: Algunas instancias tienen almacenamiento local, no EBS.

Escenario 4: Base de Datos Inaccesible​

Contexto​

Arquitectura:
- Instancia Web (subnet pública): 10.0.1.10
- Instancia BDD (subnet privada): 10.0.2.20
- Ambas en el mismo VPC

Problema:
- Desde la instancia Web, imposible conectarse a MySQL
- telnet 10.0.2.20 3306 → timeout

La instancia BDD funciona:
- Status checks OK
- MySQL está arrancado (verificado vía Session Manager)

Información Disponible​

Security Group sg-web (instancia web):
Entrada: HTTP 80, SSH 22
Salida: Todo el tráfico 0.0.0.0/0

Security Group sg-database (instancia BDD):
Entrada: MySQL (3306) desde 0.0.0.0/0
Salida: Todo el tráfico 0.0.0.0/0

NACL de la subnet privada (nacl-private):
Reglas de entrada:
  Rule 100: DENY TCP 3306 from 0.0.0.0/0
  Rule 200: ALLOW ALL from 0.0.0.0/0
Reglas de salida:
  Rule 100: ALLOW ALL to 0.0.0.0/0

Preguntas​

  1. ¿Por qué falla la conexión?

  2. Explique por qué la regla del Security Group no es suficiente

  3. ¿Cómo corregir el problema?

📋 Ver la solución

1. Causa: La NACL bloquea el puerto 3306 con una regla DENY (rule 100) que se evalúa ANTES que la regla ALLOW (rule 200).

2. Explicación:

  • Los Security Groups se evalúan en conjunto (todas las reglas)
  • Las NACLs se evalúan en orden de número de regla
  • Rule 100 (DENY 3306) se evalúa antes que Rule 200 (ALLOW ALL)
  • Por lo tanto, el puerto 3306 está bloqueado a pesar del SG

3. Correctivo: Eliminar o modificar la regla 100 de la NACL:

# Opción A: Eliminar la regla DENY
aws ec2 delete-network-acl-entry \
    --network-acl-id nacl-private \
    --rule-number 100 \
    --ingress

# Opción B: Modificar para permitir desde la subnet web
aws ec2 replace-network-acl-entry \
    --network-acl-id nacl-private \
    --rule-number 100 \
    --protocol tcp \
    --port-range From=3306,To=3306 \
    --cidr-block 10.0.1.0/24 \
    --rule-action allow \
    --ingress

Escenario 5: Permission Denied (Desafío)​

Contexto​

Situación:
- Instancia Amazon Linux 2023 lanzada con clave "mi-clave"
- Archivo mi-clave.pem presente en su máquina
- Permiso del archivo: 400 (OK)

Comando:
$ ssh -i mi-clave.pem ec2-user@52.5.6.7
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

Pruebas realizadas:
- Security Group: puerto 22 abierto hacia 0.0.0.0/0
- Instancia: running, status OK
- Ping: funciona

Información Adicional​

Tiene dos archivos de clave en su carpeta:
- mi-clave.pem (creado ayer)
- mi-clave.pem.bak (creado la semana pasada)

La instancia fue lanzada la semana pasada.

Preguntas​

  1. ¿Cuál es probablemente la causa?

  2. ¿Cómo verificar su hipótesis?

  3. ¿Cuáles son las opciones para recuperar el acceso?

📋 Ver la solución

1. Causa probable: Está usando la clave equivocada. El archivo "mi-clave.pem" actual (creado ayer) no es la clave asociada a la instancia (lanzada la semana pasada).

2. Verificación:

# Ver qué clave está asociada a la instancia
aws ec2 describe-instances --instance-ids i-xxx \
    --query 'Reservations[].Instances[].KeyName'

# Comparar la huella de su clave
ssh-keygen -l -f mi-clave.pem
ssh-keygen -l -f mi-clave.pem.bak

3. Opciones de recuperación:

Opción A - Usar la clave correcta:

ssh -i mi-clave.pem.bak ec2-user@52.5.6.7

Opción B - EC2 Instance Connect (si la AMI es compatible): Consola → Instancia → Connect → EC2 Instance Connect

Opción C - Systems Manager Session Manager: Si el agente SSM está instalado y el rol IAM configurado.

Opción D - Crear una AMI y relanzar:

  1. Crear AMI de la instancia
  2. Lanzar nueva instancia con nueva clave
  3. Montar el volumen de la instancia antigua
  4. Modificar ~/.ssh/authorized_keys

Entregables del Lab​

Informe de Resolución de Problemas (para 2 escenarios a elección)​

Para cada escenario elegido, documente:

# Escenario X: [Título]

## 1. Síntoma Identificado
[Descripción precisa]

## 2. Hipótesis Formuladas
1. [Hipótesis 1] - Probabilidad: Alta/Media/Baja
2. [Hipótesis 2]
3. [Hipótesis 3]

## 3. Pruebas de Diagnóstico
- Prueba 1: [Comando/Acción] → Resultado esperado
- Prueba 2: [Comando/Acción] → Resultado esperado

## 4. Causa Raíz
[Explicación de la verdadera causa]

## 5. Solución
[Comandos o acciones para corregir]

## 6. Validación
[Cómo verificar que está resuelto]

## 7. Prevención
[Cómo evitar este problema en el futuro]

Tabla de Evaluación​

CriterioPuntos
Síntoma bien definido2
Hipótesis pertinentes y ordenadas3
Pruebas de diagnóstico correctas3
Causa raíz identificada3
Solución correcta3
Validación propuesta2
Claridad y estructura2
Total por escenario18

¡Felicidades! Ha completado el laboratorio de resolución de problemas EC2.