Amazon CloudFront Failover 🛟 con grupo de orígenes - Parte 2
Tags: aws, cloudfront, failover, español
Published: 2024-04-16 04:39:27

Hola todos 👋, continuando con el artículo [Amazon CloudFront Failover 🛟 con grupo de orígenes - Parte 1](https://dev.to/rodossaenz/aws-cloudfront-con-grupos-de-orignes-como-failover-37ba) 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](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/0bo0talf2ln8fyqufpny.png)

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](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/cvysqdzubs2mbwhn85am.png)

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](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ozs6yy9c26e03q5j4usp.png)

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

![Origen 1 con index.html](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/d0835i8pjvau34h22rge.png)

![Origen 2 con index.html](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/uwj7tdz1sl34jz7zmu7j.png)

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](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/2dw1mk5anf8dibqvlop3.png)

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](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/fwm2dvrel814gxgxvo16.png)

## Distribución CloudFront

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

![Creación de distribución](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/r0c86e7n9uto0lpdjlya.png)

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](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/k8x0ziczhn32ubb05qtd.png)

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](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/swg7xfx5daxotp7ilnok.png)

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](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/2turfvhdtiv3ut5bqven.png)
 
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](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/cxj2sidjhxg9rt3tnqp2.png)

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](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/8o6xxgc0ortiofin3pco.png)

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](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/7zvvjzsbj859m8wlhy45.png)

Procedemos a crear un grupo de orígenes

![Creación de grupo de orígenes](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/u9kc05xm8h78y9x90zmw.png)

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](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/z58cj1twu0z7g2lg5vnl.png)

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](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/i8x60i57oztqfd6935fz.png)

![Grupo de origen creado](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/9agmj96fhmoxjq8moz7s.png)

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](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/p5lw7brmbv6qzjnjm549.png)

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

![Behaviour actualizado a usar el grupo](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/5p8vvtqk4fqfvzxw0usy.png)

## 2da prueba - con grupo de orígenes

Accedemos otra vez al URL. 

![Prueba con grupo](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/r37ivpzj9pvovhko16io.png)

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](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/d6ohbyg1xzli127i3oej.png)

## 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](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/omf18y9j86lrf84y6l2z.png)

¿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](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/3361ajmmm2s5dh7ld39f.png)

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](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/v16mm3nget3mo11s5msi.png)

Salvemos y probemos.

![Origen 2 contenido primario](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/y296hhx799mc383aqd4h.png)

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](https://dev.to/rodossaenz/aws-cloudfront-con-grupos-de-orignes-como-failover-37ba): solución conceptual

- [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 [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)](https://aws.amazon.com/es/about-aws/whats-new/2022/08/amazon-cloudfront-origin-access-control/)

[Restricting access to an Amazon Simple Storage Service origin](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.html)

[Optimizing high availability with CloudFront origin failover](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/high_availability_origin_failover.html)