Desde que moví mi blog a AWS ha llovido un poco. Lo tenía inicialmente en Linode pero pensé que sería buena idea moverlo a AWS, a pesar de ser bastante más caro, para poder ensuciarme las manos y ganar algo de experiencia. Esto fue en febrero de 2018. Ahí empecé a montar el blog y obviamente las cosas han cambiado mucho y he cambiado la manera de desplegar, la infraestructura, etc. Sigo usando ElasticBeanstalk eso sí. De hecho, me sorprende que AWS aún mantenga este servicio. En fin, os explico como lo tengo montado ahora y como podemos desplegar WordPress en AWS. El cambio principal fue dejar de usar CodePipeline y mover el CD a GitHub Actions.
Como desplegaba WordPress antes
Mirada al pasado.
Antiguamente ya usaba Github y Terraform pero además usaba CodePipeline. Hoy en día, he eliminado CodePipeline de la ecuación y lo he sustituido por Github actions. ¿Por qué? Mucho más sencillo que lidiar con CodePipeline. Usé CodePipeline por la integración con Beanstalk pero nada que no puedas hacer con Github actions. Además, de esta manera el CI y el CD están muy juntitos.
Como despliego WordPress ahora
El cambio principal: Github Actions, fuera CodePipeline
Automatización del despliegue
El despliegue de WordPress está automatizado mediante un pipeline de CI/CD que se ejecuta cuando los cambios llegan a la rama principal del repositorio.
No voy a mostrar la configuración completa del pipeline ni los identificadores de los recursos utilizados, pero conceptualmente el proceso es el siguiente:
Push a rama principal
│
▼
┌───────────────────────┐
│ Validaciones previas │
│ │
│ • Terraform format │
│ • Terraform validate │
│ • TFLint │
│ • Detectar versión WP │
└───────────┬───────────┘
│
▼
┌───────────────────────┐
│ Infraestructura │
│ │
│ Terraform plan │
│ Terraform apply │
└───────────┬───────────┘
│
▼
┌───────────────────────┐
│ Preparar aplicación │
│ │
│ Crear artefacto │
│ Versionarlo │
│ Subirlo a AWS │
└───────────┬───────────┘
│
▼
┌───────────────────────┐
│ Despliegue │
│ │
│ Elastic Beanstalk │
│ Esperar estado Ready │
│ Comprobar Health │
└───────────┬───────────┘
│
▼
┌───────────────────────┐
│ Validaciones finales │
│ │
│ • Limpiar caché CDN │
│ • Security headers │
│ • Comprobar despliegue│
└───────────────────────┘
Validación antes de desplegar
Antes de modificar producción se comprueba que la infraestructura definida con Terraform sea válida.
El pipeline realiza comprobaciones de formato, inicializa Terraform, valida la configuración y ejecuta análisis estático con TFLint.
Después se genera un terraform plan. Si existen cambios de infraestructura, estos se aplican antes de desplegar la nueva versión de WordPress.
De esta forma, la infraestructura y la aplicación evolucionan dentro del mismo proceso de despliegue.
Creación de una versión de la aplicación
Una vez validada la infraestructura, el código de WordPress se empaqueta como un artefacto de despliegue.
Algunos directorios que solo son necesarios para desarrollo, documentación o infraestructura quedan fuera del paquete.
El artefacto recibe un identificador relacionado con la revisión del repositorio, lo que permite relacionar una versión desplegada con el código que la generó.
El paquete se almacena temporalmente en AWS y posteriormente se registra como una nueva versión de la aplicación.
Despliegue en Elastic Beanstalk
Elastic Beanstalk recibe la nueva versión y actualiza el entorno de producción.
El pipeline no considera terminado el despliegue inmediatamente después de lanzar la operación. Espera hasta comprobar que:
versión desplegada == versión esperada
estado == Ready
salud del entorno == correcta
Si alguna de estas condiciones no se cumple, el pipeline se detiene y el despliegue se considera fallido.
Esto permite detectar problemas automáticamente en lugar de asumir que el simple envío de una nueva versión significa que la aplicación funciona correctamente.
Invalidación de caché
Después de un despliegue correcto se invalida la caché de la CDN.
Esto evita que los visitantes continúen recibiendo durante un tiempo archivos pertenecientes a la versión anterior de WordPress.
El pipeline espera también a que finalice esta operación antes de continuar.
Comprobaciones de seguridad
Como última validación automática se realiza una petición a la web publicada y se comprueba que continúan presentes determinadas cabeceras HTTP de seguridad.
Entre otras, se verifican cabeceras relacionadas con:
HSTS
protección frente a framing
MIME sniffing
Referrer Policy
Permissions Policy
Si alguna desapareciera accidentalmente después de un cambio de configuración, el despliegue quedaría marcado como fallido.
Caso especial: actualización del core de WordPress
El pipeline distingue entre un despliegue normal y una actualización de versión de WordPress.
Para ello compara la versión que se encuentra actualmente en producción con la versión incluida en el código que se pretende desplegar.
Conceptualmente:
Versión producción
│
├── igual ──────► despliegue normal
│
└── diferente ──► actualización WordPress
Las actualizaciones del core requieren un tratamiento especial porque una nueva versión de WordPress puede necesitar también modificar el esquema de la base de datos.
Por este motivo, este tipo de despliegue introduce una fase controlada adicional.
Nueva versión WordPress
│
▼
Despliegue temporal
│
▼
Actualización de base de datos
│
▼
Validación manual
│
▼
Despliegue definitivo
Durante esa ventana se habilita temporalmente únicamente lo necesario para poder completar la actualización.
Una vez actualizada y validada la base de datos, se requiere una confirmación manual antes de continuar.
Después se genera una segunda versión de la aplicación con la configuración normal de seguridad restaurada y se vuelve a desplegar.
La idea es que la excepción necesaria para actualizar WordPress exista únicamente durante el tiempo imprescindible y no quede habilitada permanentemente.
Resultado
Con este sistema, un cambio en WordPress no consiste simplemente en copiar archivos al servidor.
El despliegue pasa por varias capas:
Código
↓
Validaciones
↓
Infraestructura
↓
Artefacto versionado
↓
Despliegue
↓
Health checks
↓
CDN
↓
Comprobaciones de seguridad
Y cuando se detecta una actualización del propio WordPress:
Deploy
↓
Upgrade de base de datos
↓
Validación humana
↓
Restauración de configuración segura
Esto permite mantener el proceso automatizado sin eliminar por completo los controles manuales en aquellas operaciones que pueden introducir cambios irreversibles, como una actualización del esquema de la base de datos de WordPress.
Entorno de Beta
En mi caso como es un blog personal, el entorno de Beta solo lo levanto si tengo que probar alguna actualización fuerte de WordPress o algún plugin, el resto del tiempo el entorno está muerto
OIDC
Otra mejora fue implementar OIDC, justamente para mejorar todo el tema del CI y CD. Y de paso eliminar algunas AccessKeys molestas.
Encriptación punto a punto
Por motivos obvios de contención del gasto no puedo seguir las buenas prácticas al cien por cien pero al menos, la encriptación es total en tránsito desde la capa de edge hasta el recurso EC2.
Tengo planeado moverme a Let’s Encrypt pronto.
Sigo usando CloudFront al cual he ido añadiendo algunas mejoras con el tiempo.
WAF
Probé un tiempo AWS WAF pero incluso para un tráfico pequeñísimo es muy caro. De ahí me moví a configurar mejor la caché de CloudFront y endurecer la política de Nginx para evitar que Bots o simples ataques por volumen hicieran colapsar la infraestructura.
Resumen
La mejora principal ha sido sustituir CodePipeline por Github Actions y tenerlo todo centralizado en un solo punto.
Además he creado alguna herramienta pequeñita para automatizar el despliegue de actualizaciones de WordPress o los plugins para facilitarme algo más la vida.
Links
- https://www.rubenortiz.es/2020/10/04/un-wordpress-en-aws-como-implementarlo-parte-1/
- https://www.rubenortiz.es/2020/10/11/un-wordpress-en-aws-como-implementarlo-parte-ii/
- https://www.rubenortiz.es/2020/11/14/un-wordpress-en-aws-como-implementarlo-parte-3/
- https://www.rubenortiz.es/2026/05/18/configurar-oidc-en-github-actions/
- https://www.rubenortiz.es/2026/04/28/aws-waf-shield-advanced-guia-practica/
- https://www.rubenortiz.es/2026/04/12/defender-wordpress-de-bots-con-nginx/
- https://www.rubenortiz.es/2025/08/03/mostrar-ip-real-en-nginx-detras-de-cloudfront/
- https://www.rubenortiz.es/2026/08/14/habilitar-tags-en-metadatos-a-nivel-cuenta-en-aws/
- https://aws.amazon.com/lightsail/projects/wordpress/
¿Te ha ayudado este artículo?
☕ Invítame a un café