Módulo 4: Alerting On Error Budget Burn Rate
6. Lo que AWS ya automatiza: CloudWatch Application Signals, nombrado
Descripción
Las lecciones 3, 4 y 5 de este módulo construyeron, a mano, la matemática completa de burn rate multi-ventana: un evaluador Python, una regla de Alertmanager con and ignoring(window), y una alarma de CloudWatch de una sola ventana con metric math. Esta lección hace lo que la honestidad de este ecosistema exige antes de cerrar el tema: nombrar el producto gestionado que AWS ya vende para resolver buena parte de este mismo problema — CloudWatch Application Signals, sus capacidades de SLO, y una corrección importante sobre cuándo llegó cada pieza, verificada contra la documentación oficial de AWS, no asumida del conocimiento de entrenamiento.
Conexión con el módulo
Esta lección no ejecuta nada — es, deliberadamente, la más representativa de todo este módulo, y lo dice desde el título. Application Signals depende de infraestructura tipo APM (la misma familia que X-Ray, ya representativo desde el Módulo 3, lección 5, por ausencia del plan Hobby de LocalStack), sin confirmación de cobertura en LocalStack de ningún tier. Lo que sí hace esta lección es una comparación línea por línea, honesta, entre lo que este módulo construyó a mano y lo que AWS ya automatiza — la pregunta que cualquier ingeniero real se haría antes de replicar manualmente algo que un proveedor de nube ya resuelve.
La corrección que esta lección hace antes de seguir: dos fechas, no una
La investigación inicial de este diseño asumía una sola fecha de lanzamiento para "burn rate nativo en Application Signals". La verificación real, contra dos anuncios oficiales de AWS, corrige esa suposición: son dos capacidades distintas, lanzadas en dos momentos distintos.
13 de noviembre de 2024 — burn rate nativo, la pieza que sí resuelve la limitación de una sola ventana de la lección 5:
"Customers can now receive alerts when these SLOs reach a critical burn rate, which allows you to calculate how quickly your service is consuming its error budget relative to the SLO's attainment goal. [...] By setting multiple alarms with varying look-back windows, you can identify sudden error rate spikes and gradual shifts that could affect your error budget."
— AWS — Application Signals now supports burn rate for application performance goals (13 de noviembre de 2024)
La frase clave, y la respuesta directa a la limitación que la lección 5 declaró con honestidad: "multiple alarms with varying look-back windows" — múltiples alarmas, con ventanas de distinta duración, coordinadas para detectar tanto picos súbitos como deterioros graduales. Es, en sustancia, el mismo patrón multi-ventana de la Tabla 5-8 que este módulo construyó a mano —solo que aquí es una capacidad nativa de la consola de AWS, sin metric_query manual ni PromQL, desde noviembre de 2024, más de un año antes de la fecha de este diseño.
13 de marzo de 2026 — tres capacidades nuevas, encima de la anterior:
"Amazon CloudWatch Application Signals now offers three new console based capabilities for Service Level Objectives (SLOs): SLO Recommendations, Service-Level SLOs, and SLO Performance Report."
"SLO Recommendations analyzes 30 days of service metrics (P99 latency and error rates) to suggest appropriate reliability targets."
— AWS — Amazon CloudWatch Application Signals adds new SLO capabilities (13 de marzo de 2026)
Esta segunda fecha —la que la investigación original de este diseño tenía en mente— no es cuando burn rate llegó a Application Signals; es cuando AWS agregó tres capacidades adicionales, encima de un burn rate que ya llevaba más de un año disponible: recomendaciones automáticas de SLO basadas en 30 días de datos reales, una vista consolidada de reliability por servicio, y reportes históricos alineados a períodos de calendario.
LA LINEA DE TIEMPO REAL, VERIFICADA -- DOS ANUNCIOS, NO UNO
nov 2024 ────────────────────────────────── mar 2026
│ │
▼ ▼
Burn rate alarms nativos + SLO Recommendations
(multiples ventanas, + Service-Level SLOs
deteccion de picos + SLO Performance Report
y deterioro gradual) (sobre el burn rate ya existente)Contraste línea por línea: lo que este módulo construyó a mano, lo que Application Signals ya automatiza
| Pieza | Este módulo (M4.3-M4.5) | CloudWatch Application Signals |
|---|---|---|
| Cálculo de burn rate | Manual: burn_rate_of() (Módulo 2) + evaluate() (M4.3) | Automático: calculado internamente por el servicio |
| Multi-ventana (corta + larga) | Manual: and ignoring(window) en PromQL (M4.4); ausente en la alarma simple de CloudWatch (M4.5) | Nativo desde nov-2024: "multiple alarms with varying look-back windows" |
| Elección del SLO | Manual: tres corridas de la calculadora contra tres SLOs candidatos (Módulo 2, lección 5), documentadas en SLO.md | Semi-automático desde mar-2026: SLO Recommendations, basado en 30 días reales de P99 de latencia y tasa de error — sugiere, no decide por ti |
| Vista consolidada de reliability | Ausente — cada script/regla mide un solo SLI a la vez | Service-Level SLOs (mar-2026): "a holistic view of service reliability across all operations" |
| Reportes históricos | Ausente — este módulo no construye ningún reporte agregado por período | SLO Performance Report (mar-2026): análisis alineado a calendario, con cortes diario/semanal/mensual |
| Infraestructura requerida | Ninguna nueva más allá de lo ya heredado (Lambda, métricas nativas) | Application Signals necesita instrumentación tipo APM activa sobre el servicio — una capa adicional, no solo habilitar una opción |
La fila que más vale la pena leer dos veces es la de "elección del SLO". Application Signals sugiere un SLO basado en 30 días de datos reales — no lo impone, no reemplaza el juicio de ingeniería que el Módulo 2, lección 5 de esta guía ya ejerció al comparar tres escenarios (99%, 99,9%, 99,99%) contra el mismo dataset real y elegir 99,9% con una justificación documentada en SLO.md. Una recomendación automática basada en 30 días de tráfico actual puede ser un punto de partida razonable, pero no sustituye la pregunta que SLO.md sí contesta con evidencia propia: ¿qué SLO tiene sentido para este sistema, dado lo que cuesta cada nueve adicional y lo que el negocio realmente necesita? Una recomendación automática no conoce esa segunda parte de la pregunta.
Por qué esta guía construyó todo esto a mano, sabiendo que existe una alternativa gestionada
Esta no es una pregunta retórica — merece una respuesta honesta, la misma que ya se aplicó al escoger Prometheus/Grafana sobre CloudWatch nativo en el Módulo 3: entender el mecanismo por debajo es lo que te permite evaluar, con criterio, si la versión gestionada te sirve. Alguien que solo sabe activar "SLO Recommendations" en la consola de AWS no puede explicar por qué un umbral de burn rate de 14,4x corresponde a exactamente 2% del presupuesto en una hora, ni por qué una ventana corta evita el falso positivo del día 19 del Módulo 2 — dos preguntas que este módulo sí te deja contestar, porque construiste la lógica antes de ver la versión automatizada.
Además, Application Signals tiene un costo real de infraestructura y de vendor lock-in que este módulo, deliberadamente $0 y portátil (Python puro + Prometheus/Alertmanager, ninguno atado a AWS), no tiene. Un equipo real, con presupuesto y con instrumentación APM ya activa, podría elegir razonablemente usar Application Signals para las alarmas de producción del día a día, y reservar el conocimiento de este módulo para el momento en que algo en esa capa gestionada no se comporta como se espera — el mismo argumento que ya se usó, en la lección 6 del Módulo 3, sobre por qué saber leer Prometheus junto a CloudWatch es una habilidad que el mercado pide por separado, no una que reemplace a la otra.
Errores comunes
Asumir que "burn rate nativo" y "SLO Recommendations" llegaron a AWS al mismo tiempo (el error exacto que la investigación inicial de este diseño cometió, y que esta lección existe para corregir). Qué pasa: alguien cita "marzo de 2026" como la fecha en que Application Signals empezó a soportar burn rate, cuando en realidad esa fecha corresponde a tres capacidades distintas, agregadas más de un año después de que burn rate ya estuviera disponible. Cómo detectarlo: si tu cita de la fecha de burn rate nativo no distingue entre el anuncio de noviembre de 2024 y el de marzo de 2026. Cómo corregirlo: son dos anuncios oficiales distintos, con URLs distintas, citados por separado en esta lección — verifica siempre contra la fuente primaria antes de repetir una fecha de memoria, exactamente la disciplina que este diseño tuvo que aplicarse a sí mismo al escribir esta lección.
Tratar "SLO Recommendations" como un reemplazo completo del proceso del Módulo 2 (de sobreestimar lo que una recomendación automática puede saber). Qué pasa: alguien concluye que, con Application Signals disponible, todo el trabajo de SLO.md (tres escenarios comparados, una decisión justificada con evidencia) es innecesario. Cómo detectarlo: si tu razonamiento es "la máquina ya me dice qué SLO usar, no hace falta pensarlo". Cómo corregirlo: una recomendación basada en 30 días de datos reales te dice qué SLO el sistema ya cumple hoy, no qué SLO debería perseguir dado el costo de cada nueve adicional y las necesidades reales del negocio — la pregunta exacta que SLO.md (Módulo 2, lección 8) contesta con evidencia propia, y que ninguna recomendación automática puede contestar por ti, porque requiere criterio de negocio que la máquina no tiene.
Descartar la alarma de la lección 5 como "inferior" solo porque Application Signals tiene multi-ventana nativo (de subestimar el valor de entender el mecanismo). Qué pasa: alguien concluye que construir la alarma de CloudWatch de la lección 5 fue un ejercicio sin valor real, ya que existe una alternativa mejor. Cómo detectarlo: si tu conclusión de esta lección es "debería haber usado Application Signals desde el principio, sin aprender el metric math manual". Cómo corregirlo: el metric math de la lección 5 —errors / invocations, con treat_missing_data bien elegido— es exactamente la lógica interna que una capacidad gestionada como Application Signals ejecuta por debajo, sin mostrártela. Saber construirlo a mano es lo que te permite depurar un comportamiento inesperado de la versión gestionada, o migrar de vuelta a un mecanismo manual si algún día cambias de proveedor de nube — ninguna de las dos cosas es posible si solo sabes activar una casilla en una consola.
Ejercicios
Ejercicio 1 — Explica, sin mirar la lección, la diferencia entre las dos fechas citadas. ¿Qué llegó en noviembre de 2024, y qué llegó en marzo de 2026?
Ver solución
En noviembre de 2024, Application Signals agregó soporte nativo de burn rate con múltiples alarmas de ventanas de distinta duración ("multiple alarms with varying look-back windows"), capaces de detectar tanto picos súbitos como deterioros graduales — la pieza que resuelve la limitación de una sola ventana de la alarma de CloudWatch de la lección 5. En marzo de 2026, más de un año después, AWS agregó tres capacidades adicionales encima de ese burn rate ya existente: SLO Recommendations (sugerencias automáticas basadas en 30 días de P99 de latencia y tasa de error), Service-Level SLOs (una vista consolidada de reliability por servicio) y SLO Performance Report (reportes históricos por calendario). No es una sola fecha con un solo lanzamiento — son dos anuncios oficiales distintos, con contenido distinto.
Ejercicio 2 — Un colega argumenta que, dado que Application Signals ya calcula burn rate de forma nativa desde 2024, el patrón multi-ventana de la Tabla 5-8 (Módulo 4, lección 2) "ya no es relevante aprenderlo". ¿Estás de acuerdo?
Ver solución
En desacuerdo. Application Signals implementa el patrón multi-ventana —no lo reemplaza conceptualmente—; sigue siendo la misma matemática de Google SRE (ventana larga confirma que el consumo es real, ventana corta confirma que sigue activo) descrita en la Tabla 5-8, solo que ejecutada por AWS en vez de por and ignoring(window) en PromQL o por evaluate() en Python. Entender la Tabla 5-8 es lo que te permite configurar correctamente las "multiple alarms with varying look-back windows" que Application Signals ofrece —elegir umbrales y ventanas con criterio, no solo aceptar valores por defecto—, y es lo que te permite reconocer si Application Signals se está comportando como se espera o no. El mismo argumento que este módulo ya hizo sobre las alarmas de CloudWatch de la lección 5: la herramienta cambia, la matemática detrás no.
Ejercicio 3 — Diseña, en prosa, un criterio concreto para decidir si un equipo real de Andes Cargo debería migrar de las herramientas de este módulo (evaluador Python, Alertmanager, alarma de CloudWatch manual) a Application Signals. ¿Qué condiciones harían que la migración tenga sentido, y cuáles no?
Ver solución
Una respuesta razonable: la migración tendría sentido si (1) el equipo ya paga por instrumentación APM completa en sus servicios de AWS (la migración no tendría un costo de infraestructura nuevo, solo activar una capacidad ya cubierta), (2) el equipo opera exclusivamente dentro de AWS, sin necesidad de portar la misma lógica de alerta a otro proveedor de nube en el futuro (Prometheus/Alertmanager, en cambio, es portátil), y (3) el volumen de servicios a vigilar creció lo suficiente como para que mantener manualmente metric_query HCL por cada Lambda sea, en sí mismo, toil —trabajo repetitivo, sin valor duradero, del Módulo 1, lección 7—. La migración no tendría sentido todavía si Andes Cargo sigue siendo un sistema pequeño (un solo Lambda crítico, como en este proyecto), donde el costo de aprender y mantener una capacidad gestionada adicional supera el beneficio frente a una alarma de CloudWatch manual, ya funcional, ya validada.
Resumen y siguiente paso
Esta lección nombró, sin ejecutar nada, lo que AWS ya automatiza de forma nativa en el mismo espacio de problema que este módulo construyó a mano: CloudWatch Application Signals, con burn rate nativo (multi-ventana, desde noviembre de 2024) y tres capacidades adicionales agregadas en marzo de 2026 (SLO Recommendations, Service-Level SLOs, SLO Performance Report). Corrigió una fecha que la investigación inicial de este diseño tenía equivocada —no una sola fecha, sino dos anuncios distintos, verificados contra la documentación oficial de AWS—, y contrastó línea por línea qué de lo construido en las lecciones 3-5 ya existe como producto gestionado, y qué sigue siendo criterio de ingeniería que ninguna automatización puede sustituir (la elección del SLO en sí, no solo su cálculo).
Antes de avanzar deberías poder: citar las dos fechas correctas, con qué llegó en cada una; explicar por qué "SLO Recommendations" no reemplaza el proceso de SLO.md; y argumentar, con criterio propio, cuándo migrar de las herramientas de este módulo a una capacidad gestionada tendría sentido.
La lección 7 vuelve a terreno ejecutado: enruta la alarma de CloudWatch de la lección 5 hacia un aws_sns_topic real, y nombra —sin construir, por ser SaaS de pago— el destino final que un equipo de producción real usaría: PagerDuty u Opsgenie.
Recursos
- AWS — Application Signals now supports burn rate for application performance goals (13 de noviembre de 2024) — el anuncio original de burn rate nativo, con múltiples ventanas.
- AWS — Amazon CloudWatch Application Signals adds new SLO capabilities (13 de marzo de 2026) — el anuncio de SLO Recommendations, Service-Level SLOs y SLO Performance Report.
- AWS Docs — Application Signals — la documentación general del servicio, punto de entrada para cualquier verificación futura.
- Este mismo repositorio, Módulo 2, lección 8 (
08-project-andes-cargos-slo-md.md) —SLO.md, el documento que esta lección argumenta que "SLO Recommendations" no reemplaza. - Este mismo repositorio, Módulo 4, lección 5 (
05-hands-on-a-real-cloudwatch-alarm-on-the-lambda.md) — la alarma manual de una sola ventana que esta lección contrasta contra el burn rate nativo de Application Signals.