📖Capítulo 11: Lambda + S3 : Mover objetos-Parte 4 ⚡

8 jun
4 min de lectura

Pues bien, ya hemos construido los cimientos de nuestro proyecto. Y, hasta este punto:

✅ Definimos roles y políticas IAM aplicando explícitamente el principio de mínimo privilegio.
✅ Creamos la Lambda Function junto con los permisos necesarios para su ejecución.
✅ Configuramos el mecanismo que permitirá a S3 invocar la función.

Sin embargo, todavía existía una pieza pendiente dentro de la arquitectura. Y curiosamente, es una de las configuraciones que suele parecer más simple cuando trabajamos desde la consola de AWS. Pero como ya hemos visto durante este proyecto, Infrastructure as Code tiene una forma muy particular de mostrarnos qué ocurre realmente detrás de la interfaz gráfica.

🤔 El pequeño error que dejamos pendiente

Durante la construcción del template de Lambda apareció una situación bastante interesante:

La función lambda estaba correctamente definida e incluso los permisos y el mecanismo de invocación ya estaba preparado. Sin embargo, existía un problema: el bucket de origen aún no había sido creado.
Como consecuencia, la integración completa entre Amazon S3 y AWS Lambda todavía no podía resolverse completamente. A simple vista podría parecer un error.
Sin embargo, realmente se trataba de una dependencia pendiente dentro de la arquitectura. Y es precisamente aquí donde entra en juego nuestro último template: template-s3.yml

🧩 El template que completa la arquitectura

Este template tiene una responsabilidad mucho mayor que simplemente crear buckets. Es decir, adicionalmente a definir recursos de almacenamiento, también establece la configuración necesaria para que Amazon S3 pueda generar eventos y comunicarse con otros servicios AWS.

En este caso definimos:

Bucket origen.
Bucket destino.
Configuración de eventos.
Asociación con AWS Lambda.

Y gracias a ello desaparece la dependencia pendiente que observábamos en el template anterior.

⚡ Amazon S3 como generador de eventos

Uno de los aprendizajes más interesantes de este proyecto fue comprender que S3 no es únicamente almacenamiento. Sino, que puede actuar como un servicio orientado a eventos. Es decir, cada vez que ocurre una acción sobre un objeto, S3 puede reaccionar automáticamente.

Por ejemplo:

Creación de objetos.
Eliminación de objetos.
Restauraciones.
Operaciones sobre versiones.
Replicaciones.

Y dichos eventos pueden integrarse con distintos destinos dentro de AWS. Por ejemplo:

Evento S3 -> Amazon SNS
Evento S3 -> Amazon SQS
Evento S3 -> AWS Lambda

Para este proyecto elegimos Lambda porque nos permite ejecutar lógica personalizada para mover automáticamente archivos entre buckets.

🖥️ La diferencia entre UI e IaC

Cuando configuramos esta integración desde la consola normalmente seguimos un flujo muy simple.

Lambda ↓ Agregar Trigger ↓ Seleccionar Bucket ↓ Configurar Evento

Visualmente resulta muy intuitivo. Pero Infrastructure as Code nos obliga a observar la integración desde una perspectiva diferente.

🔄 La integración se construye desde ambos lados

Una de las lecciones más importantes de este capítulo es comprender que la integración no pertenece únicamente a Lambda y tampoco pertenece únicamente a S3. Sino, La integración se construye desde ambos servicios. Por ello encontramos configuraciones distribuidas entre distintos templates.

En template-lambda.yml

Definimos:

Lambda Function.
Permisos de invocación.
Relación de confianza.
Asociación con IAM.

En template-s3.yml

Definimos:

Bucket origen.
Bucket destino.
Eventos del bucket origen.
Notificación hacia Lambda.

Cuando ambas piezas existen, la arquitectura queda completamente conectada.

🎯 ¿Por qué construir primero IAM y Lambda?

Durante el diseño del proyecto decidí construir los recursos siguiendo el siguiente orden:

IAM ↓ Lambda ↓ S3

La razón principal fue mantener las dependencias lo más claras posible:

Primero definimos quién tendrá permisos.
Después definimos quién ejecutará la lógica.
Y finalmente definimos quién generará los eventos.

De esta forma la evolución de la arquitectura resulta mucho más sencilla de comprender.

🏗️ Resultado final

Una vez desplegados los tres templates obtenemos la arquitectura completa:

Bucket Origen ↓ Evento PUT (.csv) ↓ AWS Lambda ↓ Bucket Destino

Todo ello construido mediante:

Roles IAM personalizados.
Políticas explícitas.
Eventos definidos como código.
Recursos reproducibles.
Infraestructura versionada.

🚀 Despliegue del Proyecto

Una vez construidos los tres templates del proyecto, el siguiente paso consiste en desplegar la infraestructura en AWS. Para ello continuamos utilizando AWS CLI como mecanismo de despliegue desde nuestro entorno local hacia la nube, manteniendo un enfoque completamente alineado con los principios de Infrastructure as Code (IaC).

Además, para simplificar el proceso operativo, el despliegue fue automatizado mediante un único script encargado de ejecutar secuencialmente:

template-iam.yml ↓ template-lambda.yml ↓ template-s3.yml

Siguiendo el mismo orden lógico utilizado durante el diseño de la arquitectura y garantizando que las dependencias entre recursos se resuelvan correctamente. Al finalizar la ejecución obtenemos una infraestructura completamente funcional que incluye:

Políticas y roles IAM.
AWS Lambda.
Buckets S3.
Eventos de S3.
Integración completa entre S3 y Lambda.

Y lo más importante:

Toda la arquitectura puede desplegarse nuevamente en cuestión de minutos utilizando únicamente código y un único comando de ejecución.

🚀 Más allá de mover archivos

Aunque funcionalmente este laboratorio consiste en mover objetos entre buckets, el verdadero aprendizaje va mucho más allá. Durante este proyecto pudimos comprender:

Cómo funcionan los eventos en Amazon S3.
Cómo Lambda recibe permisos para ejecutarse.
Cómo se construyen integraciones entre servicios.
Cómo resolver dependencias mediante CloudFormation.
Cómo trasladar configuraciones visuales hacia Infrastructure as Code.

Y precisamente ahí está el valor real de este tipo de proyectos, donde no se trata únicamente de desplegar recursos. Se trata de comprender cómo interactúan los servicios detrás de cada clic que realizamos dentro de la consola de AWS.

🔥 Próximo destino: Networking

Con este proyecto cerramos una nueva etapa dentro de la serie de proyectos prácticos de Infrastructure as Code. Hemos trabajado con:

IAM
AWS Lambda
Amazon S3
Eventos
Arquitecturas serverless

Y en el siguiente proyecto comenzaremos a explorar uno de los pilares fundamentales de cualquier arquitectura cloud: Networking.

Porque si los servicios representan los componentes de una solución, la red representa el tejido que permite que todos ellos se comuniquen correctamente.