This content originally appeared on DEV Community and was authored by Pablo Gonzalez Robles
Hola comunidad,
¿Alguna vez te has encontrado con la necesidad de automatizar configuraciones de AWS que CloudFormation no maneja nativamente? Por ejemplo, necesitaba habilitar S3 Block Public Access a nivel de cuenta usando CloudFormation, pero resulta que no existe un tipo de recurso nativo para esto.
¿Entonces qué nos queda por hacer? Ahí es donde entran las Custom Resources de CloudFormation.
En este post les voy a compartir cómo se estructuran los custom resources en cloudformation, y adicional, cómo Kiro me ayudó a estructurar todo el proyecto usando spec-driven development.
En este post estaré cubriendo:
- Qué son los Custom Resources y cuándo usarlos
- Desarrollo del componente usando spec-driven development
- Implementación práctica del custom resource para S3 BPA
- Código real y capturas del funcionamiento
¿Qué son las Custom Resources en CloudFormation?
Las Custom Resources son básicamente una forma de extender CloudFormation cuando necesitas hacer algo que los tipos de recursos nativos no pueden manejar, como lógica o parametrizaciones en los servicios, que no es realmente el despliegue de un recurso. Funcionan mediante una función Lambda que CloudFormation invoca durante las operaciones de CREATE, UPDATE y DELETE del stack (si así lo deseamos aunque puedes elegir solo una o dos acciones). Acá puedes leer la documentación oficial de AWS: https://docs.aws.amazon.com/es_es/AWSCloudFormation/latest/TemplateReference/aws-resource-cloudformation-customresource.html
En mi caso específico, necesitaba:
- Consultar y habilitar el Bloqueo de Acceso Público (Block Public Access – BPA) a nivel de cuenta en el servicio de S3
- Enviar una notificación del cambio ejecutado
Desarrollo guiado a través de especificaciones (Spec-driven development)
Aquí es donde Kiro (https://kiro.dev/) realmente brilló. En lugar de pedirme un prompt para ponerse directamente a escribir el código de python y la plantilla de cloudformation, me guió a través de un proceso estructurado que nunca había usado antes con los agentes de inteligencia aritificial. Antes, yo ño más que hacía era crearme un archivo .txt o .md donde listaba los requisitos y le decía al agente que se guiara de ese documento para desarrollar el proyecto pero en la mayoría de los casos, tocaba hacer mucho refinamiento lo cual consume tiempo y especialmente, requests/tokens que pueden llegar a costar dinero.
Nota: Te dejo por acá el post donde compartí mi primera experiencia usando Kiro: https://dev.to/pangoro24/mi-experiencia-con-kiro-59k7.
Para este caso específico y siguiendo el spec-driven development, el proyecto se trabaja de la siguiente manera:
Paso 1: Definición de requerimientos
Kiro me ayudó a estructurar los requerimientos de manera clara:
- Habilitar S3 Block Public Access a nivel de cuenta
- Manejar operaciones CREATE, UPDATE y DELETE
- Enviar notificaciones opcionales via SNS
- Implementar manejo de errores robusto
Paso 2: Diseño de la implementación
Luego trabajamos en el diseño técnico:
- Custom Resource que invoca una función Lambda
- Función Lambda con lógica para consultar y aplicar configuraciones
- Plantilla CloudFormation con todos los recursos necesarios
- Pruebas unitarias para validar la lógica
Paso 3: Ejecución de las tareas
Finalmente, Kiro me ayudó a implementar cada componente paso a paso, siempre validando que el código funcionara antes de continuar.
¿Cómo funciona el Custom Resource?
El flujo es bastante directo:
- Despliegue: CloudFormation crea el stack e invoca la función Lambda con el evento CREATE
- Evaluación: La Lambda consulta la configuración actual de S3 BPA usando boto3
- Aplicación: Si BPA no está habilitado, la función lo configura automáticamente
- Notificación: Desde la lambda se envía un mensaje SNS con el resultado de la ejecución
- Respuesta: La Lambda responde a CloudFormation con SUCCESS o FAILED
Implementación práctica
Es cierto que, con un solo prompt bien definido, la mayoría de los modelos de inteligencia artificial habrían generado la plantilla y el código necesarios, por lo que usar aquí la metodología de desarrollo dirigido por especificaciones podría parecer “over-engineering”. Sin embargo, al ser mi primer proyecto desde cero con Kiro, quise probarlo primero en un demo sencillo antes de avanzar hacia algo más complejo.
¿Dónde puedo ver el código completo?
He subido la implementación completa a GitHub, incluyendo:
- Plantilla de CloudFormation completa
- Código de la función Lambda con tests
- Resumen del proyecto
- Documentos refinados para el desarrollo guiado por especificaciones para este proyecto (requirements.md, design.md, tasks.md)
Repositorio: https://github.com/pangoro24/aws-cloudformation-custom-resource-bpa-account/
Conclusión
Los Custom Resources son una herramienta poderosa cuando necesitas extender CloudFormation más allá de sus capacidades nativas y cuando los cambios en la cuenta deben realizarse por infraestructura como código.
Por otro lado, usar spec-driven development con Kiro realmente cambió mi forma de abordar proyectos y voy a probar en un proyecto más complejo la próxima vez.
¿Has usado Custom Resources en tus proyectos? ¿Te gustaría que profundice en algún aspecto específico o que cubra otros casos de uso? Déjamelo saber en los comentarios.
Gracias por leer.
This content originally appeared on DEV Community and was authored by Pablo Gonzalez Robles