En la lección 02-03 hicimos un cálculo que dejó a Marta en silencio: de la factura mensual de S3 del catálogo de fotos, el 97 % no era almacenamiento, era transferencia de salida. Cada vez que un cliente de Sevilla abre la ficha del tomate rama, la foto viaja íntegra desde un centro de datos de Irlanda hasta su móvil, y MercadoFresco paga por cada byte. Si el cliente recarga la página, se paga otra vez. Si diez mil clientes miran la misma foto, se paga diez mil veces por el mismo fichero.

Y ahora, tras montar el balanceador en 03-03, hay un segundo cobro por GB: el ALB también factura por el tráfico que procesa.

Amazon CloudFront es la red de distribución de contenido (CDN) de AWS: unos 700 puntos de presencia repartidos por el mundo que guardan una copia de tu contenido cerca de quien lo pide. El cliente de Sevilla recibe la foto desde Madrid en vez de desde Dublín; la petición no llega ni a S3 ni al ALB; y la transferencia de salida de CloudFront tiene una capa gratuita permanente de 1 TB al mes que cubre entera la demanda actual de MercadoFresco.

En esta lección Marta pone CloudFront delante de todo y ataca directamente el problema del coste, sin perder de vista lo otro que aporta una CDN y que a menudo importa más: latencia.

1. Qué es una CDN y cómo funciona el reparto desde el borde
2. Aciertos y fallos de caché
3. Distribuciones y orígenes
4. Grupos de origen y conmutación por error
5. Comportamientos de caché y patrones de ruta
6. La clave de caché: políticas de caché y de solicitud de origen
7. TTL: mínimo, máximo y por defecto
8. Compresión, HTTP/2 y HTTP/3
9. Origin Access Control: cerrar el bucket al mundo
10. Invalidaciones frente a versionado de nombres de fichero
11. Dominios propios y la trampa del certificado en us-east-1
12. Contenido dinámico a través de CloudFront hacia el ALB
13. CloudFront Functions y Lambda@Edge
14. Registros, métricas y tasa de aciertos
15. Clases de precio y el cálculo de ahorro de MercadoFresco
16. Creación por CLI, invalidación y limpieza

Una CDN (Content Delivery Network) es una red de servidores caché distribuidos geográficamente que se sitúan entre el usuario y el servidor de origen. CloudFront tiene tres niveles:

Las edge locations más cercanas a los clientes de MercadoFresco son Madrid y Marsella, con salida también por Londres y París. Un cliente de Sevilla que hoy espera a que la foto cruce 2.000 km hasta Dublín pasará a recibirla desde Madrid, a 400 km.

La ganancia de latencia es la mitad del argumento y no debe subestimarse: una tienda que carga medio segundo más lento pierde conversiones medibles. La otra mitad es el dinero, y la vemos con números al final de la lección.

Todo el funcionamiento de CloudFront se reduce a este diagrama:

Tres cosas que este diagrama enseña y conviene fijar:

1. Solo el primer usuario paga la espera larga. Los siguientes reciben la respuesta desde el borde.
2. La transferencia del origen a CloudFront es gratuita cuando el origen es S3 (y también desde un ALB o EC2 en la misma cuenta). Esto es la clave económica de toda la lección.
3. Existe un segundo nivel. Aunque la edge de Madrid no lo tenga, quizá lo tenga la regional edge cache, y el origen se ahorra la petición igualmente. Esto mejora mucho la tasa de aciertos real frente a lo que uno calcularía a ojo.

Cada respuesta lleva la cabecera X-Cache, que dice exactamente qué ocurrió:

Una distribución es la unidad de configuración de CloudFront. Al crearla, AWS asigna un nombre de dominio propio, del tipo d111111abcdef8.cloudfront.net, y despliega la configuración en todas las edge locations en unos minutos.

Dentro de una distribución se declaran uno o varios orígenes. MercadoFresco necesita dos:

La diferencia entre los dos tipos de origen no es cosmética:

Un matiz que confunde: si configuras un bucket de S3 como sitio web estático (el modo que vimos en 02-03, con su propio dominio .s3-website-), CloudFront lo trata como origen personalizado, no como origen S3, y entonces no puedes usar OAC. Para MercadoFresco usamos el endpoint REST de S3 con OAC, que es lo correcto.

Un grupo de origen empareja dos orígenes: uno primario y uno secundario. Si el primario devuelve uno de los códigos de error configurados, CloudFront reintenta automáticamente contra el secundario, de forma transparente para el cliente.

Solo funciona con GET, HEAD y OPTIONS, y los criterios pueden incluir además 403 y 404. Para MercadoFresco tiene sentido el día que se replique el catálogo a un bucket de otra región; hoy es una configuración preparada, no activa. La conmutación por error a nivel de DNS, que es un mecanismo distinto y complementario, se estudia en la lección 03-05.

Un comportamiento de caché (cache behavior) asocia un patrón de ruta con un origen y con un conjunto de reglas. Es el equivalente a las reglas del ALB, pero en el borde.

MercadoFresco define cuatro:

Reglas de evaluación, muy parecidas a las del ALB:

• Los comportamientos se evalúan por orden de precedencia y gana el primero que coincida.
• El comportamiento por defecto (*) se evalúa siempre el último, sin excepción.
• Los patrones admiten * y ?, y distinguen mayúsculas de minúsculas.

El comportamiento de /api/* merece atención: hay que permitir todos los métodos HTTP (GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE) porque si no, un cliente que confirme un pedido con POST recibiría un 403 de CloudFront. Y hay que desactivar la caché explícitamente: cachear una respuesta de /api/pedidos/4711 y servírsela a otro cliente sería una fuga de datos grave.

Esta sección es la que separa una CDN que ahorra dinero de una que no sirve para nada.

La clave de caché es el conjunto de datos con el que CloudFront identifica un objeto guardado. Por defecto es solo la ruta de la URL. Pero se le pueden añadir cabeceras, cookies y cadenas de consulta. Y aquí está la trampa:

Cada valor distinto de cualquier elemento de la clave de caché crea una entrada distinta en la caché.

Un ejemplo aritmético que lo deja claro. Supón que incluyes en la clave de caché la cabecera User-Agent, que tiene miles de valores distintos:

Con User-Agent en la clave, CloudFront guarda una copia distinta de la misma foto para cada versión de cada navegador. Casi todas las peticiones son fallos, todas van al origen, y has pagado por una CDN que no cachea nada. Es el error más caro y más frecuente de CloudFront.

Para distinguir bien, AWS separa dos políticas:

El caso que aclara la diferencia: el origen quiere registrar el país del visitante en sus logs. Si pones CloudFront-Viewer-Country en la política de caché, multiplicas las entradas por 30. Si lo pones en la política de solicitud de origen, el origen recibe el dato en cada fallo de caché y la caché sigue teniendo una sola entrada. La segunda es la correcta.

Las políticas gestionadas por AWS cubren casi todo:

Y una política propia, cuando de verdad hace falta variar por idioma:

Decisiones de esta política, una a una:

• Accept-Language en lista blanca: el catálogo se sirve en español y en catalán, así que sí cambia el contenido. Multiplica las entradas por 2, no por miles.
• CookieBehavior: none: las cookies de sesión no cambian el HTML del catálogo. Incluirlas destruiría la caché por completo.
• Solo dos parámetros de consulta en lista blanca: pagina y categoria sí cambian el contenido. Los parámetros de campañas de marketing (utm_source, utm_medium…) no, y si se incluyeran, cada enlace de cada campaña sería una entrada de caché distinta del mismo HTML.
• EnableAcceptEncodingGzip y Brotli: CloudFront normaliza la cabecera y guarda las variantes comprimidas de forma inteligente, sin que cuenten como valores arbitrarios.

El TTL (Time To Live) es cuánto tiempo guarda CloudFront un objeto antes de volver a preguntar. Hay tres valores y su interacción con las cabeceras del origen despista:

La lógica completa:

1. Si el origen no envía Cache-Control ni Expires → se aplica DefaultTTL.
2. Si el origen envía Cache-Control: max-age=N → se usa N, acotado entre MinTTL y MaxTTL.
3. Cache-Control: no-store o private → no se cachea (salvo que MinTTL sea mayor que 0, en cuyo caso se cachea de todos modos: una fuente clásica de sorpresas).

Los valores de MercadoFresco:

Un año de caché para las fotos suena temerario hasta que se entiende la técnica del versionado de nombres, que vemos en dos apartados. Lo correcto es poner la cabecera en el objeto de S3 al subirlo, porque ahí también la aprovechan los navegadores:

immutable es una directiva que le dice al navegador que ni siquiera pregunte si ha cambiado. Elimina incluso las peticiones de revalidación 304.

Tres ajustes que se activan con una casilla y reducen bytes y latencia:

Compresión automática. Con Compress: true, CloudFront comprime con Gzip o Brotli las respuestas de tipos de contenido comprimibles (HTML, CSS, JavaScript, JSON, SVG) cuando el cliente lo admite, siempre que el objeto pese entre 1 KB y 10 MB. Brotli reduce un 15-20 % más que Gzip. Advertencia: no comprime JPEG, PNG ni MP4, que ya están comprimidos; intentarlo solo gastaría CPU.

HTTP/2 y HTTP/3. Se activan por distribución:

HTTP/3 importa especialmente para MercadoFresco: buena parte de sus clientes navegan desde el móvil, y en el móvil las conexiones cambian de antena y de wifi constantemente. QUIC mantiene la sesión cuando eso pasa; TCP tiene que reconectar.

Hoy mercadofresco-catalogo-fotos tiene una política que permite s3:GetObject público bajo productos/. Eso significa que cualquiera puede saltarse CloudFront y descargar directamente desde S3, y MercadoFresco paga la transferencia cara. Además, hace posible el hotlinking: que otra web enlace las fotos de MercadoFresco y le cargue la factura.

Origin Access Control (OAC) resuelve las dos cosas: hace que solo CloudFront pueda leer del bucket, firmando cada petición al origen con SigV4.

OAC sustituye al antiguo OAI (Origin Access Identity). Si encuentras documentación con OAI, está desactualizada: OAI no soporta el cifrado con KMS (nuestra clave alias/mercadofresco-datos), no funciona en todas las regiones y no admite POST/PUT. Para todo lo nuevo, OAC.

Creación del control de acceso:

Y la política del bucket, que es la pieza esencial:

Lo importante de esta política, cláusula a cláusula:

• El principal es el servicio cloudfront.amazonaws.com, no una identidad de usuario.
• La condición AWS:SourceArn es la parte crítica: sin ella, cualquier distribución de CloudFront de cualquier cuenta de AWS podría leer el bucket. Restringe el permiso a la distribución concreta E2QWERTY123ABC de la cuenta 111122223333.
• Solo se concede s3:GetObject, y solo bajo los dos prefijos del catálogo. CloudFront no puede listar el bucket ni escribir nada.
• La segunda cláusula, con Deny y aws:SecureTransport: false, rechaza cualquier acceso por HTTP sin cifrar. Es una buena práctica que conviene tener en todo bucket.

El resultado, comparando el antes y el después:

Después hay que quitar la antigua política pública y comprobar que el bloqueo de acceso público (visto en 02-03) sigue activo:

El resultado esperado es 403 en el primero y 200 en el segundo. Ese par de comandos es la verificación completa de que OAC está bien montado.

Un detalle práctico: las fotos están cifradas con la clave KMS alias/mercadofresco-datos (02-03). La política de esa clave debe permitir kms:Decrypt al servicio de CloudFront; si no, todas las peticiones devolverán 403 y el mensaje no será muy claro. KMS y sus políticas de clave se estudian en 04-02.

Luis sustituye la foto del tomate por una mejor y la sube con el mismo nombre. CloudFront sigue sirviendo la antigua durante un año, porque así lo dice el TTL. Hay dos formas de resolverlo, y una es claramente mejor.

Opción A: invalidación. Se le dice a CloudFront que olvide un objeto en todas las edge locations.

Opción B: versionado del nombre. Cada versión de la foto se sube con un nombre distinto: tomate-rama-v1.jpg, tomate-rama-v2.jpg, tomate-rama-v3.jpg. El HTML apunta a la última, y como la URL es nueva, es un fallo de caché limpio. La antigua caduca sola.

La cuarta fila es la decisiva y casi nadie la ve venir: la invalidación limpia la caché de CloudFront, pero no la del navegador del cliente. Si el navegador guardó la foto con max-age=31536000, seguirá mostrando la vieja durante un año pase lo que pase. El versionado del nombre resuelve también eso, porque la URL es distinta.

Por eso MercadoFresco adopta el versionado, y las invalidaciones quedan reservadas para emergencias —una foto subida por error, un precio equivocado en el HTML cacheado.

Por defecto la distribución responde en d111111abcdef8.cloudfront.net. Para usar cdn.mercadofresco.example hacen falta dos cosas: declararlo como nombre de dominio alternativo (CNAME) y aportar un certificado TLS que lo cubra.

⚠️ La trampa clásica de CloudFront

El certificado de ACM para CloudFront debe estar SIEMPRE en la región us-east-1 (Norte de Virginia), sea cual sea la región donde vivan tus recursos.

Esto es así porque CloudFront es un servicio global y su plano de control está en us-east-1 (lo vimos al hablar de servicios globales, regionales y zonales en 01-03). Un certificado emitido en eu-west-1 es perfectamente válido para el ALB, pero CloudFront ni siquiera lo verá en la lista desplegable, y el mensaje de error no explica por qué.

Consecuencia práctica para MercadoFresco: hay que pedir dos certificados para el mismo dominio.

Ambos son gratuitos y ambos se renuevan solos. Ambos quedan en PENDING_VALIDATION hasta que se creen los registros CNAME de validación, cosa que haremos en la lección 03-05.

Además, toda distribución debería forzar HTTPS:

Una CDN sirve para más que ficheros estáticos. Pasar también el HTML y la API por CloudFront aporta cosas incluso cuando no se cachea nada:

Cuándo no compensa: si la aplicación es interna y todos los usuarios están en la misma región que el origen, CloudFront añade un salto sin ganancia. Para MercadoFresco, con clientes por toda España y planes de abrir en Portugal, compensa claramente.

El único cuidado: para el comportamiento /api/* hay que permitir todos los métodos y reenviar al origen las cabeceras que la aplicación necesita (Authorization, Host, Content-Type) mediante la política de solicitud de origen AllViewerExceptHostHeader, sin meterlas en la clave de caché.

A veces hace falta ejecutar lógica en el borde: reescribir una URL, añadir cabeceras de seguridad, redirigir por país. CloudFront ofrece dos mecanismos muy distintos.

La regla: si cabe en CloudFront Functions, va en CloudFront Functions. Es seis veces más barato, se ejecuta en más sitios y es órdenes de magnitud más rápido.

Ejemplo real de MercadoFresco: añadir cabeceras de seguridad a todas las respuestas y normalizar las URL del catálogo.

Y la reescritura de URL, en el evento de solicitud de visor:

Ese segundo ejemplo tiene efecto económico directo: es una función de cuatro líneas útiles que recupera la tasa de aciertos que las campañas de Sara estaban destruyendo sin que nadie lo supiera.

Detalle importante sobre el momento de ejecución: en viewer-request la función se ejecuta antes de consultar la caché, así que la modificación de la URI afecta a la clave de caché. Si se ejecutara en origin-request, solo se lanzaría en los fallos de caché y no cambiaría nada.

Registros estándar. CloudFront vuelca en S3 una línea por petición, con el resultado de caché incluido:

Métricas en CloudWatch (siempre en us-east-1, por ser un servicio global):

CacheHitRate es la métrica que hay que vigilar: si baja, el ahorro desaparece y el origen se carga. Las causas más frecuentes de una tasa baja son las que ya hemos visto: demasiados elementos en la clave de caché, TTL demasiado corto o Cache-Control mal puesto en el origen.

Los paneles y las alarmas sobre estas métricas se construyen en la lección 05-01.

Las clases de precio limitan desde qué edge locations se sirve, a cambio de un precio menor:

Los clientes de MercadoFresco están en España y, próximamente, en Portugal: ambos en Europa. Con PriceClass_100 se paga menos y la experiencia de los clientes reales es idéntica. Quien esté fuera seguirá siendo atendido, solo que desde una edge más lejana.

Datos de partida del catálogo de MercadoFresco:

• 40 GB de fotos y miniaturas en S3.
• 1.200.000 visualizaciones de foto al mes.
• Peso medio por foto servida: 250 KB → 300 GB de transferencia mensual.

Situación actual, sirviendo directamente desde S3:

Y ahí está el 97 % de 02-03: 27,00 ÷ 28,40 = 95 %, que con el tráfico de los meses de campaña supera el 97 %.

Con CloudFront delante, suponiendo un 90 % de aciertos de caché:

Ahorro: 27,43 USD al mes, un 96,6 %. Y además las fotos se sirven en unos 25 ms en vez de 350 ms.

La capa gratuita permanente de CloudFront (1 TB de salida y 10 millones de peticiones al mes, sin caducidad, no confundir con la capa gratuita de 12 meses de 01-01) es lo que hace que el resultado sea tan rotundo. Conviene ver también qué pasa cuando MercadoFresco crezca diez veces:

El ahorro porcentual baja al crecer, porque la capa gratuita deja de ser significativa, pero el ahorro absoluto sube. Y a esa cifra hay que sumarle lo que se deja de pagar en LCU del ALB por el tráfico que ya no lo atraviesa, más la conversión que se gana por servir cinco veces más rápido.

La configuración de una distribución es un JSON largo. Lo escribimos en un fichero:

Los identificadores largos son políticas gestionadas por AWS, iguales en todas las cuentas: 658327ea-... es CachingOptimized, 4135ea2d-... es CachingDisabled y b689b0a8-... es la política de solicitud de origen AllViewer.

Nota sobre el perfil: CloudFront es global, así que sus comandos no llevan --region; la CLI usa us-east-1 internamente.

Invalidación y seguimiento:

⚠️ Coste y limpieza

CloudFront no cobra por tener una distribución: solo por transferencia y peticiones, y las primeras 1 TB y 10 M al mes son gratuitas de forma permanente. Es, con diferencia, el servicio más barato de este módulo, y una distribución de prácticas con tráfico de laboratorio cuesta cero.

Lo único que puede sorprender son las invalidaciones: 1.000 rutas gratis al mes y 0,005 USD por ruta después. Invalidar /* cuenta como una sola ruta, así que ni eso es caro; lo malo es invalidar 5.000 ficheros uno a uno en cada despliegue.

Para borrarla hay que desactivarla primero y esperar a que se despliegue el cambio:

ETAG=$(aws cloudfront get-distribution-config --profile mercadofresco-dev \\
  --id "$DIST_ID" --query 'ETag' --output text)
# Editar el JSON poniendo "Enabled": false y volver a aplicarlo
aws cloudfront update-distribution --profile mercadofresco-dev --id "$DIST_ID" \\
  --distribution-config file://distribucion-desactivada.json --if-match "$ETAG"
aws cloudfront wait distribution-deployed --profile mercadofresco-dev --id "$DIST_ID"
aws cloudfront delete-distribution --profile mercadofresco-dev --id "$DIST_ID" --if-match "$ETAG_NUEVO"

Y si borras la distribución, acuérdate de restaurar el acceso al bucket, o las fotos dejarán de servirse por completo.

Una mención final: delante de CloudFront se pueden colocar AWS Shield, que protege frente a ataques de denegación de servicio (lección 04-04), y AWS WAF, que filtra peticiones maliciosas por reglas y por tasa (lección 04-05). Ambos se aplican en el borde, antes de que el tráfico llegue a la VPC, y ese es precisamente el motivo por el que conviene que todo el tráfico de MercadoFresco, estático y dinámico, pase por CloudFront.

Meter demasiado en la clave de caché. Es el error caro. User-Agent o todas las cookies hunden la tasa de aciertos a casi cero y pagas una CDN que no cachea. Si el origen necesita un dato pero el contenido no cambia con él, va en la política de solicitud de origen, no en la de caché.

Pedir el certificado de CloudFront en eu-west-1. Debe estar en us-east-1. Ni siquiera aparecerá en la lista y perderás media hora buscando el motivo.

Invalidar en cada despliegue en vez de versionar los nombres. Es más lento, cuesta dinero, no limpia la caché de los navegadores y no permite volver atrás. Versiona el nombre del fichero.

Olvidar AWS:SourceArn en la política del OAC. Sin esa condición, cualquier distribución de CloudFront del mundo puede leer tu bucket. Es un fallo de seguridad real y silencioso.

Cachear /api/*. Servir a un cliente la respuesta cacheada del pedido de otro es una fuga de datos. Usa CachingDisabled y permite todos los métodos HTTP.

Poner TTL largos sin Cache-Control en el origen. El TTL de CloudFront no llega al navegador. Si quieres que el cliente también cachee, la cabecera tiene que estar en el objeto de S3.

No revisar CacheHitRate. Una distribución con un 20 % de aciertos está mal configurada y nadie se entera hasta que llega la factura. Míralo cada semana.

Dejar los parámetros de campaña en la clave de caché. Cada utm_source distinto crea una entrada nueva del mismo HTML. Límpialos con una CloudFront Function en viewer-request.

Usar Lambda@Edge para algo que resuelve una CloudFront Function. Seis veces más caro, menos puntos de ejecución y mucha más latencia, para nada.

Consejo de oro: después de cada cambio de configuración, comprueba la cabecera X-Cache con curl -I dos veces seguidas. La primera debe decir Miss; la segunda, Hit. Si la segunda sigue diciendo Miss, hay algo en la clave de caché que no debería estar.

MercadoFresco añade tres tipos de contenido nuevos: /static/* (CSS y JavaScript con nombre versionado), /pedidos/* (páginas HTML personalizadas por usuario autenticado) y /buscar (búsqueda con parámetro q, cuyos resultados son iguales para todos los usuarios). Diseña el comportamiento de caché de cada uno: patrón, origen, métodos, política de caché, TTL y justificación.

MercadoFresco lleva un mes con CloudFront y CacheHitRate está en el 12 %. La factura de S3 no ha bajado. Enumera al menos cinco causas posibles, el comando o la comprobación que confirma cada una, y la corrección.

Sara quiere saber a partir de qué volumen de tráfico CloudFront deja de salir «gratis» y cuánto se ahorraría si MercadoFresco abriera en Portugal y Francia y el tráfico se duplicara. Calcula el coste mensual de servir 2 TB con 4 millones de peticiones, con y sin CloudFront, y explica qué cambia cuando se supera la capa gratuita.

Solución 1

El caso más instructivo es /buscar: es contenido dinámico que se puede cachear porque no depende del usuario. La distinción correcta no es «estático frente a dinámico», sino «igual para todos frente a personalizado». Una búsqueda popular servida desde caché ahorra una consulta a RDS por cada acierto, lo cual descarga la base de datos además de la red.

Precedencia: /static/*, /pedidos/* y /buscar antes que el comportamiento por defecto *. El orden entre ellos es indiferente porque los patrones no se solapan.

Solución 2

Causa 1: elementos innecesarios en la clave de caché. La más probable con diferencia.

Buscar HeaderBehavior: whitelist con cabeceras muy variables, CookieBehavior: all o QueryStringBehavior: all. Corrección: pasar todo lo que el origen necesite pero que no cambie el contenido a la política de solicitud de origen.

Causa 2: parámetros de campaña. Sara ha lanzado una campaña y cada correo lleva un utm_content distinto. Se ve en los registros de acceso, con miles de URL casi idénticas. Corrección: la CloudFront Function de limpieza de parámetros.

Causa 3: el origen envía Cache-Control: no-cache o max-age=0.

Si no aparece Cache-Control, el objeto se subió sin la cabecera. Corrección: volver a subir con --cache-control, o aws s3 cp sobre sí mismo con --metadata-directive REPLACE.

Causa 4: TTL demasiado corto. Un DefaultTTL de 60 s en las fotos hace que la caché caduque constantemente. Se ve en get-cache-policy. Corrección: 1 año para contenido versionado.

Causa 5: tráfico muy repartido geográficamente con contenido poco popular. Cada edge location tiene su propia caché; si un objeto se pide una vez al mes desde cada ciudad, siempre será un fallo. Se confirma cruzando los registros de acceso por x-edge-location. Corrección: PriceClass_100 concentra el tráfico en menos edges y mejora la tasa de aciertos además de abaratar.

Causa 6, menos evidente: el comportamiento por defecto * está capturando las fotos porque el patrón /productos/* está mal escrito (por ejemplo, productos/* sin la barra inicial). Se comprueba con X-Cache y con el x-edge-result-type de los registros.

Solución 3

Sin CloudFront, 2 TB (2.048 GB) y 4 M de peticiones desde S3:

Con CloudFront (PriceClass_100, 90 % de aciertos):

Ahorro: 98,72 USD al mes, un 53 %.

Qué cambia al superar la capa gratuita. Por debajo de 1 TB, CloudFront es esencialmente gratis y el ahorro roza el 100 %. Por encima, el ahorro pasa a depender de dos factores estructurales que se mantienen siempre:

1. La transferencia del origen a CloudFront es gratuita, así que S3 deja de facturar salida por completo, sea cual sea el volumen.
2. El precio por GB de CloudFront es menor que el de S3 (0,085 frente a 0,09 USD/GB en Europa) y además baja por tramos con el volumen: a partir de 10 TB, 50 TB y 150 TB el precio cae escalonadamente, mientras que el de S3 es prácticamente plano.

El punto de equilibrio, por tanto, no existe: CloudFront es más barato que S3 directo en cualquier volumen, y la única razón para no ponerlo sería que el contenido fuera imposible de cachear y estuviera consumido por un único cliente en la misma región. Ese no es el caso de una tienda.

MercadoFresco ha atacado el problema del coste por su raíz. Sabes qué es una CDN, cómo funcionan los tres niveles de CloudFront —edge locations, regional edge caches y origen— y qué ocurre exactamente en un acierto y en un fallo de caché, incluido el dato que lo cambia todo: la transferencia del origen a CloudFront es gratuita. Sabes leer la cabecera X-Cache para saber en qué situación estás.

Has configurado una distribución con dos orígenes —el bucket mercadofresco-catalogo-fotos y el alb-mercadofresco-tienda de la lección anterior—, conoces los grupos de origen para conmutar por error, y has repartido el tráfico en comportamientos de caché por patrón de ruta, con la regla de que gana el primero que coincide y el * va siempre el último. Sobre todo, dominas el concepto que decide si una CDN sirve para algo: la clave de caché. Sabes que cada valor distinto de cada elemento crea una entrada nueva, que meter User-Agent o todas las cookies hunde la tasa de aciertos al 5 %, y que la distinción correcta es entre la política de caché (lo que forma la clave) y la política de solicitud de origen (lo que el origen necesita recibir sin fragmentar la caché). Sabes cómo interactúan MinTTL, DefaultTTL y MaxTTL con el Cache-Control del origen, y por qué la cabecera debe ponerse en el objeto de S3.

Has cerrado el bucket con Origin Access Control, con una política que autoriza al servicio cloudfront.amazonaws.com únicamente desde la distribución concreta gracias a la condición AWS:SourceArn —sin la cual cualquier distribución del mundo podría leerlo—, y sabes que OAC sustituye al antiguo OAI. Has comprobado con dos curl que el acceso directo devuelve 403 y el de CloudFront 200. Sabes por qué el versionado de nombres de fichero es mejor que las invalidaciones: es inmediato, gratuito, reversible y limpia también la caché del navegador. Conoces la trampa del certificado en us-east-1 y sabes que hacen falta dos certificados, uno por región. Has visto cuándo compensa pasar también el contenido dinámico por CloudFront, y has distinguido CloudFront Functions de Lambda@Edge, escribiendo dos funciones reales: las cabeceras de seguridad y la limpieza de parámetros de campaña que recupera la tasa de aciertos que las campañas de Sara estaban destruyendo.

Y las cuentas: con PriceClass_100, la capa gratuita permanente de 1 TB y un 90 % de aciertos, el coste mensual del catálogo pasa de 28,40 USD a 0,97 USD, un 96,6 % menos, y las fotos se sirven en 25 ms en lugar de 350 ms. El problema del 97 % de transferencia de salida detectado en 02-03 está resuelto, y el ALB de 03-03 solo procesa ya lo que de verdad no se puede cachear.

Falta una sola cosa, y es la que hace que nada de esto sea visible para un cliente real: el dominio. Ahora mismo la tienda responde en d111111abcdef8.cloudfront.net y el balanceador en alb-mercadofresco-tienda-1234567890.eu-west-1.elb.amazonaws.com. Nadie va a teclear eso. Además, los dos certificados de ACM que has pedido siguen en PENDING_VALIDATION esperando unos registros DNS que aún no existen. En la lección 03-05, «Route 53», montaremos el DNS de MercadoFresco: validaremos los certificados, aprenderemos qué son los registros de alias y por qué son la única forma de apuntar el vértice mercadofresco.example a CloudFront, repasaremos las políticas de enrutamiento —ponderada para el canario del 10 %, geolocalización para abrir en Portugal, conmutación por error hacia una página de mantenimiento— y cerraremos el módulo con la arquitectura de red completa.