Infraestructura escalable WordPress en AWS

Introducción

En este proyecto pondremos en práctica todos los componentes aprendidos hasta ahora, con el objetivo de tener una visión completa de cómo diseñar una infraestructura desde un punto inicial monolítico e ir escalándola hasta alcanzar una arquitectura altamente disponible (HA) y escalable.

Será solo una breve explicación de lo que se desarrolló.

Comenzamos con el siguiente escenario:

---

Infraestructura inicial

Partimos con una VPC que contiene 9 subnets: 3 públicas y 6 privadas.

Dentro de una subnet pública desplegamos una aplicación monolítica: un sitio WordPress totalmente contenido en una sola instancia EC2 (base de datos y archivos incluidos).

Vista lógica de la infraestructura monolítica inicial con WordPress todo-en-uno en una sola instancia EC2.

---

2️⃣ Launch Template

Creamos un Launch Template, que nos permite definir configuraciones para nuestras instancias: tipo, SG, IAM Role, red, User Data, entre otros.

---

3️⃣ Separación de base de datos con RDS

Desacoplamos la base de datos, usando un RDS en modo Single AZ. Esto la saca del ciclo de vida de la EC2, lo que mejora la resiliencia en caso de que la instancia falle.

Diagrama lógico de la implementación de RDS desacoplado del ciclo de vida de la instancia WordPress.

---

4️⃣ Separación del contenido estático con EFS

Montamos un EFS distribuido en múltiples subnets/AZ y migramos el directorio wp-content allí. Esto permite que múltiples instancias WordPress compartan los mismos archivos multimedia.

Verificación desde la terminal: la instancia EC2 muestra el dispositivo EFS montado correctamente en la ruta /var/www/html/wp-content, permitiendo compartir contenido entre múltiples instancias WordPress.

Diagrama lógico de la implementación de EFS, permitiendo que múltiples instancias EC2 compartan el contenido multimedia de WordPress de forma resiliente y desacoplada.

---

5️⃣ Auto Scaling + Load Balancer

Incorporamos elasticidad utilizando un Auto Scaling Group en conjunto con un Application Load Balancer. Esto nos permite escalar horizontalmente y balancear el tráfico entre instancias.

Diagrama lógico de la implementación de ALB (Application Load Balancer) junto a ASG (Auto Scaling Group), permitiendo balanceo de carga dinámico y aprovisionamiento automático basado en métricas.

---

6️⃣ Configuración de Parameters con SSM

Creamos parámetros en Systems Manager Parameter Store (tanto públicos como SecureString) para gestionar las credenciales de la base de datos, endpoint del RDS, el ID del EFS y otros datos clave.

Parámetros definidos en AWS Systems Manager Parameter Store, utilizados para automatizar el despliegue y configuración de WordPress durante la demo.

---

7️⃣ Instalación manual de WordPress (modo clásico)

Inicialmente realizamos la instalación manual de WordPress en una instancia, recuperando los valores desde SSM, instalando los paquetes necesarios, configurando Apache y MariaDB, y ajustando los permisos.

Este proceso es tardado y puede generar errores.

---

8️⃣ Instalación automatizada con Launch Template + User Data

Creamos una nueva versión del Launch Template que incluye el bootstrapping completo del WordPress, desde la instalación hasta la conexión con RDS y EFS. Esto nos permite lanzar instancias ya configuradas en segundos.

Script userdata para automatizar la instalación y configuración inicial.

---

9️⃣ Migración a RDS y reemplazo de localhost

Hicimos un dump de la base de datos local y la importamos en RDS. Luego actualizamos el parámetro SSM con el nuevo endpoint, y modificamos el archivo wp-config.php para que WordPress apunte a la nueva base de datos.

---

Manejo del parámetro siteurl en WordPress

Uno de los puntos críticos en infraestructuras escalables es el valor siteurl, que WordPress guarda en su base de datos y que se usa para generar enlaces, redirecciones y rutas absolutas.

⚠️ Si este valor queda hardcoded (por ejemplo, con la IP pública de una instancia), genera:

• Enlaces rotos

• Imágenes que no cargan

• Redirecciones inválidas cuando cambia la IP

✅ Para resolver esto:

• Se Implementa un script que recupera el DNS del Load Balancer desde Parameter Store

• Actualizamos todos los campos donde aparece el siteurl, como home, guid, post_content y meta_value

cat >> /home/ec2-user/update_wp_ip.sh << 'EOF'
#!/bin/bash

source <(php -r 'require("/var/www/html/wp-config.php"); echo("DB_NAME=".DB_NAME."; DB_USER=".DB_USER."; DB_PASSWORD=".DB_PASSWORD."; DB_HOST=".DB_HOST); ')

SQL_COMMAND="mysql -u $DB_USER -h $DB_HOST -p$DB_PASSWORD $DB_NAME -e"

OLD_URL=$(mysql -u $DB_USER -h $DB_HOST -p$DB_PASSWORD $DB_NAME -e 'select option_value from wp_options where option_name = "siteurl";' | grep http)

ALBDNSNAME=$(aws ssm get-parameters --region us-east-1 --names /A4L/Wordpress/ALBDNSNAME --query Parameters[0].Value)
ALBDNSNAME=$(echo $ALBDNSNAME | sed -e 's/^"//' -e 's/"$//')

$SQL_COMMAND "UPDATE wp_options SET option_value = replace(option_value, '$OLD_URL', 'http://$ALBDNSNAME') WHERE option_name = 'home' OR option_name = 'siteurl';"
$SQL_COMMAND "UPDATE wp_posts SET guid = replace(guid, '$OLD_URL', 'http://$ALBDNSNAME');"
$SQL_COMMAND "UPDATE wp_posts SET post_content = replace(post_content, '$OLD_URL', 'http://$ALBDNSNAME');"
$SQL_COMMAND "UPDATE wp_postmeta SET meta_value = replace(meta_value, '$OLD_URL', 'http://$ALBDNSNAME');"
EOF

chmod 755 /home/ec2-user/update_wp_ip.sh
echo "/home/ec2-user/update_wp_ip.sh" >> /etc/rc.local
/home/ec2-user/update_wp_ip.sh

Script para actualizar el valor hardcoded del siteurl en WordPress por el DNS del Load Balancer, dentro del bootstrapping de las instancias EC2.

Conexión exitosa al sitio WordPress utilizando el DNS del Load Balancer, que distribuye el tráfico entre las instancias EC2.

---

Aprovisionamiento automático con escalado por CPU

Aplico una política de escalado basada en CPUUtilization en el Auto Scaling Group.

Cuando la CPU supera un umbral, se lanza automáticamente una nueva instancia. Cuando baja, se elimina. Esto reduce costos y mantiene disponibilidad.

Dos políticas de escalado (simple) configuradas sobre la métrica de uso de CPU: una para escalar out cuando la carga aumenta, y otra para escalar in cuando disminuye.

Monitoreo de la métrica CPUUtilization donde observamos un aumento sostenido en el uso de CPU, superando el umbral definido en la política de escalado automático.

Auto Scaling en acción: se ha lanzado automáticamente una nueva instancia al superarse el 40 % de uso de CPU, según la política definida en el ASG.

Monitoreo en tiempo real: al reducirse el uso de CPU por debajo del umbral, el Auto Scaling Group finaliza automáticamente una instancia, optimizando recursos.

Escalado inteligente en marcha: al mantenerse el uso de CPU por debajo del 40 %, el Auto Scaling Group reduce automáticamente la cantidad de instancias, finalizando una de las provisionadas.

---

Topología lógica final

La arquitectura final queda compuesta por:

• WordPress en múltiples EC2 usando un Launch Template

• ALB para entrada única y balanceo de tráfico

• RDS como base de datos desacoplada

• EFS como almacenamiento compartido para contenido estático

• ASG con políticas de escalado automático

• SSM como backend seguro de parámetros

Diagrama lógico de la topología final: arquitectura desacoplada y resiliente con EC2 escalables, RDS gestionado, EFS compartido y balanceo de carga a través de un ALB.

---

✅ Checklist final

---

Resultados y aprendizajes

• Pasamos de un WordPress monolítico a una arquitectura modular, desacoplada y tolerante a fallos.

• Automatizamos el aprovisionamiento con Launch Templates y User Data.

• Aprendimos a gestionar datos sensibles con SSM Parameter Store.

• Entendimos la importancia de manejar correctamente siteurl para evitar errores en entornos dinámicos.

• Implementamos un sistema escalable que responde automáticamente a la carga con políticas de Auto Scaling.

---

Conclusión

Este ejercicio representa una transición realista y progresiva hacia buenas prácticas en infraestructura cloud moderna: automatización, desacoplamiento, escalabilidad y seguridad.

La implementación de servicios como RDS, EFS, ALB y ASG, en conjunto con un diseño modular y el uso de herramientas como SSM, demuestran cómo podemos construir entornos resilientes que escalen según demanda, con un costo controlado y mantenimiento reducido.

Una base sólida sobre la cual crecer y optimizar en futuros escenarios productivos.

Referencias y enlaces

• 🔗 Repositorio Github imagenes