DEV Community: Rodolfo Sáenz

Amazon CloudFront Failover 🛟 con grupo de orígenes - Parte 2

Rodolfo Sáenz — Tue, 16 Apr 2024 04:39:27 +0000

Hola todos 👋, continuando con el artículo Amazon CloudFront Failover 🛟 con grupo de orígenes - Parte 1 donde mostraba una breve y práctica solución de implementar un failover en una distribución de contenido usando Amazon CloudFront, aquí veremos como configurarla en la consola de AWS. Vamos a ello..

Buckets en Amazon S3

Creamos los orígenes. En este caso son buckets de S3. Al crearlos nos aseguramos que estén en regiones distintas. En la imagen vemos que creo uno en US East (N. Virginia) us-east-1. Así mismo crearé otro en US West (N. California) us-west-1

Mantendremos las configuraciones por default al crearlos. Entre ellas están:

Object Ownership: Bucket owner enforced
Block Public Access settings for this bucket: Block all public access
Bucket Versioning: Disabled
Default encryption: Server-side encryption with Amazon S3 managed keys (SSE-S3)
Object Lock: Dissbled

Estas opciones te pueden salir así en inglés o español, depende de la configuración de tu cuenta de AWS o del navegador que estés usando.

Más adelante añadiremos algunas políticas para que solo sea accedido desde Cloudfront, pero más adelante, calma.

De esta manera ya tenemos nuestros dos bucket. Vayamos al siguiente paso.

Contenido en buckets

Para que vayamos preparados y listos a configurar nuestra distribución de CloudFront, nuestros buckets deben tener algún contenido no?

Lo que he hecho es crear dos archivos HTML sencillos que muestren un texto en grande diciendo en qué región están.

Los he nombrado index.html y los he subido a cada bucket.

Listo nuestro contenido. Nota, he subido un html sencillo, pero esto bien puede ser una aplicación completa en angular, react, vue, un pack de imágenes, videos o lo que fuese.

Origin Access Control

Antes de crear la distribución pasemos por el departamento de seguridad. Origin Access Control (OAC, control de acceso de origen) es una característica de Amazon CloudFront que ayuda a los clientes a proteger fácilmente sus orígenes de S3, ya que solo permite que las distribuciones de CloudFront designadas tengan acceso a sus buckets de S3. Y es lo que vamos hacer.

Estando en la página del servicio de CloudFront, vamos al menú izquierdo y buscamos Security - Origin access. Creamos uno nuevo

Y así hemos creado nuestro OAC. Recordemos que utilizaremos esto como nuestra forma de autenticación que usará CloudFront para poder acceder al contenido del bucket (bucket no es público, así que nadie puede acceder)

Distribución CloudFront

Ahora sí, a crear nuestra red de distribución de contenido.

En Origin domain nos aparece los buckets que tenemos disponibles. Seleccionamos el que creamos al inicio, el de origen 1. El Origin path lo dejo vacío, con tal que cuando accedamos a la ruta / (slash) sea este origen quien responda. Y en Name, dejo lo que me sugiere AWS.

Luego seleccionamos el origin access que creamos

Aquí nos advierte que luego de crear la distribución hay una política de acceso que debemos configurar en los buckets de S3. Le dejamos todas las opciones por default y damos a crear a la distribución.

Tenemos un mensaje en verde que dice que se ha creado la distribución. Y un mensaje en amarillo indicándonos que copiemos la política y la pongamos en los buckets (aunque debería configurarla el mismo si ya sabe la política y el bucket, pero bueno). Vamos a ello.

Política de acceso al bucket

Vamos a ir a cada uno de los buckets, al tab de permisos y editamos la política. Añadimos lo que copiamos al crear la distribución

Notemos que el Resource dice "Resource": "arn:aws:s3:::cloudfront-origen-1/*" ya que es del origen 1. Pero al colocarlo en el bucket del origen 2, hay que cambiarlo con el nombre del bucket. En mi caso sería "Resource": "arn:aws:s3:::cloudfront-origen-2/*".

1ra prueba - un sólo origen

Luego de haber configurado la política en el bucket, hagamos una prueba accediendo a la URL que nos ha proporcionado la distribución

Nota: si obtienes un no querido AccessDenied, verifica que en la distribución esté configurado el Default root object con index.html (me pasó y pasé mucho tiempo buscando esta respuesta). También puedes fijarte que el OAC firme todas las peticiones. Mira también que las políticas en S3 estén bien escritas.

Grupo de orígenes

Luego de haber probado que nuestra distribución funciona, usando el contenido de nuestro origen 1, un bucket en N. Virginia, ahora agreguemos nuestro segundo origen, un bucket en N. California

Elegimos el segundo bucket que creamos y también usamos el OAC creado. Ya no tenemos que hacer el paso de añadirle la política al bucket, ya lo hicimos en pasos anteriores. Le damos a crear el origen.

Procedemos a crear un grupo de orígenes

En el listado nos mostrará los dos orígenes que ya tenemos. Seleccionamos el origen 1 primero (porque éste será el primario, el predeterminado) y le damos a añadir. Luego añadimos el origen 2, para que sea el secundario.

De esta manera ahora vemos que a lado de los orígenes hay unas flechas. Con éstas podemos cambiar quién será el primario y quién será el secundario, a demanda, a nuestro criterio.

Le damos un nombre al grupo y seleccionamos todos los códigos HTTP que deseamos que cuando se detecte, haga el failover. Le damos crear.

Hasta aquí solo hemos creado el grupo y añadido ambos orígenes a él. Ahora necesitamos que cuando se acceda al URL, la petición vaya al grupo y no al origen 1. Vamos a ello.

Vamos al tab Behaviour y damos a editar a Default(*), el único path pattern que tenemos configurado.

Nos muestra los orígenes individuales y el nuevo grupo. Elegimos el grupo y guardamos.

2da prueba - con grupo de orígenes

Accedemos otra vez al URL.

Vemos que nos sigue mostrando el origen 1. Por detrás ahora está usando el grupo de orígenes y como el origen 1 es el primario éste es el que muestra.

Simulemos ahora un error. Renombremos el index.html del bucket origen 1 a index-failover.html.

3ra prueba - Failover por error

En vista que hemos renombrado el archivo/objeto, el origen va a responder con un error 404 que significa Not Found, no encuentra el index.html, así que debería ir al origen 2 como contingencia. Probemos el URL a ver que pasa.

¿Qué pasó? Es lo que esperábamos ¿verdad?. Ahora estamos viendo el contenido del index.html del origen 2 que es un bucket en la región de N. California. ¿Cool ah?

Renombremos otra vez el objeto en el origen 1 a su original. Y probemos nuevamente el URL.

Volvimos a tener el contenido del origen 1 en línea.

4ta prueba - Failover a demanda

Ahora si queremos podemos poner el origen 2 como primario usando las flechitas que habiamos visto. Hagamos eso, subamos el orden para que origen 2 quede arriba, convirtiéndolo en primario.

Salvemos y probemos.

Tal cual como lo queremos. Y si hacemos el mismo ejercicio de renombrar el index.html del origen 2, entonces se mostrará el contenido del index.html de origen 1.

Limitantes

Por ahora CloudFront solo permite tener en un grupo dos orígenes.
Si mantienes activo el caché y falla un origen quizá no te des cuenta hasta que el caché se invalide. Tal vez no sea una limitación pero es bueno tenerlo en cuenta.

Conclusiones

No solo se puede usar con bucket de S3, también con otros servicios como funciones Lambda e incluso con servicios de streaming. Aumentas la disponibilidad del contenido, de sitios web, videos, y mucho más.

Próximos pasos 👣

LLevemos esto un poco más allá con infraestructura como código en la parte 3:

Amazon CloudFront Failover 🛟 con grupo de orígenes - Parte 1: solución conceptual
Amazon CloudFront Failover 🛟 con grupo de orígenes - Parte 2: creación en la consola de AWS [este artículo]
Amazon CloudFront Failover 🛟 con grupo de orígenes - Parte 3: automatización usando CloudFormation

Algunas referencias 🔗

Amazon CloudFront lanza el control de acceso de origen (OAC)

Restricting access to an Amazon Simple Storage Service origin

Optimizing high availability with CloudFront origin failover

Amazon CloudFront Failover 🛟 con grupo de orígenes - Parte 1

Rodolfo Sáenz — Wed, 27 Mar 2024 05:01:28 +0000

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:

¿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:

La lógica aquí sería,

El usuario accede a una URL (puede ser una personalizada en Route53 o la que proporciona CloudFront para la distribución)
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.
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: éste artículo
Amazon CloudFront Failover 🛟 con grupo de orígenes - Parte 2: 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

Amazon CloudFront announces support for origin failover

High Availability Origin Failover

Disaster Recovery Resiliency

Gracias por leer, nos vemos en la nube . . .