Conociendo el Foundational Technical Review de AWS: una guía para los Software Partners – Parte 2

Por: Alvaro Plata, Arquitecto de Soluciones Intern, Sector Público en Amazon Web Services (AWS) y
Alfonso Barbosa, Arquitecto de Soluciones Sr. para Partners, Sector Público en Amazon Web Services (AWS).

Nota: En esta serie de blogs utilizaremos el término «solución» con frecuencia, el cual se refiere a la carga de trabajo o aplicación creada por su organización y desplegada o integrada con servicios de AWS.

En el blog anterior de esta serie, presentamos una introducción al Foundational Technical Review (FTR), sus beneficios y el proceso para certificar una solución de un Software Partner de AWS¹. Asimismo, se introdujo la lista de requerimientos (Checklist) del FTR, en la cual nos enfocaremos a continuación.

El objetivo de este blog es proporcionar una serie de recomendaciones para abordar las categorías de requerimientos que suelen presentar mayores retos al preparar una solución tipo Partner Hosted para la certificación del FTR. El Checklist de requerimientos completo está disponible en la siguiente página (información en inglés): Partner Hosted Foundational Technical Review.

Categorías de requerimientos: descripción a alto nivel y recomendaciones

Uno de los puntos claves al iniciar la preparación para el FTR es definir el alcance de su solución, identificando los componentes que la conforman. Usted puede considerar certificar más de una solución, aprovechando el valor que brinda el FTR para adoptar mejores prácticas de arquitectura en sus aplicaciones.

Exploraremos con más profundidad en qué consisten las siguientes categorías del Checklist para una solución Partner Hosted: copias de seguridad y recuperación (backups and recovery), resiliencia (resiliency), revisiones de arquitectura (architecture review), AWS CloudTrail, gestión de identidad y acceso (identity and access management), y nivel de soporte (support level).

Uno de los recursos recomendados para las dos primeras categorías de requerimientos que presentaremos a continuación (copias de seguridad y recuperación, resiliencia) es el video FTR Preparation Support – Backups and Recovery & Resiliency (Spanish), el cual está disponible en Partner Central². En este video, elaborado específicamente con un enfoque en el FTR, se tratan con más detalle los principales conceptos y recomendaciones para la implementación de estos requerimientos.

Copias de seguridad y recuperación (backups and recovery)

El objetivo principal de esta categoría es verificar que se están realizando copias de seguridad (respaldos) periódicas y automáticas de los datos gestionados por su solución. También valida que a través de pruebas regulares, estos datos se pueden recuperar oportunamente, asegurando su integridad y la efectividad de los procesos de respaldo. Estas pruebas deben cumplir con los objetivos del RTO (Recovery Time Objective) y RPO (Recovery Point Objective) que se hayan establecido para su solución. El RTO es el tiempo necesario para recuperar la disponibilidad de su aplicación después de una interrupción, mientras que el RPO es la cantidad máxima de tiempo de pérdida de datos que su servicio de negocio apoyado en esta aplicación puede tolerar. Para obtener más información sobre estas dos métricas y cómo definirlas, se recomienda consultar el siguiente blog de AWS en inglés: Establishing RPO and RTO Targets for Cloud Applications.

Para estos requerimientos, es importante identificar los diferentes repositorios de datos de su solución (por ejemplo, instancias, bases de datos, sistemas de archivos, etc.) y aspectos relevantes de cada uno de ellos, como patrones de lectura/escritura y criticidad de los datos. Esto permite determinar la frecuencia necesaria de creación de copias de seguridad para cada uno de los repositorios de datos de su solución.

Se recomienda el uso de AWS Backup para centralizar y automatizar el proceso de creación de copias de seguridad de sus datos, con la frecuencia de ejecución definida. Una vez configurados estos respaldos, es fundamental incorporar en su organización la práctica de realizar frecuentemente pruebas de recuperación de datos. Esto permitirá a los equipos a cargo familiarizarse con los procesos necesarios para lograrlo en caso de una eventual pérdida de información.

Recomendamos consultar el blog en inglés Automate data recovery validation with AWS Backup y el laboratorio Testing Backup and Restore de AWS Well-Architected Labs, para visualizar ejemplos de referencia para la implementación de estas pruebas.

Resiliencia (resiliency)

El AWS Well-Architected Framework define en inglés una aplicación resiliente como “aquella que tiene la capacidad de recuperarse cuando está bajo presión por la carga (más solicitudes de servicio), ataques (ya sea por errores de operación o intencionales) y fallas de cualquier componente.”

El propósito principal de esta categoría de requerimientos es validar que su solución tiene la capacidad de recuperar su operación ante determinados tipos de incidentes, según los tiempos establecidos por el RTO y RPO. Los escenarios de incidentes mínimos a considerar para el FTR incluyen: fallas a nivel de instancias, zonas de disponibilidad y pérdida accidental de datos.

Para lograr este objetivo, es necesario llevar a cabo pruebas de resiliencia al menos una vez al año, después de actualizaciones importantes a nivel de aplicación o arquitectura, y haber realizado una prueba exitosa antes de solicitar la revisión de su solución. El propósito de estas pruebas es confirmar que la solución cumple con el RTO y RPO definidos.

Al preparar su solución para la resiliencia será necesaria la implementación de una estrategia de recuperación ante desastres (Disaster Recovery – DR). AWS contempla las estrategias de Disaster Recovery según cuatro enfoques, que van desde el bajo costo y la baja complejidad de realizar copias de seguridad, hasta estrategias más complejas mediante el uso simultáneo de más de una región.

La elección de una estrategia dependerá de los requerimientos de la solución, el RTO y RPO definidos y las restricciones de presupuesto. En la siguiente imagen se observa que a medida que nos desplazamos a través de las diferentes estrategias de izquierda a derecha, disminuimos los tiempos de RPO y RTO, pero de igual forma aumentamos los costos de implementación.

Para profundizar en el tema de recuperación ante desastres y cómo implementar cada una de estas estrategias, se recomienda consultar la siguiente serie de blogs en inglés: Disaster Recovery (DR) Architecture on AWS.

Existen múltiples estrategias para llevar a cabo pruebas de resiliencia en su carga de trabajo, las cuales varían en función de los componentes que la conforman y los servicios utilizados para su construcción. AWS Well-Architected Labs cuenta con el laboratorio Test Resiliency EC2, RDS & AZ que ofrece diversos ejemplos de pruebas de resiliencia según distintos tipos de incidentes. Estos ejemplos pueden ser utilizados como referencia para implementar pruebas específicas a su carga de trabajo.

Para mejorar los niveles de resiliencia, existen diversos mecanismos recomendados que puede adaptar a su solución. Estos actúan como medidas preventivas contra algunos tipos de incidentes, evitando la necesidad de ejecutar una estrategia de recuperación ante desastres. Recomendamos hacer uso de los siguientes mecanismos:

• Grupos de escalado automático (Auto Scaling Groups) configurados para múltiples zonas de disponibilidad asociados a las instancias de su carga de trabajo. De esta forma mantiene un mínimo número de instancias en operación para recibir el tráfico de sus usuarios. En caso de identificar algún fallo a nivel de aplicación, instancia o zona de disponibilidad, nuevas instancias son creadas automáticamente y mantienen la aplicación disponible.
• Imágenes de Máquina de Amazon (Amazon Machine Images – AMIs). Una AMI es una plantilla que contiene una configuración de software (por ejemplo, un sistema operativo, un servidor de aplicaciones y dependencias) desde la cual se lanza una instancia. En caso de requerir aprovisionar varias instancias con la misma configuración, puede lanzarlas a partir de una misma AMI que haya creado previamente. Esto permite disminuir el tiempo de creación de las instancias a partir del uso de Auto Scaling Groups.
• Monitoreo y detección automática de anomalías e incidentes en los diferentes componentes de su solución. Entre estos mecanismos se destacan: alarmas de Amazon CloudWatch, health checks de Amazon Route 53 y health checks de Elastic Load Balancer. Estos le permiten ser notificado en caso de que algún incidente sea detectado, configurar acciones automáticas como respuesta a incidentes y definir health checks para la creación de instancias en un Auto Scaling Group.

El tiempo de recuperación ante un incidente (RTO), a menudo se considera únicamente como el tiempo que conlleva restaurar la carga de trabajo y hacer failover (redireccionamiento del tráfico del sistema primario a un sistema secundario). Sin embargo, como se observa en la siguiente imagen, el tiempo de detección del incidente y el tiempo para decidir el failover (escalar y declarar) son contribuyentes adicionales y potencialmente significativos al tiempo de recuperación. Para reducir este tiempo, la detección de incidentes debe ser automática. Es decir, no debemos esperar hasta que operadores de la infraestructura o usuarios finales noten el problema.

Revisiones de arquitectura (architecture review)

El principal requerimiento en esta categoría es “realizar revisiones periódicas de la arquitectura de su carga de trabajo de producción, como mínimo una vez al año, utilizando un estándar de arquitectura documentado que incluya las mejores prácticas específicas de AWS”. Para su cumplimiento es posible utilizar algún mecanismo o herramienta de revisión interna de su organización. Sin embargo, recomendamos llevar a cabo estas revisiones mediante el AWS Well-Architected Tool, una herramienta sin costo accesible a través de la consola de AWS.

El AWS Well-Architected Tool consiste en una serie de preguntas para validar su solución frente al conjunto de mejores prácticas recomendadas por el AWS Well-Architected Framework. Además, podrá habilitar otros tipos de revisiones que sean pertinentes a la arquitectura de su solución, por ejemplo, considerando requerimientos para aplicaciones SaaS y Serverless.

Esta herramienta le permite generar informes detallados con recomendaciones de remediación para aquellos puntos en los que su solución no esté alineada con prácticas del AWS Well-Architected Framework. Es importante destacar que para obtener la certificación del FTR, no es necesario cumplir con todos los requisitos presentados por el AWS Well-Architected Tool, aunque sí es necesario realizar al menos una revisión de arquitectura antes de solicitar la revisión para la certificación. Posterior al FTR, recomendamos incorporar las recomendaciones del AWS Well-Architected Tool en su solución y realizar revisiones de arquitectura de forma periódica.

AWS CloudTrail

AWS CloudTrail es un servicio que unifica y registra las acciones y eventos de sus cuentas mediante registros (logs) de los llamados a las APIs de servicios de AWS. Por ejemplo, uno de los casos de uso que habilita AWS CloudTrail es el seguimiento de la actividad de los usuarios en cuentas de AWS con propósitos de auditoría. AWS CloudTrail registra varios tipos de eventos, entre los cuales están los eventos de administración (Management Events). Estos corresponden a operaciones realizadas sobre recursos de la cuenta de AWS, como la creación de un bucket de Amazon S3, usuarios de AWS IAM e instancias de Amazon EC2. Estos registros se almacenan sin costo durante 90 días desde su creación y pueden ser persistidos en un bucket de Amazon S3 para su posterior consulta.

El FTR es la oportunidad para explorar y adoptar el uso de servicios como AWS CloudTrail para tener una visibilidad detallada de las acciones ejecutadas en su entorno de AWS. A partir del uso de AWS CloudTrail, podrá implementar estrategias de monitoreo, control y alertas personalizadas frente a eventos críticos de seguridad, además de ejecutar acciones en respuesta a estos eventos de forma automática o manual.

Para la aprobación del FTR es necesario configurar AWS CloudTrail en todas las regiones y cuentas de AWS, almacenando los logs en una cuenta de AWS independiente. Almacenar los logs en una cuenta y bucket dedicado permite aplicar estrictos controles de seguridad y segregación de funciones con propósitos de auditoría. Además, es crucial proteger el bucket donde se almacenan los registros de accesos no deseados. Para esto se recomienda el uso de mecanismos como eliminación con MFA (MFA delete), bloqueo de objetos de S3 (S3 Object Lock) y versionamiento (versioning), que ayudan a evitar la modificación o eliminación de los registros.

Para más información sobre mejores prácticas en el uso de AWS CloudTrail, se recomienda consultar el siguiente blog en inglés: AWS CloudTrail Best Practices.

Gestión de identidad y acceso (identity and access management)

El objetivo de los requerimientos de esta categoría es fortalecer la seguridad de su solución mediante buenas prácticas relacionadas con la administración de identidades y acceso a sus recursos. AWS IAM es el principal servicio que permite controlar el acceso y los permisos de los usuarios de forma centralizada y segura.

Una de las buenas prácticas de seguridad consiste en usar credenciales temporales siempre que sea posible. Se recomienda el uso de roles de IAM para identidades de máquina dentro de AWS (por ejemplo, instancias de Amazon EC2 o funciones de AWS Lambda) y fuera de AWS (por ejemplo, un servicio de monitoreo de un tercero). Para acceso a la consola y la interfaz de línea de comandos (CLI) de AWS, se recomienda el uso de AWS IAM Identity Center o de otras soluciones de federación de identidades. Entre los beneficios de utilizar credenciales temporales sobre credenciales a largo plazo está que su ciclo de vida es limitado, de manera que no es necesario rotarlas ni revocarlas explícitamente. Además, se disminuye el impacto si se ven comprometidas, pues tienen un tiempo limitado de validez que puede ser configurado y es posible su revocación inmediata.

Una mala práctica de seguridad común en el software consiste en incluir datos confidenciales directamente en código de aplicación, por ejemplo, access keys (credenciales a largo plazo para acceder a recursos de servicios de AWS). Esto podría exponer involuntariamente las credenciales (secretos), abriendo la posibilidad de que una persona o sistema no autorizado acceda a ellas. Frente a esta situación, se recomienda hacer uso de un servicio para la gestión segura de secretos como AWS Secrets Manager o AWS Systems Manager Parameter Store.

Nivel de soporte (support level)

El objetivo de esta categoría es verificar que se cuenta con un mecanismo establecido para proveer soporte a sus usuarios o recibir soporte directo de AWS en caso de ser necesario. La recomendación principal es contar con AWS Business Support o superior para su solución. Este permitirá el acceso 24/7 a soporte técnico de AWS por teléfono, chat y web, con tiempos de respuesta que van desde 24 horas para asesoramiento general hasta menos de 1 hora para sistemas en producción inactivos. Adicionalmente, este nivel de soporte habilita el acceso a todas las comprobaciones de AWS Trusted Advisor. Este servicio presenta recomendaciones en optimización de costos, seguridad, tolerancia a errores, rendimiento y cuotas de servicios, a partir de comprobaciones automáticas en cuentas de AWS. Se recomienda consultar los diferentes planes de soporte de AWS y las características que estos incluyen.

En caso de no contar con un plan de soporte de tipo Business o superior, es necesario presentar documentación que describa cómo provee el soporte de su solución a sus clientes finales y cómo maneja las situaciones en las que requiere soporte de AWS.

Siguientes pasos

A lo largo de este blog cubrimos las categorías con requerimientos que en nuestra experiencia han sido más desafiantes en su implementación. Las recomendaciones y recursos de apoyo que compartimos serán de gran utilidad durante su proceso de preparación para el FTR.

Lo invitamos a realizar una revisión general del Checklist de requerimientos, identificando el estado actual de cumplimiento frente a cada uno de ellos. A partir de esta revisión, recomendamos elaborar un plan de trabajo que considere el recurso humano a involucrar, tiempos de implementación y una priorización para abordar los requerimientos con base en un criterio. Este podría basarse en identificar sus necesidades más apremiantes y cuáles de estas corresponden a requerimientos del FTR, de forma que al atenderlas entregará mayor valor a su organización en el corto plazo.

Otros blogs de esta serie

• Conociendo el Foundational Technical Review de AWS: una guía para los Software Partners – Parte 1

Referencias

¹Los Software Partners son empresas independientes que trabajan en conjunto con AWS para crear soluciones de software que se despliegan o integran con servicios de AWS.

²AWS Partner Central es el portal de AWS para Partners mediante el cual pueden acceder a contenido, entrenamientos y herramientas claves para el crecimiento de su negocio junto con AWS. Para más información sobre cómo acceder a Partner Central, crear una cuenta y registrar su organización en el APN, se recomienda consultar el siguiente enlace: Registro en el AWS Partner Network.

Sobre los autores

Alvaro Plata es Arquitecto de Soluciones Intern en Amazon Web Services para Sector Público. Alvaro colabora con Partners y clientes del sector público a lo largo de Latinoamérica. Le apasiona la construcción de arquitecturas orientadas a eventos, el uso de tecnologías de Machine Learning e Inteligencia Artificial y el desarrollo de capacidades técnicas en las organizaciones.

Alfonso Barbosa es Arquitecto de Soluciones Sr. para Partners de Sector Público en Amazon Web Services. Alfonso ayuda a Independent Software Vendors (ISVs) en la habilitación de capacidades técnicas para la evolución de sus soluciones. Le apasiona la analítica de datos y el desarrollo de iniciativas regionales basadas en la adopción de tecnologías, para impulsar la transformación digital en las compañías.

Revisores técnicos

Camilo García es Arquitecto de Soluciones para el Sector Público en la región Andina. Camilo ha ayudado a entidades estatales y organizaciones sin ánimo de lucro en la adopción de tecnologías de nube sobre AWS. Ha profundizado en temas de resiliencia, con énfasis en recuperación ante desastres. Le apasionan los temas de TI en las organizaciones, manejo de redes y diseño de sistemas resilientes.

Victor Fernández es Arquitecto de Soluciones para Partners de Sector Público en Amazon Web Services. Victor ayuda a los diferentes Partners de la región sur a desarrollar sus capacidades y afrontar los desafíos técnicos que estos presentan. Le apasionan los contenedores, arquitecturas de microservicios y la modernización de soluciones.