Gestión automática de recursos efímeros para pruebas usando tecnología sin servidor

¿Alguna vez te has visto en la necesidad de eliminar manualmente recursos de AWS en cuentas creadas con propósitos de entrenamiento o experimentación? ¿O has tenido la preocupación que puedan quedar recursos generando costos innecesarios?

O tal vez que los desarrolladores tengan que solicitar nuevos permisos y cuentas constantemente para poder desplegar sus soluciones de innovación.

Esta publicación busca resolver las interrogantes anteriores con una solución sin servidor que automatiza el ciclo de vida de recursos efímeros en cuentas para pruebas. Brinda la posibilidad de configurar un monto de presupuesto específico y la cantidad de días que permanecerán activos los recursos antes de ser eliminados automáticamente. Todo esto por supuesto, sin perder de vista la seguridad y el control.

Nuestros clientes buscan seguir las buenas practicas y recomendaciones de AWS todo el tiempo. Esto incluye grandes corporaciones, emprendimientos y agencias gubernamentales, sin importar el estado de adopción de cada uno de ellos, ya sean los que están ejecutando una migración, los que implementan sus soluciones y aplicaciones nativamente en la nube o ambos.

Considerando lo anterior desde el punto de vista de gobierno y seguridad fue creado el servicio AWS Control Tower, la forma mas fácil de desplegar un ambiente de múltiples cuentas en AWS que ya tiene incorporado en sí, las buenas practicas y experiencias de miles de clientes que han utilizado este enfoque a lo largo de los años. De esta forma se logra mantenerse ágiles y al mismo tiempo organizados en cuanto al gobierno de recursos TI.

Esta es la estructura organizacional recomendada por AWS para el trabajo con múltiples cuentas, lo que no se considera acá es una forma automática de generar, controlar y eliminar recursos de las cuentas dentro de la unidad organizacional de “Sandbox”; o como también se conoce, ambientes bajos o desarrollo.

Descripción de la solución

Acá se presenta el diagrama de estados que comprende el ciclo de vida de una cuenta de prueba creada por esta solución.

1.     New Account: nueva cuenta de AWS, totalmente funcional, creada con fines de experimentación.

2.     Sandbox Account: después de aprovisionar un producto utilizando AWS Service Catalog introduciendo ciertos parámetros como cantidad de días y presupuesto, esta cuenta nueva se convierte en una cuenta de pruebas, donde se controla la vida útil de los recursos desplegados en ella.

3.     Expiring: la solución tiene un mecanismo de cuenta regresiva para controlar los días restantes del plazo seleccionado o hasta que se consuma el presupuesto asignado. Un día antes que caduquen los recursos, se envía un correo electrónico con un resumen de lo que será eliminado.

4.     Delete Resources: cuando finaliza la cuenta regresiva, los recursos de la cuenta se borran y la cuenta regresa al estado inicial como cuenta de pruebas. El ciclo con los parámetros definidos en el lanzamiento del producto del catálogo comienza nuevamente.

5.     Unistall: proceso de eliminación del mecanismo de control de la cuenta de prueba. La cuenta de AWS vuelve a ser una cuenta totalmente funcional. Detalles al final de la publicación.

Esta implementación se considera una extensión del servicio de AWS Control Tower, pero también puede ser utilizada si tiene AWS Organizations o la solución de AWS Landing Zone desplegada. En la presente publicación se abordará el enfoque que utiliza AWS Control Tower.

Arquitectura

En el siguiente diagrama de arquitectura se encuentran todos los componentes utilizados esta solución.

En la cuenta principal se despliega un stack de AWS CloudFormation que crea un portafolio en AWS Service Catalog que a su vez contiene un producto llamado Sandbox Account.

Cuando se lanza dicho producto completando todos los parámetros requeridos se van a crear dos stack adicionales.

El primero en la cuenta principal con un AWS Budget para controlar el gasto de la cuenta de prueba y dos Service Control Policies (SCPs) para garantizar la integridad la misma:

• SandboxRegions – SCP para restringir la creación de recursos fuera de N.Virginia (us-east-1) e Sao Paulo (sa-east-1).
• SandboxGuardrails – SCP que protege los recursos de control creados en la cuenta de prueba. Con esto ni siquiera un administrador de dicha cuenta podrá alterar el stack que garantiza la conformidad de la solución.

El segundo en la cuenta de prueba que a través de AWS Lambda solicita mediante Service Quotas un aumento del límite de CPU para las instancias de Amazon EC2. En adición a esto, también se crean configuraciones para Amazon CloudWatch Events, AWS Step Functions, AWS Systems Manager, AWS Lambda y Amazon SNS. El objetico detrás de todo esto es implementar un temporizador, sistema de notificaciones y una rutina de limpieza de cuenta utilizando AWS CodeBuild y aws-nuke.

Aclarar que aws-nuke es un proyecto de código libre independiente, desarrollado y soportado por terceros, que se utiliza en esta solución para preservar la configuración inicial de la cuenta a convertir en modo prueba.

Instalación

Esta guía contempla que ya se tiene desplegada la “landing zone” con AWS Control Tower y al entrar a la página del servicio se observa algo similar a la imagen a continuación.

Uno de los componentes fundamentales de AWS Control Tower es la Account Factory. Con ella se automatiza la creación o incorporación de cuentas AWS dentro de cada unidad de la organización. Para enrolar una cuenta de esta forma se debe acceder a la “Account Factory” en el menú de la izquierda para visualizar la siguiente pantalla.

En la sesión de configuración de redes es posible editar las características de la Amazon VPC y subnets que pueden ser desplegadas como parte de la línea base de la cuenta AWS a crear. Al presionar el botón “Enroll account” se abrirá el siguiente formulario:

Luego de completar los datos solicitados y enviar el formulario comienza el proceso de creación de la cuenta de AWS, el tiempo necesario puede variar desde 10 minutos hasta 30 en dependencia de la configuración de red y el nivel de personalización de la “landing zone”. En medio del proceso de creación se va a enviar un correo con un enlace para la autenticación del usuario de (Single Sign-On) SSO creado.

El próximo paso será activar el modo pruebas en la cuenta de AWS recién creada.

La solución de cuentas de prueba requiere la creación y lanzamiento de un producto en AWS Service Catalog. Para crear el nuevo producto se debe ejecutar un script de infraestructura como código mediante AWS CloudFormation. En el siguiente enlace se encuentra dicho script preparado para ser lanzado en al consola de AWS CloudFormation en la región de “N. Virginia”, debe cargar una pantalla similar a la siguiente:

Antes de comenzar a configurar los parámetros del stack de AWS CloudFormation, es importante mencionar que para agregar un nuevo producto en el AWS Service Catalog, es necesario que el usuario autenticado en la consola (donde se realizará toda la configuración) tenga aplicada la política de AWS IAM: arn:aws:iam::aws:policy/AWSServiceCatalogEndUserFullAccess.

Nota: Los usuarios por defecto de AWS Control Tower ya tienen esta y otras políticas aplicadas.

Al pasar al próximo paso del wizard de AWS CloudFormation se deben ingresar dos parámetros: ArnRoleAdmin y ArnRoleServiceCatalogSSO. Ambos son roles de IAM ya aprovisionados por AWS Control Tower y que pertenecen a AWS SSO.

• ARN IAM Role ServiceCatalogEndUser: Ir a la consola de AWS IAM y busca el rol: AWSServiceCatalogEndUserAccess, el ARN de dicho rol tiene el siguiente patrón: arn:aws:iam::XXXXXXXXXXXX:role/aws-reserved/sso.amazonaws.com/AWSReservedSSO_AWSServiceCatalogEndUserAccess_XXXXXXXXXXXXXXXX. Donde las X representan el id de cuenta de la cuenta master. También puede crear un rol propio, solo basta que tenga asociada la política de IAM: AWSServiceCatalogEndUserFullAccess.
• ARN IAM Role Administrator Access: Similar al caso anterior, pero rol es: AWSAdministratorAccess, y el patrón: arn:aws:iam::XXXXXXXXXXXX:role/aws-reserved/sso.amazonaws.com/AWSReservedSSO_AWSAdministratorAccess_XXXXXXXXXXXXXXXX. También puede crear el rol propio asociando la política: AdministratorAccess.

Una vez que los parámetros estén configurados, simplemente ejecute el script haciendo clic en siguiente, luego, seleccione el cuadro de opciones como se muestra a continuación y presione crear stack.

Luego de algunos segundos, una vez finalizada la ejecución, verá un nuevo producto en el catálogo. Ese producto es quien contiene el mecanismo para transformar una cuenta existente (en este caso la que se creó en el paso anterior con la “Account Factory”) en una cuenta de prueba.

En el catálogo se puede observar que se creó un nuevo portafolio llamado: SandboxAccount.

El próximo paso es acceder la página de productos en la parte superior del menú de la izquierda y lanzamos el producto que activa el modo pruebas.

Escriba un nombre para el producto y presione siguiente.

Introducir los parámetros de configuración de la cuenta de prueba y presione siguiente. Los parámetros se describen a continuación.

Email address: Dirección de correo electrónico que recibirá notificaciones. El día antes de la limpieza, el administrador recibirá una notificación que contiene un resumen de lo que se eliminará de la cuenta al día siguiente. Poco después de la creación de la cuenta de prueba, se enviará un correo electrónico con una solicitud de confirmación para suscribirse al canal de notificaciones (imagen a continuación). Es importante que se suscriba utilizando el enlace de confirmación dentro de este correo electrónico.

AWS Budget Name: El nombre del AWS Budget a crear para controlar los gastos de los recursos desplegados en la cuenta de prueba, cada vez que la cuenta alcanza un gasto superior al 90% del monto definido como presupuesto, se enviará una notificación. Esta configuración se realiza en la cuenta principal de la organización.

Budget size in USD: Monto en dólares del presupuesto para la cuenta de prueba. Considerar que el presupuesto tiene un cálculo mensual y la cuenta se puede configurar para que se limpie en menos de 30 días.

CPU limit increase for different EC2 families: Se utiliza para automatizar la solicitud de aumento de CPU disponible para la creación de instancias Amazon EC2 para las familias A, C, D, H, I, M, R, T y Z. Una cuenta nueva viene con una cantidad por defecto de CPU relativamente pequeña, al configurar este parámetro se abre un ticket para solicitar más CPU de forma automática.

What is the AWS Account ID for the Sandbox Account: ID de la cuenta de pruebas que se creó usando el “Account Factory” al inicio del post. El identificador de cuenta de AWS tiene 12 dígitos sin comillas ni espacios. Se puede obtener en la pantalla de AWS Organizations o en la pantalla de cuentas de AWS Control Tower.

Solution Deployment Region: Región donde se desplegarán los recursos que van a monitorear la cuenta de prueba. Las opciones actualmente disponibles son Virginia (us-east-1) y Sao Paulo (sa-east-1)

Period in days: Cantidad de días a esperar antes de eliminar automáticamente todos los recursos creados en la cuenta.

Luego de introducir los parámetros de configuración, presione siguiente para asignar las etiquetas y, por último, revise que todo esté en orden para lanzar el producto. Pasados aproximadamente 2 minutos debe terminar la creación y verá la siguiente pantalla.

Su nueva cuenta, ahora en modo pruebas realizará una limpieza automática dentro de un ciclo recurrente, se creará una alerta en AWS Budgets para controlar los gastos, se creará un ticket de soporte para aumentar los límites de CPU para las instancias Amazon EC2 y el proceso de limpieza realizará un respaldo de todos los componentes de redes de la cuenta para poder reutilizarlos en del próximo ciclo de uso. También se creará una política de restricción de uso solo para las regiones us-east-1 y sa-east-1. Actualice la SCP SandboxRegions utilizando el servicio AWS Organizations para controlar la disponibilidad de los servicios en otras regiones.

Desinstalación

Para desactivar el modo de pruebas, es necesario tener el id de la cuenta (anteriormente vimos como encontrarlo). Con ese número a mano, ingrese la cuenta master de Control Tower y acceda a los siguientes servicios:

1-    AWS Organizations: en el menú superior, seleccione «Políticas» para mostrar las políticas existentes. Seleccione las políticas SandboxRegions y SandboxGuardrails y elimine la asociación entre estas políticas y la cuenta de pruebas.

2-    AWS CloudFormation: durante la creación se agregaron un stack y un stackSet, debemos eliminar estos elementos. Vaya a AWS CloudFormation y en el menú de la izquierda seleccione «StackSets». En la pantalla central aparecerá una lista de registros, uno de ellos tendrá un nombre en el siguiente formato: «SandboxStackSet-XXXXXXXXXXXX», donde las X es el número de cuenta donde se desactivará el modo pruebas. Seleccione el registro y, en la siguiente pantalla, use el menú «Actions → Delete stacks from StackSet».

En la siguiente pantalla debe ingresar el número de cuenta y la región donde se desplegó la solución. Complete la información y seleccione «Next”, en la pantalla de revisión presione el botón «Submit». Después de verificar que el stack se ha eliminado de la cuenta de prueba, regrese al mismo “StackSet” y elimínelo utilizando el menú «Actions → Delete StackSet».

3-    Service Catalog: Al acceder al servicio, busque en el menú izquierdo la opción «Provisioned products». Una vez en la pantalla de productos desplegados, debe seleccionar el producto creado durante la configuración de su cuenta de prueba. Para finalizar seleccionar «Actions → Terminate».

Costos

Cada cuenta transformada en una «cuenta de prueba» utiliza servicios de control cuyo consumo mensual aproximado es alrededor de US $5,60.

Podrá encontrar mas detalles en el proyecto original mediante el siguiente vínculo.

Sobre el autor

Rene Martínez Bravet

Sr Solutions Architect at AWS.

Matheus Arrais

Arquitecto de Soluciones para Socios. Se centra en las herramientas de gobierno y la estrategia de múltiples cuentas. Trabaja junto con socios de todo Brasil ayudándoles a hacer un viaje exitoso dentro de la asociación de AWS y a ofrecer la mejor solución para sus clientes.

Luiz Henrique Decaro

Arquitecto de Soluciones con un enfoque en clientes en el sector financiero y un maestro en Ingeniería de Software con 18 años de experiencia en el desarrollo y arquitectura de sistemas de misión crítica en el área de TI.

Si tiene dudas, comuníquese con nuestro equipo a través del chat en línea.