Después de terminar un proyecto tradicional de tres capas en AWS decidí construir algo distinto para mi portafolio: más serverless, orientado a eventos y con componentes totalmente desacoplados. El objetivo fue probar el patrón fan out con SQS donde un único evento dispara múltiples acciones, y hacerlo todo desde un enfoque security first. El resultado fue un Pipeline de Pedidos Serverless que implementé con Lambda, SNS y SQS y que aprovecha buenas prácticas de red privada y control de acceso.
Arquitectura general: una Application Load Balancer público recibe solicitudes POST en /orders y las dirige a una Lambda que actúa como Publisher. Esa Lambda valida la petición y la publica en un tópico SNS. El tópico SNS hace fan out a varias colas SQS, por ejemplo billing y archive. Consumidores independientes, cada uno en su propia Lambda, procesan las colas: la Lambda de billing escribe en DynamoDB y la de archive guarda una copia JSON en S3. Todo corre dentro de una VPC con subredes públicas para el ALB y subredes privadas para las Lambdas. Las funciones no tienen acceso a internet y consumen servicios AWS a través de endpoints VPC.
Patrón fan out: un request pasa por SNS y se duplica hacia múltiples colas, permitiendo que cada consumidor sea independiente y escale según su propia carga. Esto mejora la resiliencia y facilita la extensión del sistema con nuevos consumidores sin tocar el flujo existente.
Seguridad desde el inicio: añadí autenticación en la Lambda Publisher. Las peticiones deben incluir cabeceras X-Client-Id y X-Signature. La Lambda valida esas cabeceras frente a un secreto gestionado por la configuración de entorno o un gestor de secretos para producción. Si la validación falla la función responde 401 Unauthorized. Con esto se evita que clientes no autorizados inyecten mensajes en la tubería.
Control de permisos: cada Lambda tiene su propio role IAM con permisos mínimos necesarios. Por ejemplo la Publisher solo recibe sns:Publish; la Billing tiene permisos para recibir y borrar mensajes de SQS y para put en DynamoDB; la Archive recibe y borra mensajes y pone objetos en S3. No existe un rol compartido con privilegios excesivos.
Políticas de recursos: cada cola SQS acepta mensajes únicamente del tópico SNS correspondiente mediante políticas de cola. Opcionalmente se pueden añadir condiciones que aten la fuente a un endpoint VPC usando aws:SourceVpce para evitar accesos directos desde fuera del sistema.
Red y seguridad: aprendí que las Lambdas no necesitan reglas de entrada en los security groups porque el ALB no se conecta por la red a la función sino que invoca a través del control plane de AWS. El security group influye en el tráfico saliente hacia DynamoDB, SNS o CloudWatch. Para mantener todo privado configuré endpoints VPC: endpoints de gateway para S3 y DynamoDB y endpoints de interfaz para SNS, SQS y CloudWatch Logs. De esta forma no se requieren NAT Gateways ni acceso público a internet.
Observabilidad: todas las Lambdas escriben en CloudWatch Logs y configuré métricas y alertas clave: errores de Lambda, profundidad de colas SQS, DLQ depth y 5XX del ALB. Estas señales son suficientes para detectar degradaciones y actuar antes de que el problema se propague.
Lecciones aprendidas: los security groups de Lambda se comportan distinto a instancias EC2; empaquetar funciones con Terraform requiere disciplina para mantener artefactos limpios; pensar security first desde el diseño ahorra retrabajo; el desacoplo real funciona: si un consumidor falla los demás siguen operando; y la combinación SQS más Lambda soporta picos de carga de manera eficiente frente a arquitecturas tradicionales.
Implementación con Terraform: organicé el código en carpetas para mantener claridad y aplicar por capas: infra network para VPC, subredes, rutas, SGs y endpoints; data para DynamoDB y bucket S3; messaging para SNS, SQS, DLQs y políticas; iam para roles y policies; compute para Lambdas y event source mappings; frontend para ALB y reglas; observability para alarmas CloudWatch. El orden de despliegue fue network, data, messaging, iam, compute, frontend y finalmente observability para garantizar dependencias resueltas.
En Q2BSTUDIO somos una empresa de desarrollo de software y aplicaciones a medida especializada en soluciones cloud y seguridad. Si te interesa cómo adaptar este tipo de arquitectura a proyectos reales o necesitas servicios cloud aws y azure podemos ayudarte a diseñar e implementar pipelines serverless seguros y escalables. Con experiencia en software a medida, inteligencia artificial y ciberseguridad entregamos soluciones integrales que incluyen desde agentes IA hasta visualización con power bi. Conoce más sobre nuestro enfoque para desplegar soluciones cloud en Servicios cloud AWS y Azure y sobre desarrollo de aplicaciones a medida en aplicaciones a medida y software a medida.
Resumen final: este Pipeline de Pedidos Serverless demuestra cómo combinar Lambdas, SNS y SQS con una estrategia security first y una red privada para construir sistemas escalables y resilientes. Si buscas integrar inteligencia artificial, servicios inteligencia de negocio o automatizar procesos con soluciones a medida, en Q2BSTUDIO podemos acelerar tu proyecto y asegurar su diseño desde la red hasta las políticas IAM.
