The latest articles on DEV Community by Steven Fernández (@auztinorix). https://dev.to/auztinorix https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F1347402%2F90f5abc4-d913-4fbb-b7e4-b75f032a53d4.png https://dev.to/auztinorix en Steven Fernández Tue, 13 Jan 2026 22:15:25 +0000 https://dev.to/auztinorix/implementando-el-patron-sns-sqs-fan-out-en-aws-con-terraform-1i24 https://dev.to/auztinorix/implementando-el-patron-sns-sqs-fan-out-en-aws-con-terraform-1i24 <h2> Introducción </h2> <p>Desde hace mucho tiempo tuve la intención de comenzar a <strong>aportar activamente a la comunidad tecnológica</strong>, especialmente a la comunidad de AWS, como una forma de retribuir el <strong>valioso apoyo, conocimiento y experiencias</strong> que muchos profesionales comparten día a día.</p> <p>Este artículo y el repositorio que lo acompaña nacen con ese objetivo: compartir una implementación clara y reusable del patrón <strong>SNS → SQS Fan-out en AWS</strong>, utilizando <strong>Terraform como Infrastructure as Code (IaC)</strong>, y dejarla disponible para que otros puedan aprender, reutilizarla o mejorarla.</p> <h2> ¿Por qué el patrón Fan-out es importante? </h2> <p>En arquitecturas modernas orientadas a eventos, uno de los desafíos más comunes es desacoplar productores y consumidores sin perder escalabilidad ni flexibilidad.</p> <p>En integraciones tradicionales punto a punto:</p> <ul> <li>Cada nuevo consumidor incrementa la complejidad</li> <li>Los productores quedan fuertemente acoplados</li> <li>Los cambios generan alto impacto</li> </ul> <p>El patrón Fan-out permite:</p> <ul> <li>Publicar eventos una sola vez</li> <li>Distribuirlos a múltiples consumidores</li> <li>Escalar de manera independiente</li> <li>Aislar fallos entre sistemas downstream</li> </ul> <h2> SNS y SQS como base del Fan-out en AWS </h2> <p>Amazon SNS actúa como el <strong>broker de eventos</strong>, mientras que Amazon SQS permite que cada consumidor procese mensajes de forma independiente y confiable.</p> <p>Esta combinación ofrece:</p> <ul> <li>Fan-out nativo</li> <li>Filtrado de mensajes por suscripción</li> <li>Alta durabilidad y disponibilidad</li> <li>Desacoplamiento total entre productores y consumidores</li> </ul> <h2> Visión general de la arquitectura </h2> <h3> Flujo de alto nivel </h3> <ol> <li>Un productor publica un mensaje en un SNS Topic</li> <li>SNS evalúa las políticas de filtrado configuradas</li> <li>El mensaje se distribuye a una o más colas SQS</li> <li>Cada consumidor procesa los mensajes de forma independiente</li> </ol> <p><a href="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fluw7one45vqwf3wm1lvq.png" class="article-body-image-wrapper"><img src="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fluw7one45vqwf3wm1lvq.png" alt="Arquitectura general" width="800" height="317"></a></p> <h2> Diseño con Terraform (Infrastructure as Code) </h2> <p>La solución está completamente implementada usando <strong>Terraform</strong>, permitiendo versionar, auditar y reproducir la infraestructura de manera consistente.</p> <h3> Enfoque modular </h3> <ul> <li>Root module: orquesta el patrón Fan-out</li> <li>Módulo SNS: crea y configura el Topic</li> <li>Módulo SQS: crea las colas y políticas</li> </ul> <p>Este enfoque facilita la reutilización y extensión del patrón en otros proyectos.</p> <h2> Decisiones de diseño relevantes </h2> <p>Algunas decisiones clave tomadas en este proyecto:</p> <ul> <li>Uso de Amazon SNS en lugar de EventBridge para mantener simplicidad y foco en el patrón</li> <li>Soporte para colas <strong>Standard y FIFO</strong> </li> <li>Naming consistente basado en entorno, proyecto y funcionalidad</li> <li>Filtrado de mensajes mediante <strong>subscription filter policies</strong> </li> </ul> <h2> Buenas prácticas AWS aplicadas </h2> <ul> <li>Arquitectura desacoplada y orientada a eventos</li> <li>Infrastructure as Code</li> <li>Diseño modular</li> <li>Validaciones en variables Terraform</li> </ul> <h2> Casos de uso comunes </h2> <p>Este patrón es común en escenarios como:</p> <ul> <li>Detección de fraude</li> <li>Notificaciones</li> <li>Auditoría y logging</li> <li>Integración entre microservicios</li> <li>Procesamiento asíncrono</li> </ul> <h2> Repositorio GitHub </h2> <p>El código fuente está disponible públicamente:</p> <p>🔗 Repositorio: <a href="https://github.com/auztinorix/terraform-aws-sns-sqs-fanout" rel="noopener noreferrer">https://github.com/auztinorix/terraform-aws-sns-sqs-fanout</a></p> <h2> Consideraciones para producción </h2> <p>Para un uso en producción se recomienda:</p> <ul> <li>Configurar un backend remoto de Terraform</li> <li>Implementar monitoreo con CloudWatch</li> <li>Revisar políticas IAM bajo el principio de menor privilegio</li> <li>Evaluar costos según volumen de mensajes</li> </ul> <h2> Cierre </h2> <p>Este proyecto representa un primer paso en mi objetivo de <strong>contribuir de forma constante a la comunidad AWS</strong>, compartiendo soluciones reales y aplicables basadas en experiencias de arquitectura.</p> <p>Espero que este aporte sea útil y, sobre todo, que motive a otros a compartir su conocimiento con la comunidad 🚀</p> aws terraform architecture community