Module 8: Capstone The Andes Cargo Genai Extractor
7. What Andes Cargo still needs
Description
This entire guide — eight modules, sixty-four lessons — built exactly the infrastructure Andes Cargo's current scale needs: an escalation path that's cheap to operate, with real guardrails and a budget that today rounds to zero dollars. None of that work assumed Andes Cargo would stay at exactly this size forever. This lesson looks forward, with this guide's same exact honesty: if the volume of escalated manifests grew enough, what would need to be built that this guide deliberately doesn't build? And, with that question answered, what's left for NIEVA's entire AWS ecosystem, beyond this guide?
Connection to the module
Lesson 6 closed the boundary looking backward, toward AI Engineering. This lesson opens the boundary looking forward, toward the rest of the aws-cloud-ecosystem — specifically toward kubernetes-and-eks-in-production-guide, the sibling guide that delegates here a piece this design, with evidence, decides not to build either. It's this guide's last content lesson before the final project.
Analogy: from hiring trucking by the trip to buying your own fleet
A small logistics company that starts growing doesn't buy its own truck fleet on day one — it hires trucking by the trip, pays per individual shipment, with no fixed investment at all. This guide left Andes Cargo exactly at that stage with its AI workload: pay per invocation (on-demand), with no fixed commitment. There's a point, further out, where shipment volume grows enough that hiring trucking by the trip stops being the cheapest option — that's where a real logistics company starts evaluating buying its own fleet. This lesson doesn't say that point is close; it says, with the same numerical rigor as the rest of this guide, exactly how far away it is, and what would need to be built the day it gets close.
Step 1 — The first threshold: Provisioned Throughput, already quantified
This guide's M6.7 already calculated, with two independent arithmetic paths, the exact point where buying Bedrock's reserved capacity (Provisioned Throughput) would start costing less than continuing to pay per invocation:
THE FIRST THRESHOLD, ALREADY MEASURED (M6.7)
Realistic scenario (GENAI-COST-PROFILE.md) 40 invocations/month
Stress scenario (GENAI-COST-PROFILE.md) 5,000 invocations/month
Deliberately disproportionate scenario 100,000 invocations/month
│
│ 2,593x distance
▼
Crossover point, 6-month commitment 259,285,714 invocations/monthThis threshold requires no new infrastructure this guide hasn't already named — according to M6.2, aws_bedrock_provisioned_model_throughput is a real Terraform resource, from the same hashicorp/aws provider aws_bedrock_guardrail already uses. The day Andes Cargo approaches that volume, the decision would still live inside Bedrock, with no need for dedicated GPU or a Kubernetes cluster — just a change in commitment level over the same infrastructure this guide already declared.
Step 2 — The second threshold, beyond what Bedrock solves: dedicated GPU
There's a different, more extreme scenario that not even Provisioned Throughput solves: that Andes Cargo, someday, decides not to use a managed Bedrock model at all — for full control over the model, for a data-residency requirement no managed AWS service satisfies, or because a model of its own, fine-tuned specifically for logistics manifests, beat every Bedrock offering on per-token cost at a high enough volume. That scenario would need dedicated GPU: nodes with real accelerators, a model-serving engine (something equivalent to what vLLM or TensorRT-LLM solve, for example), and a compute orchestrator that knows how to provision and deprovision that expensive capacity based on demand.
This guide doesn't build that scenario. No sibling guide in this ecosystem builds it today, either. kubernetes-and-eks-in-production-guide's DISENO.md explicitly delegates it toward this guide:
"GenAI on EKS (GPU on nodes, inference, Karpenter for AI workloads, cost per token) →
genai-on-aws-production-guide(not designed yet)."
And this same guide's DISENO.md, with evidence — not to avoid the work — decides not to fulfill that delegation:
WHY NO GUIDE BUILDS THIS SCENARIO
Dedicated GPU requires:
│
├── Nodes with real accelerators -- real hourly cost, no free
│ tier on any LocalStack plan, not even Ultimate
├── A model-serving engine really running
└── Real traffic to justify it
Andes Cargo, today:
│
├── 40-5,000 invocations/month -- 2,593x below the crossover
│ point of Provisioned Throughput (Step 1), which is
│ ALREADY cheaper than dedicated GPU at any smaller scale
└── No business case that justifies full control over a
model of its own -- the requirement doesn't exist, not just the $
Conclusion: name the scenario, precisely, without pretending a
$0 path exists that doesn't -- this same honesty discipline that
holds up this entire guide, applied here to a decision to NOT buildThis isn't a hidden ecosystem gap — it's a decision declared, with its reason, in both design documents: kubernetes-and-eks-in-production-guide names the scenario by contrast, without building GPU node groups or Karpenter provisioners for inference; this guide names the same scenario, with the same honesty, without building it either. Neither guide contradicts itself at the other's expense — both agree that a $0 path doesn't exist for this specific case.
Step 3 — The complete map: which guide solves each future scale
| If Andes Cargo's volume grows to... | The piece that would be needed | Where it would live |
|---|---|---|
| Hundreds of thousands of invocations/month, without changing managed model | Re-evaluate Provisioned Throughput with real data (M6.7 already leaves the formula) | Inside this same guide — an extension of bedrock.tf, not a new guide |
| A real requirement for full model control or data residency | Dedicated GPU, a model-serving engine, Karpenter for AI workloads | No guide assigned today — named by kubernetes-and-eks-in-production-guide and by this guide, built by neither |
| Formal certification of the knowledge accumulated across this ecosystem's eight guides | Structured review of every AWS service, in the exam's exact format | aws-saa-certification-guide — the ecosystem's declared close |
The middle row deliberately stays without a filled-in third column — it's the same kind of ecosystem gap, with no assigned guide, that Organizations/Control Tower already represents in other parts of this same aws-cloud-ecosystem. Naming it this way, instead of faking an answer, is the discipline that held this entire guide since M1.7.
Step 4 — The ecosystem's close: aws-saa-certification-guide
The eight guides in aws-cloud-ecosystem — including this one — each built an operable, real slice of Andes Cargo's infrastructure. aws-saa-certification-guide doesn't add a new slice of infrastructure: it's the review that turns that operated knowledge into the formal credential a job market recognizes — the AWS Certified Solutions Architect – Associate. src/paths/aws-cloud-ecosystem/STRATEGY.md confirms it precisely: the exam shows up named in most of the job descriptions that document analyzed, and aws-saa-certification-guide is the guide that closes the entire ecosystem, after the student has already operated — not just studied — every service the exam evaluates.
THE COMPLETE ECOSYSTEM, START TO FINISH
aws-core-services-guide (base services)
aws-serverless-and-containers-guide (serverless, containers)
terraform-and-iac-guide (infrastructure as code)
cicd-and-gitops-on-aws-guide (pipelines)
cloud-security-and-guardrails-guide (security)
finops-and-cost-guardrails-guide (cost)
sre-and-incident-response-guide (reliability)
kubernetes-and-eks-in-production-guide (managed Kubernetes)
genai-on-aws-production-guide (this guide -- generative AI)
│
▼
aws-saa-certification-guide (close -- the formal credential)Nine guides build; one closes with the exam. This lesson, and this guide, end exactly where STRATEGY.md said they would from the start.
Common mistakes
Reading Step 2 as if this guide "couldn't" build dedicated GPU due to lack of time or scope, instead of a real absence of a $0 path (confusing a design decision with a resource limitation). What happens: someone reads that no guide builds this scenario and assumes it's simply pending content that will get added someday. How to spot it: if your expectation is "surely a future version of this guide adds the GPU module." How to fix it: this lesson's Step 2 is explicit — no LocalStack plan, not even Ultimate, has a free path for dedicated GPU, and Andes Cargo, at its real volume, has no business case that justifies it. It's not a piece "not written yet" — it's a piece this design decides, with evidence, not to write while those two conditions hold.
Assuming Provisioned Throughput and dedicated GPU are the same decision at different degrees (of not distinguishing two fundamentally different architectures). What happens: someone reads Step 1 and Step 2 back to back and concludes they're two points on the same "more volume, more infrastructure" scale. How to spot it: if your summary of this lesson is "first Provisioned Throughput, then, with even more volume, GPU." How to fix it: these are two different architecture decisions, not two rungs of the same ladder — Provisioned Throughput is still a model managed by Bedrock, with reserved capacity instead of pay-per-token; dedicated GPU means leaving Bedrock entirely and operating the model yourself. This lesson's Step 3 separates them exactly for this reason: the first lives inside this same guide, extending bedrock.tf; the second has no assigned guide, in any ecosystem, today.
Concluding aws-saa-certification-guide is "more important" than the eight operational guides, because it's the one that closes the ecosystem (overvaluing the close over the construction). What happens: someone, seeing the certification is the last piece named, assumes it's the whole ecosystem's real goal, and the other eight guides are just preparation. How to spot it: if your summary of the complete ecosystem is "all of this exists to pass an exam." How to fix it: this same guide's M1.4 already quoted STRATEGY.md on the real market gap: "engineers who can demonstrate they build, deploy, and operate real generative AI applications... are getting significant market premiums" — the certification is the formal close, not the purpose. The eight guides build the real, demonstrable skill; the exam certifies, with a recognized credential, that skill exists. Order matters: operate first, certify after — never the reverse.
Exercises
Exercise 1 — Without looking at Step 1, recite from memory the approximate crossover point (in invocations/month) where Provisioned Throughput with a 6-month commitment would start being cheaper than On-Demand for Andes Cargo. How far is GENAI-COST-PROFILE.md's stress scenario from that point?
See solution
Approximately 259 million invocations a month (M6.7 calculated it precisely: 259,285,714). GENAI-COST-PROFILE.md's stress scenario — 5,000 invocations a month — is more than 50,000 times away from that point; even M6.6's deliberately disproportionate scenario (100,000/month) is 2,593 times away. If you remembered the order of magnitude (hundreds of millions, not thousands or millions), you have the decision's real scale clear.
Exercise 2 — Explain, in your own words, why Step 3's "dedicated GPU" row stays with no assigned guide, instead of this lesson simply saying "kubernetes-and-eks-in-production-guide would build that."
See solution
Because kubernetes-and-eks-in-production-guide, in its own DISENO.md, delegates that same scenario toward this guide, it doesn't build it itself — and this guide, in turn, with the same evidence of a missing $0 path, decides not to build it either. Saying "the Kubernetes guide would build it" would be inaccurate: that guide names the scenario by contrast, exactly the same way this lesson does here, without committing to build it. The gap is real and honest — neither guide solves it — and naming it with no assignment, instead of incorrectly attributing it to a guide that doesn't build it either, is the exact discipline this lesson models.
Exercise 3 — Predict what would happen to Step 3's "dedicated GPU" row if, someday, LocalStack Ultimate added a free plan for emulated-GPU instances. Would that, by itself, resolve the lack of an assigned guide?
See solution
No, that alone wouldn't be enough — it would only solve the technical half of the obstacle (a $0 path to declare and plan GPU infrastructure with Terraform, similar to how this guide already declares and plans bedrock.tf without being able to apply it). The obstacle's other half, explicitly named in Step 2, is that Andes Cargo has no real business case that justifies dedicated GPU at its current volume — that problem doesn't depend on LocalStack at all, it depends on the company's real traffic. Even with a complete $0 technical path, a guide that built dedicated GPU for a business case that doesn't need it would repeat, in a different domain, exactly the antipattern this same guide's M1.3 named first: using the most expensive tool available before the real problem justifies it.
Summary and next step
This lesson looked forward: it quantified, with M6.7's already-calculated numbers, how far Andes Cargo is from the point where Provisioned Throughput would start making sense (259 million invocations/month, more than 2,593 times above this guide's most aggressive scenario); it named, precisely and without pretending a nonexistent $0 path, the dedicated-GPU scenario that neither this guide nor kubernetes-and-eks-in-production-guide builds, with the exact quote of the delegation between both; and it closed aws-cloud-ecosystem's complete map, with aws-saa-certification-guide as its declared final piece.
Before moving on you should be able to: explain the difference between Provisioned Throughput and dedicated GPU as two different architecture decisions, not two degrees of the same one; cite, from memory or close to it, the exact reason no guide in this ecosystem builds dedicated GPU today; and correctly place aws-saa-certification-guide as the formal close, not the purpose, of the eight operational guides.
Lesson 8, this entire guide's final project, delivers the Andes Cargo repository — bedrock.tf, the custom guardrails, the Rego policies, the cost calculator, the observability metric, and this entire guide — as a single piece of portfolio, defensible line by line against any technical question.
Resources
- This same course, Module 6, lesson 7 (
07-on-demand-vs-provisioned-throughput-when-each-one-with-real-numbers.md) — the complete source of the crossover-point calculation cited in this lesson's Step 1. kubernetes-and-eks-in-production-guide/DISENO.md— the textual source of the "GenAI on EKS" delegation cited in Step 2.src/paths/aws-cloud-ecosystem/STRATEGY.md— the source ofaws-saa-certification-guide's position as the ecosystem's close, cited in Step 4.- AWS Docs — Provisioned Throughput for Amazon Bedrock — official reference for the mechanism this lesson's Step 1 quantifies.