En post anteriores donde hablé de como desplegar un WordPress usando entorno AWS, comentamos como usar CloudFront como CDN para mejorar ciertas capacidades. También expliqué que por coste, la opción de usar Spot es la más barata, pero tiene también problemas como las interrupciones. Pero ya que tenemos CloudFront delante de nuestro WordPress, ¿Por qué no usar su cache para cachear WordPress cuando la EC2 no está disponible?
EC2 Spot interrupción
Como ya sabemos a nivel de precio Spot es opción más económica pero tiene el inconveniente de las interrupciones. Al tener como origen la EC2, cuando hay una interrupción, CloudFront detecta que el backend no está disponible y lanza este error.
EC2 tarda poco en levantar la nueva instancia pero es molesto, además, puede afectar a nivel SEO si nuestra web está continuamente “caída”. Y otra cosa que no podemos controlar es el nivel de interrupción del mercado Spot. Puede que haya meses en los que la EC2 ni se mueve y otros períodos en los que sea una constante.
Estas interrupciones son tan cortas que ni el Healtcheck de Route53 ni el UptimeRobot me avisan a tiempo, al ser en intervalos de 5 minutos.
En cuanto la EC2 dejé de estar disponible, CloudFront va a lanzar un error. Y da igual si la página estaba cacheada o no, vamos a tener un 504.
curl -I https://www.rubenortiz.es/2025/05/08/comparativa-de-precios-ec2/
HTTP/2 504
content-type: text/html; charset=UTF-8
server: nginx
date: Sun, 18 May 2025 07:34:23 GMT
x-content-type-options: nosniff
x-xss-protection: 1; mode=block
link: <https://www.rubenortiz.es/wp-json/>; rel="https://api.w.org/"
x-frame-options: SAMEORIGIN
strict-transport-security: max-age=31536000
x-cache: Miss from cloudfront
via: 1.1 c16a076a98fe12ce8f7219a60d831ccc.cloudfront.net (CloudFront)
x-amz-cf-pop: MRS52-C2
x-amz-cf-id: s4rZlFP7-eo568gEE8ZgJ7ndLVnW5j-h-OvwiP5mVVh_zsVSI0VkAw==
age: 1983CloudFront al rescate
Entonces como siempre, el tema cache es complicado incluso para entornos sencillos. Y depende mucho de tu configuración de WordPress. En mi caso no uso plugin de caché. No tengo el típico W3Cache, etc. Son plugins demasiado grandes, difíciles de gestionar si no tienes mucha experiencia. Solo tengo el Opcache habilitado y listo.
Entonces, ¿Cómo le podemos indicar a CloudFront que no vaya a buscar al origen el dato que se le ha pedido si el origin no está disponible?
Lo que necesitamos es decirle a CloudFront: “si el origin (mi EC2) devuelve un error 504, intenta servir la versión cacheada que ya tenías en lugar de mostrar el error al usuario”.
Para ello, podemos usar la opción custom_error_response en la configuración de CloudFront. Este bloque permite especificar qué hacer cuando el origin devuelve ciertos errores (como 500, 502, 503 o 504). Si ya existía una copia en caché de la página solicitada, CloudFront podrá seguir sirviéndola durante un tiempo limitado, aunque la instancia EC2 esté caída.
En mi caso, añadí esta configuración en Terraform (puedes lo mismo usando la consola de AWS) para cubrir los errores típicos de origen no disponible:
custom_error_response {
error_code = 504
response_code = 504
response_page_path = "/"
error_caching_min_ttl = 60
}
Con esto, si CloudFront detecta que el backend está fallando y ya tiene una versión cacheada de esa URL, servirá esa versión durante 60 segundos, lo que suele ser más que suficiente para que la nueva EC2 Spot esté disponible de nuevo.
Cuando usar la cache de CloudFront en WordPress…y cuando no
Este paso es crítico. No todas las páginas de WordPress deben ser cacheadas. Si cacheamos contenido sensible (como el área de administración), podríamos mostrar a un visitante la sesión de otro usuario. Por eso hay que separar claramente el comportamiento de caché según la URL y las cookies:
Páginas públicas (como el home, posts, etc.)
Estas sí deben ser cacheadas agresivamente para ganar rendimiento y resiliencia. Para ello:
- En el
default_cache_behavior, configuramos: { forward = "none" }- Esto le dice a CloudFront: “ignora las cookies y cachea la misma respuesta para todos los usuarios”.
- Es ideal para páginas sin personalización como
/,/blog/, etc.
Páginas privadas (como /wp-admin/*, /wp-login.php, etc.)
Estas no deben ser cacheadas nunca. Para protegerlas:
Al hacer forward de estas cookies, CloudFront detecta que la respuesta es específica del usuario y no la guarda en caché.
Creamos ordered_cache_behavior específicos para esas rutas.
ordered_cache_behavior {
path_pattern = "wp-admin/*"
}
cookies {
forward = "whitelist"
whitelisted_names = var.cloudfront_cookies_whitelisted_names
}
variable "cloudfront_cookies_whitelisted_names" {
description = "List of cookies to be whitelisted."
type = list(string)
default = [
"comment_author_*",
"comment_author_email_*",
"comment_author_url_*",
"wordpress_*",
"wordpress_logged_in_*",
"wordpress_test_cookie",
"wp-settings-*",
"wordpress_sec_*",
"wp-settings-time-*"
]
}Precargar la cache
Ahora bien, todo lo anterior solo funciona si CloudFront ya tiene una copia cacheada de la página cuando ocurre el error. Si la página nunca fue visitada antes, y por tanto no está en la caché, CloudFront intentará ir al origin… y si la EC2 Spot está caída, mostrará igualmente un 504.
Por eso es crítico “calentar la caché” (cache warming) después de cada despliegue. Esto significa realizar peticiones automáticas a las páginas públicas más importantes de tu WordPress (como el home, entradas recientes, páginas de contacto, etc.) para que CloudFront las almacene anticipadamente.
Hay muchas formas de hacerlo:
- Un pequeño script que use
curlpara recorrer tus URLs clave. - Leer tu sitemap o la REST API de WordPress y lanzar peticiones tras cada deploy.
- Usar herramientas externas o Lambdas automatizadas.
Sin esta precarga, tu sistema de caché estará “frío” y CloudFront no podrá ayudarte si la EC2 falla justo en el primer acceso. En cambio, con una caché caliente y bien configurada, CloudFront se convierte en un verdadero escudo de resiliencia para tu WordPress sobre Spot.
Y por finalizar, fuera del alcance del post está tratar como hacer invalidaciones de la caché de forma programática porque hay varias opciones y hay que estudiarlo bien. Pero necesitaremos una herramienta para poder refrescar nuestra caché cada vez que actualicemos nuestro contenido.
Conclusión
Aunque Spot puede darnos problemas puntuales, con una configuración adecuada de CloudFront podemos ocultar muchas de esas interrupciones al usuario y proteger el SEO de nuestra web. Este pequeño cambio puede marcar una gran diferencia en la resiliencia de tu WordPress sobre AWS.
