Usando AWS para ejecutar cargas críticas en sector público: Consulta de resultados a elecciones nacionales o estatales

Eduardo Patino, Solutions Architect for Public Sector on AWS

Amazon Web Services (AWS) cuenta con millones de clientes activos al mes, muchos de los cuales ejecutan aplicaciones críticas para sus negocios. Entre ellos, en Latinoamérica podemos encontrar ICFES, Tecnológico de Monterrey, Rappi, Cinépolis, Televisa, Wizeline, Enviaflores y muchos otros más, quienes se han visto beneficiados al poder cumplir con la demanda de sus clientes.

Al igual que estas empresas y entidades, nuestros clientes de gobierno y educación requieren escalar, por ejemplo, para crear y mantener un portal web al que un país entero ingresa a consultar los resultados de elecciones presidenciales. Este fue el caso del Instituto Nacional Electoral (INE) en México, quién encontró en los servicios de AWS la seguridad y solidez para divulgar los resultados de las últimas elecciones presidenciales en 2018.

Utilizando la potencia informática de Amazon Elastic Compute Cloud, AWS Lambda y el almacenamiento de datos con Amazon Simple Storage Service, además de seguridad con AWS WAF y AWS Shield, el INE gestionó una elección nacional de forma exitosa garantizando agilidad en acceso de los datos, siempre teniendo en mente la seguridad de los mismos.

Al igual que el INE, otros clientes se preguntan ¿Está mi arquitectura en AWS lista para escalar y soportar miles o millones de usuarios por minuto?. Aunque se encuentran múltiples blogs relacionados a seguridad, arquitecturas con y sin servidores y muchas otras buenas prácticas, la preparación para estos tipos de eventos es primordial.

Con una buena preparación podemos arquitectar todos los componentes involucrados de una manera anticipada y con esto lograr que los usuarios finales accedan a una aplicación confiable, resiliente, tolerante a fallas y preparada para soportar incluso ataques de denegación distribuido (DDoS).

Durante la planeación de este tipo de eventos se busca contemplar todos los componentes y evitar o mitigar degradaciones del servicio relacionados con la cantidad de usuarios que están accediendo, latencias a nivel de red, revisiones de espacios de direccionamiento IP, políticas de escalabilidad, revisión de limites en cuanto a componentes involucrados (link), tener monitoreo constante de todos los componentes y logs, entre otros.

En este post encontrarán recomendaciones y pautas de AWS basadas en nuestros principios de buenas arquitecturas (link) y una orientación a eventos de infraestructura planeados (link).

0. El punto número cero a contemplar es la seguridad. Esta es la base de una buena arquitectura y es crítico para que nuestras arquitecturas sean resilientes y puedan soportar la cantidad de tráfico que esperamos. Es importante establecer un perímetro de seguridad y permitir o denegar el acceso basado en reglas, ya sea reglas a nivel de red (grupos de seguridad, geolocalización, entre otras) o reglas a nivel de aplicación, haciendo uso de un Web Application Firewall (WAF). Ante un DDoS existen 4 mejores prácticas generales a seguir:

a) Minimice el área de superficie de ataque y proteja los recursos expuestos: Esto nos permite centrar nuestros esfuerzos de mitigación. Desacople en capas tanto como le sea posible. Para entender como podemos proteger los servicios que tenemos expuestos, veamos qué capacidades nos entrega AWS:

i. AWS Shield en su versión estándar, es un servicio de protección contra ataques DDoS para aplicaciones ejecutadas en AWS. Protege a nivel capa de red y transporte servicios como AWS Route 53 y AWS Cloudfront. Puede usar AWS Shield en su versión Advanced para proteger los mismos servicios de la versión estándar y adicionalmente servicios como Amazon Elastic Compute Cloud (EC2), Elastic Load Balancer (ELB) y AWS Global Acelerator; incluso proporciona acceso ininterrumpido al equipo de respuesta ante DDoS (DRT), en caso que requiera realizar una mitigación.

ii. Amazon Route 53 es un servicio de DNS (Sistema de Nombres de Dominio, por sus siglas en inglés) escalable y altamente disponible en la nube. Este servicio cuenta con un SLA de 100%, adicionalmente cuenta con TTLs mínimos de 60 segundos, entre otras características del servicio; razón por la cual le permitirá tomar acciones rápidas en caso de requerir realizar cambios de DNS antes, durante y después del evento.

iii. Amazon Cloudfront (redes de distribución de contenido (CDN) le ayudará a acercar el contenido a sus usuarios, por lo cual, la carga de sus sitios web será mas rápida. Además, podrá distribuir el tráfico entrante de un ataque hacia las más de 210 ubicaciones de borde con las que Amazon CloudFront cuenta hoy en día. En Latinoamérica, contamos con ubicaciones de borde en Colombia, Chile y Argentina. Amazon CloudFront, AWS Shield, AWS WAF y Amazon Route 53 funcionan juntos para crear un perímetro de seguridad flexible y por capas frente a múltiples tipos de ataques. Dentro de los cuales están los ataques a nivel infraestructura (como UDP floods), ataques de agotamiento de estado (como TCP SYN floods) y ataques hacia la aplicación (como HTTP GET o POST floods). Otra característica de seguridad con la que cuenta Amazon Cloudfront y de la que puede sacar provecho en este tipo de eventos es la de restringir el trafico dependiendo de la geolocalización del usuario y permitir únicamente el trafico desde donde usted necesita ser visto. Por ejemplo, si nuestro evento es exclusivamente en un país y no mundial, podemos usar esta característica para bloquear tráfico no deseado de otros países. Igualmente es recomendable que, al momento de configurar sus distribuciones de contenido, piense en alta disponibilidad y para ello, puede utilizar la conmutación por error de origen y de esta manera tener un origen activo y otro pasivo. En caso de haber problema con la infraestructura que tenga en alguna región, Cloudfront podrá redirigirla a una región sana.

b) Prepárese para escalar: Este es un principio de buena arquitectura, pero a su vez una técnica eficaz de mitigación de DDoS. Respecto a seguridad, es necesario tener en cuenta cómo los ataques volumétricos buscan dos cosas: saturar el ancho de banda y saturar la capacidad de los servidores. Por esta razón, para cubrir la capacidad de ancho de banda usamos Amazon Cloudfront (del cual hablamos en el punto anterior). Adicional, recordemos que dependiendo del tipo de instancia EC2 que utilice, esta tendrá un rendimiento de red especifico (link). Para absorber un ataque volumétrico, es importante que nuestra infraestructura pueda adaptarse a la cantidad de tráfico, peticiones, entre otros; para esto es habitual el uso de balanceadores de carga y grupos de autoescalado. Con esto puede crear nueva capacidad de cómputo y dirigir la carga hacia esta nueva capacidad, con el fin de evitar sobrecargar un nodo específico.

c) Sepa lo que es normal y tome acción automática sobre lo que no lo es: Es fundamental que identifique el tráfico correctamente. En el caso de portales de revisión de resultados electorales en un país, sabemos que estos sitios tienen una gran exposición pública, desde medios de comunicación hasta redes sociales, lo cual puede provocar que el portal web se vea abrumado por el tráfico. La supervisión constante de la infraestructura pueden ayudarlo a identificar rápidamente un ataque legítimo e involucrar a AWS. Para una mayor visibilidad de los ataques en sus recursos Amazon EC2, CloudFront y Elastic Load Balancing, le recomendamos usar AWS Shield Advanced, con esto obtendrá acceso exclusivo a métricas e informes avanzados en tiempo real.

d) Arquitecte para la resiliencia: Hemos hablado acerca de cómo Amazon Route 53, Amazon Cloudfront y AWS Shield le brinda protección a nivel de capa 3 y capa 4; pero para tener resiliencia es importante proteger su aplicación a nivel capa 7 o capa de aplicación, para esto puede utilizar AWS WAF. Como punto de inicio puede usar AWS WAF Security Automations (link); sin embargo, recomendamos agregar reglas personalizadas, aplicar análisis de registros y aprovechar las reglas administradas por AWS WAF, según las necesidades de su empresa.

La siguiente imagen (Fig1) muestra una arquitectura de referencia a nivel de las capas de seguridad para una aplicación web sin estado que se basa en HTTP/S, como un sitio web, un API o una aplicación móvil.

Fig1.

1. Use Servicios, NO Servidores. Al usar servicios como AWS Route 53, Amazon Cloudfront, AWS Lambda o AWS DynamoDB, usted puede preocuparse realmente por su aplicación, mas no por administrar, gestionar o realizar el escalado de la infraestructura que necesita. Esto ayudará a que su aplicación pueda escalar dependiendo del tráfico que está recibiendo. Estos servicios ya usan múltiples zonas de disponibilidad sobre la misma región, con el fin de brindarle alta disponibilidad sin que usted tenga que preocuparse por ello. Lo anterior no significa que si su aplicación pasara de cero a dos millones de conexiones concurrentes, el servicio estará listo para soportar este tráfico. Para esto, tenga en cuenta los siguientes aspectos:

a) Diseñe antes de implementar: Parece un punto bastante normal, pero entre más tiempo invierta pensando en cómo diseñar su sistema para tener alta disponibilidad y cómo su sistema es tolerante a fallas, usted invertirá menos tiempo en tratar de solucionar problemas que no contempló durante el diseño. Apóyese en uno de nuestros arquitectos de soluciones y/o algún partner de nuestra amplia red, ellos podrán ayudarle con mejores prácticas y recomendaciones durante todo el proceso, según su carga de trabajo.

b) Realice pruebas de carga/estrés: Para realizar una prueba de carga a su aplicativo, puede utilizar herramientas que ya conozca o puede desplegarlas desde nuestro catálogo de aplicaciones. Con ellas, determinará cuál es la infraestructura o servicios mínimos que necesita para soportar los picos de carga de su aplicación, y asegurará que el servicio pueda soportar la carga esperada.

c) Arquitecturas multiregión: Para aplicaciones críticas, en donde todo un país accederá en un periodo corto de tiempo y tendrá mucha visualización a nivel nacional y/o internacional, es crítico pensar en arquitecturas multiregión. Para solventar la necesidad de dirigir el tráfico entre regiones, haga uso de los diferentes tipos de direccionamiento con los que AWS Route 53 cuenta (Simple, conmutación por error, geolocalización, geoproximidad, latencia, entre otros) según lo requiera

2. Autenticación y autorización: Cuando hablamos de autenticación y autorización para componentes que escalen masivamente, nos encontramos con problemas complejos, por ejemplo, ¿Cómo poder autenticar a cientos de miles de usuarios en un lapso de tiempo muy corto?. Para esto, Amazon Cognito proporciona servicios de identidad, federación y sincronización para aplicaciones móviles y web. Además simplifica la tarea de autenticar a los usuarios y de almacenar, administrar y sincronizar sus datos entre varios dispositivos, plataformas y aplicaciones. Amazon Cognito proporciona credenciales temporales con privilegios limitados a los usuarios autenticados y no autenticados, sin tener que administrar ninguna infraestructura interna. Amazon Cognito, además de poder generar un set de credenciales propio, también funciona en modo federación, utilizando proveedores de identidad populares como Google, Facebook y Amazon para autenticar a sus usuarios finales. Con Amazon Cognito puede utilizar características de seguridad adicionales, por ejemplo, solicitar un doble factor de autenticación o un código de única vez en el momento en que los usuarios inician sesión. Puede usar el siguiente blog como guía de implementación (link)

3. Piense de una manera diferente, haga arquitecturas serverless (sin servidores), procese del lado del cliente y resuelva problemas difíciles de una manera fácil: Muy a menudo se piensa que, para mostrar información a usuarios es necesario ir a consultarlo en línea a la base de datos. Esto hace que las arquitecturas se vuelvan complejas debido a que es necesario pensar en cómo escalar las bases de datos (Cantidad de IOPS, shardening, réplicas de lectura, multimaster, entre otros), pero la realidad es que muchos de estos procesos pueden ser procesados en back una vez cada cierto tiempo y mostrar el resultado a los ciudadanos, televidentes o usuarios finales. Pensemos en mostrar resultados electorales o resultados de calificaciones de estudiantes a nivel de un país y tratemos de resolver esto de una manera diferente:

a) Cada vez que un usuario entra al portal para consultar los resultados electorales, ¿el portal le da la información actualizada segundo a segundo? La pregunta que deben realizarse los desarrolladores es si el proceso está listo para procesar segundo a segundo cómo va el conteo de votos. Realmente, el proceso de consolidación se ejecuta cada cierta cantidad de minutos y posteriormente se actualiza la base de datos o repositorio con los datos consolidados. Teniendo esto en cuenta, en vez de tener cientos de servidores haciendo cientos o miles de consultas a una base de datos central, es posible ejecutar un único proceso que extraiga la información cada 30 segundos y la deposite en formato JSON en un almacenamiento de objetos como Amazon S3, para que este sea accedido y mostrado a los usuarios vía javascript desde su explorador.

b) Use Serverless para consolidar: Para resolver el punto anterior puede usar AWS Lambda, el cual puede ejecutar código para cualquier tipo de aplicación o servicio back-end sin tener que realizar tareas de administración. Solo tiene que cargar el código y AWS Lambda se encargará de todo lo necesario para ejecutar y escalar el código con alta disponibilidad. En este caso podrá usar AWS Lambda para que se ejecute automáticamente cada “30 segundos” usando Amazon Cloudwatch events y así, realizar la consolidación y generación de los objetos JSON para que posteriormente los deposite en Amazon S3.

c) Almacene y muestre la información actualizada como sitio web estático procesando del lado del cliente: Recuerde que Amazon S3 tiene la habilidad de alojar sitios web estáticos sin que nuestros clientes se preocupen de como este escalará. Con Amazon S3 standard, cuando se deposita un objeto este es replicado en 3 zonas de disponibilidad dentro de la misma región de AWS, por lo que tendremos alta disponibilidad y durabilidad de la información. En el caso de consulta de resultados nacionales y estatales, al ser un proceso crítico, puede obtener tolerancia adicional a fallas habilitando la opción de cross-region-replication. Una vez el usuario acceda a la página alojada en Amazon S3, esta será interpretada por su explorador y usando JavaScript, hará referencia a los objetos JSON.

La siguiente imagen (Fig2) muestra una arquitectura de referencia donde se aloja una pagina web estática usando Amazon S3 y una distribución de contenido con Amazon CloudFront. El backend se ejecuta utilizando Amazon APIGateway, AWS Lambda y/o Amazon ECS.

Fig2.

d) Simplifique la creación de aplicaciones web y móviles escalables: Para esto puede utilizar el servicio AWS Amplify en cual facilita crear, configurar e implementar aplicaciones móviles y web escalables. Amplify aprovisiona y administra de manera continua su backend móvil y ofrece un marco simple para integrar fácilmente su backend con sus frontends de iOS, Android, Web y React Native. AWS Amplify también automatiza el proceso de liberación de la aplicación de frontend y backend permitiendo que ofrezca características más rápidas. Este servicio simplificará la manera de utilizar servicios como: Amazon Cognito, Amazon S3 y Amazon Cloudfront, de los cuales ya hemos hablado en este blog. Con el uso de estos servicios puede crear sitios web escalables donde no requiere de servidores y de esta manera despreocuparse por la cantidad de recursos que requiere para soportar cientos de miles de request por minuto, ya que como lo mencionamos, estamos usando servicios, no servidores. Utilice el siguiente link en caso de que no haya implementado anteriormente sobre S3 un sitio web estático (HTML, Javascripts, Imágenes, JSON, etc) usando Amazon Route 53 y Amazon Cloudfront.

e) Almacene sus datos de manera persistente en el servicio correcto: Los Arquitectos de Soluciones de Amazon Web Services siempre mencionamos la importancia de usar la herramienta correcta para el trabajo correcto, Los días de la base de datos monolítica única y centralizada han quedado atrás y los desarrolladores ahora están creando aplicaciones altamente funcionales y de alto rendimiento, utilizando diferentes de bases de datos especialmente diseñadas para cada tipo de necesidad. El siguiente video (link) le será de gran ayuda para identificar qué tipo de base de datos debe escoger para su carga de trabajo. Pero tome las siguientes consideraciones con relación a la capa de datos que requiere para procesos como consulta de resultados a elecciones nacionales o estatales, o procesos adyacentes como puede ser consultar el lugar de votación:

a) Bases de datos NOSQL: Amazon DynamoDB es uno de los servicios de bases de datos tipo nosql administrado por AWS y además está catalogada dentro del mundo serverless. Amazon DynamoDB ajusta de manera dinámica y automática la capacidad de desempeño en respuesta a los patrones de tráfico reales. Puede usar, según su aplicación, este tipo de base de datos No SQL para consolidar el conteo de votos por candidato.

b) Bases de datos SQL: Con relación a la base de datos relacionales, es importante identificar con las pruebas de carga la cantidad de IOPS (lecturas y escrituras de disco) que requiere con la concurrencia esperada. Para escalar a nivel de IOPS en Amazon RDS, puede usar volúmenes de almacenamiento con IOPS aprovisionados. Otra ventaja obtenida al utilizar Amazon RDS es la facilidad para escalar utilizando replicas de lectura (read replicas) de la base de datos, las cuales puede desplegar con un par de clics. Para contar con alta disponibilidad puede usar la opción RDS multi-AZ, que replica su base de datos de modo síncrono hacia otra zona de disponibilidad. https://docs.thinkwithwp.com/es_es/AWSEC2/latest/UserGuide/ebs-io-characteristics.html.

c) Cache de Bases de datos: Utilice el servicio de Amazon ElastiCache para hacer cache de las consultas mas frecuentes hacia las bases de datos. Así puede acelerar la respuesta y darle una mejor experiencia de usuario a sus clientes, además de disminuir la cantidad de peticiones hacia su base de datos central. Clic aquí para más información. Siguiendo con el ejemplo de consulta de resultados en elecciones nacionales, es notable que la aplicación realizará consultas estándar, por ejemplo, lugares de mesas de votación o cantidad de votos por partidos, por lo que almacenar estas consultas en cache disminuirá la cantidad de peticiones hacia sus bases de datos.

4. El monitoreo es clave en este tipo de eventos. Existen servicios indispensables para poder tener un seguimiento adecuado en términos de visibilidad y con ello tomar acciones tempranas de lo que este sucediendo, antes, durante y posterior a estos periodos críticos. Siguiendo las mejores practicas de AWS, es recomendable contar con una única cuenta destinada a la seguridad, la cual servirá como repositorio de logs para sus demás cuentas de AWS. Hacia esta cuenta central, servicios de AWS como lo son: AWS CloudTrail, Amazon Cloudwatch, AWS Application Load Balancer, Amazon Cloudfront y VPC Flowlogs, podrán enviar sus logs y así tendrá un panorama único de todo lo que está utilizando. Para cumplir con esto, puede utilizar Amazon Cloudwatch (link). Amazon Athena es un buen aliado para poder realizar querys interactivos tipo SQL a grandes cantidades de datos (por ejemplo, logs). En este caso usted puede utilizarlo para identificar los patrones de acceso de los usuarios hacia sus aplicaciones realizando consultas en sus logs y así poder actuar de manera proactiva. Este es un ejemplo de cómo podría utilizar Amazon Athena para analizar los logs de los application load balancer (link).

5. Enterprise Support + IEM (infrastructure event Management): Al contratar servicios de soporte, usted contará con manos expertas que apoyarán durante el periodo crítico de su evento, quienes lo guiarán y ayudarán a que su aplicación funcione a la perfección. Para que este servicio se ejecute de la mejor manera, se recomienda contratarlo con al menos 1 mes de anticipación, esto con el fin de que el equipo de soporte pueda conocer su infraestructura, contenido, darle recomendaciones, hacer ajustes e identificar puntos únicos de falla, entre otros. https://thinkwithwp.com/es/premiumsupport/programs/iem/.

Conclusión: El tipo de arquitecturas y recomendaciones aquí descritas le ayudará a tener mejor desempeño, escalabilidad y alta disponibilidad para brindar una mejor respuesta a sus usuarios. Adicionalmente podrá disminuir el costo de la solución al utilizar arquitecturas basadas en servicios. Si requiere mas información acerca de procesos electorales y cómo podemos ayudarlo, hemos creado un portal específico con este caso de uso y del cual podrá documentarse más en caso de que lo requiera https://thinkwithwp.com/stateandlocal/elections/.

Sobre el Autor

Eduardo Patino Balaguera es Arquitecto de Soluciones en Amazon Web Services para Sector Público. Eduardo ha ayudado múltiples empresas de sector público y privado en la adopción tecnológica de nube en los últimos 8 años y ha llevado acabo de manera satisfactoria proyectos que marcan impacto social a nivel de ciudadanos y estudiantes alrededor de América Latina.

Revisores técnicos

Cristian Romero

Arquitecto de Soluciones, Amazon Web Services

Jesús Humberto Contreras

Arquitecto de Soluciones, Amazon Web Services