¿Te imaginas qué increíble sería poder levantar una aplicación que, en cuanto deje de ser utilizada, se pueda autodestruir sola?! 🤯
, 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:
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:
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!
SOCIAL SHARE CARD GENERATOR