Guía Completa de Amazon CloudFront: Una Guía Práctica de “Optimización del Front-End” con Comparación Práctica frente a Cloud CDN (GCP) y Azure Front Door

Introducción (Puntos clave)

• Este artículo es una guía extensa que pone en primer plano el servicio CDN de AWS “Amazon CloudFront” y lo compara con Cloud CDN de GCP y Azure Front Door, organizando de forma sistemática problemas reales como estrategias de caché, seguridad, costes, logging e integración con otros servicios.
• Amazon CloudFront almacena contenido en caché en ubicaciones de borde de todo el mundo y es un servicio CDN que entrega contenido estático y dinámico, vídeo y APIs con baja latencia.
• Cloud CDN de GCP se apoya en la red global de borde de Google e integra de forma estrecha con HTTP(S) Load Balancing, mientras que Azure Front Door se sitúa como una “plataforma de front-end” que unifica CDN + balanceo de carga global + WAF/protección DDoS.
• Lo que realmente importa en operaciones reales puede resumirse en estos cinco puntos:
  1. Qué usarás como origen (origin) (S3 / ALB / externo)
  2. Qué usarás como claves de caché (ruta, query, cabeceras, cookies)
  3. Reglas de TTL e invalidación
  4. Fronteras de seguridad como WAF, autenticación, URLs/cookies firmadas
  5. Cómo controlar el coste (ratio de aciertos de caché, logs, transferencia de datos)
• El público objetivo incluye desarrolladores web/móvil, ingenieros front-end/back-end, SREs/ingenieros de infraestructura, ingenieros de operación de vídeo/juegos, personal de seguridad/gobernanza y tech leads de startups.
  • En resumen, debería resultar relevante para cualquier equipo que entregue algo por Internet: sitios estáticos, APIs, imágenes/vídeo, distribución de descargas, etc.
• Al final, el objetivo es que adquieras una “mentalidad de diseño de front-end” centrada en CloudFront que puedas adaptar fácilmente también a Cloud CDN y Front Door.

1. ¿Qué es Amazon CloudFront? El papel de una CDN y el posicionamiento en las tres nubes

Amazon CloudFront es una red de distribución de contenido (CDN) que cachea contenido en ubicaciones de borde distribuidas globalmente y lo entrega desde el borde más cercano al usuario.
No solo maneja HTML/CSS/JS/imágenes estáticos, sino también páginas dinámicas, APIs, streaming de vídeo y descargas de archivos.

La idea central detrás de las CDNs es sencilla:

• “El rendimiento lento tiene que ver con la distancia y la congestión.”
• “Entonces coloquemos copias cerca de los usuarios y enroutemos el tráfico por caminos más rápidos.”

CloudFront construye estos “caminos más rápidos” mediante una combinación de edge locations, regional edge caches y la red troncal de AWS.

De forma simplificada, así posicionan sus servicios los tres grandes proveedores:

• CloudFront (AWS):
  • Además de las funciones básicas de CDN, Lambda@Edge / CloudFront Functions proporcionan “cómputo en el borde”, y la integración con AWS WAF / AWS Shield / ACM / S3 / ALB es extremadamente potente.
• Cloud CDN (GCP):
  • Una CDN estrechamente integrada con HTTP(S) Load Balancing. Está diseñada para aprovechar al máximo la red global de borde de Google, IPs anycast y QUIC/HTTP/2.
• Azure Front Door:
  • Posicionado como un servicio de “front door” que consolida CDN + balanceo de carga global + WAF + protección DDoS + rule engine. Se integra de forma natural con Azure Firewall y Private Link, y encaja bien en redes empresariales.

Todos comparten el mismo objetivo: servir contenido desde el borde, reducir la carga en el origen y mejorar la experiencia de usuario.

2. Casos de uso representativos y puntos de diseño

CloudFront tiene varios “patrones estándar” según el caso de uso, así que conviene empezar por entenderlos.

2.1 Sitios web y SPA

• Origen:
  • S3 (para sitios estáticos) o ALB / EC2 / ECS / EKS, etc.
• Puntos clave:
  • Un patrón clásico es TTL corto para HTML + cache busting, y TTL largo para assets (CSS/JS/imágenes) con hash en el nombre de archivo.
  • CloudFront Functions o Lambda@Edge facilitan implementar en el borde cabeceras de seguridad, redirecciones, A/B testing y autenticación sencilla.

2.2 APIs y contenido dinámico

• Origen:
  • API Gateway / ALB / Lambda URL / ECS / EKS, etc.
• Puntos clave:
  • En muchos casos se usa no-store (sin caché), pero un “micro-caching” con TTL cortos en las respuestas puede reducir tanto la latencia como la carga en el origen.
  • Diseña cuidadosamente qué partes de la petición incluir en la clave de caché (método HTTP, cabeceras, parámetros de query, etc.).

2.3 Imágenes, vídeo y archivos grandes

• Origen:
  • S3 / MediaStore / orígenes externos (on-prem, etc.)
• Puntos clave:
  • Normalmente se usan TTLs largos + URLs versionadas.
  • Presta atención a peticiones de rango, HTTP/2, compresión y tamaño de objetos para optimizar eficiencia de ancho de banda y coste.

2.4 Distribución de descargas (juegos, software, parches)

• Características: El tráfico suele ser de picos intensos, con ancho de banda máximo muy alto.
• Puntos clave:
  • Apóyate en el autoscaling de CloudFront, y usa S3 o ALB de alto rendimiento + autoscaling como orígenes.
  • Las URLs firmadas se usan típicamente para descargas limitadas en el tiempo y/o por IP.

3. Arquitectura de CloudFront: Distributions y Behaviors

Organicemos rápidamente los componentes centrales de CloudFront.

3.1 Distributions y Origins

• Distribution:
  • Unidad de configuración en CloudFront. Gestiona ajustes como nombre de dominio (xxxxx.cloudfront.net), certificados, asociación con WAF, destino de logs y comportamiento por defecto.
• Origin:
  • El backend real del que CloudFront obtiene el contenido.
  • Ejemplos: buckets S3, ALBs, instancias EC2, API Gateway, servicios de media u otros servidores HTTP externos.

3.2 Behaviors (Cache Behaviors)

Los behaviors definen cómo se manejan las peticiones por patrón de ruta.

• Ejemplo:
  • /static/* → TTL largo, no incluir query strings en la clave de caché
  • /api/* → TTL corto o sin caché, incluir cabeceras/queries específicas en la clave
  • /media/* → permitir peticiones de rango, habilitar compresión, etc.

En una sola distribution puedes combinar múltiples orígenes + múltiples behaviors y ajustar tu estrategia de caché por ruta.

3.3 Claves de caché y políticas

CloudFront usa actualmente una combinación de “cache policies” y “origin request policies” para definir:

• Qué se incluye en las claves de caché:
  • Ruta (path)
  • Query strings (todas / lista blanca / lista negra)
  • Cabeceras
  • Cookies
• Qué se reenvía al origen

Un diseño cuidadoso aquí tiene un impacto enorme en el ratio de aciertos de caché y la predictibilidad del comportamiento.

4. Estrategia de caché: combinando TTL, versionado e invalidación

La fuente más común de incidencias operativas en CDNs es que la caché no se actualiza cuando esperas—o se actualiza cuando no quieres. Hacer bien esto desde el principio facilita mucho la vida.

4.1 Guías básicas de TTL

• HTML:
  • A menudo TTL corto (segundos o minutos) o no-cache para que el cliente siempre revalide con el origen.
• Assets versionados (CSS/JS/imágenes):
  • Incluye hashes o versiones en los nombres de archivo y usa TTLs largos (días o semanas).
  • Las actualizaciones se gestionan sencillamente cambiando las URLs, así que no tienes que preocuparte por cachés antiguas en la CDN.
• Respuestas de API:
  • Considera micro-caching (varios segundos a decenas de segundos) según la volatilidad de los datos.
  • Para datos muy dinámicos, no-store puede ser más seguro.

4.2 Versionado (nombres de archivo, rutas, queries)

Los patrones comunes incluyen:

• Incluir versiones en la ruta, como /static/v123/app.js
• Añadir versiones en la query, como app.js?v=123

Pero debes asegurarte de que esto se alinea con si las queries se incluyen o no en la clave de caché.
Establece reglas como “los assets usan rutas versionadas; las APIs usan parámetros de query para condiciones” para evitar confusión dentro del equipo.

4.3 Invalidación

• Usa invalidación cuando olvidaste versionar un asset o necesitas limpiar cachés con urgencia.
• La invalidación en CloudFront funciona por ruta (por ejemplo, /index.html o /static/*). Sin embargo, invalidaciones frecuentes y de gran escala pueden ser costosas y lentas en propagarse, así que trátalas como una vía de escape excepcional, no como mecanismo principal de actualización.

5. Seguridad: HTTPS, WAF, URLs firmadas y OAC

CloudFront también juega un papel clave como frontera de seguridad.

5.1 HTTPS, certificados y terminación TLS

• CloudFront puede gestionar HTTPS tanto del lado del cliente (cliente ⇔ CloudFront) como del origen (CloudFront ⇔ origin).
• Los certificados suelen provenir de AWS Certificate Manager (ACM) y se unen a dominios personalizados.
• Terminar TLS en el borde significa que el cifrado con el cliente lo gestiona CloudFront y los backends se acceden por canales internos seguros.

5.2 AWS WAF y Shield

• CloudFront incluye de forma predeterminada AWS Shield Standard, que ofrece protección frente a ataques DDoS de capa 3/4.
• Añadir AWS WAF permite bloquear:
  • Patrones de ataque comunes como SQL injection y XSS
  • Bots, reputación IP y ataques basados en tasa
    en el borde, antes de llegar al origen.

5.3 URLs firmadas y cookies firmadas

• Para contenido de pago o material interno:
  • Usa URLs firmadas con restricciones de tiempo e IP.
  • O distribuye cookies firmadas después del login.
• Combinando esto con CloudFront y S3 puedes construir controles de acceso simples pero efectivos sin servidores adicionales.

5.4 OAC (Origin Access Control) y OAI

• Para restringir que un origen S3 solo sea accesible a través de CloudFront, se usa:
  • Enfoque clásico: Origin Access Identity (OAI)
  • Opción recomendada actual: Origin Access Control (OAC)
• Con políticas de bucket que “permiten solo peticiones procedentes de CloudFront”, puedes evitar accesos directos y listados de bucket.

6. Optimización de rendimiento: protocolos, compresión y cómputo en el borde

6.1 HTTP/2, HTTP/3 y Keep-Alive

• CloudFront soporta HTTP/2 y HTTP/3, que aportan multiplexación y compresión de cabeceras para mejorar dramáticamente el rendimiento percibido, especialmente en redes móviles.
• Las conexiones al origen se reutilizan (Keep-Alive), reduciendo el número de handshakes TCP.

6.2 Compresión (Gzip/Brotli)

• CloudFront puede servir contenido comprimido con Gzip/Brotli a los clientes que lo soportan.
• Para contenido basado en texto como HTML/CSS/JS/JSON, la compresión es casi obligatoria, ya que mejora directamente el uso de ancho de banda y los tiempos de respuesta.

6.3 Cómputo en el borde (Lambda@Edge, CloudFront Functions)

• Lambda@Edge:
  • Ejecuta código Node.js/Python en varios puntos del ciclo de petición/respuesta (viewer/origin, request/response).
  • Casos de uso: A/B testing, redirecciones por país/idioma, autenticación personalizada, reescritura de respuestas, etc.
• CloudFront Functions:
  • Runtime JavaScript ultraligero y ultrarrápido. Perfecto para manipulación sencilla de cabeceras, redirecciones y prechecks de autenticación.

7. Logging y observabilidad: una CDN sin visibilidad da miedo

La resolución de problemas en CloudFront depende enormemente de lo bien configurados que estén logs y métricas.

7.1 Logs estándar y logs en tiempo real

• Access logs estándar:
  • Entregados a S3.
  • Capturan IP del cliente, ruta, código de estado, aciertos/fallos de caché, etc.
• Logs en tiempo real:
  • Se emiten a Kinesis Data Streams o Firehose.
  • Útiles cuando necesitas visibilidad y detección casi en tiempo real.

7.2 Métricas (CloudWatch)

Las métricas típicas incluyen:

• Número de peticiones
• 4xxErrorRate / 5xxErrorRate
• BytesDownloaded / BytesUploaded
• CacheHitRate

SLOs sugeridos:

• Ratio de aciertos de caché ≥ 80%
• Tasa de errores 5xx < 0,1%

Configura alertas cuando se superen los umbrales.

7.3 Patrones de análisis de logs

• Consulta logs en S3 mediante Athena u OpenSearch para visualizar:
  • Qué rutas golpean demasiado al origen
  • Patrones de error por país o ISP
• Estos insights alimentan mejoras en estrategia de caché y reglas de WAF.

8. Modelo de precios y optimización de costes

El pricing de CloudFront se basa de forma aproximada en:

1. Transferencia de datos (borde → cliente)
2. Número de peticiones
3. Funciones específicas como logs en tiempo real y ejecuciones de Functions/Lambda@Edge

Consulta siempre la página oficial de precios de AWS para la información más reciente.

8.1 Enfoques para optimizar costes

• Mejora del ratio de aciertos de caché:
  • Ratios bajos implican que pagas transferencia desde el origen + peticiones de CloudFront + transferencia de CloudFront.
  • Usa versionado y TTLs adecuados para evitar fallos de caché no intencionados en cada petición.
• Ubicación del origen:
  • La transferencia desde orígenes en AWS (S3/ALB, etc.) hacia CloudFront se beneficia de precios preferenciales.
• Granularidad y retención de logs:
  • No envíes todo a logs en tiempo real. Usa una mezcla como logs estándar + logs en tiempo real solo para rutas/distributions críticas.
• Manejo de objetos muy pequeños:
  • Servir cantidades enormes de archivos diminutos puede hacer que los cargos por petición dominen sobre la transferencia de datos. Considera agrupar assets pequeños cuando tenga sentido.

9. CloudFront vs Cloud CDN vs Azure Front Door

Comparemos a alto nivel estos tres servicios.

9.1 Diferencias de arquitectura e integración

• CloudFront (AWS)
  • Enfocado en CDN pero muy integrado con ALB, S3, API Gateway, servicios de media, WAF y Shield.
  • Fuerte soporte de cómputo en el borde (Lambda@Edge, CloudFront Functions).
• Cloud CDN (GCP)
  • Funciona estrechamente acoplado con HTTP(S) Load Balancing.
  • Diseñado para sacar el máximo partido a IPs anycast globales, QUIC/HTTP/2 y la red troncal de Google.
• Azure Front Door
  • Un global load balancer + CDN + WAF + DDoS protection + rule engine unificado.
  • Fuerte integración con Azure DNS, Private Link, Azure Firewall, etc.

9.2 Seguridad, WAF y DDoS

Los tres ofrecen:

• Protección DDoS L3/L4, integración con WAF, mitigación de bots y terminación TLS.

Azure Front Door se inclina más hacia ser una “solución perimetral integral” con WAF, bot management y protección DDoS integrados.

9.3 ¿Cuál deberías elegir?

• Principalmente en AWS, usando S3/ALB/Media, queriendo Lambda@Edge y control fino de caché
  → CloudFront es la elección natural.
• Principalmente en GCP, centrado en Cloud Load Balancer, con integración a BigQuery/Logging
  → Cloud CDN encaja mejor.
• Principalmente en Azure, necesitando balanceo global + WAF + Private Link + integración con red corporativa
  → Azure Front Door.

En setups multi-cloud, un patrón habitual es usar el servicio “front” de cada nube delante de cargas alojadas en esa nube y diseñar un punto de entrada global a través de DNS y routing.

10. Ejemplos de configuración (centrados en CloudFront, a alto nivel)

Nota: Son ejemplos simplificados para transmitir la idea general.

10.1 Creación de una Distribution vía AWS CLI (imagen conceptual)

aws cloudfront create-distribution \
  --distribution-config file://dist-config.json

{
  "CallerReference": "2025-11-13-001",
  "Comment": "example static site",
  "Enabled": true,
  "Origins": {
    "Quantity": 1,
    "Items": [
      {
        "Id": "s3-origin",
        "DomainName": "my-bucket.s3.ap-northeast-1.amazonaws.com",
        "S3OriginConfig": { "OriginAccessIdentity": "" }
      }
    ]
  },
  "DefaultCacheBehavior": {
    "TargetOriginId": "s3-origin",
    "ViewerProtocolPolicy": "redirect-to-https",
    "AllowedMethods": { "Quantity": 2, "Items": ["GET","HEAD"] },
    "CachePolicyId": "658327ea-f89d-4fab-a63d-7e88639e58f6"  // Example: CachingOptimized
  },
  "PriceClass": "PriceClass_200"
}

10.2 Estrategia de Cache Policy de ejemplo

• Cache policy para /static/*:
  • TTL: por defecto 1 día, máximo 7 días
  • Clave de caché: ruta + parámetros de query seleccionados (solo v)
  • Cabeceras y cookies: no incluidas
• Cache policy para /api/*:
  • TTL: varios segundos a decenas de segundos (o 0)
  • Clave de caché: ruta + query + cabeceras clave (por ejemplo, idioma)
  • Cookies: cookies de sesión fuera de la clave (se gestionan en el origen)

10.3 Ejemplo simplificado en Terraform (conceptual)

resource "aws_cloudfront_distribution" "static" {
  enabled             = true
  default_root_object = "index.html"

  origins {
    domain_name = aws_s3_bucket.site.bucket_regional_domain_name
    origin_id   = "s3-origin"
  }

  default_cache_behavior {
    target_origin_id       = "s3-origin"
    viewer_protocol_policy = "redirect-to-https"
    cache_policy_id        = data.aws_cloudfront_cache_policy.caching_optimized.id
  }

  price_class = "PriceClass_200"
}

11. Checklist de diseño (decisiones para la primera semana)

1. Tipo y ubicación de los orígenes
   • ¿S3 o ALB? ¿En qué región? ¿Usarás on-prem u otra nube como origen?
2. División de rutas y behaviors
   • Decide segmentos como /static/, /api/, /media/, /admin/ y cómo segmentar behaviors.
3. Claves de caché y TTLs
   • Qué incluir (query, cabeceras, cookies) y las estrategias de TTL.
4. Reglas de versionado
   • Dónde representar versiones: nombre de archivo, ruta o parámetros de query.
5. HTTPS y certificados
   • Certificados ACM, dominios personalizados, políticas TLS.
6. WAF, DDoS y autenticación
   • Reglas de WAF, URLs/cookies firmadas, restricciones por IP, defensas frente a bots.
7. OAC/OAI y políticas de bucket
   • Asegurar que S3 no esté expuesto directamente.
8. Logs y dashboards
   • Alcance de logs estándar vs en tiempo real, analítica (Athena, paneles, etc.).
9. Definición de SLO/SLI
   • Ratio de aciertos de caché, tasas de error, latencia p95 y alertas asociadas.
10. Monitorización de costes
    • Revisar regularmente costes de transferencia, recuento de peticiones y almacenamiento de logs.

12. Errores frecuentes y cómo evitarlos

• Cachés que no se actualizan—o que se actualizan demasiado
  • Causa: reglas de TTL y versionado poco claras, comportamiento mezclado de Cache-Control/ETag.
  • Solución: Define y documenta políticas de TTL claras, y versiona siempre los assets estáticos.
• Partes de S3 siguen siendo accesibles por enlaces directos
  • Causa: políticas de bucket en public-read.
  • Solución: Usa OAC/OAI + políticas de bucket para permitir solo CloudFront.
• Reglas WAF bloquean tráfico válido
  • Causa: falta de pruebas antes de activar el modo block.
  • Solución: Usa modo Count → observa → cambia a Block por fases.
• Cantidad abrumadora de logs y costes altos de almacenamiento/análisis
  • Causa: logging de todo con granularidad completa y retención larga.
  • Solución: Aplica logging detallado solo a distributions/rutas críticas y resume o acorta retención para el resto.
• No está claro si los errores provienen de CloudFront o del origen
  • Solución: Construye dashboards que correlacionen errores 5xx de CloudFront con logs del origen, usando IDs de correlación cuando sea posible.

13. Casos prácticos (por escenario)

13.1 Servicio web moderno con SPA y API

• Arquitectura:
  • app.example.com → CloudFront → S3 (SPA)
  • /api/* → CloudFront → API Gateway o ALB → ECS/EKS
• Puntos clave:
  • TTL corto o no-cache para index.html de la SPA, y TTL largo + versionado para assets.
  • Para APIs, gestiona cabeceras CORS y de autenticación en el origen, y considera el micro-caching en CloudFront.

13.2 Sitio de medios centrado en imágenes/vídeo

• Arquitectura:
  • CloudFront → S3/MediaStore
• Puntos clave:
  • Separa rutas por formato/resolución (por ejemplo, /img/hd/, /img/webp/) para simplificar la estrategia de caché.
  • Descarga la transcodificación a procesos batch o servicios de media y deja que CloudFront se centre solo en la entrega.

13.3 Exposición segura de un portal interno

• Arquitectura:
  • CloudFront + WAF + URLs/cookies firmadas → S3/ALB
• Puntos clave:
  • Integra con un IdP interno (Cognito o externo) y genera cookies firmadas solo tras el login.
  • Añade controles adicionales en CloudFront basados en país, IP y User-Agent para acercarte a un perímetro de tipo zero trust.

14. ¿Quién se beneficia y cómo? (“Futuro feliz” por rol)

• Ingenieros front-end
  • Ganarán confianza al decidir TTLs y estrategias de versionado para assets, y dejarán de temer incidentes de caché en cada despliegue.
• Desarrolladores back-end/app
  • Aprenderán a diseñar qué debe ocurrir en el origen (CORS, auth, logging, diseño de API) teniendo presente CloudFront, y superarán la mentalidad de “la CDN es una caja negra”.
• SREs/ingenieros de infraestructura
  • Podrán empaquetar CloudFront + WAF + Shield + logging + SLOs como una plantilla de infraestructura de front-end estándar para la organización.
• Personal de seguridad/gobernanza
  • Diseñarán un perímetro de Internet auditable mediante S3 no público, WAF, URLs firmadas y orígenes privados.
• Tech leads de startups
  • Incluso con equipos pequeños, podrán construir un stack de front-end robusto con distribución global, protección DDoS, WAF y analítica de logs, listo para escalar y salir al mundo.

15. Tres cosas que puedes empezar hoy

1. Colocar CloudFront delante de un sitio/servicio existente
   • Comienza con un solo origen, como S3 o ALB, y pruébalo con políticas de caché estándar.
2. Crear behaviors separados para /static y /api
   • Solo con separar rutas y usar TTL largo + versionado para assets y TTL corto o no-cache para APIs tu configuración será ya mucho más robusta.
3. Construir dashboards para logs de acceso y ratios de aciertos de caché
   • Usa CloudWatch o Athena para visualizar qué rutas aciertan en caché, cuáles golpean el origen y dónde se producen errores. Detectarás enseguida oportunidades de mejora.

16. Conclusión: piensa el front-end como un conjunto de “Caché + Frontera + Observabilidad”

Mirando CloudFront en paralelo con Cloud CDN y Azure Front Door, se hace evidente que la infraestructura moderna de front-end se apoya en tres pilares: “CDN, frontera de seguridad y observabilidad.”

• Decide estrategias de caché (claves, TTL, versionado).
• Solidifica la frontera (HTTPS, WAF, URLs/OAC firmados).
• Visualiza logs y métricas (ratios de aciertos, errores, latencia).

Una vez tengas estos tres elementos, podrás reproducir tu enfoque de diseño aunque cambien la nube o las herramientas.
En el próximo artículo veremos Amazon CloudWatch como plataforma de monitorización estrechamente conectada tanto al backend como a la CDN, comparándolo con Cloud Monitoring (GCP) y Azure Monitor para explorar el diseño de monitorización, métricas y logging en un mundo multi-cloud.

Referencias

• Amazon CloudFront Developer Guide
• Amazon CloudFront Product Page
• Google Cloud CDN Overview
• What is Cloud CDN and how does it work?
• Azure Front Door Overview (Japanese / English)
• What is Azure Front Door? (Explanation article)

Consulta siempre la documentación oficial y las páginas de precios para obtener las especificaciones, límites y tarifas más recientes.