Ya sabes que una función Lambda se ejecuta cuando ocurre un evento (subcapítulo 14.1). Pero ¿qué eventos? ¿Quién «llama» a la función? Eso lo definen los triggers (disparadores): las fuentes que invocan tu Lambda. En este subcapítulo veremos los más importantes y cómo abren la puerta a un montón de arquitecturas.

Qué es un trigger

Un trigger (disparador) es lo que hace que tu función se ejecute. Tú conectas una fuente de eventos a tu Lambda, y cada vez que esa fuente genera un evento, AWS invoca tu función automáticamente, pasándole los datos del evento.

   Fuente de eventos   ──(evento)──►   Lambda se ejecuta
   (API, S3, cola...)

Una misma función puede tener uno o varios triggers. Veamos los cuatro más comunes.

  1. API Gateway: convertir tu Lambda en una API web

API Gateway permite que tu Lambda responda a peticiones HTTP, igual que una API web normal. Es la forma de crear backends y APIs serverless.

Usuario / app móvil
      │ HTTP (GET /productos)
      ▼
  API Gateway  ──invoca──►  Lambda  ──► consulta datos ──► responde JSON

Ejemplo del mundo real: una app móvil necesita un backend que devuelva la lista de productos. En vez de montar un servidor siempre encendido (EC2), pones API Gateway + Lambda: cuando la app hace GET /productos, API Gateway invoca tu Lambda, que devuelve los datos. Si nadie usa la app de noche, no pagas nada. Si de día la usan miles, escala solo.

Este es uno de los patrones serverless más populares, y la base del proyecto del blog serverless que veremos en el Capítulo 33.

  1. S3: reaccionar a archivos subidos

Recuerda S3, el almacenamiento de objetos (Capítulo 5). Puedes configurar un bucket para que cada vez que se sube (o borra) un archivo, dispare una Lambda.

Usuario sube una foto a S3
      │
      ▼
  S3 dispara ──► Lambda ──► genera una miniatura / la analiza / la procesa

Ejemplo clásico: una web donde los usuarios suben fotos. Cuando una imagen llega al bucket de S3, se dispara una Lambda que crea automáticamente una miniatura (versión pequeña) y la guarda. El usuario no espera: la foto se procesa «sola» en segundo plano. Otros usos: convertir formatos, extraer texto, escanear en busca de virus, etc.

  1. DynamoDB Streams: reaccionar a cambios en la base de datos

Recuerda DynamoDB (subcapítulo 8.3). Un DynamoDB Stream es un «registro de cambios» de la tabla: cada vez que se crea, modifica o borra un elemento, puede disparar una Lambda con el detalle del cambio.

Se inserta un pedido en la tabla DynamoDB
      │
      ▼
  DynamoDB Stream dispara ──► Lambda ──► envía email de confirmación,
                                          actualiza estadísticas...

Ejemplo: en una tienda, cuando se inserta un nuevo pedido en la tabla Pedidos, el stream dispara una Lambda que envía un email de confirmación al cliente y actualiza un panel de ventas. La base de datos «avisa» de sus propios cambios, y la lógica reacciona automáticamente.

  1. SQS: procesar mensajes de una cola

Recuerda las colas (las veremos a fondo en el Capítulo 15). Una cola SQS acumula mensajes (tareas pendientes), y una Lambda puede ir procesándolos uno a uno o en lotes.

Tareas se acumulan en la cola SQS
   [tarea] [tarea] [tarea] [tarea]
      │
      ▼
  SQS dispara ──► Lambda ──► procesa cada tarea (a su ritmo)

Ejemplo: una tienda recibe miles de pedidos en una avalancha (Black Friday). En vez de procesarlos todos de golpe y saturarse, los mete en una cola SQS. Una Lambda los va sacando y procesando a un ritmo sostenible. La cola actúa de «amortiguador» (lo veremos como desacoplamiento en el Capítulo 15).

Tabla resumen de triggers

Trigger Se dispara cuando... Caso de uso típico
API Gateway Llega una petición HTTP APIs y backends serverless
S3 Se sube/borra un archivo Procesar imágenes, archivos
DynamoDB Streams Cambia un dato en la tabla Reaccionar a cambios (emails, stats)
SQS Hay mensajes en la cola Procesar tareas en segundo plano

Y hay muchos más: CloudWatch (tareas programadas tipo «cada noche a las 2:00»), SNS (notificaciones), EventBridge (eventos del sistema, Capítulo 15), Kinesis (streaming de datos, Capítulo 29), etc.

La idea poderosa: arquitecturas dirigidas por eventos

Lo importante de los triggers es el patrón que habilitan: las arquitecturas dirigidas por eventos (event-driven). En vez de un gran programa monolítico que lo hace todo, tienes pequeñas funciones que reaccionan a eventos:

Sube foto → Lambda crea miniatura
Nuevo pedido → Lambda envía email
Mensaje en cola → Lambda procesa la tarea
Llega petición HTTP → Lambda responde

Cada pieza es pequeña, independiente y se ejecuta solo cuando hace falta. Esto hace los sistemas más flexibles, desacoplados y baratos. Profundizaremos en estos patrones en los Capítulos 15 y 28.

Lo que debes recordar

  • Un trigger (disparador) es la fuente que invoca tu Lambda cuando ocurre un evento; conectas la fuente y AWS llama a tu función automáticamente.
  • API Gateway: peticiones HTTP → tu Lambda actúa como API/backend serverless.
  • S3: un archivo subido → procesar imágenes, convertir formatos, escanear...
  • DynamoDB Streams: un cambio en la base de datos → reaccionar (emails, estadísticas).
  • SQS: mensajes en una cola → procesar tareas en segundo plano a un ritmo sostenible.
  • Los triggers habilitan las arquitecturas dirigidas por eventos: pequeñas funciones que reaccionan a eventos, más flexibles y baratas que un monolito.

En el siguiente subcapítulo veremos un aspecto práctico clave: cómo gestionar las dependencias (librerías) de tu función y reutilizar código con las capas (Layers).

Cloud, AWS & Terraform — De cero a experto

Capítulo 1 · Qué es el cloud computing

Capítulo 2 · El mercado cloud y los grandes proveedores

Capítulo 3 · Regiones, zonas de disponibilidad y edge

Capítulo 4 · Cómputo: EC2

Capítulo 5 · Almacenamiento: S3

Capítulo 6 · Redes: VPC

Capítulo 7 · Identidad y acceso: IAM

Capítulo 8 · Bases de datos gestionadas

Capítulo 9 · Por qué Infraestructura como Código

Capítulo 10 · HCL: el lenguaje de Terraform

Capítulo 11 · Providers y estado

Capítulo 12 · Tu primera infraestructura real en Terraform

Capítulo 13 · Balanceo de carga y autoescalado

Capítulo 14 · Serverless con Lambda

Capítulo 15 · Mensajería y eventos

Capítulo 16 · Entrega de contenido y DNS

Capítulo 17 · Contenedores en AWS

Capítulo 18 · Módulos: reutilización y composición

Capítulo 19 · Workspaces y gestión de entornos

Capítulo 20 · Backends remotos y locking

Capítulo 21 · Testing de infraestructura

Capítulo 22 · Terraform en CI/CD

Capítulo 23 · Seguridad en profundidad

Capítulo 24 · Observabilidad: logs, métricas y trazas

Capítulo 25 · Optimización de costes

Capítulo 26 · Alta disponibilidad y disaster recovery

Capítulo 27 · Well-Architected Framework de AWS

Capítulo 28 · Arquitecturas serverless a escala

Capítulo 29 · Plataformas de datos en AWS

Capítulo 30 · Multi-cuenta y landing zones

Capítulo 31 · Platform Engineering e Internal Developer Platform

Capítulo 32 · Certificaciones AWS relevantes

Capítulo 33 · Proyectos para consolidar lo aprendido

Capítulo 34 · Recursos y comunidad

© Copyright 2024. Todos los derechos reservados