Quizás te ha pasado que quieres trabajar sobre una instancia EC2 de desarrollo, la dejaste encendida más tiempo del que deberías y ahí es cuando el bolsillo comienza a doler, en especial si quieres experimentar con los tipos de instancia más costosos.

También puede suceder que necesites una instancia para un caso concreto; la configuras mediante la consola de AWS y luego vienen los dolores de cabeza de eliminar todo manualmente. Le encuentro muchísimas ventajas a la infraestructura como código, y este me parece un buen caso de uso porque es bastante frecuente y replicable.

Este Stack está pensado para entornos de desarrollo/pruebas y tiene mucha flexibilidad en cuanto al tipo de instancia, almacenamiento, el aislamiento o no de la instancia, horas de apagado y encendido, timezone y si falta algo, siempre es posible realizar modificaciones necesarias y desplegar.

¿Qué se necesita?

• Cuenta de AWS
• Node.js + npm
• Instalar aws CLI
• Configurar las credenciales
• Clonar el repositorio
• Bootstrap del CDK en tu cuenta/región (si no lo tienes configurado)

Una vez cumplidos los prerrequisitos y habiendo instalado las dependencias de npm del proyecto, se puede ejecutar este comando que es el más básico:

cdk deploy

Este comando despliega los valores por defecto (todos pensando en gastos mínimos de prueba, (ej. instancia t2.micro, rootVolume 20GB, etc).

Por defecto, la instancia se encuentra en estado "Running" y las horas de trabajo están agendadas de lunes a viernes de 9 am a 7 pm.

Luego para conectarse a la instancia pueden tomar el id de la instancia y ejecutar:

aws ssm start-session --target <INSTANCE_ID>

Qué es configurable mediante parámetros

• InstanceType: desde una t2.micro (capa gratuita) hasta instancias de cómputo intensivo.
• MachineImage: por defecto usa Amazon Linux 2023, pero permite inyectar cualquier AMI ID específico.
• RootVolumeSize / DataVolumeSize: maneja el almacenamiento de forma separada. Puedes tener un disco de sistema pequeño y un disco de datos grande que se monta automáticamente.
• ScheduleStartCron / ScheduleStopCron: utilizan la sintaxis estándar de cron de AWS. Por defecto, está configurado para horario de oficina (9:00 AM a 7:00 PM).
• Zona horaria: el proyecto está preconfigurado para America/Argentina/Buenos_Aires, ideal para evitar confusiones con el horario UTC.
• AssignPublicIp: por defecto es false. La instancia vive segura en una subred privada.

Ejemplo de un Stack configurado para un caso específico, supongamos una r6i.8xlarge para procesamiento de Big Data:

cdk deploy \
  -c instanceType=r6i.8xlarge \
  -c rootVolumeSize=50 \
  -c dataVolumeSize=500 \
  -c scheduleStartCron="cron(0 13 ? * MON-FRI *)" \
  -c scheduleStopCron="cron(0 21 ? * MON-FRI *)" \
  -c project=big-data-analytics \
  -c environment=staging

Como diría Jack el destripador, vamos por partes:

Para el comando anterior se despliega:

• Una instancia de instanceType r6i.8xlarge
• Esa instancia tiene asociada un volumen EBS "rootVolume" de 50 GB
• Esa instancia tiene asociada un volumen EBS para datos "dataVolumeSize" de 500 GB
• La instancia está programada para iniciar de lunes a viernes a las 13 h (1pm) ART
• La instancia está programada para detenerse de lunes a viernes a las 21 h (9pm) ART
• Por trazabilidad y manejo de costos, el stack tiene los Tags: project=big-data-analytics y environment=staging.

Consideraciones:

• EBS Volume Root, al usarlo, significa que el apagado y el encendido automático son seguros, sin pérdida de información.
• EBS Volumes con Delete on Termination: si eliminas el Stack, se eliminan también los volúmenes EBS. Es algo a considerar porque, dependiendo de la aplicación, podrías querer que el volumen EBS persista aun si borras el stack.
• La Timezone por defecto (si no le pasas el parámetro) de las reglas de EventBridge Scheduler es America/Argentina/Buenos_Aires.

Gracias por haber leído hasta aquí. Ánimense a probar.
¡Todo feedback es bienvenido! Les dejo el enlace al repositorio.