📖Capítulo 10: Lambda + S3 : Mover objetos-Parte 3 ⚡
- 4 jun
- 4 min de lectura
Pues bien, ya tenemos construidas las bases de IAM para nuestro proyecto. Ahora llega el momento de avanzar hacia los componentes que realmente ejecutarán la lógica principal del flujo:
AWS Lambda
Amazon S3
Y aquí aparecen preguntas bastante interesantes:
¿Qué deberíamos construir primero mediante Infrastructure as Code?
¿La Lambda Function?
¿Los buckets S3?
A simple vista parece una decisión sencilla, sin embargo, cuando comenzamos a trabajar con CloudFormation descubrimos que detrás de esta pregunta existen múltiples dependencias entre servicios que normalmente pasan desapercibidas cuando utilizamos la consola de AWS.
🖥️ ¿Cómo se construye desde la consola?
Si observamos el proyecto desde la perspectiva de la consola de administración, normalmente seguiríamos un flujo similar a este:
Paso 1)
Crear los buckets S3.
Bucket origen
Bucket destino
Paso 2).
Crear la Lambda Function, y, durante este proceso AWS realiza automáticamente múltiples tareas:
crea un rol IAM,
configura permisos para CloudWatch Logs,
establece relaciones de confianza,
asocia el rol a la función.
Todo esto ocurre detrás de la interfaz gráfica.
Paso 3).
Configurar el trigger que activará la Lambda. Además, recordemos que una Lambda normalmente posee tres componentes principales:
Trigger ↓ Lambda Function ↓ Destino (Opcional)
En este proyecto:
Evento S3 ↓ Lambda Function ↓ Bucket Destino
Ahora, para configurar este trigger desde la consola debemos indicar:
qué servicio activará la Lambda,
qué bucket utilizará el evento,
qué acciones dispararán la ejecución,
filtros opcionales,
validaciones para evitar ejecuciones recursivas.
Y aquí aparece una dependencia importante, si los buckets aún no existen:
👉 no podremos utilizarlos como origen del trigger.
Paaso 4).
Agregar permisos para que Lambda pueda acceder a S3, y, es aquí donde muchas veces comienzan los problemas. Porque ahora debemos localizar recursos que AWS creó automáticamente y posteriormente modificar sus permisos.
Esto implica:
buscar el rol correcto,
asociar nuevas políticas,
comprender configuraciones generadas por AWS.
Parte de la arquitectura queda oculta detrás de la interfaz gráfica.
🧩 La perspectiva de Infrastructure as Code
Cuando trasladamos esta arquitectura hacia CloudFormation, el enfoque cambia completamente. En lugar de construir visualmente paso por paso, comenzamos a dividir la solución en componentes independientes.
Cada template tiene una responsabilidad específica, y cada servicio pasa a representar una pieza claramente definida dentro del proyecto. Por ello, después del template de IAM, el siguiente componente desarrollado fue:
🚀 La Lambda no es solamente una Lambda
Una de las primeras sorpresas al trabajar con CloudFormation es descubrir que una Lambda no está representada por un único recurso. En este template realmente definimos varios elementos relacionados.
🔹 Recurso N.º 1 — Lambda Function
Este recurso representa la función propiamente dicha.
Aquí definimos:
runtime,
arquitectura,
handler,
timeout,
memoria,
variables necesarias,
rol IAM asociado,
ubicación del código.
Es decir, toda la configuración necesaria para ejecutar la lógica de negocio.
📦 El código no debería vivir dentro del template
Otro aprendizaje importante aparece cuando comenzamos a gestionar el código fuente. Y aunque CloudFormation permite ciertos mecanismos para incorporar código directamente dentro del template, esta práctica deja de ser sostenible rápidamente.
Por ello, una estrategia mucho más mantenible consiste en almacenar los artefactos de despliegue dentro de un bucket dedicado.
Por ejemplo:
Bucket de Artefactos ↓ lambda-move-object.zip ↓ CloudFormation ↓ Lambda Function
Esto aporta varias ventajas:
separación entre infraestructura y código,
despliegues más organizados,
reutilización de artefactos,
mayor mantenibilidad.
Y nuevamente aparece una característica interesante de IaC:
No solamente pensamos en infraestructura, sino, también pensamos en cómo administrar correctamente el ciclo de vida del código.
🔹 Recurso N.º 2 — Permiso de invocación
Existe un segundo recurso que suele pasar completamente desapercibido cuando utilizamos la consola: El trigger visual que conecta S3 con Lambda. Este, también necesita ser representado mediante infraestructura. Y, en CloudFormation se debe definir explícitamente el permiso que permitirá a S3 ejecutar la función.
Conceptualmente:
S3 ↓ Permiso de Invocación ↓ Lambda
Lo que desde la consola parece una simple configuración termina convirtiéndose en un recurso independiente dentro del template. Y justamente ahí es donde comenzamos a comprender mejor cómo AWS construye realmente sus integraciones.
⚠️ ¿Qué ocurre si los buckets todavía no existen?
Aquí aparece una situación bastante interesante: Nuestro trigger necesita referenciar buckets S3. Sin embargo, dichos buckets aún no han sido desplegados, y, si intentamos resolver completamente la integración en este punto, observaremos referencias pendientes o dependencias aún no satisfechas. Pero, esto no significa que la arquitectura esté mal diseñada, sino, simplemente estamos construyendo el proyecto por capas:
Primero:
IAM ↓ Lambda
Posteriormente:
S3 ↓ Eventos ↓ Integración completa
Y finalmente (en el siguiente post):
Evento S3 ↓ Lambda ↓ Bucket Destino
Cuando todos los componentes existan, las referencias quedarán completamente resueltas.
🎯 Lo que realmente aprendímos en este capítulo
Más allá de crear una Lambda Function, este template nos enseña algo mucho más importante. Nos muestra que muchos elementos que parecen simples configuraciones dentro de la consola son realmente recursos independientes que forman parte de la arquitectura.
Lo que desde la UI parece: Agregar Trigger
En Infrastructure as Code se traduce en:
Definir permisos ↓ Crear recursos ↓ Gestionar dependencias ↓ Establecer relaciones entre servicios
Y es precisamente en este punto donde comenzamos a comprender cómo AWS construye realmente sus servicios detrás de la interfaz gráfica. Porque al final, el aprendizaje más valioso no es desplegar una Lambda: Es entender todas las dependencias que hacen posible que esa Lambda funcione correctamente dentro de una arquitectura real.
Comentarios