Amazon CloudFront
Red de entrega de contenido que acerca tu sitio a los visitantes y le pone HTTPS.
En palabras simples
Es tener una copia de tu sitio en bodegas repartidas por todo el mundo: quien lo pide desde Cuenca lo recibe de la bodega más cercana, no del servidor original.
Cuándo aplicarlo
Cuando quieres que tu sitio o tus archivos carguen rápido desde cualquier parte, con HTTPS y sin exponer directamente el origen que los almacena.
- ▸Servir un sitio estático alojado en S3 con dominio propio y certificado TLS
- ▸Distribuir imágenes y videos pesados sin saturar el origen
- ▸Reducir el costo de transferencia de datos frente a servir todo desde S3
- ▸Proteger el origen para que nadie pueda acceder al bucket directamente
Vocabulario mínimo
- Distribución
- La configuración de CloudFront: qué origen sirve, con qué dominio y con qué reglas de caché.
- Edge location
- Cada uno de los puntos de presencia repartidos por el mundo donde se guarda la copia en caché.
- Origin Access Control (OAC)
- El mecanismo que permite que solo CloudFront lea el bucket S3, manteniéndolo privado.
- Invalidación
- La orden de borrar la caché para que los visitantes reciban la versión nueva tras un despliegue.
Costo y capa gratuita
- Cómo se cobra
- Por GB transferido hacia internet y por número de peticiones, con precios que varían según la región del visitante.
- Capa gratuita
- 1 TB de transferencia de datos y 10 millones de peticiones al mes, de forma permanente — más que suficiente para un sitio universitario.
Cuidado con los créditos
- ⚠Invalidar rutas con comodín en cada despliegue: las primeras 1.000 invalidaciones al mes son gratis, después se cobran.
- ⚠Configurar un TTL de caché muy bajo: cada visita vuelve al origen y se pierde el ahorro.
Descripción
CloudFront es la CDN de AWS: guarda copias de tu contenido en cientos de edge locations repartidas por el mundo, de modo que cada visitante lo recibe desde el punto más cercano en vez de viajar hasta la región donde vive el origen.
Además de velocidad, aporta dos cosas que un bucket S3 solo no da: HTTPS con certificado propio (vía ACM) y la posibilidad de mantener el bucket completamente privado, ya que solo CloudFront tiene permiso para leerlo.
Cómo funciona
- Creas una distribución y le indicas un origen — por ejemplo, el bucket S3 de un sitio estático.
- Configuras Origin Access Control para que el bucket solo acepte peticiones de esa distribución.
- Asocias un certificado de ACM y, si lo hay, el dominio propio vía Route 53.
- En cada despliegue, se invalida la caché para que los visitantes reciban la versión nueva.
Manos a la obra
- Crea una distribución apuntando a un bucket S3 privado con OAC.
- Abre la URL de CloudFront: el sitio carga por HTTPS.
- Intenta abrir la URL directa del objeto en S3: Access Denied.
- Sube un cambio al bucket y recarga sin invalidar: seguirás viendo la versión vieja. Invalida y recarga: ahí aparece. Ese experimento explica la caché mejor que cualquier definición.
Ejemplo visual
La flecha hacia S3 es la que menos se recorre: si la caché de borde ya tiene la página, el bucket ni se entera. Ahí está el ahorro de transferencia.
Este sitio empezó planeado así, y al final se publicó con AWS Amplify, que monta por debajo una distribución de CloudFront y la administra por su cuenta.
Cuándo NO es la mejor opción
- S3 con website hosting directo — si es una prueba interna sin dominio propio y no te importa que no tenga HTTPS ni caché global.
- AWS Amplify Hosting — si solo quieres publicar un front-end desde Git: Amplify monta y administra la distribución por ti. Es lo que usa este sitio.
Se usa junto con
Aparece en certificaciones
- AWS Certified Cloud Practitioner
- AWS Certified Solutions Architect – Associate