DEV Community: Jonathan Vogel

How to Build and Deploy an AI Agent on AWS with Bedrock, Strands, and AgentCore

Jonathan Vogel — Mon, 03 Aug 2026 16:45:16 +0000

A foundational look at building and deploying an AI agent on AWS, from a single model call to a managed cloud endpoint, so you understand what Bedrock, Strands and AgentCore each do and how they fit together.

If you prefer video format, check out this content on our YouTube channel.

TL;DR

What you build: the same question, "What should I make for dinner?", answered three ways. A raw model call, a local agent with one tool, then that same agent deployed to AWS. Each step shows what the next AWS layer adds.
The three layers: Amazon Bedrock is the model, the brain. Strands is the harness that gives it a tool and a loop. Amazon Bedrock AgentCore runs it in production.
What it costs: close to nothing. Chapters 1 and 2 are just local Node and a Bedrock call. Chapter 3 creates real resources you tear down at the end. Free Tier eligible accounts can cover it, and new AWS users can get up to $200 in credits.
Time: 30 minutes to breeze thru or 1+ hour if you're really taking your time to unpack each piece.

I asked an AI model what I should make for dinner. It gave me some suggestions and it asked me what ingredients I had on hand.

Duh! This is a critical question to get an idea of what to suggest and it had no idea. I had eggs, spinach, garlic, rice and some cheddar around the kitchen and the model couldn't see any of it. A sharp brain with no access to my world, getting one shot to guess.

That gap is the whole story of this post. A model on its own is smart and blind. To make it useful you wrap it in a harness that gives it tools and a loop. Then, once it works on your machine, you hit the next wall: running it for other people, around the clock, without babysitting a server.

I'll answer the same question three times, "What should I make for dinner?", and change what sits behind it. First a raw model call with nothing else. Then a local pantry chef agent with a single tool, get_pantry, that can actually check the kitchen. Then that same agent running on AWS. The tool only shows up in chapters two and three, once there's an agent to use it.

Here's the progression:

Raw Amazon Bedrock. Just the model. It answers, but it can't see the pantry.
A local Strands agent. Add one tool and a loop. Now it checks the pantry and grounds the answer.
The same agent on Amazon Bedrock AgentCore Runtime. Deployed to AWS. Now running in the cloud from a managed endpoint anyone you authorize can call.

By the end you'll have run all three and you'll know which AWS piece does what.

What's in this post

The mental model
Prerequisites
Chapter 1: Raw Bedrock, a brain with no eyes
Chapter 2: A local Strands agent, the loop that grounds the answer
Chapter 3: Deploy to AgentCore Runtime
Who can actually call this thing?
Cost and teardown
The extras you grow into: memory, gateway, observability
The whole stack in one picture
Reproduce this yourself

The mental model

One idea to hold onto before we write any code.

An agent is a model plus a harness. The model is the brain, the part that reads your request and reasons about it. The harness is the code around the brain that gives it tools, instructions and a loop to use them.

Map that onto AWS:

Amazon Bedrock gives you the brain. It's a managed, serverless way to call top models from Anthropic, Meta and others, with no GPUs to rent and no servers to run. You pick a model, send a prompt, get a response.
Strands is the harness. It's an open source SDK from AWS that runs the tool-calling loop for you and works with almost any model.
AgentCore is where the finished agent runs in production. Managed, serverless hosting for the agent, plus the extras it needs to operate out there like memory, a gateway to your APIs, observability and more.

Three layers that snap together. Pick your brain, build your agent, run it for real. The rest of this post is that sentence, in code.

Prerequisites

An AWS account. A personal one is fine. Free Tier eligible accounts can cover this whole thing, and new AWS users can get up to $200 in credits.
Bedrock model access. I use Claude in this demo, but you can use whatever model you want. Make sure it's enabled for your preferred Region in the Amazon Bedrock console.
Node.js 22 or newer. I ran v24. Check with node --version.
AWS CLI v2, configured. Run aws configure (or SSO), set a default Region, then confirm with aws sts get-caller-identity. If that returns your account, you're good. Install guide here.
A Region. I used us-east-1 for everything. The us.* model inference profiles resolve there and AgentCore Runtime is available there. If you pick a different Region, re-check that your model and AgentCore Runtime both exist in it before you start.

For Chapter 3 (the deploy), you also need two more things. You don't need them for Chapters 1 and 2, so you can install them later:

AWS CDK, installed globally with npm install -g aws-cdk.
A one-time CDK bootstrap of your account and Region. More on this when we get there. The short version: it creates a small CloudFormation stack in your account called CDKToolkit. It lives in the cloud, not in your project folder, and you only do it once.
The AgentCore CLI, installed with npm install -g @aws/agentcore.

Why this matters: Chapters 1 and 2 run on nothing but Node and your AWS credentials. If you only want to see a model answer and then an agent ground that answer, you can stop after Chapter 2 and never install the CDK or the AgentCore CLI.

Chapter 1: Raw Bedrock, a brain with no eyes

For this we're simply calling the model directly. We get a good answer but it ultimately ends by asking what's in your kitchen. That missing context is the gap the next chapter closes.

About the model and why your output will look different from mine. Every code sample here uses us.anthropic.claude-sonnet-5, the US cross-region inference profile for Claude Sonnet 5. One model across all three chapters keeps the comparison honest. Just know that model output is non-deterministic. Ask "What should I make for dinner?" twice and you might get the same dish in different words, or a different dish entirely. That's expected. Your recipe might not match mine and two of your own runs might not match either.

Set up the project

mkdir 01-bedrock-raw && cd 01-bedrock-raw
npm init -y
npm pkg set type=module
npm install @aws-sdk/client-bedrock-runtime
npm install -D tsx typescript @types/node

npm pkg set type=module matters. The code uses ES module import syntax and a top-level await, and that flag tells Node to treat the file as a module. We run TypeScript directly with tsx, so there's no separate compile step.

The whole file

Create bedrock.ts:

import { BedrockRuntimeClient, ConverseCommand } from '@aws-sdk/client-bedrock-runtime'

const client = new BedrockRuntimeClient({ region: 'us-east-1' })

const response = await client.send(new ConverseCommand({
  modelId: 'us.anthropic.claude-sonnet-5',
  messages: [
    { role: 'user', content: [{ text: 'What should I make for dinner?' }] },
  ],
}))

console.log(response.output?.message?.content?.[0]?.text)

Let's walk through and explain each part.

The client points at Bedrock in one Region:

const client = new BedrockRuntimeClient({ region: 'us-east-1' })

ConverseCommand is the Converse API, one consistent way to talk to any chat model on Bedrock. You name the model and hand it a list of messages:

const response = await client.send(new ConverseCommand({
  modelId: 'us.anthropic.claude-sonnet-5',
  messages: [
    { role: 'user', content: [{ text: 'What should I make for dinner?' }] },
  ],
}))

Then you dig the text out of the response. The path looks fussy because a message can hold more than one content block, so you reach for the first one:

console.log(response.output?.message?.content?.[0]?.text)

Run it

npx tsx bedrock.ts

What comes back

You get a helpful, generic answer. Here's a trimmed run (yours will differ, and the full list is longer):

# Dinner Ideas

I'd love to help! To give you good suggestions, it helps to know a bit more:

- What ingredients do you have on hand (or are willing to shop for)?
- How much time do you want to spend cooking?
- Any dietary preferences/restrictions?

...

Let me know what you've got in the fridge/pantry, and I can suggest something more specific!

Read that last line again. The model is asking me what's in my kitchen. It has no way to know so it makes some recommendations inspired by its training data and leaves us hanging a bit. Nothing is wrong with the model. It's sharp. It's just blind and it gets one shot to answer.

Chapter 2: A local Strands agent, the loop that grounds the answer

Now the same brain gets one tool and a loop. It checks the pantry before it answers and the reply changes completely.

Set up the project

mkdir 02-strands-agent && cd 02-strands-agent
npm init -y
npm pkg set type=module
npm install @strands-agents/sdk
npm install -D tsx typescript @types/node

The whole file

Create agent.ts:

import { Agent, tool, BedrockModel } from '@strands-agents/sdk'

const getPantry = tool({
  name: 'get_pantry',
  description: 'Return the ingredients the user has at home right now.',
  callback: () => ['eggs', 'spinach', 'garlic', 'rice', 'cheddar cheese'],
})

const agent = new Agent({
  model: new BedrockModel({ modelId: 'us.anthropic.claude-sonnet-5', region: 'us-east-1' }),
  tools: [getPantry],
  systemPrompt:
    'Suggest a recipe to make, check the pantry',
})

await agent.invoke('What should I make for dinner?')

Still short. The last line is the same request from Chapter 1. Everything above it is the harness. Let's break down the three pieces that matter.

The tool. This is the agent's connection to my world:

const getPantry = tool({
  name: 'get_pantry',
  description: 'Return the ingredients the user has at home right now.',
  callback: () => ['eggs', 'spinach', 'garlic', 'rice', 'cheddar cheese'],
})

The description is not a comment. The model reads it to decide when to call the tool, so write it for the model. This tool takes no arguments, so there's nothing else to declare. The callback is the code that runs when the model calls the tool. Mine returns a hardcoded array, which is perfect for a demo. In a real app this is where you might hit a database or an API.

The agent. Model, tools, instructions, wired together:

const agent = new Agent({
  model: new BedrockModel({ modelId: 'us.anthropic.claude-sonnet-5', region: 'us-east-1' }),
  tools: [getPantry],
  systemPrompt:
    'Suggest a recipe to make, check the pantry',
})

Same model as Chapter 1, on purpose, so you can see the brain didn't change. I pass it explicitly here, though the Strands TS SDK defaults to a Bedrock Claude Sonnet model if you leave it out. The systemPrompt tells the agent what to do and points it at the tool. The tools array is the list it's allowed to reach for.

The invocation. One line:

await agent.invoke('What should I make for dinner?')

No orchestration code. That's the part worth pausing on.

What the loop actually does

When you call invoke, Strands runs a cycle you didn't have to write:

The model reads the request and reasons about it.
It decides to call get_pantry.
Strands runs the tool and feeds the result back to the model.
The model looks at the ingredients and decides if it's done. If not, it goes again.

That cycle is the agentic loop. The whole reason to use an SDK like Strands is that you get the loop, the tool calling and the message plumbing for free. For a simple agent, all you need to bring is a tool and a prompt.

Run it

npx tsx agent.ts

What comes back

The Strands TypeScript SDK ships with a console printer that's on by default, so you see the agent think, call the tool and answer, with no logging code from you. A representative run (again, wording will vary):

Same brain. Same question. Completely different answer. It saw the eggs, spinach, garlic, rice and cheddar, and it built a real recipe around them instead of asking me what I had. I didn't write a loop, a parser or an orchestrator. I gave the model a tool and let Strands run the back and forth.

That's a working agent. On my laptop. Which is exactly where the next problem starts.

Chapter 3: Deploy to AgentCore Runtime

My agent ran great on my machine. Then I thought about letting other people use it. Now I'm thinking about hosting, scaling and keeping it healthy when more than one person shows up at once. I did not want to write and operate a web server just to expose one function.

That's what Amazon Bedrock AgentCore Runtime handles. It's a managed, serverless way to run your agent in production. You bring the agent you already wrote, the CLI wraps it and ships it, and you get an endpoint back. Same agent logic, no server for you to run.

Same pantry chef from Chapter 2, now put behind a managed endpoint with the AgentCore CLI.

Install the deploy tooling

npm install -g @aws/agentcore aws-cdk
agentcore --version   # I had 0.21.1
cdk --version         # I had 2.1128.1

Bootstrap once (this is the "we bootstrap this thing" step)

AgentCore deploys through the AWS CDK, and the CDK needs a one-time setup per account and Region called a bootstrap:

cdk bootstrap aws://<ACCOUNT_ID>/us-east-1

Swap in your 12-digit account ID. This creates a CloudFormation stack named CDKToolkit and a small supporting S3 bucket. You only do this once per account and Region, so if you've bootstrapped here before you can skip it. To check:

aws cloudformation describe-stacks --region us-east-1 --stack-name CDKToolkit

If that returns a stack with status CREATE_COMPLETE, you're already bootstrapped. More on bootstrapping here.

Scaffold the project

The agentcore create command scaffolds a new agent project. It can walk you through an interactive wizard, but I'll pass the options directly so the step is repeatable and you can see exactly what we picked:

agentcore create \
  --project-name PantryChef --name PantryChef --type create \
  --build CodeZip --language TypeScript --framework Strands \
  --model-provider Bedrock --memory none --skip-git

Those flags say: a TypeScript project called PantryChef, built as a CodeZip (your code shipped as a zip), on the Strands framework with Bedrock as the model provider and no memory feature for now. It runs npm install under the hood, so give it a moment. When it's done you have a PantryChef/ directory that looks like this:

PantryChef/
  agentcore/
    agentcore.json          # runtime config: CodeZip, NODE_22, PUBLIC, HTTP
    cdk/                    # the CDK app the CLI deploys for you
  app/PantryChef/
    main.ts                 # entrypoint: wraps your agent in a runtime handler
    model/load.ts           # the model config lives HERE, not in main.ts
    mcp_client/client.ts    # an example MCP client, unused by our agent
    package.json
    tsconfig.json

The scaffold is a sample agent, not our agent

Here's the thing the video does off camera. agentcore create does not hand you a blank project. It generates a working sample agent, and the sample is not the pantry chef. Two files ship with content you have to replace.

First, the model. Open app/PantryChef/model/load.ts and you'll see this:

import { BedrockModel } from '@strands-agents/sdk/models/bedrock';

export function loadModel(): BedrockModel {
  return new BedrockModel({ modelId: 'global.anthropic.claude-sonnet-4-5-20250929-v1:0' });
}

That's a real, pinned model ID, and it is not the one this demo uses. The scaffold defaults to Claude Sonnet 4.5. We've been running Sonnet 5 everywhere, so this file has to change.

Second, the agent itself. Open app/PantryChef/main.ts and you'll find a sample that adds two numbers and wires up an example MCP client:

import { BedrockAgentCoreApp } from 'bedrock-agentcore/runtime';
import { Agent, McpClient, tool, type ToolList } from '@strands-agents/sdk';
import { z } from 'zod';
import { loadModel } from './model/load.js';
import { getStreamableHttpMcpClient } from './mcp_client/client.js';

// Define a collection of MCP clients (filter out anything that failed to initialize)
const mcpClients: McpClient[] = [getStreamableHttpMcpClient()].filter(
  (client): client is McpClient => Boolean(client)
);

// Define a collection of tools used by the model
const tools: ToolList = [];

// Define a simple function tool — the Zod schema gives us type inference and runtime validation for free
const addNumbers = tool({
  name: 'add_numbers',
  description: 'Return the sum of two numbers',
  inputSchema: z.object({
    a: z.number(),
    b: z.number(),
  }),
  callback: async ({ a, b }) => a + b,
});
tools.push(addNumbers);

// Add MCP clients to tools
tools.push(...mcpClients);

const SYSTEM_PROMPT = `
You are a helpful assistant. Use tools when appropriate.
`;

// ... the rest of the file (the runtime handler) is shown below

New to MCP? Don't worry about it too much right now. It's a standard way to plug external tools into an agent. The scaffold includes an example client to show it's possible but the pantry chef doesn't need it. We're about to replace the whole sample with our own tool and prompt.

So "the agent logic stays the same" is true for the tool, the prompt and the model, but there's real runtime plumbing around it that the CLI wrote for you. Turning this sample into the pantry chef is exactly two edits.

Edit 1: swap the model in `app/PantryChef/model/load.ts`

Replace the whole file with this:

import { BedrockModel } from '@strands-agents/sdk/models/bedrock';

export function loadModel(): BedrockModel {
  return new BedrockModel({ modelId: 'us.anthropic.claude-sonnet-5', region: 'us-east-1' });
}

Two changes from the scaffold. The model ID is now us.anthropic.claude-sonnet-5, and I added region: 'us-east-1' so the model resolves in the Region we've been using.

Edit 2: make it the pantry chef in `app/PantryChef/main.ts`

Replace the whole file with this. It's our get_pantry tool and prompt from Chapter 2, dropped into the runtime handler the CLI generated:

import { BedrockAgentCoreApp } from 'bedrock-agentcore/runtime';
import { Agent, tool, type ToolList } from '@strands-agents/sdk';
import { loadModel } from './model/load.js';

// The one tool this agent has: what is in the kitchen right now.
const getPantry = tool({
  name: 'get_pantry',
  description: 'Return the ingredients the user has at home right now.',
  callback: () => ['eggs', 'spinach', 'garlic', 'rice', 'cheddar cheese'],
});

const tools: ToolList = [getPantry];

const SYSTEM_PROMPT = `
Suggest a recipe to make, check the pantry
`;

let cachedAgent: Agent | null = null;

async function getOrCreateAgent(): Promise<Agent> {
  if (!cachedAgent) {
    const model = await loadModel();
    cachedAgent = new Agent({
      model,
      systemPrompt: SYSTEM_PROMPT,
      tools,
    });
  }
  return cachedAgent;
}

const app = new BedrockAgentCoreApp({
  invocationHandler: {
    async *process(payload: any, context: any) {
      const agent = await getOrCreateAgent();

      for await (const event of agent.stream(payload.prompt ?? '')) {
        if (
          event.type === 'modelStreamUpdateEvent' &&
          event.event?.type === 'modelContentBlockDeltaEvent' &&
          event.event.delta?.type === 'textDelta'
        ) {
          yield { data: event.event.delta.text };
        }
      }
    },
  },
});

app.run({ port: parseInt(process.env.PORT ?? '8080') });

The top half is the Chapter 2 agent, unchanged. Notice there's no zod here. The scaffold imported it for its sample add_numbers tool, which takes arguments that need a schema, but get_pantry takes none. The Strands tool() helper treats inputSchema as optional and defaults to an empty schema, so dropping zod changes nothing about the tool the model sees. The bottom half is the part the CLI gave you, and it's worth understanding because it's what makes this a deployable service instead of a script.

getOrCreateAgent builds the agent once and caches it, so you're not rebuilding it on every request:

let cachedAgent: Agent | null = null;

async function getOrCreateAgent(): Promise<Agent> {
  if (!cachedAgent) {
    const model = await loadModel();
    cachedAgent = new Agent({ model, systemPrompt: SYSTEM_PROMPT, tools });
  }
  return cachedAgent;
}

BedrockAgentCoreApp is the runtime handler. This is the part you'd otherwise hand write as a web server. The process generator receives the incoming request payload, streams the agent's output and yields just the text as it's produced:

const app = new BedrockAgentCoreApp({
  invocationHandler: {
    async *process(payload: any, context: any) {
      const agent = await getOrCreateAgent();
      for await (const event of agent.stream(payload.prompt ?? '')) {
        if (
          event.type === 'modelStreamUpdateEvent' &&
          event.event?.type === 'modelContentBlockDeltaEvent' &&
          event.event.delta?.type === 'textDelta'
        ) {
          yield { data: event.event.delta.text };
        }
      }
    },
  },
});

app.run({ port: parseInt(process.env.PORT ?? '8080') });

Notice what this handler streams: only the text deltas. So a caller sees the recipe but not the get_pantry tool-call line. The tool still runs on the server. You just don't stream that part to the client. Hold that thought for the observability note near the end.

You do not need to run npm run build. Local dev runs your TypeScript directly, and the deploy compiles and bundles during the CDK step. There's no manual build in this workflow.

Run it locally first

The CLI gives you a local server that behaves like the deployed one. Open two terminals, both inside the PantryChef directory.

Terminal 1, start the server (give it a few seconds to come up):

cd PantryChef
agentcore dev --logs

Terminal 2, send the prompt:

agentcore dev "What should I make for dinner?" --stream

You'll see the fried rice recipe stream back in Terminal 2. Over in Terminal 1, the --logs output shows the get_pantry tool firing on the server side, which is the tool call the streamed client output doesn't show.

Deploy it

If you want to see what the deploy will do before it does it, preview first:

agentcore deploy --dry-run

Then ship it:

agentcore deploy -y -v

This takes a minute or so. Under the hood the CLI zips your code and uses the CDK to create a handful of resources: a CloudFormation stack named AgentCore-PantryChef-default, an IAM execution role with its policy and the AWS::BedrockAgentCore::Runtime itself. When it finishes it prints the outputs, which look like this (account ID shown as a placeholder):

Runtime ARN: arn:aws:bedrock-agentcore:us-east-1:111122223333:runtime/PantryChef_PantryChef-xxxxxxxxxx
Runtime ID:  PantryChef_PantryChef-xxxxxxxxxx
Role ARN:    arn:aws:iam::111122223333:role/AgentCore-PantryChef-defa-ApplicationAgentPantryChe-xxxxxxxxxxxx
Stack:       AgentCore-PantryChef-default

Invoke it from the cloud

agentcore invoke "What should I make for dinner?" --stream

A few seconds later, the same kitchen assistant answers, this time from the managed runtime instead of your laptop:

That Session ID at the end is worth noticing. Each invoke without a session ID starts a fresh conversation. Same grounded answer as the laptop, now coming from an endpoint other people can call, with no server for you to run.

Want to check on it later?

agentcore status
# PantryChef: Deployed - Runtime: READY

The four commands, start to finish

That's the whole deploy loop, and it really is four commands once the tooling is in place:

agentcore create   # scaffold: TypeScript, Strands, CodeZip
agentcore dev      # run and test locally
agentcore deploy   # ship to AWS via CDK
agentcore invoke "What should I make for dinner?"

The only thing the video hides between create and dev is the two-file edit you just did by hand.

Who can actually call this thing?

The runtime we deployed uses networkMode: PUBLIC. That phrase sounds alarming, so let's be precise about what it means, because it does not mean an open, anonymous endpoint.

Public here means reachable over the internet, not open to everyone. By default an AgentCore Runtime endpoint is public on the network, but every request has to be authenticated, either with AWS IAM (SigV4) or an OAuth bearer token. With the default IAM setup, "anyone can call it" really means "anyone you grant the bedrock-agentcore:InvokeAgentRuntime permission to." No credentials, no call. It is not a URL a stranger can hit.

If you've read my IAM post, you know where this is going. The execution role and policy the AgentCore CLI generated are fine for a demo, but AWS is explicit that CLI-generated policies are meant for development and testing, not production. Before you put anything real behind this, scope the permissions down to the specific runtime ARN and the specific callers that need it. Least privilege, same as everywhere else in AWS.

Cost and teardown

The deploy left real, billable resources running: the AgentCore runtime, an IAM role and a CloudFormation stack. When you're done experimenting, tear them down. From inside the PantryChef directory:

agentcore remove all -y     # clears the agentcore config
agentcore deploy -y         # applies the removal, tears down the AWS resources

Yes, you run deploy to tear down. The first command empties the config, the second pushes that empty state to AWS, which removes the stack.

Verify it's actually gone:

aws cloudformation describe-stacks --region us-east-1 \
  --stack-name AgentCore-PantryChef-default
# should error: Stack ... does not exist

aws bedrock-agentcore-control list-agent-runtimes --region us-east-1 \
  --query "agentRuntimes[].agentRuntimeName" --output text
# your PantryChef runtime should no longer be listed

Leave the CDKToolkit bootstrap stack in place. It costs almost nothing, it's shared by any CDK work in the account, and you don't want to re-bootstrap next time. Only remove it if you're certain nothing else in that account and Region uses the CDK.

The extras you grow into: memory, gateway, observability

Hosting is the headline, but AgentCore brings more building blocks you pull in when you actually need them. Three worth naming.

Memory lets your agent remember people across conversations. My pantry chef could remember that I like spicy food without me saying it every time.
Gateway turns APIs and Lambda functions you already have into tools the agent can call, so you're not hand writing every integration. Today get_pantry returns a hardcoded list. A real version would call an API, and Gateway is how you'd wire that up.
Observability shows you what the agent actually did. Remember how the streamed output hid the get_pantry tool call? This is where you'd see it, the full trace of the agent's reasoning and tool use, for when something looks off.

You reach for these when your agent needs them. Not before. There's more we didn't cover, like Identity and payments. If you're curious, the Amazon Bedrock AgentCore docs walk through the full set.

The whole stack in one picture

Step back and look at what you built.

Bedrock is the brain. It reasons, but on its own it can't see your world.
Strands is the harness. It gives the brain a tool and runs the agentic loop, which turns a smart guess into a grounded answer.
AgentCore is production. It takes the agent off your laptop and runs it as a managed endpoint, with memory, gateway and observability waiting when you need them.

Three layers that snap together. Pick your brain, build your agent, run it for real. Same pantry chef the whole way, same dinner question, and you watched the answer go from a generic list to a real recipe to that same recipe served from the cloud.

Reproduce this yourself

Everything above runs on AWS today. Here's the checklist I use to confirm a clean run, top to bottom.

[ ] aws sts get-caller-identity returns the account you intend to use, and your Region is set.
[ ] Bedrock model access is enabled for us.anthropic.claude-sonnet-5 in your Region.
[ ] The model resolves: aws bedrock list-inference-profiles --region us-east-1 shows it ACTIVE.
[ ] Chapter 1: npx tsx bedrock.ts prints a generic answer that asks what ingredients you have.
[ ] Chapter 2: npx tsx agent.ts shows the get_pantry tool call and a recipe built from the pantry.
[ ] Deploy tooling: agentcore --version and cdk --version both succeed.
[ ] CDK is bootstrapped, or CDKToolkit already shows CREATE_COMPLETE.
[ ] agentcore create produced the PantryChef/ scaffold.
[ ] Both edits are applied: the model in model/load.ts and the get_pantry tool plus prompt in main.ts.
[ ] agentcore dev with --stream returns the grounded recipe locally.
[ ] agentcore deploy succeeds and prints the runtime outputs.
[ ] agentcore invoke --stream returns the recipe from the cloud and a Session ID.
[ ] Teardown done: the stack and the runtime are both gone, and CDKToolkit is left in place.

Your turn

You've watched me type every command so we could see the concepts with nothing in the way. In practice, most people building agents aren't typing this by hand. You might be using an agent to help you move faster, examples include agentic coding tools like Kiro, Claude Code, Codex or something similiar to move faster. Whatever you use, set up the Agent Toolkit for AWS so your agent knows best how to work with AWS.

Build something and ship it. Tell me what your agent does in the comments.

A model on its own is all brains. Make it an agent, give it a tool, a loop and a place to run, and it gets to work.

us-east-1 or Somewhere Closer? How to Pick an AWS Region Without Overthinking It

Jonathan Vogel — Fri, 05 Jun 2026 15:21:21 +0000

A 30-second decision on your very first screen that saves a lot of confusion later.

You sign up for AWS, open the console for the first time, and before you've built anything there's a dropdown in the top-right corner asking you to pick a Region. N. Virginia. Ohio. Ireland. Tokyo. A couple dozen options and no context for what any of them mean or why you'd choose one over another.

So you do what most people do. You leave it on whatever it defaulted to, or you pick one that sounds close, and you move on. Then a week later you come back, switch something, and your S3 bucket is gone. Your EC2 instance is gone. Everything you built looks like it vanished.

Not a good feeling until you realize it's all good, everything's there, you're simply looking in the wrong Region.

I talk to students and AWS beginners who run into this scenario. What's up with the Region drop down and why does it matter? By the end of this post you'll know what a Region is, the four things that go into picking one, why most of them don't matter for you yet, and why your stuff seems to disappear when you switch.

Quick note before we start. If you search around, most Region guidance is written for companies shipping production workloads. The advice is good and I link to the best of it below, but it carries an unspoken assumption: that this choice is heavy and you'd better get it right. For a student on a first project, that framing is backwards. Your Region choice is low-stakes and easy to redo. I regularly get asked by folks getting started with AWS which region to pick. This post is for you.

What a Region actually is

A Region is a physical location in the world where AWS runs a cluster of data centers. US East (N. Virginia) is a real set of buildings in Virginia. Europe (Ireland) is a real set of buildings in Ireland. When you launch an EC2 instance or create an S3 bucket in a Region, your stuff physically lives in that part of the world.

The list of AWS regions continues to grow. In June 2026, AWS runs 39 Regions and 123 Availability Zones around the world, with more announced. You don't need to memorize them. You need to pick one and understand the reasons why people end up in one region or another. The high level reasoning doesn't change even as more regions continue to launch.

The four things that actually matter

AWS publishes a short list of what goes into a Region choice. There are four factors you should be aware of. While it might be worth bookmarking that post, it is aimed at teams choosing a home for a real production workload. Let's walk through the same four factors through a beginner lens.

1. Latency. This is the big one for anything people interact with. The closer a Region is to whoever uses your app, the faster it feels, because the data has less physical distance to travel. A site hosted in Tokyo will feel snappy in Osaka compared to say Toronto. For a student building a portfolio project, "whoever uses your app" is mostly you and whoever clicks the link on your resume, so closer to you wins.

2. Cost. AWS prices the same service differently depending on the Region. The differences come from real-world costs like land, power and taxes in each location. The gaps are real but small at the scale you'll be working at. You can check exact numbers in the AWS Pricing Calculator when it matters. One thing to put out of your mind: free tier limits are account-wide, not Region-specific, so your Region choice won't affect your free tier eligibility.

3. Service availability. AWS rolls new services and features out Region by Region. A smaller Region might not have that brand-new service you read about yet, though it's just as reliable, the newest features simply land in the bigger Regions first. For the core building blocks a beginner uses, EC2, S3, Lambda, RDS, every Region has them (you can check what's where on the Region services list or the Builder Center's visual capabilities page).

4. Compliance and data residency. Some data is legally required to stay inside a specific country or jurisdiction. If you're handling that kind of data, this factor overrides the other three. As a student on a personal project, this almost never applies to you. It's worth knowing it exists, because the day a job hands you regulated data, this becomes the first question you ask, not the last.

Notice the order of who cares about what. A bank cares about compliance first. A game backend cares about latency first. A data-crunching batch job that no human waits on cares about cost first. Right now, you care about latency, which conveniently points to the simplest possible answer.

There's technically a fifth factor AWS publishes for teams with sustainability goals: some Regions run on cleaner energy than others. Don't worry about this as a beginner. If you care about your footprint, you'll have far more impact by turning off resources you're not using than by hunting for a greener Region. This same instinct will help keep your bill lower too!

For your first project, pick the closest one and move on

The beginner shortcut: pick the Region closest to you and stick with it for everything. This move will ensure you don't have to worry about latency for a personal project and give you the services you need as a beginner.

One nuance worth a sentence. A lot of tutorials and AWS examples default to us-east-1 (N. Virginia), and some guides quietly assume you're in it. It's worth noting us-east-1 is often the first Region to get the latest goodies AWS drops, new services tend to start there before they're available anywhere else. If you're following a step-by-step guide and something won't line up, check whether the author is in us-east-1 while you're somewhere else. For your own building, closest-to-you is the better default. For following along with a tutorial, matching the tutorial's Region can save you a headache.

The part that matters more than which Region you pick is picking one and being consistent. Which brings us to the thing that trips up almost everyone.

"But what if I pick wrong?"

You won't and you're not stuck there. If you start in Ohio and later decide Ireland is closer to your users, you spin up fresh resources in Ireland and tear down the old ones. There's no penalty, no lock-in, no big migration task for a personal app with a handful of resources. The companies that agonize over this are moving terabytes of data and thousands of resources, where moving might take a bit more work. You are moving a bucket and an instance. Pick one, learn on it, change your mind freely. The cost of "wrong" at your scale is measured in minutes instead of weeks or months.

Why your bucket "disappeared" (one of the gotchas)

Most AWS resources are Region-scoped. That means a resource you create lives in exactly one Region and shows up only when you're viewing that Region in the console. Each Region is fully isolated from the others, by design, so a problem in one Region can't take down another.

So picture this. You create an EC2 instance in Ireland on Monday. On Wednesday you open the console, the Region dropdown happens to say Ohio, and you go looking for your instance. It's not there. Panic.

Nothing got deleted. You're standing in a different room. Switch to Ireland and your instance is right where you left it.

This is exactly how beginners end up scattering resources without realizing it. You do one tutorial in us-east-1, a class project in us-west-2, and a weekend experiment somewhere else. Now your account has things spread across three Regions. You can't find your stuff, your bill has charges from Regions you forgot you touched, and resources look "missing" when they're just somewhere else.

Future you will be grateful for picking a region and sticking to it in the beginning.

The exception that's worth knowing

A handful of AWS services are global, not Region-scoped, so they look the same no matter what the dropdown says. The ones you'll meet early are IAM (users and permissions), billing (account-wide), and likely Route 53 / CloudFront. So if your IAM users don't change when you switch Regions, that's correct. They're global. Everything else, assume it's tied to a Region until you learn otherwise.

The 30-second decision, as a flow

When deciding on a region, run this in your head.

Is there a legal rule about where this data must live? If yes, pick a compliant Region in that jurisdiction. Done. (As a student, you'll almost always skip this.)
Does a human wait on this app? If yes, pick the Region closest to those people. For a personal project, that's closest to you.
No humans waiting, just background number-crunching? Pick the cheapest Region that has the services you need.
Following a tutorial that assumes a Region? Match it.

Then, the rule that ties it all together. Whatever you pick, use it for everything in this project so your resources don't scatter.

Quick reference

Region decision factor	What it means	Does it matter for your first project?
Latency	Closer Region = faster for users	Yes. Pick closest to you.
Cost	Same service, slightly different price per Region	Barely. Differences are small at your scale.
Service availability	Newer features land in bigger Regions first	No. Core services are everywhere.
Compliance	Data legally bound to a location	Almost never for students. Know it exists.
Consistency	Keep everything in one Region	Yes. This is the one that saves you pain.

Gotcha	Why it happens	What to do
"My resource disappeared"	Resources are Region-scoped; you switched Regions	Switch the dropdown back to the Region you built in
Charges from a Region you forgot	You scattered resources across Regions	Pick one Region and stay in it; clean up the strays
IAM users look the same everywhere	IAM is a global service	That's correct, nothing to fix

What's next

Picking a Region is step one. The next fear most beginners have is the bill. If you've heard the horror stories about surprise AWS charges, read You Deleted Everything and AWS Is Still Charging You next. It walks through what actually keeps costing you after you think you've cleaned up, and how to set a billing alarm so nothing sneaks past you. Pair these two and you've handled the two things that scare people off AWS on day one.

The Region dropdown isn't a test you can fail. Pick the one closest to you, keep everything there, and keep building.

Access Denied: What Every AWS Beginner Gets Wrong About IAM

Jonathan Vogel — Wed, 20 May 2026 19:45:19 +0000

The IAM mental model I wish someone had drawn on a whiteboard for me when I was starting out with AWS.

If you want a video to follow along with this blog, you can find it on the AWS Developers Youtube Channel

I spun up a Lambda function and tried to have it read from an S3 bucket only to get Access Denied.

This wasn't a typo or misconfiguration. I just straight up didn't understand IAM. So I did what every beginner does, I attached AdministratorAccess, the error went away, and I moved on.

What I didn't think about at the time is that I'd just given that Lambda function permission to do anything in my account. Delete databases. Create resources that cost money. Access data across every service it had no business touching. All because it needed to read from one S3 bucket.

I talk to students and developers getting started with AWS all the time, and this is the pattern. Everything goes smooth when you follow the tutorial. When it comes to implementing your own project, you run into a permission blocker. You come up with an easy solution. You slap on AdministratorAccess and now you have a security problem you don't even know about. The Access Denied error was actually trying to help you. It was telling you exactly which permission was missing. You just didn't know how to read it yet.

This post is the mental model I wish I'd had. Once you understand what I'm about to lay out, Access Denied stops being a wall and starts being a useful message.

What IAM Actually Is

IAM stands for Identity and Access Management. Not sure if that name really helps you, let me put it differently.

IAM is the bouncer at the door of every AWS service. Every time anything happens in your account, whether you click a button in the console, your code calls an API, or a Lambda function tries to read from a database, IAM checks two things.

Who are you?
Are you allowed to do this?

If the answer to either question is "no," you get Access Denied. Those two questions are the entire foundation. The rest of this post is about how they get answered.

Users, Roles and Policies

Three concepts make up the whole model when you're getting started.

IAM Users = Employee Badge

An IAM user is a persistent identity. It represents a person who needs to log into the console or use the CLI. It has long-term credentials, a username and password for the console, or access keys for programmatic access.

Think of it like an employee badge. It's yours, it has your name on it, and it works every day until someone revokes it.

IAM Roles = Visitor Pass

An IAM role is temporary. It doesn't belong to anyone permanently. Instead, it gets assumed (borrowed) by whoever needs it at that moment. AWS gives the assumer temporary credentials that expire automatically.

Think of it like a visitor pass at an office. You check in, you get a badge, it works for a few hours, then it stops working.

Rule of thumb. If it's a person logging in, that's a user. If it's a service doing something, a Lambda function, an EC2 instance, another AWS account, that's a role. Roles are how Lambda functions access S3, how EC2 instances talk to DynamoDB and how one AWS account talks to another. The credentials are always short-lived, so there's nothing sitting around that could be stolen.

Policies = Permission Slip

A policy is a JSON document that says "this identity is allowed to do these actions on these resources." You attach policies to users or roles. Without a policy attached, an IAM identity can do nothing. You have to explicitly grant every single permission.

A simple policy looks like this:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-bucket/*"
    }
  ]
}

This says: allow reading objects from one specific S3 bucket. Nothing else.

The Mental Model

A user or role is who you are. A policy is what you're allowed to do. Identity plus permission. That's the whole thing.

The Least Privilege Principle

This is the one concept that makes everything in IAM make sense. It applies across all of computer security, not just cloud.

Least privilege means: give every identity only the permissions it needs to do its job. Nothing more.

You already saw the wrong version in my story. I gave a Lambda function permission to do everything because it needed to do one thing. AdministratorAccess makes the error go away, but it also means anything in your account can do anything to your account.

That's like giving every employee in a company a key that opens every door because they needed to open one.

The right approach is to figure out exactly which actions your identity needs, on exactly which resources, and grant only that. That Lambda function I mentioned at the start? The policy it actually needed:

{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::my-bucket/*"
}

One action. One bucket. If that function ever gets compromised, the damage is limited to reading objects from one bucket, not your entire account.

"But figuring out exact permissions sounds like a lot of work." It can take some extra minutes upfront. AWS gives you a tool called IAM Access Analyzer that looks at what your identity actually used over a period of time and generates a scoped policy based on real activity. You let your service run, then Access Analyzer tells you what it actually needed. You don't have to guess.

Your IAM Starter Checklist

I share this with every student setting up a new AWS account. Bookmark it and come back at the end of every project.

1. Lock down your root user

When you first create an AWS account, you start as the root user. Root can do anything, including things no other identity can do, like closing the account entirely. It's the "break glass in case of emergency" identity.

Enable MFA on root immediately. That's multi-factor authentication, so even if someone gets your password, they still can't log in without your second factor. Then stop using root for daily development.

2. Set up daily access

For day-to-day work, create a separate identity. If you're learning on a personal account, an IAM user with MFA works fine. If you're working with a team or thinking about production, IAM Identity Center is the current best practice. It gives you temporary credentials and scales well when you add team members.

3. Use roles for services

When you build things, Lambda functions, EC2 instances, anything running code, use roles. They don't need long-lived access keys. They need roles with temporary credentials.

4. Start with managed policies, then tighten

AWS has pre-built managed policies for common use cases. They're a reasonable starting point when you're learning. As you understand what your application actually needs, narrow the permissions down. You don't have to write perfect policies on day one, but you should be moving toward least privilege over time.

5. Never put access keys in your code

Putting keys directly in source code is a bad idea. They should never be in config files or any variable pushed to Git. Use roles instead. If you ever accidentally push AWS keys to a public repo, rotate them immediately. Bots scan for exposed keys within minutes.

Quick Reference

Step	What to Do	Why
Lock down root	Enable MFA, stop using root daily	Root = key that opens all doors
Set up daily access	IAM user (learning) or Identity Center (teams)	Limits root exposure
Use roles for services	Lambda, EC2 get roles, not users	Temporary credentials, nothing to steal
Start managed, then tighten	Use AWS managed policies first	Don't guess permissions on day one
No keys in code	Use roles, not hardcoded credentials	Bots scan for exposed keys within minutes

What I Tell Students Who Are Afraid of IAM

Every time someone tells me "I just attach AdministratorAccess because IAM is confusing," I tell them the same thing. The confusion comes from not having the mental model. Now you have it.

Users are people. Roles are services. Policies define what any of them can do. Least privilege means only what you need, nothing more. And Access Denied is IAM telling you exactly which permission is missing. Read the error. It's trying to help you.

Next time you get Access Denied, and you will, don't reach for AdministratorAccess. Check the policy. You've got this.

The best time to learn IAM was when you created your AWS account. The second best time is right now.

Click here for more info on AWS Free Tier.

You Deleted Everything and AWS Is Still Charging You

Jonathan Vogel — Fri, 13 Mar 2026 18:33:50 +0000

The AWS cleanup checklist I wish someone had given me when I was starting out with cloud.

I talk to computer science students regularly. There's one fear that comes up more than almost anything else: "I am worried about spinning up stuff in the cloud and charges getting out of control."

I used to feel this. Some time ago, I set up a relational database on RDS, some virtual machines as EC2 instances, an S3 bucket to upload some data. After I was done, I deleted everything on the AWS console. Deleted my database. Terminated my instances. Then I got a bill I wasn't expecting.

Didn't everything get deleted? Literally AWS told me "deleting" in the console. I didn't think anything was running. What happened?

That experience stuck with me. As I work with students building on AWS, I see the exact same thing happen to them. Last semester alone, I heard some version of this story from students.

I'm gonna walk us through what's actually going on and give you a checklist to eliminate this fear when building out on AWS.

What's Actually Charging You After You "Delete Everything"

Here's an example. You delete your RDS instance at the end of a semester project. Makes sense. Project's done. But during deletion, AWS offers to create a final snapshot of your database. It's a checkbox. You probably don't even register that it's there. You click through, the database goes away, and that snapshot sits in your account quietly costing you money.

Same thing with EC2. You terminate your instances and depending on how your volumes were configured, the EBS volumes that were attached don't always get deleted with the instance. They're still there, billing. Invisible unless you know where to look.

And then there's this one that gets people: Elastic IPs. When you terminate an instance, the Elastic IP doesn't get deleted with it. It just sits there, unattached, costing you a few dollars per month. Not huge, but it adds up when you forget about it. That one catches people off guard.

None of this is hidden. It's all documented. But nobody tells you to look for it when you're learning, and the console doesn't wave a red flag that says "hey, you still have billable resources over here."

Why This Frustrates Me

Here's the part that actually gets to me as a Developer Advocate. When a student gets a surprise bill, they don't usually think "I missed a step in my cleanup." They think "AWS secretly charges you even after you delete stuff." They tell their classmates and that becomes the narrative. I've heard it in person, on discord, etc. "Be careful with AWS, they'll charge you for nothing." It's not cool because it can scare people away from learning skills that would genuinely help their careers.

AWS doesn't charge you in mysterious ways. It charges you in specific, predictable ways that nobody taught you to look for. That's a knowledge gap. The purpose of this post is to shed some light on this.

There's a Better Way Now

Here's something I wish existed when I was starting out. AWS now has a free account plan where you get $100 in credits just for signing up, and you can earn up to $200 total by completing activities like launching an EC2 instance or creating a budget. The key part: you literally cannot be billed. There's no scenario where you wake up to a surprise charge. When your credits run out or six months pass, whichever comes first, your account just closes. That's it. No bill.

If you want more flexibility -- say you're working on a longer project or you don't want to risk your account closing mid-semester -- you can choose the paid account plan instead. You still get the same $200 in credits, but your account stays open after they're used up. The tradeoff is that you can be billed beyond your credits, which is exactly why the billing alarm later in this post matters. Set that up on day one and you're covered.

I've been guiding more students toward these options lately and it keeps coming up enough that I'll probably write a dedicated post about it soon.

The Cleanup Checklist

This is what I share with every student I work with now. I tell them to bookmark it and come back to it at the end of every project.

Start With Your Bill, Not Your Console

Before you click around trying to find leftover resources, go to AWS Billing Dashboard from the AWS console. Look at the current month's charges broken down by service. This tells you exactly which services are costing money right now.

If you see a charge for RDS, go check RDS. If you see a charge for EC2, go check EC2. Let this be your map.

Use Resource Explorer

Looking for an exhaustive list of everything going on in your AWS account across all regions?

Instead of clicking through every service console in every region hoping you didn't forget something, Resource Explorer gives you a single search interface across your entire account. All services. All regions. One view.

That last part matters more than you'd think. I've seen students create resources in us-east-1 for a tutorial and us-west-2 for a class project, then only check one region during cleanup and assume everything's gone. Resource Explorer solves that completely. Resource Explorer in the console. If your account is truly clean, you'll see very little. If it's not, you'll see exactly what's still hanging around.

Check the Usual Suspects

Even with Resource Explorer, it helps to know the specific things that catch people. These are the ones I see come up a lot:

Snapshots (EBS and RDS) Check EC2 -> Snapshots and RDS -> Snapshots. Common silent cost I see among students. They get created automatically, often during deletion workflows, and nobody thinks to look for them. These snapshot costs can add up - something like 100 GB could be $5/month.

Unattached EBS Volumes Go to EC2 -> Volumes and filter by state: "available." If a volume shows "available," it's not attached to anything. It's just sitting there being billed.

Elastic IPs Check EC2 -> Elastic IPs. If any are listed and not associated with a running instance, release them.

NAT Gateways If you followed a VPC tutorial with public and private subnets, check VPC -> NAT Gateways. These run about $32/month whether you're pushing traffic through them or not. If you don't need it, delete it.

Set Up a Billing Alarm

This takes two minutes and it's the single most important thing you can do on a new AWS account.

Go to Billing -> Budgets
Create a low budget, say $5 or $10
Set an alert at 80% of that threshold
Add your email

What I Tell Students Who Are Afraid to Start

Every time I meet a student who communicates to me in a way that signals "I'm scared of cloud billing getting out of control," I tell them the same thing. That fear is valid. Every dollar matters when you're a student. Once you understand where surprise charges actually come from, which is a pretty short list, the fear goes away.

The students who get burned are the ones who don't know about snapshots, orphaned volumes, and unattached Elastic IPs. Now you do.

I tell students these three things:

If you want zero billing risk, choose the free account plan when you sign up. You get up to $200 in credits and you cannot be charged. The tradeoff is that your account closes when credits run out or after six months. If you'd rather keep your account open longer, go with the paid plan -- you get the same credits, just set up a billing alarm so nothing sneaks past you.
Set up a billing alarm no matter which plan you pick
Bookmark this checklist and come back to it at the end of every project

Start the account. Build the project. Learn the skills. And when the semester ends, come back to this checklist.

Quick Reference

Check	Where to Look	What to Do
Billing by service	Billing Dashboard -> Bills	See which services are charging you
All resources, all regions	Resource Explorer	Find anything still alive in your account
Snapshots	EC2 -> Snapshots, RDS -> Snapshots	Delete what you don't need
Orphaned EBS volumes	EC2 -> Volumes -> filter "available"	Delete unattached volumes
Elastic IPs	EC2 -> Elastic IPs	Release unassociated IPs
NAT Gateways	VPC -> NAT Gateways	Delete if project is done
Billing alarm	Billing -> Budgets	Set one up before you do anything else

Or to avoid any billing entirely, choose the free account plan when signing up. You still get credits, but you are never billed. Note: when you run out of credits (or 6 months pass, whichever comes first), AWS closes your account.

Click here for more info on AWS Free Tier.

The best time to set up a billing alert was when you created your account. The second best time is right now.

DEV Community: Jonathan Vogel

How to Build and Deploy an AI Agent on AWS with Bedrock, Strands, and AgentCore

TL;DR

What's in this post

The mental model

Prerequisites

Chapter 1: Raw Bedrock, a brain with no eyes

Set up the project

The whole file

Run it

What comes back

Chapter 2: A local Strands agent, the loop that grounds the answer

Set up the project

The whole file

What the loop actually does

Run it

What comes back

Chapter 3: Deploy to AgentCore Runtime

Install the deploy tooling

Bootstrap once (this is the "we bootstrap this thing" step)

Scaffold the project

The scaffold is a sample agent, not our agent

Edit 1: swap the model in app/PantryChef/model/load.ts

Edit 2: make it the pantry chef in app/PantryChef/main.ts

Run it locally first

Deploy it

Invoke it from the cloud

The four commands, start to finish

Who can actually call this thing?

Cost and teardown

The extras you grow into: memory, gateway, observability

The whole stack in one picture

Reproduce this yourself

Your turn

us-east-1 or Somewhere Closer? How to Pick an AWS Region Without Overthinking It

What a Region actually is

The four things that actually matter

For your first project, pick the closest one and move on

"But what if I pick wrong?"

Why your bucket "disappeared" (one of the gotchas)

The exception that's worth knowing

The 30-second decision, as a flow

Quick reference

What's next

Access Denied: What Every AWS Beginner Gets Wrong About IAM

What IAM Actually Is

Users, Roles and Policies

IAM Users = Employee Badge

IAM Roles = Visitor Pass

Policies = Permission Slip

The Mental Model

The Least Privilege Principle

Your IAM Starter Checklist

1. Lock down your root user

2. Set up daily access

3. Use roles for services

4. Start with managed policies, then tighten

5. Never put access keys in your code

Quick Reference

What I Tell Students Who Are Afraid of IAM

You Deleted Everything and AWS Is Still Charging You

What's Actually Charging You After You "Delete Everything"

Why This Frustrates Me

There's a Better Way Now

The Cleanup Checklist

Start With Your Bill, Not Your Console

Use Resource Explorer

Check the Usual Suspects

Set Up a Billing Alarm

What I Tell Students Who Are Afraid to Start

Quick Reference

Edit 1: swap the model in `app/PantryChef/model/load.ts`

Edit 2: make it the pantry chef in `app/PantryChef/main.ts`