Module 8: Capstone The Andes Cargo Reliability Package
6. What this guide left representative, final honesty
Description
Every module in this guide, at the exact moment a piece appeared that didn't actually run in this environment, flagged it precisely: representative, with the exact technical reason, never invented. This lesson brings those five pieces together — X-Ray, CloudWatch Application Signals, AWS Systems Manager Incident Manager, PagerDuty/Opsgenie, and the real result of the DynamoDB backup attempt — in one place, not to repeat what each lesson already explained, but so that whoever finishes this guide has, at a glance, the complete map of what the executed backbone is and what the honest contrast is with what a real team, with a real budget, would adopt instead.
Connection to the module
This lesson doesn't discover any new limitation — each of the five pieces below was already declared, with its cited source, in the module where it first appeared. Its value is of a different kind: the same honesty DISENO.md demanded since this guide's first paragraph ("nothing gets simulated in prose [...] representative cases [...] are explicitly labeled at the exact moment they appear") gets confirmed here, once more, as a property of the whole guide, not just each isolated lesson.
The backbone, for contrast: what really ran
Before the five representative pieces, it's worth recalling, in a single table, how much of this guide is not on this list — the real proportion, not an impression:
| Piece | Actually ran, in this environment |
|---|---|
scripts/error_budget_calculator.py, scripts/burn_rate_evaluator.py | Yes — pure Python, no external dependency |
Prometheus v3.13.2, Grafana 13.1.3, Alertmanager v0.33.1 | Yes — docker pull, docker compose up, /-/ready, real PromQL queries |
Jaeger v2 v2.20.0 (jaegertracing/jaeger, not all-in-one) | Yes — UI and OTLP endpoint confirmed with 200 |
oncall/schedule.py | Yes — deterministic, verified across two identical runs |
terraform validate/terraform plan against observability.tf | Yes — no schema errors, Plan: 2 to add confirmed |
| CloudWatch (Logs, metrics, alarms) as a service | Yes, confirmed on LocalStack's Hobby plan — this guide's limitation is an authoring-environment one (no LOCALSTACK_AUTH_TOKEN), not a service-coverage one |
| The two synthetic/real incidents from Modules 6-8 | Yes — the complete machine, run twice, with literal evidence at every layer |
With that as a reference, the five pieces below are the deliberate minority, not the rule.
1. AWS X-Ray — absent from the Hobby plan
Where it appeared: Module 3, lesson 5 (traces with OpenTelemetry and Jaeger).
Exact technical reason: LocalStack's official documentation is explicit — "Included in Plans: Ultimate" — X-Ray isn't in the free Hobby plan this guide uses across its entire $0 lab. The alternative this guide built instead, local OpenTelemetry + Jaeger v2, teaches the same concept (a distributed trace, with spans crossing upload → Lambda → DynamoDB) with a tool that does run end to end, verified in this environment.
What a real team choosing X-Ray instead of Jaeger would be missing: native integration with the rest of AWS services with no exporter of their own to maintain, and the contrast already named in Module 3: even on the paid tier, X-Ray doesn't offer complete trace_id correlation across every service.
2. CloudWatch Application Signals — SLO Recommendations, not run
Where it appeared: Module 4, lesson 6.
Exact technical reason: launched in March 2026, with capabilities that automate a good part of what this guide's Modules 2 and 4 built by hand — SLO recommendations based on 30 days of P99 latency and error rate, native burn rate alerts. Never run in this guide because it depends on APM-type infrastructure (the same kind of continuous trace instrumentation X-Ray provides), with no confirmed coverage on any LocalStack tier.
The contrast worth taking away: a team with a real AWS budget, today, would have the legitimate option of not building scripts/burn_rate_evaluator.py or alert_rules.yml's rules by hand — Application Signals already calculates recommended SLOs and burn rate natively. This guide built the manual version on purpose: understanding Google SRE's math line by line is what makes adopting the managed version, later, an informed decision, not a black box nobody on the team would know how to debug if something went wrong.
3. AWS Systems Manager Incident Manager — closed to new accounts
Where it appeared: named in Module 5, flagged as a service in active decline.
Exact technical reason, quoted verbatim: "AWS Systems Manager Incident Manager is no longer open to new customers. Existing customers can continue to use the service as normal." — closed to new accounts since November 2025. This isn't a LocalStack limitation or a decision by this guide — it's a verified fact about AWS's own service: a learner starting in 2026 couldn't adopt it even if they wanted to, regardless of budget.
Why this guide built INCIDENT-RESPONSE-PLAN.md by hand instead of assuming a managed service: this guide's lifecycle, severity matrix, roles, and on-call rotation don't depend on any specific AWS product — they're a process framework, not a piece of infrastructure. That independence is precisely what gives it value: it works no matter what incident-management tool a real team adopts, whether Incident Manager (while it was open), PagerDuty, Opsgenie, or none.
4. PagerDuty / Opsgenie — SaaS, no $0 tier
Where they appeared: Module 4, lesson 7 (alert routing) and Module 5, lesson 6 (on-call's real cost).
Exact technical reason: both are commercial products, with no free tier equivalent to the rest of this guide's lab. This guide built the $0 equivalent instead — a real aws_sns_topic (Module 4) and a deterministic pure-Python rotation (oncall/schedule.py, Module 5) — and was honest, in both modules, about what that equivalent lacks: automatic escalation across on-call tiers, a mobile app, native chat integration.
The quote worth remembering here, again: Hacker News, jamiemallers (Module 5, lesson 6), on treating on-call routing as a portable layer: "switching costs are higher than almost any other category." This guide's decision to build schedule.py in a simple, JSON-exportable format wasn't just a budget limitation — it was, explicitly, avoiding that lock-in from day one, even before the team had the budget to pay for either of these two tools.
5. DynamoDB backup/restore — the real result, with no promises
Where it appeared: Module 7, lesson 7, the Claude Code incident postmortem's action item #4.
The exact result, unsoftened: a direct network check unambiguously confirmed the root cause of why awslocal dynamodb create-backup/restore-table-from-backup didn't complete in this specific authoring environment — no process listening on port 4566, the same limit across this entire ecosystem with no LOCALSTACK_AUTH_TOKEN. What that lesson couldn't confirm, unlike the CloudTrail precedent in cloud-security-and-guardrails-guide, is whether DynamoDB's specific backup API has textually confirmed coverage on LocalStack's Hobby plan — the DynamoDB service itself is confirmed; the specific backup operations don't have the same documentary clarity.
Why this result, uncertain at a specific point, is still a valid close for the action item: the action item asked to "document the real outcome, whatever it is" — not "confirm backup/restore works in LocalStack." Module 7's lesson 7 documented, field by field against AWS's official API reference, the exact shape a successful response would have, without inventing any ARN or timestamp. An honest result about the limits of what can be confirmed in this specific environment is a real result, not a failed exercise.
THE FIVE REPRESENTATIVE PIECES -- SAME LABEL, TWO DIFFERENT KINDS
ABSENCE OF FREE COVERAGE NATURE OF THE SERVICE/PRODUCT
(a technical limit of LocalStack Hobby) (outside this guide's control)
──────────────────────────────────── ─────────────────────────────────
X-Ray (Ultimate-only) Incident Manager (closed to new
Application Signals (no confirmed APM) accounts, AWS's own decision)
DynamoDB backup/restore (API with no PagerDuty/Opsgenie (commercial
explicit textual confirmation) SaaS, no possible $0 tier)Common mistakes
Reading this lesson as a list of "what this guide was missing," instead of "what this guide precisely identified and didn't fake having" (confusing declared honesty with a shortcoming). What happens: someone, seeing five pieces marked representative, concludes the whole guide is less rigorous than it looks. How to spot it: if your summary of this guide starts with the limitations instead of the backbone table (Prometheus, Grafana, Alertmanager, Jaeger, the calculator, the rotation, the validated HCL, the two complete incidents). How to fix it: the real proportion — seven central pieces actually executed against five representative ones, each with a cited, not invented, technical reason — is the same honesty discipline every guide in this ecosystem has already applied since terraform-and-iac-guide. Precisely flagging what didn't run is what makes what did run trustworthy.
Assuming all the representative pieces share the same reason (lack of money) (losing this lesson's diagram's distinction). What happens: someone explains the five pieces with a single generic sentence ("they're all paid, that's why they weren't run"). How to spot it: if your explanation for why Incident Manager is representative mentions cost, instead of its closure to new accounts. How to fix it: this lesson's diagram distinguishes two real categories — pieces absent from LocalStack's free plan (X-Ray, Application Signals, DynamoDB backup's uncertain case) versus pieces that are, by their very nature, impossible to have on a $0 tier no matter what lab tool is used (Incident Manager is closed by AWS's decision, not LocalStack's; PagerDuty/Opsgenie are commercial SaaS). Confusing the two categories loses real information about what would and wouldn't change if this guide had a different budget.
Treating the DynamoDB backup/restore result as "failed" instead of "uncertain at a specific point, precisely documented" (repeating the same error Module 7, lesson 7 already named). What happens: someone summarizes this guide by saying "the backup attempt didn't work." How to spot it: if your summary of piece 5 uses the word "failed" or "didn't work" without the distinction between "the network cause is confirmed" and "the specific API coverage has no textual confirmation." How to fix it: Module 7, lesson 7's corresponding step already established it — an uncertain result, documented with precise evidence about exactly what can and can't be claimed, fulfills the action item just as well as a confirmed success would have.
Exercises
Exercise 1 — Classify each of this lesson's five pieces into one of the diagram's two categories ("absence of free coverage" or "nature of the service/product"), without looking at the diagram.
See solution
Absence of free coverage on LocalStack: X-Ray (confirmed Ultimate-only), CloudWatch Application Signals (no coverage confirmed on any tier), and DynamoDB backup/restore's uncertain case (DynamoDB is indeed on Hobby, the specific backup API doesn't have the same textual clarity). Nature of the service/product, outside LocalStack's control: AWS Systems Manager Incident Manager (closed to new accounts by AWS's own decision, not a LocalStack limit) and PagerDuty/Opsgenie (third-party commercial SaaS, never going to have a free tier equivalent to a Docker container).
Exercise 2 — A classmate argues this guide should have "waited" for LocalStack to add X-Ray coverage to the Hobby plan, instead of using Jaeger. What would have been lost with that decision?
See solution
Waiting would have left Module 3 with no way to teach real distributed traces, indefinitely, subject to a LocalStack product decision this guide doesn't control. The alternative this guide chose — OpenTelemetry + Jaeger v2, verified running end to end in this environment — teaches exactly the same concept (a trace with correlated spans) with an open-source tool any learner can spin up today, with no dependency on any future third-party change. Besides, OpenTelemetry is, in itself, the standard the industry is moving toward regardless of which trace backend gets used — Jaeger, X-Ray, or any other — so the knowledge isn't tied to a single tool.
Exercise 3 — Explain why the "The backbone, for contrast" section opens this lesson, instead of the lesson starting directly with the list of representative pieces.
See solution
Opening with the backbone establishes the correct proportion before the reader sees the list of limitations — without that context, five pieces marked "representative" could read as if they dominated the guide, when in reality they're the minority against a backbone of seven categories of central pieces, each actually executed and verified with literal evidence. It's the same honesty discipline, applied to the presentation order: declaring first what did run, with the same precision with which what didn't run gets declared afterward, keeps the absence of context from skewing this lesson's reading toward disproportionate self-criticism.
Summary and next step
This lesson brought together, in one place, the five pieces this guide left representative — X-Ray, CloudWatch Application Signals, AWS Systems Manager Incident Manager, PagerDuty/Opsgenie, and the real result of the DynamoDB backup attempt — each with its exact technical reason, cited from the lesson where it first appeared, never invented. You confirmed, with the backbone table, that these five pieces are the deliberate minority of a guide where Prometheus, Grafana, Alertmanager, Jaeger, the error budget calculator, the on-call rotation, and the two complete incidents — one real, one synthetic — actually ran, with literal evidence at every layer.
Before moving on you should be able to: name the five representative pieces and their exact technical reason without looking at this lesson; distinguish which are absent because of a LocalStack limit and which because of the service or product's own nature; and defend why an uncertain result, precisely documented, isn't the same as a failed one.
Lesson 7 looks outward from this guide: which parts of Andes Cargo's complete ecosystem — EKS, AI systems in production, deep observability as its own discipline — still await their own guide, and why this guide, deliberately, doesn't build them.
Resources
- LocalStack Docs — X-Ray and LocalStack Docs — CloudWatch — the source of the distinction between what is and isn't on the Hobby plan.
- AWS — Amazon CloudWatch Application Signals adds new SLO capabilities — the announcement cited in piece 2.
- AWS Docs — What Is AWS Systems Manager Incident Manager? — the verbatim quote on closure to new accounts.
- This same repository, Module 7, lesson 7 (
07-hands-on-the-honest-backup-restore-attempt.md) — piece 5's complete development. - This same repository,
DISENO.md— the honesty table and the hard "nothing gets simulated in prose" rule governing every piece in this lesson.