Amazon CloudFront Failover 🛟 con grupo de orígenes - Parte 1
Tags: aws, cloudfront, failover, español
Published: 2024-03-27 05:01:28

Hola todos 👋 quiero dejarles este artículo breve y práctico para que sea de guía básica si necesitas implementar una distribución de contenido usando Amazon CloudFront, pero (y he aquí la razón de este articulo) asegurando que el contenido servido sea altamente disponible. 

Empecemos definiendo algunas cosas a modo simple...

## ¿Qué es Amazon CloudFront? 🕸️

Es un servicio web que acelera la distribución de contenido web estático y dinámico, como archivos .html, .css, .js e imágenes, a los usuarios.

## ¿Cómo funciona Amazon CloudFront? ⛅

CloudFront distribuye contenido a través de una red global de centros de datos llamados ubicaciones de borde (Edge Locations). Al solicitar contenido que se está sirviendo con CloudFront, la petición del usuario es dirigido a la ubicación de borde con la latencia más baja (retardo de tiempo) para que el contenido se entregue con el mejor rendimiento posible.

Si el contenido ya se encuentra en la ubicación de borde con la latencia más baja, como un cache del contenido, CloudFront lo entregará de inmediato.

Si el contenido no se encuentra en esta ubicación de borde, ya sea porque el cache venció o fue invalidado, CloudFront lo recupera desde un origen definido, como un bucket S3 o una instancia EC2 que sirve de servidor web.

Hasta aquí parece que se entiende como funciona (a quince mil pies de altura como diría un amigo).

Este comportamiento se vería algo como esto:

![Funcionamiento básico de la red global de distribución cloudfront](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/y7kkfdfm4cfxdvt4v96i.png)

## ¿Cómo implementar Amazon CloudFront Failover? ⚒️

Ahora, ¿qué pasaría si el origen del contenido sufre una falla? Ya sea que un archivo no se encuentra en el bucket, resultando en un 404. O que la aplicación en sí misma retorne un error 500. O simplemente porque el contenido ha o fue actualizado con otras versiones de archivos, ejemplo un despliegue de una nueva versión del software. Pudiese ser muchas razones. Lo cierto es que AWS siempre nos insta a diseñar soluciones pensando que cualquier cosa (o todo) puede fallar. Incluso una región de AWS puede quedar inaccesible (y ha sucedido ya).

Lo que nos puede salvar temporalmente es que una de las características del servicio de CloudFront es que mantiene en caché una versión del contenido en la ubicación de borde sin tener que ir al origen a buscar los archivos.

Pero una vez ese caché venza o se invalide, CloudFront va al origen a buscar el contenido nuevo para servirlo al usuario final.

Lo que haremos es hacer uso de varios orígenes de contenido. En este caso vamos a tener dos buckets de Amazon S3. Importante, que estén ubicados en dos regiones distintas. De esta manera garantizamos la alta disponibilidad y reducimos riesgos.

Este comportamiento de recuperación de desastres (Disaster Recovery) se vería algo como esto:

![Funcionamiento con failover de la red global de distribución cloudfront con un grupo de origenes](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/x1buhfgqm5y56bw3bnkt.png)

La lógica aquí sería, 

1. El usuario accede a una URL (puede ser una personalizada en Route53 o la que proporciona CloudFront para la distribución)
2. Suponiendo que es la primera vez que se accede (no hay caché en la ubicación de borde de menos latencia), entonces CloudFront evalúa el path de la URL y determina el comportamiento (Behaiviour) para saber donde buscar el contenido.
3. Mediante la configuración que hemos hecho, CloudFront ve que debe buscarlo en un grupo de orígenes y entonces lo busca en el origen primario. En el caso de la ilustración, es el bucket S3 primario en la región 1.

Aquí quiero hacer una anotación relevante. El tener dos orígenes no significa que hará un "balanceo" entre los buckets. Siempre se servirá el contenido del origen primario que configuramos.

En caso que el origen primario no esté disponible, por algún evento, un error en la aplicación (esto también lo configuramos si se recibe un código HTTP 5XX ó 4XX), entonces CloudFront buscará el contenido en el origen secundario, en este caso el bucket S3 secundario en la región 2.

## Próximos pasos 👣

La idea es poder entonces llevar esta solución a la consola de AWS:

- [Amazon CloudFront Failover 🛟 con grupo de orígenes - Parte 1](https://dev.to/rodossaenz/aws-cloudfront-con-grupos-de-orignes-como-failover-37ba): éste artículo

- [Amazon CloudFront Failover 🛟 con grupo de orígenes - Parte 2](https://dev.to/rodossaenz/amazon-cloudfront-failover-con-grupo-de-origenes-parte-2-2apc): creación en la consola de AWS

- Amazon CloudFront Failover 🛟 con grupo de orígenes - Parte 3: automatización usando CloudFormation

## Algunas referencias 🔗

[Amazon CloudFront](https://aws.amazon.com/es/cloudfront/)

[Amazon CloudFront announces support for origin failover](https://aws.amazon.com/es/about-aws/whats-new/2018/11/amazon-cloudfront-announces-support-for-origin-failover/)

[High Availability Origin Failover](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/high_availability_origin_failover.html)

[Disaster Recovery Resiliency](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/disaster-recovery-resiliency.html)

----

_Gracias por leer, nos vemos en la nube . . ._