¿Te imaginas qué increíble sería poder levantar una aplicación que, en cuanto deje de ser utilizada, se pueda autodestruir sola?! 🤯
If you rather read this article in English, click here!
En este artículo voy a compartirles algunos casos de uso, el diagrama de arquitectura y la explicación de cada servicio que se utiliza en esta infraestructura de AWS. Lo padre de esta solución es que ¡puedes integrar cualquier otro servicio que necesites!
Motivación
Suele suceder que desarrolladores levantan muchos recursos para hacer pruebas en sus aplicaciones y después olvidan borrarlos, provocando gastos innecesarios.
Trabajando en una inciativa interna junto con un gran compañero mío, se me solicitó encontrar una solución creativa para este tipo de problema. Fue entonces que mi compañero se enfocó en crear una configuración automática de aplicación dentro de una instancia EC2, mientras que yo me encargué de construir una infraestructura que pudiera borrarse automáticamente.
¿En qué tipo de escenarios necesito esta arquitectura?
Imagina que quieres crear un ambiente de desarrollo para hacer pruebas de código. Con esta arquitectura tu puedes crear y borrar ambientes bajo demanda, reduciendo costos e incluso incrementando la eficiencia.
Otro caso de uso sería en cargas de trabajo basada en eventos, como lo son conferencias o webinars. Para llevar a cabo estos eventos necesitas servidores y almacenamiento durante un periodo corto de tiempo. Al utilizar una arquitectura que se autodestruye, podrías facilmente eliminar todo después del evento, reduciendo así la complejidad.
Y ¿qué tal una aplicación para recuperación de desastre? Si llega a existir una interrupción de servicio, podrías transferir el tráfico a esta infraestructura. Una vez que la original se restaure y regrese el tráfico, este ambiente puede eliminarse automáticamente.
¿Cómo funciona?
Esta arquitectura es creada con AWS CloudFormation, un servicio de aprovisionamiento que utiliza infraestructura como código. La ventaja de esta herramienta es que todos los recursos y dependencias se definen en plantillas y se despliegan en pilas, lo cual hace que sea sencillo borrar todo como una sola unidad.
Diagrama de arquitectura
Vamos a enfocarnos en los componentes principales de la arquitectura: Instancia EC2, la Alarma CloudWatch, Regla de EventBridge, la función Lambda y su respectivo IAM Rol, política y permiso. Hay otros recursos triviales que se necesitan como un grupo de seguridad, rol de instancia y perfil de instancia. Estos los vamos a omitir.
La pila de CloudFormation va a crear la siguiente arquitectura:
Esta es la arquitectura en acción:
Ahora si, vamos a entrar de lleno a cada uno de estos elementos! 🤓
Instancia WebServer
Antes que nada, necesitamos una aplicación. Esta será desplegada en una instancia EC2 y puedes configurarla como tu quieras. En este caso, yo la configuré dentro de la sección de UserData.
Esta es la definición del recurso:
"WebServerInstance": {
"Type" : "AWS::EC2::Instance",
"Properties": {
"ImageId" : "ami-0ab4d1e9cf9a1215a",
"InstanceType" : "t3.small",
"KeyName" : "PAR_DE_LLAVES",
"IamInstanceProfile" : "PERFIL_DE_INSTANCIA",
"BlockDeviceMappings" : [
{
"DeviceName" : "/dev/xvda",
"Ebs" : {
"VolumeType" : "gp2",
"VolumeSize" : "25",
"Encrypted" : "true",
"KmsKeyId" : "LLAVE_KMS",
"DeleteOnTermination" : "true"
}
}],
"NetworkInterfaces" : [{
"AssociatePublicIpAddress" : "true",
"DeleteOnTermination" : "true",
"SubnetId" : "ID_DE_SUBRED",
"GroupSet" : ["GRUPO_DE_SEGURIDAD"],
"DeviceIndex" : 0
}],
"UserData" : { "Fn::Base64" : { "Fn::Join" : ["", [
"#!/bin/bash\n",
"CONFIGURACION_DE_APLICACION"
]]}}
}
}
Alarma de inactividad
Basándose en la métrica de la utilización de CPU, podemos saber si la aplicación sigue en uso.
La alarma esta programada para lo siguiente: Una vez que la máxima utilización del CPU llega a estar por debajo del 12% durante 1 hora, la alarma va a detener la instancia.
✏️Nota: El límite establecido para la utilización del CPU debe ser definido acorde a tu aplicación. En mi caso, la aplicación era un dashboard de Splunk, por lo tanto ese límite era lo más adecuado.
Esta es la definición de la alarma:
"MyEC2Alarm": {
"Type": "AWS::CloudWatch::Alarm",
"Properties": {
"AlarmDescription": "Alarm to stop Instance",
"AlarmName": "Inactivity Alarm",
"AlarmActions":
[ "arn:aws:automate:us-east-1:ec2:stop" ],
"MetricName": "CPUUtilization",
"Namespace": "AWS/EC2",
"Statistic": "Maximum",
"Period": "1800",
"Threshold": "3",
"ComparisonOperator": "LessThanOrEqualToThreshold",
"EvaluationPeriods": "2",
"Dimensions": [
{
"Name": "InstanceId",
"Value": { "Ref" : "WebServerInstance" }
}
]
}
}
Regla de EventBridge
La regla de EventBridge va a estar esperando que la aplicación se encuentre en estado detenido, para entonces poder tomar acción. La acción será invocar la función Lambda que contiene el código que eliminará la *pila *de CloudFormation.
"EventRule": {
"DependsOn": ["ADLambda", "WebServerInstance"],
"Type": "AWS::Events::Rule",
"Properties": {
"Description": "EventRule for EC2 Stopping",
"EventPattern": {
"source": [
"aws.ec2"
],
"detail-type": [
"EC2 Instance State-change Notification"
],
"detail": {
"state": [
"stopped"
],
"instance-id": [{
"Ref": "WebServerInstance"
}]
}
},
"State": "ENABLED",
"Targets": [{
"Arn": {"Fn::GetAtt": ["ADLambda", "Arn"] },
"Id": "ADLambda"
}]
}
}
Función Lambda
Una vez que la función sea invocada por la regla, ésta va a correr el código Python que eliminará la pila de CloudFormation... ¿Increíble, no? 🤯
Aquí la definición de la Lambda:
"ADLambda": {
"Type": "AWS::Lambda::Function",
"Properties": {
"Handler": "index.handler",
"Role": {
"Fn::GetAtt": [
"LambdaExecutionRole",
"Arn"
]
},
"Code": {
"ZipFile": "import boto3 \nimport os \nimport json \nstack_name = os.environ['stackName'] \n\ndef delete_cfn(stack_name):\n try:\n cfn = boto3.resource('cloudformation')\n stack = cfn.Stack(stack_name)\n stack.delete()\n return \"SUCCESS\"\n except:\n return \"ERROR\" \ndef handler(event, context):\n print(\"Received event:\")\n print(json.dumps(event))\n return delete_cfn(stack_name)"
},
"Environment": {
"Variables": {
"stackName": {
"Ref" : "AWS::StackName"
}
}
},
"Runtime": "python3.9"
}
}
Código Python
Este es el código que se encuentra en la línea “ZipFile” de la sección anterior.
import boto3
import os
import json
stack_name = os.environ['stackName']
def delete_cfn(stack_name):
try:
cfn = boto3.resource('cloudformation')
stack = cfn.Stack(stack_name)
stack.delete()
return "SUCCESS"
except:
return "ERROR"
def handler(event, context):
print("Received event:")
print(json.dumps(event))
return delete_cfn(stack_name)
Para que la función Lambda pueda funcionar, se necesita un rol, una política y un recurso de permiso. El IAM rol y la política van a permitir que la función pueda borrar la pila. Por otra parte, el permiso de Lambda será el que permitirá que la regla EventBridge pueda invocarla.
Rol de Lambda
Aquel IAM rol que permitirá que la función borre los recursos de la pila, justo como lo establece la política.
"LambdaExecutionRole": {
"Type": "AWS::IAM::Role",
"DeletionPolicy": "Retain",
"Properties": {
"AssumeRolePolicyDocument": {
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": ["lambda.amazonaws.com"]
},
"Action": ["sts:AssumeRole"]
}
]
},
"Path": "/"
}
}
Política de Lambda
Esta es la política con los permisos para eliminar cada recurso que la pila aprovisionó.
✏️Nota: No olvides agregarle cualquier recurso extra que despliegues.
"LambdaExecutionPolicy": {
"Type": "AWS::IAM::Policy",
"DeletionPolicy": "Retain",
"Properties": {
"PolicyName": "autodestruction-policy",
"PolicyDocument": {
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["logs:"],
"Resource": "arn:aws:logs:::"
},
{
"Effect": "Allow",
"Action": [ "cloudformation:DeleteStack" ],
"Resource": {
"Ref": "AWS::StackId"
}},
{
"Effect": "Allow",
"Action": [ "lambda:DeleteFunction" ],
"Resource": ""
},
{
"Effect": "Allow",
"Action": [ "events:RemoveTargets" ],
"Resource": ""
},
{
"Effect": "Allow",
"Action": [ "events:DeleteRule" ],
"Resource": ""
},
{
"Effect": "Allow",
"Action": [ "lambda:RemovePermission" ],
"Resource": ""
},
{
"Effect": "Allow",
"Action": ["iam:DeleteRolePolicy","iam:DeleteRole"],
"Resource": ""
},
{
"Effect": "Allow",
"Action": [ "ec2:TerminateInstances" ],
"Resource": [{ "Fn::Join": ["", [
"arn:aws:ec2:",{"Ref": "AWS::Region"},":",
{"Ref": "AWS::AccountId"}, ":instance/",
{"Ref": "WebServerInstance"}]]}]
},
{
"Effect": "Allow",
"Action": [ "iam:DeleteRolePolicy" ],
"Resource": ""
},
{
"Effect": "Allow",
"Action": [ "cloudwatch:DeleteAlarms" ],
"Resource": [{"Fn::GetAtt" : ["MyEC2Alarm","Arn"]}]
}
]
},
"Roles": [{
"Ref" : "LambdaExecutionRole"
}]
}
}
Permiso para Lambda
Es el recurso que le va a permitir a la regla EventBridge invocar la función.
"PermissionForADLambda": {
"Type": "AWS::Lambda::Permission",
"Properties": {
"FunctionName": {
"Ref": "ADLambda"
},
"Action": "lambda:InvokeFunction",
"Principal": "events.amazonaws.com",
"SourceArn": {
"Fn::GetAtt": [
"EventRule",
"Arn"
]
}
}
}
Ahora aquí viene lo interesante…
La función Lambda no puede eliminar toda la pila porque estaría borrando la política Lambda (la que tiene los permisos para borrar) y el rol Lambda (el que ejecuta esas política). Si los borramos, entonces ¿cómo se podría terminar la tarea? No puede auto eliminarse y seguir continuando con lo que le pidió.
Incluso agregando dependencias para alterar el orden de eliminación, eventualmente se llega al punto en donde se tienen que eliminar ese rol y esa política. Es por eso que estos dos recursos se separan de la destrucción con el parámetro de DeletionPolicy = Retain.
Se lo que están pensando… “Ana, esto ya no es una arquitectura que se autodestruye por completo 🤔”. Bueno, ¡Esto es lo más cercano que pude llegar! Y la ventaja es que ese rol y esa política no generan costos, asi que aún asi ¡estas ahorrando!
💡Fun fact: Estuve varias semanas tratando de encontrar una manera de que esta arquitectura funcionara, hasta que fui al AWS Summit Mexico City y le expliqué esto a un Arquitecto AWS (en la sala “Pregunta a los Expertos”). ¡El fue el que me iluminó con la idea de la retención de recursos!
Asi es como se debe de ver CloudFormation una vez que todo se ha creado:
Ahora lo único queda es dejar de utilizar esa aplicación y esperar…⏰
Asi que anímate y despliega esta arquitectura, abre tu aplicación y luego deja de utilizarla por unas horas. La utilización del CPU bajará y eventualmente comenzará a eliminarse. Créame, es bellísimo ver como todo se va eliminando automáticamente.🥲
Conclusión
Crear una arquitectura que se destruye automáticamente al dejarla de utilizar, es una solución que puedes implementar en tus proyectos para ahorrar gastos, incrementar la eficiencia de la aplicación, reducir la complejidad e incluso recuperarte en el evento de un desastre.
Te invito a probarla, romper esta arquitectura y regresar con nuevas soluciones. ¡Me encantaría escuchar tu retroalimentación o las mejoras que encuentres! 🔍
👩💻¡Sigamos construyendo!
Top comments (6)
Es una buena idea para ambientes de pruebas, ambientes de desarrollo. Que dado un umbral de uso ya no se necesitan y hacer un deploy nuevamente no importaría esperar hasta que quede ready. Buen post y súper recomendable para quien no se anima a crear cosas por miedo a que quedaran para siempre arriba
De acuerdo contigo Hector 🤟
Estaría increible que utilizaras el hashtag #spanish
¡Agregado! 😉
Genial. Que buena idea
Muy buena idea! :)