AWS Builder Center

Builder Center

Control Here, Build There: 5 Lessons Connecting Claude Code to AWS

What the Weekend Challenge taught me about Regions, guardrails, spend limits, and clear prompts. Plus copyable prompts so you can find your own answers.

Doug Skinner

100 Leads Sprint, Turning Early Signals into Paying Customers, Author - 21 Keys to AI Orchestration
I took the Weekend Challenge. I connected Claude Code to my AWS account using the Agent Toolkit for AWS .
The setup was quick. The mental model took longer.
Good Builds Happen Sometimes on Weekends
My first question was simple. Why does my agent talk to one Region while my resources live in another?
That one question opened five more. Each one became a picture. Each picture became a lesson.
After 30 years in enterprise technology, I've learned one thing about new platforms. The tools usually work. The confusion lives in the handoffs.
This article walks through those handoffs. For each picture, you get my point of view, the lesson, the pitfall I hit or nearly hit, and the recovery steps.
Then you get something better than my answer. You get a prompt.

How to use the prompts

Every prompt below is copyable. Paste it into your own coding agent.
Each one starts with a short "My setup" line. That line gives your agent the context it needs. Edit it to match your account before you run it.
If your agent is connected to the Agent Toolkit, it will check current AWS documentation before it answers. That's the whole point of the toolkit. Let it do the research.

Control Here, Build There

Separating two functions

My Take

The diagram separates two roles.
us-east-1 is the control point. It hosts the AWS MCP Server that the Agent Toolkit connects to.
us-east-2 is the build site. It holds my buckets, files, and APIs.
Think of it like an air traffic control tower. The tower sits in one place. The planes land somewhere else. Nobody expects the runway to be inside the tower.

The Lesson

The MCP endpoint Region does not decide where your resources go.
AWS documents this directly. The endpoint Region picks which MCP server you connect to. A separate setting called AWS_REGION picks where your API calls land.
Today, the AWS MCP Server runs in two Regions: us-east-1 and eu-central-1 (Frankfurt). Your resources can live almost anywhere.
New AWS projects also get a home Region based on your contact address. US accounts get us-east-2 (Ohio). That's why my resources ended up in Ohio while my agent talked to Virginia.

The pitfall

If AWS_REGION isn't set, operations default to us-east-1.
So a vague prompt like "create a bucket" can put your bucket in Virginia. Your project lives in Ohio. Now you have region drift, and you may not notice for weeks.

Recovery steps

  1. Name the Region in every build prompt. "Create the bucket in us-east-2" leaves nothing to guess.
  2. Set a default. Check your agent's MCP configuration for an AWS_REGION metadata setting. Point it at your home Region.
  3. Verify where things landed. Ask your agent to list your resources by Region, or run aws s3api get-bucket-location --bucket <your-bucket>.
  4. Fix a misplaced bucket the right way. S3 buckets can't move Regions. Create a new bucket in the correct Region, copy the objects over, then remove the old one.

Ask your own agent

1A. Why two Regions?
1
2
My setup: I connected Claude Code to AWS with the Agent Toolkit for AWS. The AWS MCP Server endpoint is in us-east-1 (N. Virginia). My project's home Region and resources are in us-east-2 (Ohio). Check current AWS documentation before answering.
Question: Why does this setup use two AWS Regions, one for the "control here" side and one for the "build there" side?
1B. What if it were one Region?
1
2
3
My setup: I connected Claude Code to AWS with the Agent Toolkit for AWS. The AWS MCP Server endpoint is in us-east-1 (N. Virginia). My project's home Region and resources are in us-east-2 (Ohio). Check current AWS documentation before answering.

Question: What would change if everything ran in one Region instead of two?
1C. What are the trade-offs?
1
2
3
My setup: I connected Claude Code to AWS with the Agent Toolkit for AWS. The AWS MCP Server endpoint is in us-east-1 (N. Virginia). My project's home Region and resources are in us-east-2 (Ohio). Check current AWS documentation before answering.

Question: What are the trade-offs of this two-Region setup? Cover latency, cost, reliability, compliance, and simplicity.
1D. Is this standard practice?
1
2
3
My setup: I connected Claude Code to AWS with the Agent Toolkit for AWS. The AWS MCP Server endpoint is in us-east-1 (N. Virginia). My project's home Region and resources are in us-east-2 (Ohio). Check current AWS documentation before answering.

Question: Is separating a control endpoint Region from a build Region a standard AWS practice? Where else does AWS use this pattern?
1E. Can I build somewhere else and keep the same endpoint?
1
2
3
My setup: I connected Claude Code to AWS with the Agent Toolkit for AWS. The AWS MCP Server endpoint is in us-east-1 (N. Virginia). My project's home Region and resources are in us-east-2 (Ohio). Check current AWS documentation before answering.

Question: Can I move my work, or start building, in another Region while keeping us-east-1 as my Agent Toolkit endpoint? What settings or account restrictions would I need to change?

Claude Code on your machine speaks MCP to the Agent Toolkit bridge in the AWS control layer

Build Through the Bridge. Stay Inside the Guardrails.

My Take

The flow reads left to right:
Claude Code → MCP bridge → IAM identity → SCP-protected resources
The badge and the shield separate two ideas that people often mix up.
IAM decides who Claude Code is. It's the badge.
An SCP decides what it can never do. It's the shield.
A badge can open a lot of doors. The shield decides which doors exist in the first place.

The Lesson

Your agent doesn't get its own identity. It borrows yours.
The Agent Toolkit signs in with aws login. From then on, the AWS MCP Server uses that signed-in identity for every call. Your agent can only do what you are allowed to do.
A service control policy (SCP) sits above that. It sets the outer boundary for the whole account. Even an administrator can't cross it.
In my sandbox, the guardrails kept EC2 off the table. My agent could build. It could not launch servers.

The pitfall

Two traps here.
First, assuming the agent is "safer" than you by default. It isn't. It holds exactly your permissions.
Second, running old MCP servers next to the new one. If you used aws-api-mcp-server or aws-knowledge-mcp-server before, the toolkit replaces both. Running them side by side leaves your agent choosing between overlapping tools.

Recovery steps

  1. Remove the legacy MCP servers. Keep only the Agent Toolkit connection.
  2. Restart your agent and test. Ask it: "What AWS Regions are available?" A list means you're connected.
  3. Tighten agent-only permissions. AWS adds a condition key called aws:ViaAWSMCPService to every request that comes through its managed MCP servers. You can write IAM policies or SCPs that treat agent requests more strictly than your own. For example, read-only for the agent while you keep write access.
  4. Treat "Access Denied" as a signal. It usually means a guardrail did its job. Ask the agent which policy blocked it before you change anything.

Ask your own agent

2A. What if I switch coding agents?
1
2
3
My setup: I connected Claude Code to AWS with the Agent Toolkit for AWS. My agent uses my signed-in IAM identity, and my account uses service control policies (SCPs) that block EC2. Check current AWS documentation before answering.

Question: What happens when I switch my coding agent to Kiro, Codex, or another LLM? What carries over, what do I need to reconfigure, and do my IAM and SCP guardrails still apply?
2B. When would I need EC2?
1
2
3
My setup: I connected Claude Code to AWS with the Agent Toolkit for AWS. My agent uses my signed-in IAM identity, and my account uses service control policies (SCPs) that block EC2. Check current AWS documentation before answering.

Question: What types of projects or workloads would require lifting the EC2 restriction? For each one, is there a serverless or managed alternative that avoids EC2?
2C. What is an SCP?
1
2
3
My setup: I connected Claude Code to AWS with the Agent Toolkit for AWS. My agent uses my signed-in IAM identity, and my account uses service control policies (SCPs) that block EC2. Check current AWS documentation before answering.

Question: What does SCP mean, and how does it work? Explain how an SCP differs from an IAM policy, and show me how to see which SCPs apply to my account.

A Limit Is Not a Charge

A pay-as-you-go meter feeds an S3 Free Tier umbrella

My Take

The money logic reads left to right:
Usage meter → Free Tier umbrella → $20 circuit breaker → $0.00 current spend
The key idea: a limit is protection, not a charge.
A $20 spend limit doesn't bill you $20. It's a circuit breaker in your house. It doesn't use electricity. It stops the fire.

The Lesson

AWS now lets you set a monthly spend limit per project in AWS Settings. It's a ceiling on pre-tax costs, not a fee. The minimum is $20.
You also get warnings before anything trips. AWS notifies you at 50%, 75%, and 90% of your limit. It also warns you when you're on track to hit the limit within 10 days.
Then there are three optional early cost controls. These are the three icons under the breaker:
  • Blocks new launches. About 7 days before you'd hit the limit, new resources stop launching. AWS does this with a managed SCP.
  • Pauses idle resources. About 5 days out, idle EC2, RDS, and SageMaker endpoints pause. Active apps keep running.
  • Pauses top cost drivers. About 4 days out, your most expensive active resources pause.

The pitfall

Two things surprised me.
First, "pause" can be stronger than it sounds. For a top-cost EC2 instance, AWS snapshots the disks and then terminates the instance. For Lambda, it disables triggers. Read the details before you turn these on.
Second, a paused project has a clock. If you take no action within 90 days, AWS permanently deletes the project data.
One more note on the umbrella. The 5 GB, 20,000 GET, and 2,000 PUT numbers are the classic S3 Free Tier allowance. Accounts created after July 15, 2025 get Free Tier credits instead. Check which model your account uses.

Recovery steps

  1. Set the limit first, then build. It costs nothing to have a breaker.
  2. Route the alerts somewhere you'll see them. An alert nobody reads is just a log entry.
  3. If a project pauses, act fast. Raise the limit in AWS Settings to reactivate it. Don't let the 90-day clock run.
  4. Match early controls to the workload. Pausing idle resources is safe for a sandbox. Pausing top cost drivers on a live app is a business decision.

Ask your own agent

3A. What pushes past the free request limits?
1
2
3
My setup: I use Claude Code with the Agent Toolkit for AWS. My project stores a static website in Amazon S3 in us-east-2 under the S3 Free Tier (5 GB storage, 20,000 GET and 2,000 PUT requests per month), with a $20 monthly spend limit. Check current AWS documentation and pricing before answering.

Question: Give me real-world examples of workloads that would go over 20,000 GET requests or 2,000 PUT requests in a month. Estimate what each would cost beyond the free allowance.
3B. How do the notifications work?
1
2
3
My setup: I use Claude Code with the Agent Toolkit for AWS. My project has a $20 monthly spend limit in AWS Settings with early cost controls turned on. Check current AWS documentation before answering.

Question: Explain the notification process in three cases. One, the system wants to block a new launch. Two, resources sit idle too long. Three, my spending is on pace to hit the $20 limit before the month ends. Tell me what triggers each alert, when it arrives, and what I should do when I get it.

Claude Code at a workbench

Builds Within the Boundaries

My Take

This picture captures the operating principle:
Claude Code is capable inside the approved lane. It is structurally blocked outside it.
The workbench shows productivity. The striped boundary shows governance. The boundary doesn't make the agent less useful. It makes it trustworthy.
A good apprentice doesn't need a locked toolbox. They need a clear workbench.
What it can do:
  • Write clean local web assets: index.html, CSS, JavaScript.
  • Create an S3 bucket, configure it, and upload files through aws-mcp.
  • Check live AWS documentation, so it doesn't rely on outdated patterns.
What it cannot do:
  • Launch virtual servers or bypass the organization's SCP restrictions.
  • Spend beyond what you authorize.

The Lesson

Boundaries are a feature. They let you say yes to the agent more often.
When the blast radius is small, you can let the agent move fast. You don't have to review every step.

The pitfall

A vague prompt invites the agent to reach for tools it can't use. That leads to an "Access Denied" loop. The agent retries, rephrases, and burns time.

Recovery steps

  1. State the boundaries in your prompt. "Use S3 only. No EC2." The agent will plan around it.
  2. Keep a short "can do / cannot do" note in your project. Many agents read a project instructions file. Put your guardrails there once.
  3. Loosen boundaries on purpose, not by accident. When you need more, change the policy deliberately, then tell the agent what changed.

Ask your own agent

4A. What does oversight look like when I loosen the guardrails?
1
2
3
My setup: I use Claude Code with the Agent Toolkit for AWS. Today my account blocks EC2 through service control policies (SCPs), the agent cannot bypass those SCPs, and my project has a $20 monthly spend limit. Check current AWS documentation before answering.

Question: If I later allow EC2, relax the SCP restrictions, or raise spending above $20 a month for Claude's MCP access, what should administrative monitoring and control look like? Cover logging and audit trails, agent-only permissions, budget alerts, and who should approve each change.

Claude Code builds index.html locally, sends it through aws-mcp

One Clear Prompt. One Safe Path.

My Take

This is the deployment runway:
Local page → MCP bridge → correct Region → unique S3 bucket → website endpoint
The dashed Free Tier line says the whole trip stays in the low-risk lane.
Every lesson above shows up in one prompt. Name the Region. Name the service. Name the limit. Ask for proof at the end.

The Lesson

Clarity beats cleverness. The best prompt I wrote wasn't long. It was specific.
Here's the prompt I used. Copy it and change the name and Region to yours.
1
Please create a clean single-page website locally named index.html. Then, using the aws-mcp tool targeting our assigned Region us-east-2, create an S3 bucket named hello-world-[your-name]-[random-4-digits] with static website hosting enabled, upload index.html, and provide the website endpoint URL. Ensure all actions stay strictly within AWS Free Tier storage.

Why it works:

  • It names the Region. No silent default to us-east-1.
  • It adds a random suffix. S3 bucket names are global. "hello-world" is taken.
  • It sets a cost boundary. The agent knows the lane before it starts.
  • It asks for proof. The endpoint URL is your receipt.

The pitfall

The two most common snags are a taken bucket name and a 403 Forbidden on the website endpoint.
The 403 usually means the objects aren't publicly readable. S3 blocks public access by default, which is a good default.
Also know this. S3 website endpoints serve HTTP, not HTTPS. That's fine for a hello-world. It isn't fine for customers.

Recovery steps

  1. Name collision? Add a longer random suffix and retry.
  2. 403 on the endpoint? Ask the agent to explain which setting is blocking public reads before it changes anything. Decide on purpose.
  3. Need HTTPS? Put Amazon CloudFront in front of the bucket and keep the bucket private.
  4. Clean up when you're done. Empty and delete test buckets you no longer need.

Ask your own agent

1
2
3
My setup: I used Claude Code with the Agent Toolkit for AWS to deploy a static website to an S3 bucket in us-east-2 with static website hosting, inside the Free Tier, in a sandbox with SCP guardrails and a $20 spend limit. Check current AWS documentation before answering.

Question: What does the architecture look like when I move from this testing sandbox to production? Cover separate accounts or projects, HTTPS and a CDN, custom domains, CI/CD, monitoring, backups, security guardrails, and cost controls. Show it as a before-and-after comparison.

Key takeaways

  • Control here, build there. The MCP endpoint Region and your build Region are different settings. Name your Region every time.
  • Badge and shield. IAM decides who your agent is. SCPs decide what it can never do.
  • A limit is not a charge. Set the breaker before you build, and read what "pause" really means.
  • Boundaries create speed. A clear workbench lets you trust the agent with more.
  • One clear prompt. Region, service, limit, and proof. Every time.
The challenge asked for one thing I learned. I got five.
Now it's your turn. Pick one prompt above, run it against your own setup, and share what your agent tells you in the comments. I'm curious where your answers differ from mine.
See you in the Zero to Shipped hackathon.
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article