Construye una arquitectura en AWS que se autodestruye
Tags: tutorial, aws, cloud, spanish
Published: 2023-04-23 21:49:00

¿Te imaginas qué increíble sería poder levantar una aplicación que, en cuanto deje de ser utilizada, se pueda autodestruir sola?! 🤯

![Una gran escena de The Mandalorian](https://cdn-images-1.medium.com/max/2000/1*VSOAzKGb24wT3NgXCUivPw.gif)

*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](https://aws.amazon.com/es/cloudformation/?nc1=h_ls), 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:

![Arquitectura autodestructiva](https://cdn-images-1.medium.com/max/2000/1*vj8hzYhr720yd0PEmLRwag.png)

Esta es la arquitectura en acción:

![Arquitectura autodestructiva una vez que el app no esta en uso](https://cdn-images-1.medium.com/max/2000/1*Ss_itdMP5d4vjuxCJaaPxw.png)

---

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:

![Creación de recursos en CloudFormation](https://cdn-images-1.medium.com/max/2006/1*cwbKWFz_PmWCCIgp4LyLsQ.png)

Ahora lo único queda es dejar de utilizar esa aplicación y esperar…⏰

![Eliminación de recrusos en CloudFormation](https://cdn-images-1.medium.com/max/2062/1*j628wWrKw_WjnzWGtDjhAg.png)

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!