Module 8: Capstone The Andes Cargo Reliability Package

7. What Andes Cargo still needs

Description

This guide closes the SRE gap VALIDACION.md marked CRITICAL for the entire aws-cloud-ecosystem since Module 1 — SLI/SLO/error budget math, burn rate alerting, an incident's complete lifecycle, honest on-call, blameless postmortems. But Andes Cargo, like any real system, doesn't end here: there are three concrete directions where the same vocabulary you built in this guide is needed again, with a different system behind it, and this lesson names them precisely — which guide covers them, and why this guide, deliberately, doesn't build them.

Connection to the module

Every boundary in this lesson was already declared in DISENO.md before a single lesson of this guide was written — this lesson discovers nothing new, it confirms, at the close, that every boundary was respected exactly as promised. Lesson 8, the final project, is going to cite this lesson as part of the portfolio: not just what you built, but also where what's still missing points.

First direction: EKS and its own SRE discipline

Andes Cargo, across this entire ecosystem, has no containers — this guide's SLI measures a Lambda and an API, never a pod. If Andes Cargo ever migrated process-shipment-manifest, or any new service, to a Kubernetes cluster, this guide's vocabulary (SLI, SLO, error budget, burn rate, blameless postmortem) would keep applying unchanged — but the signals feeding that vocabulary would be completely different:

This guide's concept	Its equivalent in an EKS world
`AWS/Lambda`/`Invocations`, `Errors` (Module 3)	Readiness and liveness probes per pod, pod restart rate
An alarm on a specific Lambda (Module 4)	A `PodDisruptionBudget` protecting against simultaneous disruptions
`process-shipment-manifest`'s SLO (Module 2)	A per-service SLO within the cluster, potentially different by namespace
`observability.tf` over a single Lambda	Observability at full-cluster scale, with dozens or hundreds of pods

kubernetes-and-eks-in-production-guide is this ecosystem's guide that builds that system and its own SRE discipline — this guide doesn't replace it or get ahead of it. The reason is simple and was already declared since DISENO.md: Andes Cargo, in the state the six sibling guides and this complete guide leave it in, is serverless end to end — introducing EKS here would mean adding a new business system, exactly what DISENO.md prohibited since its first paragraph ("this guide does not add a new business component to Andes Cargo").

Second direction: SRE for AI systems in production

The same vocabulary — SLI, SLO, error budget, burn rate — applies again, almost word for word, to a production AI inference system. The real difference isn't in the framework, it's in what counts as a golden signal:

   SAME VOCABULARY, DIFFERENT SIGNALS

   THIS GUIDE (process-shipment-manifest)      AI SYSTEMS IN PRODUCTION
   ────────────────────────────────────        ──────────────────────────
   Latency: the Lambda's execution time         Latency: time to first
                                                  token, total inference time
   Errors: validation ValueError,               Errors: detected hallucination,
   timeout, throttled invocation                 response rejected by a safety
                                                  classifier
   Saturation: ReservedConcurrentExecutions      Saturation: a model queue with
                                                  limited GPU capacity
   (new, no equivalent in this guide)            Cost per token as its own SLI,
                                                  not just separate FinOps
   (new, no equivalent in this guide)            Model drift: the model itself
                                                  gets worse over time, with
                                                  nobody changing any code

Two of these signals — cost per token as an SLI, and model drift — have no equivalent at all in process-shipment-manifest: they're questions that only make sense when the system being measured is, itself, a language model or an inference system. genai-on-aws-production-guide is this ecosystem's guide that builds that application of SRE to a real AI system. This guide names it, right here, as the next place where the vocabulary you just finished building is needed again — it doesn't build it, because Andes Cargo, across the full scope of this ecosystem's seven business guides, never had an AI inference component in production.

Third direction: deep observability, as its own discipline

DISENO.md declared this boundary with the most precision of the three, since the first module: this guide's Module 3 instrumented the bare minimum to have real data feeding an SLI — never the three pillars as a complete discipline. Every time a lesson in this guide touched metrics, logs, or traces, the question governing it was always "does this let me calculate a real SLI?", never "how do you instrument an application in general?"

What this guide never taught, and what remains monitoring-observability-guide's territory:

The complete difference between a counter, a gauge, a histogram, and a summary — this guide used both types where needed (Counter for accumulated invocations, Gauge for burn rate), but never taught the complete metric-type taxonomy.
How to instrument an application from scratch, deciding what to measure before having any SRE question in mind.
Deep Grafana dashboards — this guide built a minimal panel (Module 3, lesson 6) to confirm the data pipeline worked, never a complete dashboard-design discipline.
The complete telemetry stack of an organization with dozens of services, not just one.

That sibling guide's real state, declared with the same honesty as the rest of this ecosystem: at the time this guide was designed, monitoring-observability-guide had no DISENO.md of its own, and its inherited content (from AI Engineering) didn't cover AWS/infrastructure at all — VALIDACION.md already flagged it ⚠️ WEAK for that same reason, pointing to the same SLI/SLO/error budget gap this guide precisely closed. The resolution this ecosystem adopted: the SLI/SLO gap didn't live in the observability guide, it lived here — and now it's closed. The complete, deep three-pillar instrumentation discipline remains that sibling guide's pending work, not this one's.

What's left off the map, named without resolving it

Two more gaps, inherited from earlier guides in the ecosystem, that this guide also doesn't resolve — named here for completeness, not because this guide ever intended to close them:

Multi-account AWS, Organizations, Control Tower — inherited as a HIGH gap with no assigned guide since cloud-security-and-guardrails-guide. This guide operates within a single account (000000000000), the same one across this entire ecosystem, and never touched it.
Organization-scale disaster recovery — a Landing Zone with multi-region DR, complete cross-region failover runbooks. Outside the $0 scope and outside Andes Cargo's case (a single region, us-east-1). The only recovery attempt this guide did make — restoring a DynamoDB table from a backup, Module 7, lesson 7 — is the minimal case the Claude Code incident itself made relevant, deliberately scoped, never complete DR.

Common mistakes

Reading this lesson as a list of "what this guide should have built" (confusing a map toward other guides with a list of this guide's own pending tasks). What happens: someone, finishing this lesson, concludes this guide is incomplete because it doesn't cover EKS, AI in production, or deep instrumentation. How to spot it: if your evaluation of this guide judges it by what this lesson names, instead of by what this module's previous eight lessons already demonstrated with executed evidence. How to fix it: each of this lesson's three directions has a boundary declared since DISENO.md, before a single lesson was written — they aren't gaps discovered at the end, they're scope limits decided with the same precision governing every decision in this guide. A guide that "covers everything" with no declared boundary would be, in practice, a guide with no real focus.

Assuming "same vocabulary, different signals" means learning SRE for AI systems is trivial once you've finished this guide (underestimating how much really changes). What happens: someone, seeing the second direction's table, concludes applying SRE to an AI system is "the same thing, with different names." How to spot it: if your reading of that table stops at "the framework is the same" without noticing the two rows with no equivalent (cost per token, model drift). How to fix it: the framework — SLI, SLO, error budget, burn rate, blameless postmortem — does generalize, and that's the real value of having learned it here first. But deciding what a good SLI is for an inference system, with signals no traditional Lambda produces, is genuinely new work genai-on-aws-production-guide has to build from scratch — the transferred framework doesn't automatically solve what to measure in a different domain.

Treating the final section's two gaps ("What's left off the map") as if they were this guide's responsibility, just because they're mentioned here (confusing "named" with "adopted"). What happens: someone, reading about multi-account/Organizations or organization-scale DR, expects this guide — or some future lesson in this same guide — to resolve them. How to spot it: if your expectation after reading this section is "where in this guide does this get explained?" How to fix it: this lesson names them for exactly the same reason it names the three main directions — completing the ecosystem's map — with no intention of resolving them here. Both are gaps inherited from earlier guides, with no guide assigned yet across this entire ecosystem, not pending work for this specific guide.

Exercises

Exercise 1 — Without looking at the second direction's table, name the two signals of an AI system in production that have no direct equivalent in process-shipment-manifest.

See solution

Cost per token as its own SLI (distinct from a separate FinOps measurement) and model drift (the model itself getting worse over time with nobody changing the code). Neither makes sense for a Lambda that validates and processes text manifests — there's no "token" to cost per unit, and no model that can degrade over time without direct human intervention. These two signals are precisely what makes "SRE for AI systems" a genuinely new domain, not a mechanical application of the same framework.

Exercise 2 — A teammate, after finishing this guide, proposes starting genai-on-aws-production-guide without having completed kubernetes-and-eks-in-production-guide first, arguing that "AI systems almost always run in containers anyway." Does this reasoning contradict anything this lesson established?

See solution

Not necessarily — this lesson establishes no mandatory order between the two guides, it only names them as two different directions the same vocabulary extends toward. It's true that many production AI inference systems run on Kubernetes in practice, so already having EKS-specific SRE discipline (readiness probes, PodDisruptionBudget) would be useful as a foundation before facing the additional layer of AI-specific signals (cost per token, model drift). But this lesson, deliberately, doesn't impose a sequence — each guide has its own DESIGN with its own declared prerequisites, and the decision of which guide to take first depends on what real system whoever's choosing is building, not on a fixed rule from this module.

Exercise 3 — Explain why this lesson states the SLI/SLO/error budget gap "didn't live in the observability guide, it lived here — and now it's closed," instead of simply saying both guides share the same gap.

See solution

The distinction matters because, without it, someone might conclude monitoring-observability-guide still needs to build its own version of SLI/SLO/error budget to be complete — a duplication of effort this guide's own DISENO.md explicitly ruled out when designing the boundary between the two guides. Precisely stating that the gap "lived here" unambiguously declares which of the two guides has responsibility for that specific piece of SRE vocabulary — leaving monitoring-observability-guide with a narrower, clearer scope: three-pillar instrumentation as its own discipline, citing this guide for the SLI/SLO/error budget math instead of rebuilding it.

Summary and next step

This lesson mapped the three directions where this guide's vocabulary is needed again, with a different system behind it: EKS and its own SRE discipline (kubernetes-and-eks-in-production-guide, pod signals instead of Lambda), AI systems in production (genai-on-aws-production-guide, same framework, new signals like cost per token and model drift), and deep observability as a complete instrumentation discipline (monitoring-observability-guide, the boundary declared since this guide's first module). You named, without resolving them, two more gaps inherited from the complete ecosystem — multi-account/Organizations and organization-scale DR — that no existing guide covers yet.

Before moving on you should be able to: explain, for each of the three directions, what changes and what stays the same from this guide's vocabulary; name the two AI-system signals with no direct equivalent in Andes Cargo; and defend why the SLI/SLO/error budget gap got resolved here, not in the observability guide.

Lesson 8, this guide's final project, closes with Andes Cargo's complete reliability package as a portfolio piece — the final inventory of everything you built, verified one last time.

Resources

This same repository, DISENO.md — the "What this guide teaches (and does NOT)" section, the source of every boundary named in this lesson.
src/paths/aws-cloud-ecosystem/VALIDACION.md — monitoring-observability-guide's ⚠️ WEAK diagnosis, and the SLI/SLO gap this guide closed in its place.
kubernetes-and-eks-in-production-guide and genai-on-aws-production-guide — the two ecosystem guides where this guide's vocabulary gets applied again, with different systems.
Google SRE Book — Table of Contents — the original source of an SRE framework designed, from the start, to generalize beyond a single kind of system.

← Previous6. What this guide left representative, final honesty Next →8. Final project: Andes Cargo's reliability package as a deliverable