Rodolfo Sáenz

Posted on Apr 16, 2024

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

#aws #cloudfront #failover #español

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.