WordPress Serverless AWS Lambda Aurora 2025

La migración de WordPress a un modelo serverless basado en AWS Lambda y Aurora Serverless representa un cambio de paradigma en la administración de sitios web. Dejar atrás el servidor tradicional (ya sea Apache o Nginx) y adoptar una arquitectura de eventos y bases de datos sin servidor permite alcanzar niveles de escalabilidad automática que antes eran impensables para un CMS como WordPress. Este artículo es una guía técnica completa para entender, planificar y ejecutar esta migración, optimizando costes y rendimiento.

¿Por qué migrar WordPress a una arquitectura Serverless?

WordPress tradicional se ejecuta sobre un stack LAMP/LEMP. Esto implica un servidor web siempre encendido, que consume recursos incluso cuando no hay tráfico. Con WordPress serverless, eliminamos el servidor persistente. En su lugar, usamos AWS Lambda para ejecutar el código PHP (vía capas personalizadas o contenedores) y Aurora Serverless para la base de datos, que escala a cero cuando no se usa.

Las ventajas clave son:

Escalabilidad automática: Lambda escala desde cero a miles de ejecuciones concurrentes en segundos. Aurora Serverless ajusta la capacidad de la base de datos según la demanda.
Coste reducido en entornos de baja carga: Pagas solo por las ejecuciones de Lambda y el almacenamiento de Aurora. Sin servidor ocioso.
Alta disponibilidad nativa: Lambda replica funciones en múltiples AZs. Aurora Serverless es multi-AZ por defecto.
Mantenimiento delegado: AWS gestiona parches, seguridad y escalado. Tú solo te centras en el código y el contenido.

[INFO] Esta arquitectura es ideal para sitios con tráfico impredecible, blogs personales, sitios corporativos con picos estacionales o portafolios. No es recomendable para WooCommerce con sesiones de usuario complejas o sitios que requieran plugins con dependencias de servidor muy específicas.

Desafíos técnicos de la migración

Migrar WordPress a serverless no es un simple «lift and shift». Hay que adaptar el comportamiento del CMS a un entorno sin sistema de archivos persistente y sin sesiones tradicionales.

Problemas principales a resolver

Sistema de archivos efímero: Lambda solo dispone de /tmp con 512 MB (ampliable a 10 GB). Los uploads de medios deben ir a S3.
Sesiones PHP: WordPress usa sesiones nativas. En Lambda no hay persistencia entre requests. Hay que usar sesiones externas (Redis o DynamoDB).
Procesamiento de imágenes: La biblioteca de medios requiere redimensionado. Debe delegarse a Lambda o servicios como AWS Image Handler.
Plugins y temas: Muchos plugins esperan un sistema de archivos real. Deberán auditarse y, en muchos casos, modificarse.
Caché de página: El caché de WordPress (W3 Total Cache, WP Super Cache) no funciona igual. Necesitas una CDN como CloudFront.

Arquitectura de referencia para WordPress Serverless

La arquitectura típica se compone de estos elementos:

Amazon CloudFront: CDN para servir contenido estático (CSS, JS, imágenes) y páginas cacheadas.
AWS Lambda + API Gateway: Ejecuta el código PHP de WordPress mediante Bref (capa PHP para Lambda) o Laravel Vapor (si usas Laravel). Cada request HTTP se convierte en una invocación de Lambda.
Amazon S3: Almacena los archivos multimedia (wp-content/uploads). Se monta virtualmente o se usa un plugin como WP Offload Media.
Aurora Serverless v2: Base de datos MySQL compatible con WordPress. Escala automáticamente en función de la carga.
ElastiCache Redis: Para sesiones, caché de objetos y colas.
AWS Systems Manager Parameter Store: Guarda credenciales y configuraciones (wp-config.php).

Flujo de una petición

El usuario accede a https://tusitio.com/articulo.
CloudFront verifica si la página está en caché. Si es así, la sirve directamente.
Si no está cachead, CloudFront reenvía la petición a API Gateway.
API Gateway invoca una función Lambda con el evento HTTP.
Lambda ejecuta el runtime PHP (Bref), que carga WordPress desde un layer.
WordPress procesa la petición. Los archivos estáticos se sirven desde S3 (vía plugin).
La base de datos se consulta en Aurora Serverless (conexión desde Lambda).
La respuesta HTML se genera y se devuelve a CloudFront, que la cachea.
La sesión del usuario se almacena en Redis.

Pasos prácticos para la migración

1. Preparación del entorno

Primero, necesitas tener una cuenta de AWS con los permisos adecuados. Instala la AWS CLI y Serverless Framework o Terraform para gestionar la infraestructura como código.

# Instalar Serverless Framework
npm install -g serverless

# Configurar credenciales AWS
aws configure

2. Configurar Aurora Serverless

Crea un clúster de Aurora Serverless v2 con MySQL 8.0. Es importante que la base de datos esté en la misma VPC que las funciones Lambda.

aws rds create-db-cluster \
    --db-cluster-identifier wordpress-serverless \
    --engine aurora-mysql \
    --engine-version 8.0 \
    --serverless-v2-scaling-configuration MinCapacity=0.5,MaxCapacity=4 \
    --master-username admin \
    --master-user-password TuPasswordSegura

[TIP] Usa Secrets Manager o Parameter Store para almacenar las credenciales de la base de datos. Nunca las hardcodees en el código.

3. Empaquetar WordPress para Lambda

Usa Bref para crear un layer de PHP que ejecute WordPress. Crea un proyecto con la estructura adecuada:

composer create-project bref/bref wordpress-serverless
cd wordpress-serverless

Edita el archivo serverless.yml para definir la función Lambda:

service: wordpress-serverless

provider:
  name: aws
  region: us-east-1
  runtime: provided.al2
  environment:
    WP_HOME: 'https://tudominio.com'
    WP_SITEURL: 'https://tudominio.com'
    DB_HOST: !GetAtt AuroraCluster.Endpoint.Address
    DB_NAME: wordpress
    DB_USER: admin
    DB_PASSWORD: ${ssm:/wordpress/db/password}
    S3_UPLOADS_BUCKET: tu-bucket-uploads

functions:
  wordpress:
    handler: public/index.php
    layers:
      - ${bref:layer.php-80}
    events:
      - httpApi: '*'

4. Migrar los archivos multimedia a S3

Descarga todos los archivos de wp-content/uploads y súbelos a un bucket S3. Luego instala el plugin WP Offload Media o usa un script personalizado que reescriba las URLs.

aws s3 sync /ruta/local/wp-content/uploads/ s3://tu-bucket-uploads/uploads/

5. Exportar e importar la base de datos

Usa mysqldump para exportar tu base de datos local y luego impórtala en Aurora Serverless.

# Exportar desde el servidor original
mysqldump -h old-db-host -u user -p wordpress_db > wordpress_backup.sql

# Importar a Aurora Serverless
mysql -h aurora-endpoint -u admin -p wordpress_db < wordpress_backup.sql

6. Configurar sesiones y caché

Añade las siguientes constantes a wp-config.php para usar Redis:

define('WP_REDIS_HOST', 'redis-cluster-endpoint');
define('WP_REDIS_PORT', 6379);
define('WP_CACHE', true);
define('WP_SESSION_TYPE', 'redis');

Instala el plugin Redis Object Cache y actívalo.

Optimización y escalabilidad automática

Una vez migrado, la escalabilidad automática es inherente. Lambda escalará horizontalmente con el tráfico. Sin embargo, hay que ajustar algunos parámetros:

Concurrencia de Lambda: Establece un límite de concurrencia reservada para tu función WordPress (ej. 1000) para evitar un consumo excesivo de recursos.
Aurora Serverless scaling: Configura MinCapacity y MaxCapacity según el tráfico esperado. Aurora Serverless v2 escala en incrementos de 0.5 ACU.
Caché de CloudFront: Configura comportamientos de caché agresivos para contenido estático y páginas HTML. Usa Cache-Control y ETag para reducir las invocaciones a Lambda.
Cold starts: Para mitigar el tiempo de arranque de Lambda, usa Provisioned Concurrency (mantiene un número de instancias calientes). Esto tiene un coste adicional, pero es crítico para sitios con tráfico constante.

[WARNING] Los cold starts de Lambda pueden durar entre 500ms y 2s la primera vez que se invoca una función después de un periodo de inactividad. Para sitios con tráfico muy bajo, considera usar Provisioned Concurrency o un plugin de keep-alive.

Monitorización y costes

Usa Amazon CloudWatch para monitorizar:

Invocaciones y errores de Lambda.
Latencia de las peticiones.
Capacidad de Aurora Serverless (unidades de capacidad).
Costes estimados con AWS Cost Explorer.

Para un sitio pequeño (10k visitas/mes), los costes mensuales podrían ser:

Lambda: ~$2-5 (dependiendo del tiempo de ejecución y memoria).
Aurora Serverless: ~$10-15 (con 0.5 ACU de media).
S3: <$1.
CloudFront: ~$1-3.
Total: ~$15-25/mes. Mucho menor que un VPS tradicional.

Conclusión

Migrar WordPress a AWS Lambda y Aurora Serverless es técnicamente complejo pero altamente gratificante. Obtienes una arquitectura que escala automáticamente, reduce costes en baja carga y elimina la gestión de servidores. La clave está en adaptar el comportamiento de WordPress: sistema de archivos en S3, sesiones en Redis y procesamiento asíncrono de imágenes.

¿Es para todos? No. Si tu sitio depende de muchos plugins pesados (WooCommerce, LMS complejos) o necesitas control total sobre el servidor, mejor quédate con un VPS. Pero si buscas escalabilidad automática, resiliencia y una factura predecible, este es el camino.

[INFO] Este artículo es una guía conceptual y práctica. Para una implementación completa, recomiendo leer la documentación de Bref (bref.sh) y Serverless WordPress (github.com/bref/wordpress). La migración puede llevar de 2 a 5 días dependiendo de la complejidad del sitio.

¡Ahora es tu turno! Empieza por crear un entorno de pruebas y exporta tu WordPress. La nube sin servidor te espera.