Diagnosticar fallos y retirar los recursos

4.1. Establece un punto de partida

Usa la instancia y el HTML de la publicación web. Necesitas la consola, una shell en Debian y acceso SSH a la instancia. No se crea ningún recurso nuevo. Comprueba el tiempo restante de tu laboratorio y reserva margen para retirar los recursos. Si no puedes reproducir una situación de partida funcional, anota el punto exacto del bloqueo y realiza el cierre; no registres resultados previstos como observados.

Antes de cambiar nada, confirma estas tres señales:

• En EC2: systemctl is-active httpd muestra active.
• En EC2: curl --noproxy '*' -fsS --max-time 5 http://127.0.0.1/ devuelve tu HTML.
• En Debian: la petición a http://$IPV4_EC2/ que preparaste antes muestra HTTP 200. Confirma que la variable contiene la IPv4 pública vigente.

Para cada caso, predice qué debería responder, elige una primera prueba y cambia solo una cosa. Vuelve al estado funcional antes del caso siguiente. El lugar desde el que haces la prueba importa: 127.0.0.1 en Debian no apunta a EC2.

4.2. Caso A: el servidor responde, pero la ruta no existe

En la instancia EC2, compara una ruta que no creaste con la raíz de la web:

curl --noproxy '*' -sS --max-time 5 -o /dev/null \
  -w 'HTTP %{http_code}\n' http://127.0.0.1/aviso-inexistente.html
curl --noproxy '*' -sS --max-time 5 -o /dev/null \
  -w 'HTTP %{http_code}\n' http://127.0.0.1/

El resultado esperado es 404 para la primera y 200 para la segunda. Un 404 es una respuesta HTTP: has llegado a un servidor que no encontró ese recurso. Si la raíz funciona, revisa la ruta o el archivo antes de tocar el grupo de seguridad. En este caso, recuperas el acceso pidiendo la ruta correcta.

4.3. Caso B: el servicio no está en ejecución

En la instancia EC2, detén únicamente Apache, no la instancia:

sudo systemctl stop httpd
systemctl is-active httpd
sudo ss -ltnp 'sport = :80'
curl --noproxy '*' -sS --max-time 5 -o /dev/null \
  -w 'HTTP %{http_code}\n' http://127.0.0.1/

Busca inactive, ausencia de Apache en el puerto 80 y un fallo de conexión sin respuesta HTTP. Es un fallo distinto del caso anterior. SSH puede seguir funcionando, porque lo atiende otro servicio. Si necesitas consultar los últimos mensajes de Apache, usa sudo journalctl -u httpd -n 20 --no-pager: -u selecciona el servicio, -n 20 limita las líneas y --no-pager muestra la salida directamente.

Restaura el servicio y repite la prueba local. Si no responde, no pases aún al siguiente caso.

sudo systemctl start httpd
systemctl is-active httpd
systemctl is-enabled httpd
curl --noproxy '*' -fsS --max-time 5 http://127.0.0.1/

stop no deshabilita el arranque automático. La comprobación is-enabled permite separar ambas cosas.

4.4. Caso C: la web funciona en EC2, pero no desde fuera

En la consola, edita el grupo de seguridad propio de la instancia y retira solo la regla de entrada temporal TCP 80. Conserva la regla de SSH TCP 22 con el origen autorizado. Tras guardar, vuelve a pedir la raíz dentro de EC2:

curl --noproxy '*' -sS --max-time 5 -o /dev/null \
  -w 'HTTP %{http_code}\n' http://127.0.0.1/

Ahora haz una petición nueva desde Debian. Si abres otra shell, recupera primero la IPv4 de la instancia.

curl -4 --noproxy '*' -sS --max-time 8 -o /dev/null \
  -w 'HTTP %{http_code}\n' "http://$IPV4_EC2/"

Se espera 200 dentro de EC2 y ausencia de respuesta HTTP desde Debian. Una pestaña abierta puede mostrar una copia anterior: usa la petición nueva de curl para decidir. En este experimento conoces el único cambio; en una incidencia real este contraste orienta hacia el recorrido exterior, pero no demuestra por sí solo que falle el grupo de seguridad.

Vuelve a añadir solo TCP 80 desde 0.0.0.0/0 para terminar la prueba y verifica una nueva respuesta 200 desde Debian. Si no se recupera, revisa el grupo asociado y la IPv4 actual; no abras SSH ni otros puertos.

4.5. Detén e inicia la instancia y comprueba qué queda

Antes de parar, predice qué ocurrirá con el HTML, Apache, la IPv4 pública, la IPv4 privada y el coste. Anota para uso local las dos direcciones que muestra la consola y registra en EC2 si el servicio está habilitado y qué archivo tienes:

systemctl is-enabled httpd
sha256sum /var/www/html/index.html
exit

En Instancias, selecciona la tuya y usa Estado de la instancia → Detener instancia (Instance state → Stop instance). No elijas Terminar en este punto. Espera a Detenida (Stopped). Comprueba en Volúmenes que el EBS raíz sigue asociado. El cómputo de esa instancia deja de cobrarse mientras está detenida; el EBS sigue almacenado y sigue generando coste. La IPv4 pública automática se libera al parar. Un reinicio del sistema (Reboot) no hace el mismo experimento: no libera esa IP ni interrumpe la facturación del cómputo.

Desde la consola, usa Iniciar instancia (Start instance). Espera a que vuelva a estar en ejecución y a que supere las comprobaciones de estado. Compara las direcciones: la privada principal se conserva y AWS asigna una IPv4 pública automática, que puede ser distinta de la que anotaste. No reutilices una URL o una orden con la dirección anterior sin comprobarla.

Actualiza IPV4_EC2 en Debian como en el primer acceso. Reconecta después de comprobar la identidad: si la nueva dirección es desconocida para OpenSSH, compara la huella con el registro de arranque de esa misma instancia o con la huella que ya verificaste para ella. Si advierte de un cambio en una dirección ya conocida, detente y verifica antes de actualizar una entrada concreta. No borres todo known_hosts.

En EC2, comprueba el servicio y compara el resumen del HTML con el de antes:

systemctl is-active httpd
systemctl is-enabled httpd
sha256sum /var/www/html/index.html
curl --noproxy '*' -fsS --max-time 5 http://127.0.0.1/

Repite también la prueba desde Debian con la IPv4 vigente. Si el HTML se conserva pero Apache no está activo, tienes persistencia del disco sin disponibilidad del servicio: revisa el arranque y los registros. Si no puedes detener, iniciar o reconectar, anota el punto y continúa con el cierre que permita la cuenta.

Estados de la instancia · Detener e iniciar.

4.6. Retira los recursos

Empieza el cierre antes de agotar el tiempo de Learner Lab. Usa este orden también si la práctica se interrumpe a mitad: omite solo los recursos que no se llegaron a crear y registra los que no puedas retirar.

1. Conserva el trabajo local. Guarda tu HTML y las comprobaciones en la carpeta compartida. No copies secretos, identificadores de cuenta ni salidas completas. El archivo local es la copia que conservarás al eliminar la instancia.

2. Retira la exposición. Elimina la regla HTTP temporal de tu grupo, si existe. Sal de SSH. Identifica por el inventario tu instancia y su EBS raíz, interfaz y grupo asociados.

3. Termina la instancia propia. En Instancias → Estado de la instancia → Terminar (eliminar) instancia (Terminate (delete) instance), revisa la selección y confirma. Este paso es irreversible. Si la instancia ya está detenida puedes terminarla desde ese estado; dejarla detenida por sí solo no es el cierre. Espera el estado Terminada (Terminated). Puede seguir visible un tiempo en la lista sin estar en ejecución.

4. Comprueba los recursos asociados. En Volúmenes, verifica que se eliminó el EBS raíz. Si queda como disponible, confirma que era el de esta práctica y que no contiene trabajo que debas conservar antes de eliminarlo. En Interfaces de red, comprueba que desapareció la interfaz creada para tu instancia; si persiste, identifica su estado y dependencia antes de hacer cambios. No borres interfaces, discos o instantáneas de otra práctica.

5. Elimina el grupo y el registro de clave propios. Cuando no estén asociados a otros recursos, elimina tu grupo de seguridad y el registro de par importado para la práctica. Eliminar ese registro por sí solo no revoca la clave dentro de una instancia que siga existiendo. La VPC y la subred existentes se conservan.

6. Revisa las copias locales y el saldo. Si la pareja local era solo para esta práctica y ya no vas a usarla, en Debian P00 elimina esos dos archivos concretos. Si reutilizarás la pareja en el integrador de esta serie, consérvala en la ubicación privada validada y vuelve a registrar únicamente la pública cuando corresponda. Nunca borres otras claves ni todo ~/.ssh.

   rm -i "$HOME/.ssh/aws-ec2-ed25519" "$HOME/.ssh/aws-ec2-ed25519.pub"

   rm -i pide confirmación para cada archivo. Comprueba el inventario final y el saldo. Si un recurso propio sigue presente o no tienes permiso para retirarlo, registra la incidencia antes de cerrar el laboratorio. El saldo puede actualizarse con retraso; que no haya cambiado aún no demuestra coste cero.

Cuando hayas comprobado la retirada, puedes pulsar End Lab. No sustituye la terminación ni la revisión de los recursos asociados.

Terminar instancias EC2.

A entregar. En la bitácora individual, resume para cada caso qué predijiste, desde dónde probaste, qué observaste y cómo recuperaste el acceso. Añade el antes y después de Stop/Start (archivo, servicio, relación entre direcciones y coste del volumen) y el inventario de cierre. Si algún paso estuvo bloqueado, separa el resultado esperado de lo que pudiste observar.