Module 4: Alerting On Error Budget Burn Rate
6. What AWS already automates: CloudWatch Application Signals, named
Description
Lessons 3, 4, and 5 of this module built, by hand, the complete multi-window burn rate math: a Python evaluator, an Alertmanager rule with and ignoring(window), and a single-window CloudWatch alarm with metric math. This lesson does what this ecosystem's honesty demands before closing the topic: name the managed product AWS already sells to solve a good part of this same problem — CloudWatch Application Signals, its SLO capabilities, and an important correction about when each piece arrived, verified against AWS's official documentation, not assumed from training knowledge.
Connection to the module
This lesson runs nothing — it's, deliberately, the most representative lesson in this whole module, and it says so in the title. Application Signals depends on APM-type infrastructure (the same family as X-Ray, already representative since Module 3, lesson 5, for being absent from LocalStack's Hobby plan), with no confirmed coverage on any LocalStack tier. What this lesson does do is an honest, line-by-line comparison between what this module built by hand and what AWS already automates — the question any real engineer would ask before manually replicating something a cloud provider already solves.
The correction this lesson makes before continuing: two dates, not one
This design's initial research assumed a single launch date for "native burn rate in Application Signals." The real verification, against two official AWS announcements, corrects that assumption: they're two different capabilities, launched at two different times.
November 13, 2024 — native burn rate, the piece that does solve lesson 5's single-window limitation:
"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 (November 13, 2024)
The key phrase, and the direct answer to the limitation lesson 5 honestly declared: "multiple alarms with varying look-back windows" — multiple alarms, with windows of different duration, coordinated to detect both sudden spikes and gradual degradation. It is, in substance, the same multi-window pattern from Table 5-8 this module built by hand — only here it's a native console capability in AWS, with no manual metric_query or PromQL, since November 2024, more than a year before this design's date.
March 13, 2026 — three new capabilities, on top of the previous one:
"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 (March 13, 2026)
This second date — the one this design's original research had in mind — isn't when burn rate arrived in Application Signals; it's when AWS added three additional capabilities, on top of a burn rate that had already been available for more than a year: automatic SLO recommendations based on 30 days of real data, a consolidated per-service reliability view, and historical reports aligned to calendar periods.
THE REAL TIMELINE, VERIFIED -- TWO ANNOUNCEMENTS, NOT ONE
Nov 2024 ────────────────────────────────── Mar 2026
│ │
▼ ▼
Native burn rate alarms + SLO Recommendations
(multiple windows, + Service-Level SLOs
spike and gradual + SLO Performance Report
degradation detection) (on top of the already-existing burn rate)Line-by-line contrast: what this module built by hand, what Application Signals already automates
| Piece | This module (M4.3-M4.5) | CloudWatch Application Signals |
|---|---|---|
| Burn rate calculation | Manual: burn_rate_of() (Module 2) + evaluate() (M4.3) | Automatic: calculated internally by the service |
| Multi-window (short + long) | Manual: and ignoring(window) in PromQL (M4.4); absent in the simple CloudWatch alarm (M4.5) | Native since Nov 2024: "multiple alarms with varying look-back windows" |
| SLO choice | Manual: three calculator runs against three candidate SLOs (Module 2, lesson 5), documented in SLO.md | Semi-automatic since Mar 2026: SLO Recommendations, based on 30 real days of P99 latency and error rate — suggests, doesn't decide for you |
| Consolidated reliability view | Absent — each script/rule measures a single SLI at a time | Service-Level SLOs (Mar 2026): "a holistic view of service reliability across all operations" |
| Historical reports | Absent — this module builds no report aggregated by period | SLO Performance Report (Mar 2026): calendar-aligned analysis, with daily/weekly/monthly cuts |
| Infrastructure required | None new beyond what's already inherited (Lambda, native metrics) | Application Signals needs active APM-type instrumentation on the service — an additional layer, not just flipping on an option |
The row most worth reading twice is "SLO choice." Application Signals suggests an SLO based on 30 real days of data — it doesn't impose it, it doesn't replace the engineering judgment this guide's Module 2, lesson 5 already exercised when comparing three scenarios (99%, 99.9%, 99.99%) against the same real dataset and choosing 99.9% with a justification documented in SLO.md. An automatic recommendation based on 30 days of current traffic can be a reasonable starting point, but it doesn't substitute for the question SLO.md does answer with its own evidence: what SLO makes sense for this system, given what each additional nine costs and what the business actually needs? An automatic recommendation doesn't know that second half of the question.
Why this guide built all of this by hand, knowing a managed alternative exists
This isn't a rhetorical question — it deserves an honest answer, the same one already applied when choosing Prometheus/Grafana over native CloudWatch in Module 3: understanding the mechanism underneath is what lets you judge, with real criteria, whether the managed version serves you well. Someone who only knows how to flip on "SLO Recommendations" in the AWS console can't explain why a 14.4x burn rate threshold corresponds to exactly 2% of the budget in an hour, or why a short window avoids Module 2's day 19 false positive — two questions this module does let you answer, because you built the logic before seeing the automated version.
On top of that, Application Signals has a real infrastructure cost and vendor lock-in this module — deliberately $0 and portable (pure Python + Prometheus/Alertmanager, neither tied to AWS) — doesn't have. A real team, with budget and with APM instrumentation already active, could reasonably choose to use Application Signals for day-to-day production alarms, and reserve this module's knowledge for the moment something in that managed layer doesn't behave as expected — the same argument already made, in Module 3's lesson 6, about why knowing how to read Prometheus alongside CloudWatch is a skill the market asks for separately, not one that replaces the other.
Common mistakes
Assuming "native burn rate" and "SLO Recommendations" arrived in AWS at the same time (the exact mistake this design's initial research made, and that this lesson exists to correct). What happens: someone cites "March 2026" as the date Application Signals started supporting burn rate, when that date actually corresponds to three different capabilities, added more than a year after burn rate was already available. How to spot it: if your citation of native burn rate's date doesn't distinguish between the November 2024 announcement and the March 2026 one. How to fix it: they're two different official announcements, with different URLs, cited separately in this lesson — always verify against the primary source before repeating a date from memory, exactly the discipline this design had to apply to itself when writing this lesson.
Treating "SLO Recommendations" as a complete replacement for Module 2's process (overestimating what an automatic recommendation can know). What happens: someone concludes that, with Application Signals available, all of SLO.md's work (three compared scenarios, a decision justified with evidence) is unnecessary. How to spot it: if your reasoning is "the machine already tells me which SLO to use, no need to think about it." How to fix it: a recommendation based on 30 days of real data tells you what SLO the system already meets today, not what SLO it should pursue given the cost of each additional nine and the business's real needs — the exact question SLO.md (Module 2, lesson 8) answers with its own evidence, and that no automatic recommendation can answer for you, because it requires business judgment the machine doesn't have.
Dismissing lesson 5's alarm as "inferior" just because Application Signals has native multi-window (underestimating the value of understanding the mechanism). What happens: someone concludes building lesson 5's CloudWatch alarm was an exercise with no real value, since a better alternative exists. How to spot it: if your conclusion from this lesson is "I should have used Application Signals from the start, without learning the manual metric math." How to fix it: lesson 5's metric math — errors / invocations, with treat_missing_data chosen well — is exactly the internal logic a managed capability like Application Signals runs underneath, without showing it to you. Knowing how to build it by hand is what lets you debug unexpected behavior from the managed version, or migrate back to a manual mechanism if you ever switch cloud providers — neither is possible if all you know is how to flip on a checkbox in a console.
Exercises
Exercise 1 — Explain, without looking at the lesson, the difference between the two dates cited. What arrived in November 2024, and what arrived in March 2026?
See solution
In November 2024, Application Signals added native burn rate support with multiple alarms of different-duration windows ("multiple alarms with varying look-back windows"), able to detect both sudden spikes and gradual degradation — the piece that solves lesson 5's CloudWatch alarm's single-window limitation. In March 2026, more than a year later, AWS added three additional capabilities on top of that already-existing burn rate: SLO Recommendations (automatic suggestions based on 30 days of P99 latency and error rate), Service-Level SLOs (a consolidated per-service reliability view), and SLO Performance Report (calendar-based historical reports). It isn't a single date with a single launch — they're two different official announcements, with different content.
Exercise 2 — A colleague argues that, since Application Signals has natively calculated burn rate since 2024, Table 5-8's multi-window pattern (Module 4, lesson 2) "isn't relevant to learn anymore." Do you agree?
See solution
Disagree. Application Signals implements the multi-window pattern — it doesn't replace it conceptually — it's still the same Google SRE math (a long window confirms the consumption is real, a short window confirms it's still active) described in Table 5-8, just executed by AWS instead of by and ignoring(window) in PromQL or evaluate() in Python. Understanding Table 5-8 is what lets you correctly configure the "multiple alarms with varying look-back windows" Application Signals offers — choosing thresholds and windows with judgment, not just accepting defaults — and it's what lets you recognize whether Application Signals is behaving as expected or not. The same argument this module already made about lesson 5's CloudWatch alarms: the tool changes, the math behind it doesn't.
Exercise 3 — Design, in prose, a concrete criterion for deciding whether a real Andes Cargo team should migrate from this module's tools (Python evaluator, Alertmanager, manual CloudWatch alarm) to Application Signals. What conditions would make the migration worthwhile, and which wouldn't?
See solution
A reasonable answer: the migration would make sense if (1) the team already pays for complete APM instrumentation on its AWS services (the migration would carry no new infrastructure cost, just flipping on an already-covered capability), (2) the team operates exclusively within AWS, with no need to port the same alert logic to another cloud provider in the future (Prometheus/Alertmanager, by contrast, is portable), and (3) the number of services to monitor grew large enough that manually maintaining metric_query HCL for every Lambda is, in itself, toil — repetitive work with no enduring value, from Module 1, lesson 7. The migration would not make sense yet if Andes Cargo is still a small system (a single critical Lambda, like in this project), where the cost of learning and maintaining an additional managed capability outweighs the benefit over a manual CloudWatch alarm that's already functional, already validated.
Summary and next step
This lesson named, with nothing run, what AWS already automates natively in the same problem space this module built by hand: CloudWatch Application Signals, with native burn rate (multi-window, since November 2024) and three additional capabilities added in March 2026 (SLO Recommendations, Service-Level SLOs, SLO Performance Report). It corrected a date this design's initial research had wrong — not a single date, but two different announcements, verified against AWS's official documentation — and contrasted, line by line, what was built in lessons 3-5 that already exists as a managed product, and what remains engineering judgment no automation can substitute (the SLO choice itself, not just its calculation).
Before moving on you should be able to: cite the two correct dates, with what arrived on each; explain why "SLO Recommendations" doesn't replace SLO.md's process; and argue, with your own judgment, when migrating from this module's tools to a managed capability would make sense.
Lesson 7 returns to executed ground: it routes lesson 5's CloudWatch alarm toward a real aws_sns_topic, and names — without building, since it's paid SaaS — the final destination a real production team would use: PagerDuty or Opsgenie.
Resources
- AWS — Application Signals now supports burn rate for application performance goals (November 13, 2024) — the original announcement of native, multi-window burn rate.
- AWS — Amazon CloudWatch Application Signals adds new SLO capabilities (March 13, 2026) — the announcement of SLO Recommendations, Service-Level SLOs, and SLO Performance Report.
- AWS Docs — Application Signals — the service's general documentation, the entry point for any future verification.
- This same repository, Module 2, lesson 8 (
08-project-andes-cargos-slo-md.md) —SLO.md, the document this lesson argues "SLO Recommendations" doesn't replace. - This same repository, Module 4, lesson 5 (
05-hands-on-a-real-cloudwatch-alarm-on-the-lambda.md) — the manual, single-window alarm this lesson contrasts against Application Signals' native burn rate.