Notificaciones DevOps con AWS Chatbot - Integración de eventos de AWS con Slack / Teams

Se presenta cómo crear un entorno de ChatOps que envía las notificaciones de alarmas de CloudWatch y de CodePipeline a Slack / Teams y permite operar AWS desde el chat con comandos @aws.

Unos 7 min de lecturaÚltima actualización: 2026-10-31

Funcionamiento de Chatbot y servicios compatibles

AWS Chatbot (cuyo nombre actual es Amazon Q Developer in chat applications) es un servicio de ChatOps que envía notificaciones de AWS a canales de chat como Slack y Microsoft Teams y permite operar AWS desde ellos. Al asociar un tema de SNS a un canal de chat, los mensajes publicados en ese tema se notifican en el chat. Los servicios de AWS compatibles son muy variados, como las alarmas de CloudWatch, AWS Health, Security Hub, Budgets, CodePipeline, CodeBuild, GuardDuty, Systems Manager y Config. Las notificaciones se muestran con un formato propio de cada servicio, y las métricas de CloudWatch pueden adjuntarse como gráficos.

Configuración de notificaciones y ChatOps

La configuración consta de tres pasos. Se conecta un espacio de trabajo de Slack o un inquilino de Teams a Chatbot, se selecciona un canal y se asocia un tema de SNS. En las notificaciones de alarmas de CloudWatch, cuando una alarma pasa al estado ALARM se publica un mensaje en el canal de Slack y se adjunta el gráfico de la métrica. Con la función de ChatOps, puede ejecutar la AWS CLI desde un canal de chat con comandos @aws. Por ejemplo, puede invocar una función de Lambda con @aws lambda invoke --function-name my-function o listar las alarmas en estado de alarma con @aws cloudwatch describe-alarms --state-value ALARM. Durante la respuesta a incidentes, puede llevar a cabo la comprobación de la situación y las operaciones de respuesta en el canal de chat, lo que permite reducir el esfuerzo de cambiar de pantalla.

Seguridad y control de acceso

A la configuración del canal de Chatbot se le asocia un rol de IAM para controlar las operaciones de AWS que pueden ejecutarse desde ese canal. Una configuración posible es permitir las operaciones del entorno de producción solo desde un canal ops dedicado y permitir únicamente operaciones de solo lectura en los canales de desarrollo generales. Antes de ejecutar un comando, Chatbot comprueba si lo permiten el rol de IAM del canal y las políticas de barreras de protección, por lo que, si limita las acciones de IAM que se permiten, puede reducir el riesgo de que una operación errónea alcance el entorno de producción. Los registros de operaciones de Chatbot se guardan en CloudTrail, por lo que puede auditar quién ejecutó qué comando y cuándo. El uso de Chatbot en sí es gratuito, y solo se cobra la entrega de SNS.

Precios de Chatbot

AWS Chatbot se puede usar de forma gratuita. No se cobran cargos adicionales por la entrega de notificaciones a Slack o Teams ni por la ejecución de la AWS CLI desde el chat. Los únicos costes son los temas de SNS que activan las notificaciones (unos 0.50 USD por cada 1 millón de solicitudes) y los cargos de los recursos creados / modificados como resultado de las operaciones de AWS ejecutadas con ChatOps (a fecha de agosto de 2026). Como puede implantarse sin cargos adicionales, se puede considerar como un medio para mejorar la visibilidad de la operación y la rapidez de la respuesta.

Organización de las notificaciones y reducción del ruido

Si hay demasiadas notificaciones, las alertas importantes quedan enterradas. Si separa los canales por finalidad, por ejemplo los incidentes de producción en un canal dedicado y el intercambio de información en otro canal, puede reducir los descuidos. Se preparan temas de SNS por nivel de gravedad y, en la configuración de canales de Chatbot, se diseña qué tema se envía a qué canal. Lo fundamental es limitar las notificaciones a las que requieren una respuesta, en lugar de enviar todas las alarmas por igual. Al mantener un estado en el que alguien responde cuando llega una notificación, el chat sigue funcionando como un centro de operaciones con sentido.

Integración eficaz con las alarmas de CloudWatch

Para aprovechar el valor de Chatbot, es importante la calidad de las propias alarmas que se envían. Si usa alarmas compuestas (Composite Alarm) que combinan varias condiciones, se reducen las falsas alertas por fluctuaciones temporales de una sola métrica y resulta más fácil notificar solo las situaciones problemáticas. Si la alarma incluye información que indique qué está ocurriendo y los pasos que deben comprobarse primero, quien la recibe puede actuar de inmediato. Como se adjunta el gráfico del estado de la alarma, se puede crear un flujo en el que se capta la tendencia en el chat y se pasa a la consola solo cuando hace falta profundizar.

Uso combinado con otros medios de notificación

Las notificaciones por chat son adecuadas para hacer llegar la información al lugar que el equipo consulta a diario. En cambio, cuando hay que despertar al responsable por un incidente grave de madrugada, lo realista es combinarlas con una plataforma de guardia dedicada que realice llamadas telefónicas o envíe notificaciones push. Resulta eficaz un reparto de funciones en el que Chatbot se encarga de la respuesta conjunta durante el día y de la visualización de la situación, y los niveles de gravedad que requieren escalado se envían por la ruta de guardia. Si usa SNS como centro, puede entregar el mismo evento a la vez por varias rutas, como el chat, el correo electrónico y las herramientas de guardia, y reducir las notificaciones perdidas.

Prácticas recomendadas para la operación con ChatOps

La comodidad de operar AWS desde el chat es inseparable del riesgo de operaciones erróneas. Se limita a privilegios mínimos el rol de IAM que se concede a cada canal y se separan los canales centrados en la lectura de los canales que permiten operaciones de cambio limitadas. Lo seguro es que, como norma, las operaciones destructivas en producción pasen por los pipelines y los runbooks oficiales, y que desde el chat se limite a la comprobación de la situación y a respuestas menores. Como los registros de ejecución quedan en CloudTrail, se revisa periódicamente el historial de operaciones. Si fija en el canal los procedimientos de investigación de uso frecuente, resulta más fácil evitar que la respuesta recaiga en determinadas personas.

Resumen

AWS Chatbot es un servicio de ChatOps que convierte Slack y Teams en un centro de operaciones de AWS. Permite organizar una operación en la que se detectan pronto los incidentes con las notificaciones de alarmas, se avanza en la respuesta con operaciones de AWS desde el chat y se controla el acceso con roles de IAM. También resulta atractivo que se pueda usar de forma gratuita y que la barrera de implantación sea baja.

Referencias (recursos oficiales de AWS)

Las fuentes primarias de esta página son el sitio web y la documentación oficiales de AWS. Consulta las páginas oficiales siguientes para conocer las especificaciones y los precios más recientes.

Si esta página y la documentación oficial difieren, prevalece la documentación oficial.

El mecanismo de sincronización horaria interna de AWS - Amazon Time Sync Service y el diseño de smearing de segundos intercalaresExplicamos el mecanismo de Amazon Time Sync Service operado de forma independiente por AWS, la fuente de tiempo de alta precisión con GPS y relojes atómicos, la decisión de diseño de absorber los segundos intercalares mediante smearing y la importancia de la sincronización horaria en sistemas distribuidos.Centralización de registros de auditoría SaaS con AWS AppFabric - Estandarización OCSF e integración con Security LakeExplicamos la recopilación de registros de auditoría de aplicaciones SaaS con AppFabric, la estandarización al formato OCSF y la construcción de pipelines de análisis.Implementación de Feature Flags con AWS AppConfig - Despliegue seguro de configuración y rollbackDespliega cambios de configuración de forma independiente al código mediante estrategias Linear y Exponential. Garantiza la seguridad con rollback automático activado por alarmas de CloudWatch.Revisión de arquitectura - Evaluación sistemática de cargas de trabajo con AWS Well-Architected ToolExplica la revisión de arquitectura de cargas de trabajo con AWS Well-Architected Tool. Presenta la evaluación basada en los 6 pilares, la elaboración de planes de mejora y el uso de lentes personalizadas.Diseño y operación de logs de auditoría - Registro completo de actividad API con CloudTrailExplica las técnicas de diseño de logs de auditoría con AWS CloudTrail, el registro de actividad API, el almacenamiento a largo plazo en S3 y la respuesta de cumplimiento mediante integración con Config.Lecciones de sistemas distribuidos a partir de los informes de incidentes de AWS (COE) - Principios de diseño transformados por los grandes incidentes del pasadoA partir de los Correction of Errors (COE) y los informes de incidentes publicados por AWS, explica las causas raíz de grandes incidentes del pasado, como el incidente de S3, el incidente de DNS en us-east-1 y el incidente de Kinesis, y cómo cambiaron los principios de diseño de AWS.El diseño de tags determina las operaciones - Curiosidades y reglas de nomenclatura prácticas de la estrategia de tags de recursos AWSExplicamos por qué los tags de recursos AWS no son simples etiquetas sino la base de la asignación de costos, control de acceso y automatización, las reglas de nomenclatura de claves de tags, cómo usar el límite de 50 tags y la gobernanza mediante políticas de tags.Por qué existen las cuotas de servicio de AWS - Diseño multitenant que protege la infraestructura compartidaExplicamos que las cuotas de servicio de AWS (antes límites de servicio) no son simples restricciones sino un diseño para proteger a otros clientes en un entorno multitenant, desde el problema del vecino ruidoso, la diferencia entre límites soft y hard, y el trasfondo de las solicitudes de aumento.