Under the hood: the AWS decoder ring

The map names a dozen AWS services. Marketing pages describe what each one does for you; this chapter is about what each one actually is: the machinery underneath, and, again and again, the open-source project at the bottom that you can read, run, and in several cases outgrow AWS with.

Why bother looking down the stack? Three practical reasons, which this chapter keeps returning to:

1. Limits become predictable. When you know AgentCore sessions live in microVMs, the 8-hour session ceiling and the pricing model stop being arbitrary trivia and become obvious consequences of a design.
2. Pricing becomes legible. "CPU billed only while actively consumed" sounds like a promotion until you know the runtime can pause a microVM while your agent waits on a model response; then it is just physics.
3. Exit paths stay real. If a managed service is an operationalized open-source project plus an API, then "what would it take to run this ourselves" has a concrete answer, and that answer is your negotiating position and your contingency plan in one.

The theme, worth stating up front: what AWS mostly sells is operations, not secrets. The ideas, and much of the actual code, are public.

One project under everything: Firecracker

Start with the deepest layer, because one open-source project turns out to be the floor of nearly every service in this book.

In the early days of Lambda, AWS faced an ugly choice. Containers start fast and pack densely, but every container on a host shares one Linux kernel, and a kernel exploit in your function is a kernel exploit next to someone else's bank. Traditional virtual machines have the strong wall (each guest brings its own kernel; the host exposes only a narrow, hardware-shaped interface) but took seconds to boot and megabytes of overhead, because they faithfully emulate thirty years of PC hardware: BIOS, PCI buses, floppy controllers, all of it.

AWS's answer was to write a new virtual machine monitor with the nostalgia deleted, and, notably, to open-source it in 2018. Firecracker is about 50,000 lines of Rust that sit on KVM, the virtualization support already built into the Linux kernel, and emulate almost nothing: a virtio disk, a virtio network card, a serial console, a one-button keyboard. The published numbers from its NSDI 2020 paper: a microVM boots to running application code in under 125 milliseconds, costs under 5 MB of overhead, and a single host can start 150 of them per second. A companion process called the jailer wraps each microVM in a second fence (a locked-down process sandbox) so an escape would have to break two walls of different construction. Firecracker also snapshots: a booted microVM's memory and device state can be written to disk and restored in tens of milliseconds, which turns "boot a fresh isolated machine" into something you can do per request.

Now watch how much of the AWS agent stack is this one project wearing different uniforms:

• Lambda runs every function invocation in a Firecracker microVM; it has since 2018, trillions of invocations a month.
• Lambda SnapStart, the cold-start eliminator, is Firecracker's snapshot-restore: boot your runtime once at deploy time, snapshot it, restore the snapshot instead of booting thereafter.
• Fargate, the serverless container service, runs each task in a microVM, which is exactly why this book is comfortable running agent workers there.
• AgentCore Runtime gives every agent session "a dedicated microVM, terminated and its memory sanitized when the session ends." Same project, per-session.
• AgentCore Code Interpreter and Browser are microVM sandboxes with a tool-shaped API in front.

And because it is open source (Apache 2.0, on GitHub), Firecracker also runs outside AWS: Fly.io boots customer machines with it, CodeSandbox and E2B start developer and agent sandboxes with it, and in Part 5 you will boot it yourself on a bare-metal EC2 instance, build a root filesystem, take snapshots, and see precisely what the managed services wrap. That is the exit path made concrete: the wall AWS sells you is a wall you can also own.

Don't be confused: hypervisor vs VMM vs KVM. KVM is the part of the Linux kernel that lets a process create and run virtual CPUs using the hardware's virtualization instructions. A virtual machine monitor (VMM) like Firecracker is the userspace program that uses KVM and provides the virtual devices the guest sees. "Hypervisor" loosely names the whole sandwich. Firecracker did not replace KVM; it replaced the big general-purpose VMMs (like QEMU) with a minimal one for exactly this job.

Bedrock: what "managed model" actually means

Amazon Bedrock is AWS's model-hosting service: frontier models from several vendors (Anthropic's Claude among them, which this book uses throughout), served from AWS data centers behind one API, paid per token on your AWS bill. Unpacking the pieces:

• The weights live with AWS. Bedrock is not a proxy to some other company's cloud. The models are deployed inside AWS regions, which is why Bedrock can make data-residency and no-training-on-your-data promises, and why each region has real, physical capacity limits. Notably, much of Claude's serving capacity runs on Trainium, AWS's own machine-learning chips, under the Anthropic-AWS buildout publicly known as Project Rainier; the GPUs-only mental model of model serving is a generation out of date.
• One API across vendors. The Converse API gives every hosted model one request shape for chat, tools, and streaming, so swapping models is a string change rather than a rewrite. For the newest Claude models (Opus 4.7 and later), Bedrock additionally serves Anthropic's native Messages API shape directly (the endpoint AWS calls Mantle), with model ids like anthropic.claude-opus-4-8; you get Anthropic's own SDK ergonomics with AWS auth and billing.
• An inference profile is routing, not a model. When you call the profile for a Claude model, you are calling an indirection layer that spreads your traffic across capacity pools in several regions. This is why profiles are the unit of capacity planning, and why a region's bad day does not have to be yours.
• Quotas are physics with paperwork. Tokens-per-minute limits exist because the silicon serving your region is finite and shared. The governor we build in Part 6 is client-side cooperation with that fact.

One adjacent thing shares the name and deserves separation: Claude Platform on AWS is Anthropic operating its own full API surface on AWS infrastructure (bare model ids like claude-opus-4-8, AWS-style SigV4 signing, AWS Marketplace billing). Bedrock is AWS operating the serving. Part 2 gives the choosing guide; for now, know there are two doors into the same models and the book will always say which one it is walking through.

AgentCore: assembled from parts you can now name

Amazon Bedrock AgentCore is AWS's managed agent platform, and after the last two sections you can read its component list like an ingredients label rather than a brochure. For each component: what it is, and what it is made of.

• Runtime hosts your agent loop as a managed session: you bring the loop code (any framework, or none), it brings lifecycle, scaling, and isolation. Underneath: one Firecracker microVM per session, up to 8 hours per session, destroyed and memory-wiped at the end. The pricing follows the substrate: per-second, with CPU billed only while actively consumed, so the long stretches an agent spends awaiting a model response cost you memory but no compute. That single billing detail makes economically viable a class of long, mostly-waiting agents that would be absurd on always-on servers.
• Gateway turns things you already have (Lambda functions, REST APIs described by OpenAPI, and AWS-style Smithy models) into agent tools. Underneath: it is an MCP server factory. The tools it manufactures speak the open Model Context Protocol from the concepts chapter, which is why they work from any MCP-speaking agent, not just AWS's. (Smithy, for the curious, is the open-source interface-definition language in which AWS writes all of its own service APIs; Gateway understanding it natively means every AWS API is one step from being an agent tool.)
• Identity stores OAuth credentials and handles token flows so agents can act on a user's behalf without secrets ever appearing in prompts or sandboxes. It is the managed version of Part 8's rule that the agent acting for Alice holds only Alice-scoped credentials.
• Memory is managed short-term and long-term memory with extraction strategies, the buy-side counterpart of the store you build in Part 7.
• Code Interpreter and Browser are the microVM sandboxes described above, sold by the session.
• Observability emits traces in OpenTelemetry format, the CNCF-governed open standard for distributed tracing (AWS ships its own supported build of the OTEL toolchain, the AWS Distro for OpenTelemetry). Because the format is open, the same traces flow to CloudWatch's generative-AI dashboards or to any OTEL backend you already run.
• Policy, added after launch, enforces rules on agent behavior from outside the model's reasoning loop, where a jailbreak cannot reach them. Underneath: your natural-language rules are compiled to Cedar, AWS's open-source policy language (Rust implementation, formally verified core, the same engine behind Amazon Verified Permissions). The lesson generalizes and Part 8 repeats it: real guardrails live outside the model.
• Evaluations, also post-launch, is a managed grader suite (tool selection accuracy, goal success, safety) pointed at your agent traces: the buy-side of Part 9's eval chapter.

Worth knowing about the neighborhood: the original "Bedrock Agents" service (the one with action groups, from 2023) is now formally Agents Classic, in maintenance mode and closed to new customers as of July 2026. AWS consolidated on AgentCore, which is why this book spends a full part on it and mentions its predecessor only here.

The serverless skeleton, opened up

Lambda you now know: Firecracker microVMs on a giant bare-metal EC2 fleet, plus a scheduler that keeps warm microVMs around between invocations (which is all a "warm start" is). The famous 15-minute execution ceiling is a scheduling policy, not physics, and Part 4 treats it as a design input: short agent turns fit in Lambda; long fleets move to Fargate.

Step Functions is a workflow engine: you define a state machine (steps, transitions, retries, parallel branches) and AWS runs it durably for up to a year per execution. The definition language is the Amazon States Language, a published JSON specification, which has a consequence people miss: your orchestration logic is a document, diffable in code review and testable offline, not code hidden in a runtime. Two features earn their keep constantly in this book: waitForTaskToken, which parks an execution mid-flow until something (a human approver) posts a token back, giving us approval gates for free; and distributed map, which fans one step out over up to 10,000 parallel child executions with failure thresholds and a redrive button that re-runs only the failed children. That redrive button is checkpoint-and-resume, purchased rather than built.

SQS is the queue, and its at-least-once delivery promise is not a defect to work around but the honest contract explained in the concepts chapter: SQS is a replicated distributed log, and redelivery-after-uncertainty is what any honest replicated queue must do. Visibility timeouts (how long a taken message stays hidden before the queue assumes the worker died) become an agent-specific tuning problem, because agent tasks run minutes, not milliseconds. EventBridge is the event bus in front: services and SaaS apps publish events, rules pattern-match them, and matches trigger targets; it is how "an alarm fired" becomes "an agent woke up" without anything polling.

DynamoDB is the state store, and its lineage is worth knowing because it explains its personality. It descends from Amazon's 2007 Dynamo paper, the internal system (born from Oscar-season shopping-cart outages) whose publication helped launch the entire NoSQL movement. The modern service (described in a 2022 USENIX paper) keeps the creed: predictable single-digit-millisecond reads and writes at any scale, purchased by giving up SQL's flexibility. Two of its primitives carry Hive's control plane: conditional writes ("write this only if the current value is X"), which give us leases and exactly-once bookkeeping without a lock server, and TTL expiry, which makes leases self-cleaning.

S3 stores everything big (shards, artifacts, reports, and via S3 Vectors, embeddings), and OpenSearch, when we need it, carries its own open-source story: it is the fork of Elasticsearch that AWS created in 2021 when Elastic changed its license, and it has since been handed to the Linux Foundation. Part 7 stages a measured shoot-out between S3 Vectors (cheap, cold-tolerant, storage-first) and OpenSearch (fast, filterable, operationally heavier) rather than declaring a winner here.

The open protocol layer

The last layer is not infrastructure but agreements, all of them open:

• Strands Agents is AWS's open-source agent SDK (Apache 2.0, Python and TypeScript). It is the loop from Part 1, productionized: model-driven tool selection, sessions, and multi-agent primitives (agents-as-tools, swarm, graph, workflow). Two facts make it more than a courtesy library: AWS uses it internally for production agents (Amazon Q Developer and several AWS service teams), and it is model-agnostic, speaking to Bedrock, Anthropic's API directly, and others. Part 10 reads its source as a design review of everything Part 1 built by hand.
• MCP (Model Context Protocol) is the tool port from the concepts chapter: JSON-RPC based, started by Anthropic in November 2024, now the de facto standard; AgentCore Gateway manufactures it, Strands consumes it, and Part 10 hosts MCP servers on Lambda.
• A2A (Agent2Agent) is the agent-to-agent protocol, donated by Google to the Linux Foundation in 2025, at version 1.0 since 2026, with AWS among the 150-plus member organizations; AgentCore Runtime and Strands both speak it.
• Amazon Nova Act, AWS's browser-automation agent service, is worth a decoder line too: its SDK drives Chromium through Playwright, the open-source browser automation framework, with the model deciding what to do and Playwright doing it. The pattern should look familiar by now: judgment from a model, hands from an open-source project, operations from AWS.

The decoder ring, on one page

Read the right-hand column top to bottom and the chapter's thesis stares back: the AWS agent stack is, to a remarkable degree, open-source machinery with world-class operations wrapped around it. That is not a criticism. Operations is the hard part, which is why this book happily buys plenty of it. But it means every buy decision in the chapters ahead comes with a knowable build alternative, and the production bar can hold managed services to the same twelve gates as anything we write ourselves.

👉 Next: the production bar, where "production ready" stops being a vibe and becomes twelve testable gates.