📖Capítulo 9: Lambda + S3 : Mover objetos-Parte 2 ⚡

1 jun
3 min de lectura

Continuando con este proyecto orientado a eventos utilizando Amazon S3 y AWS Lambda, comenzaremos por uno de los componentes más importantes de toda la arquitectura:

👉 la definición explícita de permisos mediante Infrastructure as Code.

El primer template desarrollado corresponde a: template-iam.yml Y aunque visualmente puede parecer un componente secundario, realmente representa la base de todo el proyecto. Porque antes de que Lambda pueda interactuar con S3, registrar logs o ejecutar cualquier acción, primero necesita permisos correctamente definidos.

🧠 Lo que la consola hace por nosotros

Si observamos el flujo tradicional desde la consola de AWS, normalmente el proceso luce bastante sencillo:

Crear Lambda ↓ Cargar código ↓ Configurar Trigger S3 ↓ Probar funcionamiento

Y aparentemente todo funciona...

Sin embargo, internamente AWS realiza múltiples acciones que normalmente permanecen ocultas para el usuario. Por ejemplo:

crea un rol IAM,
configura permisos para CloudWatch Logs,
genera relaciones de confianza,
asocia políticas necesarias,
vincula permisos con la función Lambda.

Todo esto ocurre automáticamente detrás de la interfaz gráfica. Y precisamente aquí aparece una de las principales ventajas de Infrastructure as Code:

nos obliga a comprender qué recursos realmente hacen posible la arquitectura.

📋 Política N.° 1 — CloudWatch Logs

La primera política personalizada creada dentro del template es:

PoliticaPersonalizada-LambdaExecution-CloudWatchLogs

Su objetivo es permitir que AWS Lambda pueda registrar información dentro de CloudWatch Logs.

Gracias a ello podremos:

visualizar ejecuciones,
analizar errores,
validar eventos recibidos desde S3,
monitorear comportamiento,
realizar debugging.

Sin esta política, Lambda podría ejecutarse correctamente, pero perderíamos gran parte de la visibilidad necesaria para operar la solución.

🔄 De JSON a YAML: pensando en IaC

Las políticas IAM suelen encontrarse documentadas en formato JSON. Sin embargo, al trabajar con CloudFormation normalmente utilizamos YAML. Por ello, una práctica habitual consiste en adaptar dichas definiciones al formato utilizado por nuestros templates.

Pero más allá del formato, el aprendizaje más importante consiste en comprender:

qué permisos estamos otorgando,
por qué son necesarios,
y qué impacto tienen dentro de la arquitectura.

Porque Infrastructure as Code no debería convertirse en una actividad de copiar y pegar configuraciones. La verdadera ventaja aparece cuando comprendemos el propósito de cada permiso definido.

🪣 Política N.° 2 — Acceso de Lambda a S3

La segunda política personalizada creada dentro del template es:

PoliticaPersonalizada-LambdaExecution-S3

Esta política permitirá que la función Lambda pueda interactuar con los buckets utilizados por el proyecto. Recordemos el flujo principal:

Bucket Origen ↓ Evento S3 ↓ Lambda ↓ Bucket Destino

Para que esto funcione correctamente, Lambda requiere permisos explícitos sobre ambos buckets.

Entre ellos:

lectura de objetos,
obtención de metadatos,
copia de archivos,
eliminación de objetos (si se implementa un movimiento completo).

Y esto nos acerca mucho más al principio de mínimo privilegio. Es decir:

otorgar únicamente los permisos estrictamente necesarios para realizar una tarea.

👤 Creación del rol IAM

Una vez definidas ambas políticas, podemos construir el componente final del template:

👉 el rol IAM.

Este rol será asumido posteriormente por AWS Lambda y tendrá asociadas las políticas creadas previamente. Conceptualmente:

Política CloudWatch Logs + Política Acceso S3 ↓ Rol IAM ↓ AWS Lambda

Este enfoque nos permite construir una arquitectura más controlada, auditable y mantenible.

⚖️ Consola AWS vs Infrastructure as Code

Una forma sencilla de visualizar la diferencia es la siguiente.

Desde la consola de administración (UI)

Paso 1: Crear Lambda.

Paso 2:

AWS crea automáticamente:

rol IAM,
permisos CloudWatch,
asociaciones internas.

Paso 3:

Agregar permisos adicionales para S3.

Desde Infraestructura como Código

Paso 1:

Definir políticas IAM.

CloudWatch Logs
Acceso S3

Paso 2:

Crear explícitamente el rol IAM.

Paso 3:

Asociar las políticas al rol.

Paso 4:

Utilizar dicho rol dentro de la Lambda Function.

🚀 Conclusión

Este template representa perfectamente una de las principales ventajas de Infrastructure as Code.

Mientras que la consola abstrae gran parte de la complejidad, CloudFormation nos obliga a comprender los componentes reales que participan en la arquitectura.

Al finalizar este despliegue obtenemos:

✅ Políticas IAM personalizadas.

✅ Un rol IAM completamente controlado.

✅ Aplicación explícita del principio de mínimo privilegio.

✅ Mayor trazabilidad.

✅ Mejor gobernanza sobre permisos.

Y, sobre todo, una comprensión mucho más profunda de cómo AWS construye realmente sus servicios detrás de la interfaz gráfica. Porque muchas veces el verdadero aprendizaje no está en crear recursos, sino, en entender todo lo que ocurre detrás de ellos.