Objetivo del Laboratorio

Objetivo General

Implementar y validar una arquitectura básica de cómputo en Amazon EC2 mediante la creación manual de un Bastion host y el aprovisionamiento automatizado de un servidor web con AWS CLI, integrando controles de acceso, configuración de red y un script de inicialización para desplegar una aplicación HTTP.

Desplegar una instancia Bastion host

Crear una instancia EC2 de tipo t3.micro dentro de la VPC y la subred pública provistas por el entorno del laboratorio.
Utilizar Amazon Linux 2023 como sistema operativo actualizado para la instancia de administración.
Asociar un Security Group que permita el acceso administrativo mediante SSH conforme a las condiciones del laboratorio.
Asignar el perfil de instancia Bastion-Role para habilitar operaciones autorizadas contra la API de AWS sin almacenar credenciales estáticas.

Establecer acceso administrativo seguro

Conectarse al Bastion host mediante EC2 Instance Connect desde la consola de administración.
Validar la identidad del usuario del sistema y la disponibilidad de una sesión Linux funcional.
Obtener dinámicamente la región de ejecución mediante Instance Metadata Service v2.
Comprobar que el rol IAM asociado entregue permisos temporales suficientes para consultar y crear recursos EC2.

Automatizar la creación del servidor web

Consultar mediante AWS Systems Manager Parameter Store la AMI más reciente de Amazon Linux 2023 para arquitectura x86_64.
Recuperar dinámicamente los identificadores de la subred pública y del WebSecurityGroup mediante AWS CLI.
Adaptar el script de user data para instalar Apache y sus dependencias con el gestor de paquetes dnf.
Ejecutar aws ec2 run-instances con parámetros reutilizables y almacenar el identificador de la instancia resultante para su seguimiento.

Recursos AWS Utilizados

Servicio Principal

Amazon Elastic Compute Cloud (Amazon EC2)

Servicio de cómputo elástico utilizado para aprovisionar y operar las instancias Bastion host y Web Server. EC2 permitió definir la imagen de máquina, el tipo de instancia, la red, los controles de acceso, el perfil IAM y la configuración de inicialización requerida por cada servidor.

Servicios y Características Utilizadas

Recurso	Descripción
Amazon EC2	Plataforma de cómputo usada para crear, etiquetar, consultar y validar el ciclo de vida de las dos instancias del laboratorio.
Amazon Linux 2023 AMI	Imagen de sistema operativo empleada en reemplazo de Amazon Linux 2, seleccionada dinámicamente desde Parameter Store para mantener una base actualizada y compatible con x86_64.
EC2 Instance Connect	Mecanismo utilizado para abrir una sesión administrativa en el Bastion host desde la consola, sin administrar manualmente una clave privada persistente.
AWS Systems Manager Parameter Store	Fuente administrada consultada para recuperar el identificador de la AMI más reciente de Amazon Linux 2023, evitando fijar manualmente un ID dependiente de la región.
Amazon VPC y Public Subnet	Entorno de red donde se desplegaron las instancias con direccionamiento privado y conectividad pública conforme a la topología preconfigurada del laboratorio.
Security Groups	Firewalls virtuales con estado utilizados para controlar el tráfico administrativo hacia el Bastion host y el tráfico HTTP hacia el servidor web.
AWS Identity and Access Management	Servicio responsable del perfil de instancia Bastion-Role, que proporcionó credenciales temporales y permisos para ejecutar operaciones autorizadas mediante AWS CLI.

Recursos Implementados

Instancia EC2 Bastion host de tipo t3.micro desplegada en la subred pública.
Instancia EC2 Web Server de tipo t3.micro creada mediante aws ec2 run-instances.
Sistema operativo Amazon Linux 2023 configurado en ambas instancias.
Perfil IAM Bastion-Role asociado al Bastion host para operar AWS CLI con credenciales temporales.
Security Group del Bastion host con acceso SSH habilitado para la conexión administrativa del laboratorio.
WebSecurityGroup asociado al servidor web para permitir el tráfico HTTP requerido por la aplicación.
Variables de shell para almacenar dinámicamente la región, AMI, subred, Security Group e identificador de instancia.
Script UserData.txt adaptado a Amazon Linux 2023 con instalación de httpd, wget y unzip mediante dnf.
Servidor Apache HTTP habilitado para iniciar automáticamente y servir contenido desde /var/www/html.
Aplicación dashboard desplegada y publicada mediante el DNS público de la instancia Web Server.

Conceptos Clave

Bastion host

Servidor de acceso administrativo que actúa como punto controlado de entrada hacia un entorno de infraestructura. En este laboratorio se utilizó como estación de operación para ejecutar AWS CLI y lanzar el servidor web. En producción, su exposición, registro y alcance de red deben restringirse cuidadosamente.

Perfil de instancia y credenciales temporales

Un perfil de instancia permite que una máquina EC2 asuma un rol IAM y obtenga credenciales temporales de manera automática. Este patrón evita guardar access keys en archivos locales y facilita aplicar privilegio mínimo, rotación automática y trazabilidad sobre las llamadas a la API.

Descubrimiento dinámico de recursos

Consiste en consultar atributos de la infraestructura en tiempo de ejecución en vez de fijarlos manualmente. La región se obtuvo mediante IMDSv2, la AMI desde Parameter Store y los identificadores de red mediante filtros de AWS CLI, reduciendo errores y mejorando la portabilidad del procedimiento.

User data y bootstrap de instancia

User data permite entregar instrucciones que cloud-init ejecuta durante el primer arranque de una instancia. Se empleó para instalar Apache, descargar la aplicación, extraer sus archivos y ajustar permisos. Una instancia en estado running no garantiza que este proceso haya terminado correctamente, por lo que el servicio debe validarse por separado.

Controles de red en EC2

La conectividad depende de la combinación entre direccionamiento, rutas, asignación de IP pública y reglas de Security Group. El Bastion host requirió acceso administrativo, mientras que el Web Server necesitó exposición HTTP. La verificación correcta debe seguir el flujo del tráfico y no limitarse al estado de la instancia.

Arquitectura Implementada

La solución se implementó dentro de la VPC preconfigurada del laboratorio, utilizando una subred pública para alojar dos instancias Amazon EC2 con funciones diferenciadas. La instancia Bastion host, basada en Amazon Linux 2023 y asociada al perfil IAM Bastion-Role, funcionó como estación de administración desde la cual se ejecutaron consultas y operaciones sobre la API de AWS mediante AWS CLI.

Desde el Bastion host se descubrieron dinámicamente la región, la AMI vigente de Amazon Linux 2023, la subred pública y el WebSecurityGroup. Con estos parámetros se aprovisionó una segunda instancia denominada Web Server mediante aws ec2 run-instances. Durante su primer arranque, cloud-init procesó el script de user data para instalar Apache, descargar la aplicación y publicar su contenido en /var/www/html.

La conectividad se controló mediante Security Groups separados: uno destinado al acceso administrativo del Bastion host y otro orientado al tráfico HTTP del servidor web. Finalmente, la aplicación fue accedida desde un cliente externo mediante el DNS público de la instancia Web Server, validando tanto la infraestructura desplegada como la disponibilidad efectiva del servicio.

Desarrollo del Laboratorio

1. Creación y configuración del Bastion host

Se inició el procedimiento desde la consola de Amazon EC2 mediante el lanzamiento de una instancia denominada Bastion host. Se seleccionó una AMI de Amazon Linux 2023 para arquitectura x86_64 y el tipo de instancia t3.micro, manteniendo el tamaño definido por el laboratorio.

La instancia se ubicó en la VPC del laboratorio y en su subred pública, con asignación de dirección IP pública. También se configuró almacenamiento EBS de 8 GiB, un Security Group destinado al acceso SSH y el perfil de instancia Bastion-Role. La creación se realizó sin un par de claves persistente, debido a que el acceso posterior se efectuaría mediante EC2 Instance Connect.

Figura 1

Figura 1. Instancia Bastion host creada en Amazon EC2 mediante una AMI Amazon Linux 2023, utilizando el tipo t3.micro y una subred pública de la VPC del laboratorio.

2. Acceso remoto mediante EC2 Instance Connect

Una vez que la instancia alcanzó el estado Running y superó sus comprobaciones de estado, se estableció una sesión remota desde la consola utilizando EC2 Instance Connect. Este mecanismo permitió acceder al sistema sin descargar ni administrar manualmente una clave privada de larga duración.

La terminal confirmó el ingreso con el usuario ec2-user sobre Amazon Linux 2023. Desde esta sesión se realizaron las operaciones administrativas del laboratorio, utilizando el Bastion host como punto controlado de ejecución para consultar metadatos, descubrir recursos y lanzar posteriormente la instancia Web Server.

Figura 2

Figura 2. Conexión remota establecida con el Bastion host mediante EC2 Instance Connect, verificando el acceso al sistema Amazon Linux 2023 con el usuario ec2-user.

3. Obtención de la región y de la AMI mediante servicios administrados

Desde el Bastion host se consultó Instance Metadata Service v2. Primero se solicitó un token temporal y luego se utilizó para recuperar la zona de disponibilidad de la instancia. A partir de este valor se derivó la región y se almacenó en la variable AWS_DEFAULT_REGION, evitando fijarla manualmente en los comandos posteriores.

A continuación, AWS CLI consultó AWS Systems Manager Parameter Store para recuperar el identificador de la AMI más reciente de Amazon Linux 2023 compatible con x86_64. Esta implementación adaptó el procedimiento original basado en Amazon Linux 2 y conservó el descubrimiento dinámico de la imagen, reduciendo la dependencia de identificadores estáticos que varían entre regiones.

Figura 3

Figura 3. Obtención dinámica de la región y de la AMI más reciente de Amazon Linux 2023 mediante Instance Metadata Service v2 y AWS Systems Manager Parameter Store.

Nota técnica. El procedimiento original del laboratorio contemplaba el uso de una AMI de Amazon Linux 2. La implementación fue adaptada para utilizar Amazon Linux 2023, manteniendo la arquitectura y los objetivos del laboratorio. También se actualizó la ruta consultada en AWS Systems Manager Parameter Store para recuperar dinámicamente la AMI más reciente compatible con arquitectura x86_64.

4. Descubrimiento de la subred pública y del Security Group

Antes de crear el servidor web se consultaron los recursos de red preexistentes del laboratorio. Mediante aws ec2 describe-subnets se filtró la subred etiquetada como Public Subnet y su identificador se almacenó en la variable SUBNET.

De forma equivalente, aws ec2 describe-security-groups recuperó el identificador del grupo WebSecurityGroup y lo asignó a la variable SG. Finalmente, se imprimieron en conjunto los valores de AMI, SUBNET y SG para verificar que todos estuvieran definidos antes del aprovisionamiento. Este descubrimiento dinámico disminuyó errores de transcripción y permitió reutilizar los valores directamente en aws ec2 run-instances.

Figura 4

Figura 4. Recuperación dinámica de la AMI, la subred pública y el Security Group requeridos para desplegar el servidor web mediante AWS CLI.

5. Preparación y adaptación del script de user data

Se descargó el archivo UserData.txt en el Bastion host y se revisó su contenido antes de asociarlo a la nueva instancia. El script debía instalar el servidor Apache, habilitar su inicio automático, descargar la aplicación dashboard, extraerla en el directorio público del servicio web y asignar la propiedad adecuada sobre los archivos desplegados.

Debido a que la implementación utilizó Amazon Linux 2023, el script original fue adaptado para emplear dnf e instalar explícitamente las dependencias httpd, wget y unzip. También se utilizó systemctl enable --now para habilitar e iniciar Apache en una sola operación, se descargó el archivo comprimido hacia /tmp y se aplicó una extracción con sobrescritura controlada.

Script de inicialización utilizado:

#!/bin/bash

# Actualizar metadatos de paquetes e instalar dependencias
dnf install -y httpd wget unzip

# Habilitar e iniciar Apache
systemctl enable --now httpd.service

# Descargar y desplegar la aplicación web
wget -O /tmp/dashboard-app.zip \
"https://aws-tc-largeobjects.s3.amazonaws.com/CUR-TF-100-RESTRT-1/171-lab-%5BJAWS%5D-create-ec2/dashboard-app.zip"

unzip -o /tmp/dashboard-app.zip -d /var/www/html/

# Ajustar propiedad del contenido web
chown -R apache:apache /var/www/html/

La instalación explícita de dependencias redujo el riesgo de que el bootstrap fallara por paquetes ausentes y dejó el procedimiento alineado con el sistema operativo seleccionado.

Figura 5

Figura 5. Descarga y revisión del script de user data utilizado para automatizar la instalación y configuración inicial del servidor web en la nueva instancia EC2.

6. Aprovisionamiento automatizado del Web Server

Con las variables AMI, SUBNET y SG previamente verificadas, se ejecutó aws ec2 run-instances para crear una instancia de tipo t3.micro denominada Web Server. El comando vinculó la AMI de Amazon Linux 2023, la subred pública, el WebSecurityGroup y el archivo UserData.txt encargado de realizar la configuración inicial del sistema.

La consulta de salida se limitó al identificador de la instancia y el valor obtenido se almacenó en la variable INSTANCE. Esto permitió reutilizarlo inmediatamente en las operaciones de seguimiento sin copiarlo manualmente. Posteriormente, aws ec2 describe-instances confirmó la creación del recurso y su transición desde Pending hasta Running. El procedimiento demostró una alternativa más repetible y menos propensa a errores que la configuración íntegramente manual desde la consola.

Figura 6

Figura 6. Creación automatizada de la instancia Web Server mediante AWS CLI, utilizando la AMI, subred pública, Security Group y script de user data definidos previamente.

7. Validación funcional de la aplicación web

Una vez que la instancia Web Server alcanzó el estado Running, se recuperó su nombre DNS público mediante aws ec2 describe-instances y se construyó la dirección HTTP de acceso. La aplicación dashboard fue abierta desde el navegador utilizando dicho endpoint, comprobando que el contenido se encontraba disponible externamente.

Esta validación fue de extremo a extremo: confirmó que la instancia disponía de conectividad pública, que el WebSecurityGroup permitía el tráfico requerido, que Apache estaba escuchando en el puerto 80 y que los archivos de la aplicación habían sido desplegados correctamente en /var/www/html. También permitió distinguir entre el estado Running de la infraestructura y la disponibilidad real del servicio, ya que una instancia iniciada no garantiza por sí sola que el proceso de bootstrap haya terminado sin errores.

Figura 7

Figura 7. Aplicación web desplegada correctamente en una instancia Amazon EC2 creada mediante AWS CLI, validando la ejecución del script de user data y la disponibilidad del servicio Apache mediante HTTP.

8. Verificación final de las instancias desplegadas

Al finalizar el procedimiento se revisó la consola de Amazon EC2 para comprobar la presencia simultánea de las dos instancias creadas. La vista mostró al Bastion host y al Web Server en estado Running, cada uno identificado mediante su etiqueta Name y con una función claramente diferenciada dentro de la arquitectura.

El Bastion host representó el método de lanzamiento manual desde la consola y funcionó como estación de administración. El Web Server representó el aprovisionamiento automatizado mediante AWS CLI y ejecutó la carga de trabajo HTTP. Esta verificación consolidó el resultado del laboratorio al demostrar que ambos métodos de creación produjeron recursos operativos dentro de la VPC configurada.

Figura 8

Figura 8. Vista final de las instancias Bastion host y Web Server en estado Running, confirmando la creación manual y automatizada de recursos Amazon EC2.

Observaciones Operacionales

1. Adaptación a Amazon Linux 2023

El procedimiento fue actualizado para utilizar Amazon Linux 2023 sin alterar el objetivo arquitectónico del laboratorio. Esta decisión exigió ajustar la consulta de la AMI en Systems Manager Parameter Store y modificar el script de inicialización para utilizar dnf e instalar explícitamente httpd, wget y unzip. La adaptación evidenció la necesidad de revisar compatibilidad de sistema operativo, nombres de paquetes y comandos antes de reutilizar automatizaciones existentes.

2. Automatización y descubrimiento dinámico

La región, la AMI, la subred y el Security Group fueron obtenidos en tiempo de ejecución y almacenados en variables de shell. Este enfoque redujo dependencias de identificadores escritos manualmente, mejoró la repetibilidad y facilitó reutilizar los valores en comandos posteriores. Del mismo modo, el uso del perfil Bastion-Role permitió operar AWS CLI con credenciales temporales, evitando almacenar access keys estáticas dentro de la instancia.

3. Consideraciones de seguridad y producción

La configuración fue apropiada para un entorno temporal de laboratorio, pero requiere endurecimiento antes de utilizarse en producción. El acceso SSH no debería quedar abierto de forma amplia; el alcance del Security Group debe limitarse y el acceso administrativo puede centralizarse mediante mecanismos como AWS Systems Manager Session Manager. El servidor web debería publicar tráfico cifrado mediante HTTPS, aplicar privilegio mínimo al rol IAM, registrar actividad y métricas, mantener parches actualizados y contar con alertas, respaldos y procedimientos de recuperación.

Conclusiones

El laboratorio permitió implementar una arquitectura básica de cómputo en Amazon EC2 combinando dos métodos de aprovisionamiento: creación manual desde la consola y creación automatizada mediante AWS CLI. Se configuró un Bastion host con acceso mediante EC2 Instance Connect y un perfil IAM, desde el cual se descubrieron dinámicamente los parámetros necesarios para desplegar un Web Server en la subred pública.

La adaptación a Amazon Linux 2023 permitió mantener vigente el procedimiento y reforzó la importancia de verificar dependencias, gestores de paquetes y rutas de parámetros al actualizar una plataforma. El uso de user data automatizó la instalación de Apache y el despliegue de la aplicación, mientras que la validación mediante HTTP confirmó el funcionamiento integral de la red, los controles de acceso, el sistema operativo y el servicio web.

Como aprendizaje operacional, se comprobó que la creación exitosa de una instancia no equivale a la disponibilidad de la carga de trabajo. Una operación cloud confiable exige validar cada capa, utilizar credenciales temporales, evitar identificadores estáticos, revisar registros y diseñar pensando en seguridad, observabilidad y recuperación ante fallos.