Código en el borde: CloudFront Functions y Lambda@Edge

CloudFront ya acerca tus archivos al usuario. Pero a veces necesitas decidir algo en cada petición: redirigir según el país, limpiar encabezados, revisar un token o mandar al 10 % de la gente a una versión nueva. Si esa decisión va hasta tu región, pierdes lo que ganaste con el borde. CloudFront permite correr ese código en los puntos de presencia.

Los cuatro momentos de una petición

CloudFront te deja enganchar código en cuatro eventos. Elegir el correcto define cuántas veces corre y qué puede tocar.

1. 1

   Viewer request

   Llega la petición del usuario, antes de mirar la caché. Corre en todas las peticiones, incluso las que luego son aciertos de caché. Lugar para redirecciones, reescritura de URL y validar tokens.
2. 2

   Origin request

   Solo si no estaba en caché, antes de ir al origen. Lugar para elegir otro origen o agregar datos que el origen necesita.
3. 3

   Origin response

   Llega la respuesta del origen, antes de guardarla en caché. Lo que cambies aquí queda guardado y no se repite en los siguientes aciertos.
4. 4

   Viewer response

   Justo antes de responder al usuario, en todas las peticiones. Lugar para encabezados que dependen de quién pide.

CloudFront Functions o Lambda@Edge

Criterio	CloudFront Functions	Lambda@Edge
Lenguaje	JavaScript (compatible con ECMAScript 5.1, con extras en el runtime 2.0)	Node.js y Python
Eventos	Solo viewer request y viewer response	Los cuatro eventos
Escala	Millones de peticiones por segundo	Hasta 10.000 peticiones por segundo por región
Duración	Menos de un milisegundo	Hasta 30 segundos
Memoria y tamaño	2 MB de memoria, 10 KB de código	128 MB en eventos viewer, hasta 10.240 MB en eventos de origen; paquete de 50 MB
Red, archivos y cuerpo de la petición	No	Sí: puede llamar servicios externos, a DynamoDB o a S3
Datos de configuración	CloudFront KeyValueStore: pares llave-valor que cambias sin redesplegar	Lo que traiga en el paquete o consulte por red

La regla práctica: empieza con CloudFront Functions. Pasa a Lambda@Edge cuando necesites red, librerías, el cuerpo de la petición, más tiempo o un evento de origen. Las dos reutilizan lo que viste en Lambda, pero no son lo mismo que una función regional.

Usos típicos y dónde van

Este mismo sitio es un ejemplo. Es un sitio estático en S3 detrás de CloudFront, desplegado con SST. SST agrega una CloudFront Function en viewer request que traduce cada URL limpia al archivo HTML que existe en el bucket, parecida a esta:

// CloudFront Function en viewer request:
// /curso/lambda/ → /curso/lambda/index.html
function handler(event) {
  var request = event.request;
  var uri = request.uri;
  if (uri.endsWith("/")) {
    request.uri = uri + "index.html";
  } else if (!uri.includes(".")) {
    request.uri = uri + "/index.html";
  }
  return request;
}

La llave de caché y las políticas

La llave de caché (cache key) es lo que CloudFront usa para decidir si dos peticiones piden lo mismo. Por defecto es el dominio y la ruta. Cada encabezado, cookie o parámetro que agregas crea más variantes y baja la proporción de aciertos.

• 

  Cache policy

  Define la llave de caché y los TTL. Lo que entra aquí también llega al origen.
• 

  Origin request policy

  Envía al origen encabezados, cookies o parámetros que necesita, sin meterlos en la llave de caché.
• 

  Response headers policy

  Agrega encabezados a la respuesta: CORS, HSTS, Content-Security-Policy. Sin código.

Origin Shield y grupos de origen

Sin ayuda, cada caché regional de CloudFront que no tiene un objeto lo pide al origen. Con usuarios en varios continentes, el mismo archivo puede llegar al origen muchas veces. Origin Shield agrega una capa más de caché, en la región que elijas (la de menor latencia hacia tu origen). Todas las cachés regionales pasan por ahí, y las peticiones simultáneas por el mismo objeto se juntan en una sola. Conviene con audiencias globales, orígenes en tu centro de datos con poco ancho de banda, video en vivo o imágenes que el origen procesa al vuelo. No ayuda con contenido dinámico que no se cachea.

Un grupo de origen (origin group) tiene un origen primario y uno secundario. Si el primario responde con un código que configuraste (por ejemplo 500, 502, 503 o 504) o no responde a tiempo, CloudFront reintenta en el secundario. Solo hace failover con GET, HEAD y OPTIONS; un POST no cambia de origen. Por defecto espera hasta 30 segundos (3 intentos de 10) antes de cambiar; puedes bajar esos valores.