1 Descripción general del trabajo

Example University se prepara para el nuevo curso escolar. El departamento de admisiones ha recibido quejas de que su aplicación web para los registros de los estudiantes es lenta o no está disponible durante el período pico de admisiones debido al alto número de consultas.

Usted es un ingeniero de la nube. Su gerente le ha pedido que cree una prueba de concepto (POC) para alojar la aplicación web en la nube de AWS. Su gerente desea que diseñe e implemente una nueva arquitectura de alojamiento que mejore la experiencia de los usuarios de la aplicación web. Usted es responsable de construir la infraestructura para alojar la aplicación web de registros de estudiantes en la nube.

Su reto consiste en planificar, diseñar, crear e implementar la aplicación web en la nube de AWS de forma coherente con las prácticas recomendadas del marco de trabajo bien diseñado de AWS. Durante el periodo de máxima admisión, la aplicación debe soportar miles de usuarios y estar altamente disponible, ser escalable, tener una carga equilibrada, ser segura y tener un alto rendimiento.

La siguiente imagen muestra un ejemplo de la aplicación web de registros de estudiantes. El sitio muestra los registros de los estudiantes que han solicitado la admisión en la universidad. Los usuarios pueden ver, añadir, eliminar y modificar los registros de los estudiantes.

2 Fase 1: Planeación del diseño y estimación de costos

2.1 Diseño

2.2 Estimación de costos

3 Fase 2: Creación de una aplicación web funcional básica en AWS

3.1 Objetivo de la fase

Desplegar una prueba de concepto (PoC) de una aplicación web funcional en una sola máquina virtual dentro de una red virtual personalizada en AWS, con conectividad a Internet. Esta base será reutilizada y mejorada en fases posteriores.

3.2 Tarea 1: Creación de una red virtual (VPC)

Se creó una VPC denominada VPC-Final, con un rango CIDR 10.0.0.0/16 para alojar la aplicación web.

Se crean 2 subredes públicas y 2 subredes privadas para alojar posteriormente algunos elementos.

Subredes de la VPC-Final

Nombre.de.la.Subred	Zona.de.Disponibilidad	CIDR.IPv4
Subred-Publica-A	us-east-1a	10.0.1.0/24
Subred-Publica-B	us-east-1b	10.0.3.0/24
Subred-Privada-A	us-east-1a	10.0.2.0/24
Subred-Privada-B	us-east-1b	10.0.4.0/24

Se creó el Internet Gateway para garantizar salida a Internet y se asoció con la VPC.

Se creó una tabla de enrutamiento para las instancias con acceso público.

3.3 Tarea 2: Creación de una máquina virtual (EC2)

Se implementó una instancia EC2 usando la AMI Ubuntu 24.04 LTS, tipo t2.micro, en la subred pública Subred-Publica-A. Esta instancia se utilizó como servidor web para alojar la aplicación de estudiantes.

3.3.1 Acciones realizadas:

• Se asignó una IP pública a la instancia (3.95.234.68).

• Se configuró el tráfico por los puertos 22 (SSH) y 80 (HTTP) en el grupo de seguridad.

En la configuración del UserData de la instancia se usó el siguiente código:

#!/bin/bash -xe

### ---------------------------------------
### 1. ACTUALIZACIÓN E INSTALACIÓN DE PAQUETES
### ---------------------------------------
apt update -y
apt install nodejs unzip wget npm mysql-server -y

### ---------------------------------------
### 2. DESCARGA Y DESCOMPRESIÓN DE LA APLICACIÓN
### ---------------------------------------
# Descarga del archivo ZIP que contiene el código de la aplicación web
wget https://aws-tc-largeobjects.s3.us-west-2.amazonaws.com/CUR-TF-200-ACCAP1-1-91571/1-lab-capstone-project-1/code.zip -P /home/ubuntu

# Cambio de directorio y descompresión del archivo (excluye node_modules)
cd /home/ubuntu
unzip code.zip -x "resources/codebase_partner/node_modules/*"

### ---------------------------------------
### 3. CONFIGURACIÓN DE LA APLICACIÓN NODE.JS
### ---------------------------------------
cd resources/codebase_partner

# Instalación de dependencias necesarias para interactuar con servicios AWS
npm install aws aws-sdk

### ---------------------------------------
### 4. CONFIGURACIÓN DEL SERVIDOR MySQL
### ---------------------------------------
# Crear usuario de base de datos
mysql -u root -e "CREATE USER 'nodeapp' IDENTIFIED WITH mysql_native_password BY 'student12';"

# Otorgar privilegios al nuevo usuario
mysql -u root -e "GRANT all privileges on *.* to 'nodeapp'@'%';"

# Crear base de datos
mysql -u root -e "CREATE DATABASE STUDENTS;"

# Crear tabla dentro de la base de datos STUDENTS
mysql -u root -e "USE STUDENTS; CREATE TABLE students(
    id INT NOT NULL AUTO_INCREMENT,
    name VARCHAR(255) NOT NULL,
    address VARCHAR(255) NOT NULL,
    city VARCHAR(255) NOT NULL,
    state VARCHAR(255) NOT NULL,
    email VARCHAR(255) NOT NULL,
    phone VARCHAR(100) NOT NULL,
    PRIMARY KEY ( id ));"

# Permitir conexiones externas a MySQL (bind-address a 0.0.0.0)
sed -i 's/.*bind-address.*/bind-address = 0.0.0.0/' /etc/mysql/mysql.conf.d/mysqld.cnf

# Habilitar y reiniciar el servicio MySQL
systemctl enable mysql
service mysql restart

### ---------------------------------------
### 5. CONFIGURACIÓN DE VARIABLES DE ENTORNO PARA LA APLICACIÓN
### ---------------------------------------
# Obtener IP privada de la instancia (para que la app se conecte a sí misma)
export APP_DB_HOST=$(curl http://169.254.169.254/latest/meta-data/local-ipv4)
export APP_DB_USER=nodeapp
export APP_DB_PASSWORD=student12
export APP_DB_NAME=STUDENTS
export APP_PORT=80

# Iniciar la aplicación en segundo plano
npm start &

### ---------------------------------------
### 6. CREACIÓN DE SCRIPT DE INICIO AUTOMÁTICO (PERSISTENCIA)
### ---------------------------------------
# Crear script rc.local para que la app se inicie tras reinicio
echo '#!/bin/bash -xe
cd /home/ubuntu/resources/codebase_partner
export APP_PORT=80
npm start' > /etc/rc.local

# Dar permisos de ejecución al script
chmod +x /etc/rc.local

Se generó una conexión SSH exitosa a la instancia desde el CMD.

Se aprecia el servicio MySQL instalado y ejecutándose correctamente.

3.4 Tarea 3: Pruebas de despliegue

Se accedió a la aplicación web desde un navegador utilizando la IP pública de la instancia EC2 (http://3.95.234.68). Se realizaron pruebas exitosas de las operaciones CRUD (crear, leer, editar).

Página principal de la aplicación web de XYZ University y de la lista de estudiantes con datos ingresados.

3.4.1 Conclusión de la fase 2

Fue posible realizar el despliegue de una aplicación web funcional sobre una instancia EC2 con conectividad pública y usando una arquitectura de red personalizada. Esta fase demuestra la viabilidad de ejecutar aplicaciones web en AWS usando infraestructura como servicio (IaaS) y permite concluir que es posible escalar como se desee la solución en fases posteriores.

4 Fase 3: Desacoplamiento de los componentes de la aplicación

4.1 Objetivo

En esta fase se separa la lógica de la base de datos de la aplicación web. El servidor web y la base de datos se despliegan en entornos independientes para aumentar la escalabilidad y mantenibilidad de la arquitectura.

4.2 Tarea 1: Configuración de la VPC y subredes privadas

En esta etapa se debía crear las 2 subredes privadas correspondientes a cada zona de disponibilidad. Sin embargo, esa configuración se hizo desde el principio cuando se creó la VPC, por ende, las subredes privadas que alojarán la base de datos ya están creadas.

4.3 Tarea 2: Creación de base de datos con Amazon RDS

Se implementó una instancia RDS llamada db-final con el motor MySQL, localizada en us-east-1a, sobre las subredes privadas de la VPC-Final.

Puerto: 3306

Motor: MySQL Community

Seguridad: Se creó el grupo SG-BDMySQL que permite el tráfico por el puerto 3306.

4.4 Tarea 3: Configuración del entorno de desarrollo con AWS Cloud9

Se creó un entorno de desarrollo Cloud9 sobre una instancia t2.micro, conectado vía SSH a la “Subred-Publica-A” de la VPC. Esto es muy útil porque permite la ejecución de scripts y conexión directa al entorno EC2 y RDS sin tener que ocupar otras consolas como el CMD.

4.5 Tarea 4: Uso de Secrets Manager para credenciales

Se creó un secreto para almacenar las credenciales de acceso a la base de datos. Este secreto fue creado desde Cloud9 usando el siguiente script (extraído del archivo cloud9-scripts.yml):

# Script para crear secreto en AWS Secrets Manager
aws secretsmanager create-secret \
  --name Mydbsecret \
  --description "Secreto para uso de credenciales de la base de datos" \
  --secret-string "{\"user\":\"nodeapp\",\"password\":\"student12\",\"host\":\"db-final.c0offsb2iqnv.us-east-1.rds.amazonaws.com\",\"db\":\"STUDENTS\"}"

4.6 Tarea 5: Nueva instancia EC2 para el servidor web de la zona de disponibilidad b

Se creó una nueva instancia EC2 “ServidorB” en la “Subred-Publica-B”, utilizando el script de UserDataScript-phase-2.sh adaptado al nuevo entorno RDS. El rol IAM LabRole fue adjuntado para que la instancia EC2 pueda acceder a Secrets Manager.

Se usa el siguiente código en el UserData en el lanzamiento de la instancia:

#!/bin/bash -xe

# Instalación de dependencias
apt update -y
apt install nodejs unzip wget npm mysql-client -y

# Descarga y extracción del código fuente
wget https://aws-tc-largeobjects.s3.us-west-2.amazonaws.com/CUR-TF-200-ACCAP1-1-91571/1-lab-capstone-project-1/code.zip -P /home/ubuntu
cd /home/ubuntu
unzip code.zip -x "resources/codebase_partner/node_modules/*"
cd resources/codebase_partner

# Instalación de dependencias npm
npm install aws aws-sdk

# Configuración de variables de entorno para conectarse a RDS
export APP_DB_HOST=db-final.c0offsb2iqnv.us-east-1.rds.amazonaws.com
export APP_DB_USER=nodeapp
export APP_DB_PASSWORD=student12
export APP_DB_NAME=STUDENTS
export APP_PORT=80

# Iniciar aplicación
npm start &

# Hacer persistente en reinicio
echo '#!/bin/bash -xe
cd /home/ubuntu/resources/codebase_partner
export APP_PORT=80
npm start' > /etc/rc.local
chmod +x /etc/rc.local

4.7 Tarea 6: Migración de base de datos (EC2 ➝ RDS)

4.7.1 Paso 1: Exportar desde EC2

mysqldump -h 10.0.1.254 -u nodeapp -p --databases STUDENTS > data.sql

4.7.2 Paso 2: Importar en RDS

mysql -h db-final.c0offsb2iqnv.us-east-1.rds.amazonaws.com -u nodeapp -p STUDENTS < data.sql

4.8 Tarea 7: Verificación de funcionamiento

Se accedió a la nueva IP pública del ServidorB, confirmando la funcionalidad completa de la aplicación conectada a RDS.

• URL de acceso: http://107.22.86.107/students

• Confirmación visual de los datos migrados: estudiantes Carlos y Martha visibles.

4.9 Conclusión

La fase 3 permitió desacoplar exitosamente la aplicación de su base de datos, utilizando Amazon RDS, AWS Secrets Manager y múltiples subredes en VPC. La arquitectura final está lista para escalar y permite buena seguridad mediante control de acceso.

5 Fase 4: Implementación de alta disponibilidad y escalabilidad en AWS

5.1 Tarea 1: Creación del Application Load Balancer (ALB)

Para que la aplicación web cumpla con el criterio de alta disponibilidad y sea capaz de manejar múltiples usuarios simultáneamente sin afectar su rendimiento como se solicita y como se requiere en una institución educativa, es necesario distribuir eficientemente el tráfico de red entre distintas instancias que loren asegurar el procesamiento de todas las solicitudes hechas en un momento t. En esta tarea se implementa un Application Load Balancer (ALB), el cual se encarga de enrutar las solicitudes entrantes hacia las instancias EC2 disponibles, alojadas en múltiples zonas de disponibilidad, permitiendo así lograr resiliencia, escalabilidad y tolerancia a fallos dentro de la arquitectura desplegada.

5.1.1 ¿Qué se hizo?

• Se creó un ALB llamado ALB-Final.

• Se asociaron al ALB subredes de dos zonas de disponibilidad distintas (us-east-1a y us-east-1b).

• Se configuró con el protocolo HTTP (Puerto 80) para recibir tráfico público.

• Se creó el grupo de destino Destino-Final, donde se asociaron instancias EC2 (donde corre la app).

5.1.2 ¿Qué hace el ALB?

• Distribuye automáticamente el tráfico HTTP entrante entre las instancias EC2 registradas que estén en buen estado.

• Asegura alta disponibilidad al balancear tráfico entre múltiples AZs.

• Permite escalar horizontalmente gracias a su integración con Auto Scaling Groups.

5.2 Tarea 2: Implementación de EC2 Auto Scaling

Para implementar una arquitectura que sea fácilmente escalable se requiere que la infraestructura pueda acoplarse automáticamente con el tráfico. En esta tarea se configura un grupo de Auto Scaling, basado en una plantilla de lanzamiento creada a partir de la AMI de una de las instancias EC2 para permitir que nuevas instancias EC2 con las características de la AMI se creen automáticamente cuando la demanda lo requiera, y se eliminen cuando esta disminuya. Esta configuración garantiza una disponibilidad completa y continua, optimizando los recursos sin intervención manual.

5.2.1 ¿Qué se hizo?

• Se creó una “plantilla de lanzamiento” llamada Plantilla-Final.

5.2.2 Esta plantilla incluye:

• AMI personalizada: una imagen de la instancia web funcional con la app configurada.

• Tipo de instancia, par de llaves, rol de IAM (LabRole) y scripts si es necesario.

5.2.3 Se creó un Auto Scaling Group (ASG) que:

• Lanza instancias según esa plantilla.

• Se conecta con el Application Load Balancer (ALB).

• Utiliza una política de escalado por seguimiento de objetivo (Target Tracking Policy) basada en CPU Utilization, permitiendo escalar las instancias según criterio de uso de la CPU.

5.2.4 ¿Qué es Auto Scaling y por qué es importante?

• Auto Scaling lanza o termina instancias automáticamente según la demanda, lo que es lo ideal y más óptimo.

• Permite que la aplicación web maneje picos de tráfico sin degradar el rendimiento, la app perfecta.

• Reduce costos al eliminar instancias en momentos de baja carga, una gran ventaja frente a la computación tradicional.

• Trabaja en conjunto con el ALB para asegurar que solo instancias sanas reciban tráfico.

5.3 Tarea 3: Acceso a la aplicación

Una vez se configura el balanceador de carga y el grupo de Auto Scaling, es fundamental verificar que la aplicación esté operando correctamente. En esta tarea se accede al endpoint del ALB y se prueba la funcionalidad del sistema: visualizar, agregar, editar o eliminar registros estudiantiles en la base de datos. Este paso valida la correcta integración entre el balanceador, las instancias EC2 y la base de datos RDS.

5.3.1 ¿Qué se hizo?

• Se accedió a la app desde el endpoint DNS del ALB ALB-Final-134594452.us-east-1.elb.amazonaws.com.

• Se probaron las funciones de la aplicación

5.3.2 ¿Qué se logra con esta prueba?

Se valida que:

• La base de datos RDS se conecta correctamente a la app.

• Secrets Manager funciona correctamente.

• El tráfico se enruta vía el ALB y llega a una instancia activa del grupo de destino.

5.4 Tarea 4: Prueba de carga (Load Testing)

Después de la configuración anterior es fundamental evaluar el rendimiento y comportamiento de la aplicación bajo condiciones de alto tráfico. Se realiza una prueba de carga utilizando herramientas ya automatizadas desde AWS Cloud9 y desde la consola de CMD. Esta simulación permite observar si el grupo de Auto Scaling responde adecuadamente al aumento en la demanda, activando nuevas instancias según la política configurada. Es un paso esencial para validar la escalabilidad dinámica y la estabilidad del sistema.

Se ejecuta el comando:

loadtest --rps 1000 -c 500 -k http://ALB-Final-134594452.us-east-1.elb.amazonaws.com

Se verifica el comportamiento del número de solicitudes:

Se verifica la disponibilidad de la aplicación una vez atendido el tráfico: