CloudFlare vs CloudFront, Route53 y AWS shield que servicio es más útil

En el último mes uno de mis clientes me pidió crear un entorno de producción optimizado para magento 2, uno de los requerimientos era que todo se creará en AWS (Amazon Web Services), por lo que configuré servicios adicionales de AWS los cuales fueron:

• Route53 como administrador de dominio (DNS).
• EC2 como servidor o VPS.
• S3 como servidor de archivos estáticos.
• CloudFront como el CDN.
• AWS Shield y WAF como protección de ataques DDoS.

El proyecto si se pudo configurar con todos los servicios de AWS, pero como no solo debía configurar el servidor, también me encargaron el diseño y la administración de este proyecto, tuve varias reuniones con mi cliente y a final acordamos  regresar a CloudFlare.

Para mi, CloudFlare es un servicio más útil que CloudFront, route53 y AWS Shield

Esta publicación es creada para explicar mis razones y quiero que sean consideradas desde el enfoque de un desarrollador web.

Las necesidades del proyecto son:

• Magento 2 para poder realizar la venta de los productos.
• Wordpress como blog de la empresa.
• El tipo de cliente que se pretende es el minorista, por lo que se pretende que el sitio web sea visitado por muchos usuarios.
• Tener un diseño dinámico o cuando menos que se esté actualizando regularmente.
• Poder crear campañas publicitarias dentro de Magento, con la posibilidad de cambiar precios, diseños, imágenes, videos, etc.

** AWS tiene una capa gratuita, la cual ofrece por un plazo de 12 meses o algunos cubren un límite mínimo y después de el usuario pagará la diferencia, esto lo indico porque en la publicación estaré mencionando que AWS cobra sus servicios, será buena idea revisar los servicios que están dentro de su capa gratuita. Bien con esto estamos listos para empezar a dar mi opinión sobre mi preferencia de CloudFlare.

Cloudflare VS Route53

El dominio puede ser comprado com cualquier distribuidor como godaddy, neubox, hostgator, etc, nuestro dominio necesita un DNS (Domain Names System), este servicio se encarga de indicarle a internet a donde dirigir la información, el caso más común es conectar nuestro contenido con nuestro dominio pero también podemos utilizar este servicio para "firmar" digitalmente un correo, AWS cuenta con Route53 es su administrador DNS, cuando empecé a crear el proyecto, di de alta el dominio en Route53 pero me topé con la sorpresa de que es un servicio de pago, revisé los precios y no me parecieron malos, mientras terminaba de configurar los demás servicios me quede el Route53, pero una vez que tuve reuniones con el cliente y decidimos cambiar a CloudFlare, dejé de utilizar Route53 ya que CloudFlare tiene el servicio de DNS de forma nativa y es gratis, aunque el precio es algo que pasa a segundo plano en este servicio.

EC2 como servidor.

El servidor es el lugar en donde se almacena y procesa la información, dependiendo de lo que se requiera podemos hablar de un Hosting, VPS, Droplet, EC2, Docker, etc. para poder distribuir la información, el servidor necesita de un punto entra o salida, este punto es la IP.

AWS cuenta con EC2 (Elastic Compute Cloud) como servidor de contenido, configuré LEMP (Linux, Nginx, Mysql y PHP), EC2 asigna una IP a cada instancia (así le llama AWS a cada Virtualización), pero cada vez que se reinicia la instancia, la IP cambia, para evitar esto, se debe tener una IP elástica, la cual es una IP que se asigna a nuestra instancia y sin importar que se reinicie, la IP no cambiará, otra cosa que se debe configurar en EC2 son los grupos de seguridad, los cuales permiten la entrada o salida de información por puertos de la instancia, esta función me encantó,

Lo que hace diferente a EC2 de cualquier otro servidor es su diseño "elástico" el cual mantiene estable el servidor, en cualquier otro servicio, cuando los recursos son consumidos, el servidor se satura y en muchos de los casos se detienen, lo que ocasiona que el sitio web deje de visualizarse, he trabajado con otros servidores y cada uno tiene su propio sistema de "amortiguación" de picos de tráfico. Para el proyecto de mi cliente fue la mejor decisión utilizar EC2 ya que su diseño elástico permite que el sistema esté estable durante la época de promociones.

S3 como servidor de archivos estáticos.

AWS S3 (Simple Storage Service), es un servicio de almacenamiento de objetos, tiene diferentes usos pero el principal es que se puede utilizar para entregar contenido estático de una forma más eficiente, es un servicio opcional pero es altamente recomendable.

Para que un sitio web funcione, cada vez que accedemos a un dominio, para visualizar el contenido es necesario que se descarguen archivos CSS, JS, HTML, IMG, estos archivos comúnmente se encuentran en el mismo servidor, al descargar los archivos que están en nuestro servidor, el tiempo de carga va aumentando, provocando que un sitio se tarde en visualizarse.

S3 tiene como objetivo reducir las peticiones a nuestro servidor, así en vez de descargar la información de nuestro servidor, descarga la información desde los servidores de AWS. el inconveniente que veo es la forma en la que nuestros archivos locales (nuestro servidor) son sincronizados con S3, para eso AWS ha desarrollado una api con la que se puede trabajar.

Regresando al proyecto, magento 2 tiene 2 carpetas que representan el 95% de las peticiones al crear un sitio web, "static" y "media"  y  wordpress tiene un carpeta llamada "wp-uploads",

S3 permite crear diferente "buckets" los cuales son tus "carpetas online" principales, asi podriamos tener varios buckets llamados: static.dominio.com, media.dominio.com y uploads.dominio.com

En otra publicación profundizaré más a fondo S3, lo que interesa en esta publicación es que se tiene una versión online exactamente igual a nuestro servidor y será AWS quien se preocupe por el consumo de lo recursos de estos "buckets" aunque nosotros al final del mes pagaremos estos consumos.

Cloudflare VS CloudFront

Hemos llegado a la parte más interesante de nuestro proyecto, una vez que nuestro sitio web ya está publicado y ya hemos logrado entregar un sitio web con el tiempo de carga lo más reducido posible, nos hemos dado cuenta que entre más lejos nos encontremos del servidor más tiempo se tardará en entregar el contenido, esto es lógico ya que le toma más tiempo a la información llegar a la computadora del usuario final, para evitar este problema se utiliza un CDN (Content Delivery Network / red de distribución de contenido), su función es tener una copia de tu archivos en varios servidores, así cuando un usuario entre a tu sitio web, el CDN se encarga de mostrar el contenido tomándolo del servidor más cerca, reduciendo el tiempo de carga.

CloudFront es el CDN que ofrece AWS, al principio configuré el proyecto con CloudFront, después lo cambié por CloudFlare y por consecuencia dejé de usar route53 y AWS Shield ya que son servicios que trae CloudFlare.

Hasta este punto todo estaba bien, toda la configuración con AWS estaba funcionando de maravilla, y llegó el momento de empezar a trabajar dentro del proyecto, como desarrollador debo crear las páginas, darle diseño al sitio, subir archivos, etc, me encontraba ya interactuando con el sitio web, aquí fue donde me dí cuenta de los problemas de CloudFront.

No tiene forma de pausar la distribución cacheada y mostrar la original.

La idea del CDN es tener lo más cerca posible una copia del archivo original para así poderlo entregar más rápido, esto está bien si el archivo original no va acambiar, pero como estoy realizando cambios constantemente, me gustaría que se mostrará el archivo original en vez del que tiene CloudFront, CloudFlare tiene un botón llamado "modo developer" el cual hace que durante un periodo de 3 horas, todas las peticiones se realicen al servidor original o puntos de acceso en caso de tener configurado "S3", la alternativa en CloudFront es cambiar el parámetro de header "cache-control" a "0"  pero uno debe entrar hasta el administrador de AWS y realizar este cambio  o a través de aws-cli, esto no tendría problema ya que puedo usar la consola sin problemas, pero cuando mi cliente quiera hacer un cambio??, otra opción serían las "invalidaciones" las cuales se ejecutan una vez y tiene como objetivo recibir una o varias rutas las cuales eliminan la versión cacheada, así cuando se realice una nueva petición, se mostrará la versión original y volverá a ser colocada en caché, este es el problema, solo sirve por vez, cada que realice un cambio debo crear una invalidación.

S3 y CloudFront no son la pareja ideal.

S3 es un "folder online" en el caso del proyecto, los 3 buckets que se crearon se hicieron públicos  y AWS proporciona un dominio por bucket y estos dominios fueron configurados para que sean administrados por CloudFront, así ya no es solo mi EC2 el que es administrado, si no también 3 buckets.

Se realizó una configuración para la sincronización de magento y wordpress con S3, hasta este punto todo bien, ya que la sincronización se realizó mediante SSH, así no fué necesario colocar algún plugin en wordpress o un módulo en magento que se encargará de esta tarea (sincronización). En wordpress si fue necesario activar un plugin para cambiar las URL de los archivos media, pero no para sincronizar, de este tema también crearé otra publicación para especificar cómo realicé la sincronización de magento y wordpress con S3.

El Problema con S3 y CloudFront es que S3 no tiene una forma sencilla de avisarle a CloudFront que ha cambiado un archivo, cuando realizo un cambio en un archivo en mi servidor, si se sincroniza con S3, pero S3 no le dice a CloudFront que ha cambiado el archivo y por tal motivo, CloudFront sigue mostrando la versión cacheada, provocando un problema en el flujo de trabajo, para solucionar este problema AWS tiene otro servicio llamado "Lambada" el cual es un especie de interceptor de eventos, al momento de cambiar algún archivo en S3, lambada intercepta el evento y le puede avisar a CloudFront que hizo un cambio y crear una "invalidación" y así al momento de entrar al sitio web se obtiene el archivo nuevo, el problema que le veo es que se debe hacer uso de otro servicio (que sirve para muchas cosas adicionales pero para este caso es un puente entre S3 Y CloudFront) y este servicio también es de pago, el código hay que crearlo y editarlo en caso de realizar cambios al DNS o  S3. En CloudFlare, al ser una capa externa, solo es cosa de dar click en el botón "modo developer" y las peticiones pasarán directo a los S3 y así de simple se obtiene la versión más actual de nuestros archivos o si se prefiere también está la opción purge la cual permite liberar todos los archivos cacheados solo una vez  o podemos realizar un purge de solo una o varias url que nosotros podemos agregar fácilmente.

Actualización: he creado un módulo para Magento 2 el cual permite crear Invalidaciones a Cloudfront de forma relativamente sencilla, en esta publicación puedes saber más.

Muy posiblemente te este preguntando, porque no dejas el dominio inicial de cada bucket de S3 y después que termines tus cambios o el desarrollo del proyecto y ya no realices tantos cambios, activas CloudFront, la respuesta es muy sencilla, porque con CloudFlare se puede dejar configurado una sola vez, cuando eres desarrollador, y en mi caso que soy freelancer, el tiempo es muy valioso, así que si ya tengo una forma de configurarlo bien a la primera, mejor hacerlo así y no realizar cambios adicionales que me consumen tiempo, de hecho este fue uno de los temas que se trataron con mi cliente, le dije que si me quedaba en AWS debo invertir más tiempo y por tal motivo debo cobrar más, le dije que había un alternativa que hace lo mismo pero sigue teniendo el mismo costo.

CloudFlare VS AWS Shield

Una vez que se tiene el sitio web, ya sea en producción o desarrollándose, se puede dar el caso de ataques DDoS, es decir puede que algún script traté de sacar provecho de su servidor y para evitar esto, se den agregar capas de protección, tales como reglas de acceso, geolocalización, IPs que puedan solo acceder a ciertas zonas de tu servidor, y para ser sincero, desde que vi el problema con CloudFront, ya no configuré AWS Shield el cual tiene el objetivo de ser la capa de seguridad para tu servidor, en este caso EC2. CloudFlare cuenta con reglas de firewall las cuales son fáciles de agregar y también se pueden deshabilitar con 1 solo click,

Una regla que tengo configurada es que sólo los países de habla hispana, pueden acceder sin problemas al dominio, en caso de tener una IP diferente, por ejemplo de Rusia o Asia, CloudFlare mostrará un captcha y si es aceptado, mostrará el contenido, con esto se previenen muchos ataques DDoS, he incluso mejora las estadísticas de tu público objetivo.

Conclusión:

El proyecto final quedó de la siguiente forma:

• Route53 CloudFlare como administrador de dominio (DNS).
• EC2 como servidor o VPS.
• S3 como servidor de archivos estáticos.
• CloudFront CloudFlare como el CDN.
• AWS Shield y WAF  CloudFlare como protección de ataques DDoS.

Como se puede ver, solo utilizo los servicios que son meramente necesarios en AWS, si CloudFront implementara una función de paso como CloudFlare, me quedaría con ese servicio pero para este proyecto no funcionó, al necesitar CloudFlare, al instante, dejé de necesitar Route53, AWS Shield, WAF y Lambada, AWS debe diseñar una forma más eficiente de CloudFront.

Espero esta publicación ayude a los programadores que empiezan con AWS y están indecisos sobre los servicios que ofrece.