Module 8: Capstone Andes Cargo On Kubernetes
7. What Andes Cargo still needs
Description
This guide closes the aws-cloud-ecosystem ecosystem's container-orchestration chapter — andes-cargo-status-api actually runs, with real GitOps and real admission control on top. But a running cluster, with good admission guardrails, isn't a complete system — it's still missing knowing how much it costs, what to do when something breaks at three in the morning, and what would happen if Andes Cargo ever needed AI inference on this same infrastructure. This lesson maps, precisely and with nothing invented, the ecosystem's three real guides that cover exactly those three gaps — two of them, complete, exist today.
Connection to the module
This lesson revisits, with real names instead of placeholders, the boundary this guide's DISENO.md declared from the start: Kubernetes FinOps, SRE for the cluster itself, and GenAI/GPU over EKS fall outside this guide's scope by design — not by oversight. What this lesson adds is the confirmation, verified against each one's real content, that two of those three guides already exist, complete, in this ecosystem.
1. Kubernetes FinOps — finops-and-cost-guardrails-guide
The boundary this guide declared, from its own design: a guardrail in this guide is never "this is expensive," it's "this violates a policy" or "this failed the scan" — cost discipline is, deliberately, another guide's job.
The real state: finops-and-cost-guardrails-guide already exists, complete, in production (src/guides/finops-and-cost-guardrails-guide). It covers Lambda rightsizing with real Infracost data, PAY_PER_REQUEST versus PROVISIONED on DynamoDB, and per-team budgets — over Lambda, DynamoDB, and S3, not Kubernetes (this same module's previous lesson documented, with a textual quote, that its premise about "Andes Cargo has no containers" is still uncorrected, even though its technical scope is correct).
What Andes Cargo concretely still needs in this domain: everything a real production Kubernetes team would need to ask about this same cluster's cost, that no guide in the ecosystem builds yet: CPU and memory requests/limits rightsizing at the Pod level (the equivalent of the Lambda memory tuning finops-and-cost-guardrails-guide did do, applied to a Kubernetes manifest instead of a function); Compute Optimizer applied to a real cluster's nodes, instead of a serverless function; and the economics of node groups with mixed Spot versus On-Demand instances — a real EKS cost decision no guide in this ecosystem has built yet, because none has a real node group to experiment with.
2. SRE for the cluster itself — sre-and-incident-response-guide
The boundary this guide declared, from its own design: a Pod that goes into CrashLoopBackOff in production and wakes someone up at 3 a.m. is the kind of incident an SRE discipline would operate — this guide built the system that prevents it (probes, HPA, admission control), not the discipline of responding when it fails anyway.
The real state: sre-and-incident-response-guide already exists, complete, in production (src/guides/sre-and-incident-response-guide), with eight modules: what SRE and reliability are as a feature, SLI/SLO and the error budget, observability as SLI input, burn-rate alerts, an incident's lifecycle, operating an incident with Claude Code, blameless postmortems and runbooks, and its own capstone. Its capstone (Module 8, lesson 7, already cited in this module's previous lesson) explicitly names kubernetes-and-eks-in-production-guide as the place where its own vocabulary — SLI, SLO, error budget, burn rate, blameless postmortem — would get applied again, with completely different signals, if Andes Cargo migrated from Lambda to a cluster.
What Andes Cargo concretely still needs in this domain: a real SLI defined over andes-cargo-status-api running on andes-cargo-cluster (/shipments/<id> latency, the Service's error rate, not an API Gateway's); an explicit PodDisruptionBudget, which no lesson in this guide built; and a real postmortem written about an incident from this cluster — for example, this same module's lesson 4's finding (Kyverno blocking a Deployment Gatekeeper didn't cover) would be, on a real team, exactly the kind of operational surprise a postmortem would document, with concrete follow-up actions.
3. GenAI and inference over AWS infrastructure — genai-on-aws-production-guide
The boundary this guide declared, from its own design: GPU on nodes, inference, Karpenter for AI workloads, cost per token — named by contrast in this guide's Module 7, without being built, because Andes Cargo, at this case's manifest volume, doesn't need dedicated GPU capacity.
The real state, and the honest nuance worth spelling out here: genai-on-aws-production-guide already exists, complete, in production (src/guides/genai-on-aws-production-guide), with eight modules on real production GenAI on AWS: Bedrock's cost model, infrastructure as code for an AI endpoint, Bedrock guardrails and defense in depth, AI workload security, FinOps for tokens, and production observability/latency/evals. But that guide, in its own design, also doesn't build dedicated GPU over EKS — it explicitly declares that GPU on nodes, inference over Kubernetes, and Karpenter for AI workloads stay named by contrast, not built, for the same underlying reason this guide uses for complete EKS: dedicated GPU has no $0 path on LocalStack, not even on the Ultimate plan. In other words: GPU/inference over EKS is still a real gap in the complete ecosystem, named by two different guides, built by neither — not for lack of an assigned guide, but because no guide in this ecosystem today has a free path to actually run it.
What Andes Cargo concretely still needs in this domain: if Andes Cargo's volume ever grew enough to justify its own inference (instead of a Bedrock-managed model, which genai-on-aws-production-guide does cover), that's where dedicated GPU would come in, nodes with Karpenter provisioning accelerator-backed instances, and cost per token calculated over owned infrastructure instead of a managed API — a scenario that, given the ecosystem's current market evidence, no guide covers end to end yet, and that would remain the clearest honest gap for whoever continues expanding this ecosystem.
The summary table: three gaps, three real states
| Domain | Assigned guide | Verified status | What's missing, concretely |
|---|---|---|---|
| Kubernetes FinOps | finops-and-cost-guardrails-guide | ✅ Exists, complete — but no Kubernetes coverage | Pod rightsizing, node Compute Optimizer, node group Spot/On-Demand economics |
| Cluster SRE | sre-and-incident-response-guide | ✅ Exists, complete — names this guide by contrast, doesn't build on it | Real SLI for andes-cargo-status-api, PodDisruptionBudget, a real postmortem for an incident from this cluster |
| GenAI/GPU over EKS | genai-on-aws-production-guide | ⚠️ Exists, complete — but declares GPU/EKS outside its own $0 scope, same as this guide | Own inference with dedicated GPU, Karpenter for AI workloads, cost per token over owned infrastructure — real gap, no guide covers it today |
Analogy: the route map, with two roads paved and one still unopened
If the aws-cloud-ecosystem ecosystem were a route map from Andes Cargo toward the rest of its platform needs, two of the three roads this lesson points to are already paved, fully signposted, with real traffic flowing: the road toward cost (finops-and-cost-guardrails-guide) and the road toward operational reliability (sre-and-incident-response-guide) — neither one yet passes through Kubernetes-specific territory, but both exist, complete, ready for someone to build the missing stretch. The third road, toward AI inference with dedicated GPU, has two signs pointing at it — one from this guide, one from genai-on-aws-production-guide — and no real stretch of asphalt yet: both signs are honest about where that road would lead, but neither guide paved it, for the same underlying reason (real GPU costs real money, with no plan exception).
Common mistakes
Assuming "named by contrast" in two different guides means "covered twice" (rushed counting). What happens: someone, seeing that both this guide and genai-on-aws-production-guide mention GPU/EKS, assumes that between the two there's complete coverage. How to spot it: if your conclusion is "between the two guides, GPU over EKS is already solved." How to fix it: both guides declare, each in its own design, that GPU/EKS falls outside their executable scope — naming it twice by contrast isn't the same as building it once. It's still a real ecosystem gap, documented with more precision (two sources, not one), but unresolved.
Confusing "the guide exists" with "it covers the Andes Cargo case over Kubernetes" (surface reading of the status). What happens: someone reads "✅ Exists, complete" in the table and assumes finops-and-cost-guardrails-guide or sre-and-incident-response-guide already resolved this specific cluster's case. How to spot it: if you look, in either guide, for a concrete example about andes-cargo-status-api running on Kubernetes, and don't find it. How to fix it: both guides exist and are complete within their own scope (Lambda/DynamoDB/S3 for FinOps; Lambda/API for SRE) — neither extends that scope toward Kubernetes, and both say so explicitly at their boundary. "Exists" isn't the same as "covers this case."
Treating the GPU/EKS gap as a design failure of this guide (misplaced responsibility). What happens: someone concludes kubernetes-and-eks-in-production-guide "should have built" GPU over EKS, since it's the ecosystem's Kubernetes guide. How to spot it: if your question is "why didn't this guide do it, if it's the Kubernetes guide?" How to fix it: the reason, declared in this guide's own DISENO.md and independently confirmed by genai-on-aws-production-guide's own DISENO.md, is the same in both: dedicated GPU has no $0 path on LocalStack. It isn't an avoidable scope decision — it's a real limit of the simulation tool that carries this entire zero-cost ecosystem.
Exercises
Exercise 1 — Rebuild the three-domain table from memory. Without going back to this lesson, state, for each of the three domains (FinOps, SRE, GenAI/GPU), which guide covers it and whether that coverage includes the specific Kubernetes case or not.
See solution
FinOps → finops-and-cost-guardrails-guide, exists complete, doesn't cover Kubernetes. SRE → sre-and-incident-response-guide, exists complete, doesn't cover Kubernetes (though it names this guide by contrast). GenAI/GPU over EKS → genai-on-aws-production-guide, exists complete, but explicitly declares GPU/EKS outside its own executable scope — still a real ecosystem gap.
Exercise 2 — Explain why GenAI/GPU is a different case from FinOps and SRE. In two or three sentences, explain to a colleague the underlying difference between "a guide exists but doesn't cover Kubernetes" (FinOps, SRE) and "a guide exists but declares the topic outside its own executable scope" (GenAI/GPU).
See solution
A reasonable explanation: "In FinOps and SRE, the guide fully covers its own domain — that domain simply never included Kubernetes, because the Andes Cargo case, when those guides were written, didn't have a cluster yet. In GenAI/GPU, the guide does recognize the topic (GPU over EKS) as relevant, but explicitly decides not to build it because there's no free path to actually run it — it's a recognized, named gap, not an absence of scope due to the case's history."
Exercise 3 — Propose the concrete example that would close the SRE gap for Andes Cargo. Based on this same module's lesson 4's real finding (Kyverno blocking a Deployment Gatekeeper didn't cover), describe, in two or three sentences, what a blameless postmortem (sre-and-incident-response-guide's format) written about that same finding would look like.
See solution
A reasonable proposal: "The postmortem would describe the fact with no blame-seeking: a real change tried to remove resource limits from the production Deployment; Kyverno blocked it thanks to its autogen coverage, but Gatekeeper, configured since Module 6 with match.kinds: [\"Pod\"], wouldn't have reacted if Kyverno hadn't been active. The follow-up action (not blame, a system improvement) would be to explicitly add Deployment to Gatekeeper's Constraint's match.kinds, so protection doesn't depend on a single engine covering the complete scope — exactly the kind of finding a postmortem turns into a concrete, verifiable improvement of the guardrail system itself."
Summary and next step
This lesson mapped, with precision verified against each guide's real content, the three domains that fall outside this guide's scope by design: Kubernetes FinOps and cluster SRE each have a complete guide already written in this ecosystem — finops-and-cost-guardrails-guide and sre-and-incident-response-guide — though neither yet extends its discipline toward the specific Kubernetes case. GenAI/GPU over EKS also has a complete guide (genai-on-aws-production-guide), but that guide, with the same cost honesty as this one, declares the topic outside its own executable scope — it remains, of the three, the only genuinely uncovered gap in the entire ecosystem.
Before moving on you should be able to: name the three real guides on this map with no hesitation; explain why GenAI/GPU is a different case from FinOps/SRE in terms of what's missing; and propose, with a concrete example from this same guide, what the first step of each of the three disciplines applied to andes-cargo-status-api would look like.
Next lesson: final project, andes-cargo-k8s/ as the capstone deliverable. There this entire guide closes with the real repository — code, policies, cluster configuration — presented as a portfolio piece, with the honest checklist of what actually ran and what stayed representative.
Resources
finops-and-cost-guardrails-guide(NIEVA) — the ecosystem's complete FinOps guide, verified in this lesson.sre-and-incident-response-guide(NIEVA) — the ecosystem's complete SRE and incident response guide, verified in this lesson.genai-on-aws-production-guide(NIEVA) — the ecosystem's complete production GenAI on AWS guide, verified in this lesson, including its own declared GPU/EKS limit.src/paths/aws-cloud-ecosystem/VALIDACION.md— the market audit that originated this entire ecosystem's design, including the Kubernetes boundary this guide resolved.