DEV Community

Cover image for Amazon CloudFront Failover 🛟 con grupo de orígenes - Parte 2
Rodolfo Sáenz
Rodolfo Sáenz

Posted on

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

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

Creación de bucket S3

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.

Dos buckets creados en distintas regiones

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.

VS Code mostrando ambos archivos index.html

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

Origen 1 con index.html

Origen 2 con index.html

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

Creación OAC

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)

OAC creado

Distribución CloudFront

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

Creación de distribución

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

Seleccionamos el OAC

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.

Distribución creada

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

S3 Bucket Policy

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

Prueba uno, origen 1 o primario

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

Creación de segundo origen

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.

Dos orígenes creados

Procedemos a crear un grupo de orígenes

Creación de 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.

Orígenes añadidos al grupo

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.

Nombre de grupo y códigos de failover

Grupo de origen creado

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.

Edición de behaviour

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

Behaviour actualizado a usar el grupo

2da prueba - con grupo de orígenes

Accedemos otra vez al URL.

Prueba con grupo

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.

Objeto renombrado

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.

Mismo url monstrando el origen 2

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

Nuevamente contenido origen 1

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.

Origen 2 como primario

Salvemos y probemos.

Origen 2 contenido primario

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:

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

Top comments (0)