What Is the AWS MCP Server? A Complete Guide for AI Engineers (2026)

Anastasiia Kuten Marketing & Partnerships Department Manager

May 15, 2026

AWS partner dedicated to startups

• 2000+ Clients
• 5+ Years of Experience
• $10M+ saved on AWS

AWS just shipped one of the most important pieces of AI infrastructure they have ever built, and most teams have no idea what it does or why it matters. This is the practical guide nobody is writing yet.

The AWS MCP Server went generally available in early May 2026. It is a managed remote server that gives AI coding agents secure, authenticated access to every AWS service through a small set of standardized tools. If you are building with Claude Code, Cursor, Kiro, Codex, or any other coding agent that supports MCP, this is the missing piece that lets your agent actually work on AWS without you handing it root credentials.

Our Cloudvisor’s guide covers what it is, how it works, what it costs, how to set it up, and the real security implications you need to understand before you turn it on.

What Is the AWS MCP Server?

The AWS MCP Server is a managed service that lets AI agents securely interact with AWS through the Model Context Protocol (MCP). Instead of giving an AI agent raw AWS access keys (and hoping nothing bad happens), the MCP Server gives the agent a structured, audited, IAM-governed way to call AWS APIs.

It is part of the Agent Toolkit for AWS, a broader suite of tooling that includes the MCP Server, skills, and plugins designed to help coding agents build more effectively on AWS.

The short version: it is the bridge between AI coding agents and your AWS account, with enterprise-grade security baked in.

Why This Matters: Two Problems It Solves

AI coding agents have been useful for writing code, suggesting fixes, and explaining concepts for a couple of years now. But anyone who has tried to use them on real AWS infrastructure has hit two walls.

Problem 1: The Knowledge Gap

AI models have training cutoffs. They do not know about services that launched recently. If you ask Claude or GPT how to store embeddings on S3, the model will probably suggest something that worked in 2024, not Amazon S3 Vectors, which went GA in December 2025.

The same problem hits Aurora DSQL, Bedrock AgentCore, Amazon Quick, and every other recent AWS launch. Your agent gives you confident-sounding answers that are months out of date.

The AWS MCP Server fixes this by giving the agent access to live AWS documentation. The agent looks up the current state of services before writing code, not what the model remembers from training data.

Problem 2: The Trust Gap

Even if your agent knows what to do, giving it AWS credentials has always been scary. Hand an autonomous agent your access keys and you are one bad prompt away from a billing disaster, a deleted production database, or a public S3 bucket full of customer data.

Teams have been working around this with sandboxes, read-only credentials, or just refusing to let agents touch AWS at all. None of those scale.

The AWS MCP Server fixes this by using your existing IAM permissions. The agent inherits the access controls you have already configured. Every action runs through CloudTrail. Nothing escapes your audit trail.

How It Works

The architecture is straightforward once you see it laid out.

The agent makes a tool call. The proxy authenticates it with your AWS credentials. The MCP server checks IAM, executes the API call, and returns the result. CloudTrail logs everything.

The Fixed Tool Set

This is the design choice that makes the server actually safe. Instead of exposing 15,000+ AWS API operations as individual tools (which would overwhelm any agent’s context), the server exposes a small fixed set of tools that can reach any AWS service.

The core tools at GA:

• aws___call_aws_api: Calls any AWS API. The agent specifies the service, operation, and parameters. Supports file uploads and long-running operations.
• aws___get_documentation: Retrieves current AWS documentation for any service, API, or concept. No authentication required for this tool, so even agents without AWS credentials can pull up-to-date docs.
• aws___run_script: The agent writes a short Python script that runs server-side in a sandboxed environment. The sandbox inherits your IAM permissions but has no network access or filesystem access to your local machine.

That last one is more important than it looks. When an agent needs to call multiple APIs and combine the results, doing them one at a time is slow and burns through context. With run_script, the agent chains API calls, filters responses, and computes results in a single round-trip. Faster, cheaper in tokens, and easier to reason about.

Security Model: What Actually Protects You

This is the section that should matter most to anyone evaluating it for production use. The security story is built on four pillars.

1. IAM-Based Access Control

The server uses your existing IAM permissions. The agent can only do what your IAM policies allow. If your developer role has read-only access to S3, the agent has read-only access to S3. No new permission model to learn.

With GA, the server now supports IAM context keys, so you can express fine-grained access in a standard IAM policy. Example:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:RequestTag/Environment": "dev"
        }
      }
    },
    {
      "Effect": "Deny",
      "Action": [
        "iam:*",
        "organizations:*",
        "ec2:TerminateInstances",
        "rds:DeleteDBInstance"
      ],
      "Resource": "*"
    }
  ]
}

This policy lets the agent do anything in dev environments while explicitly blocking IAM changes and destructive operations. Build your policy once, the agent inherits it.

2. Sandboxed Script Execution

The run_script tool runs Python in a sandbox with no network access and no shell access to your local machine. The agent cannot exfiltrate your local files, install software, or reach the internet outside of AWS APIs.

The sandbox inherits your IAM permissions, so it still cannot do anything in AWS that you have not explicitly allowed.

3. CloudTrail Audit Logging

Every API call the agent makes is logged in CloudTrail, exactly as if you had made it yourself. You get full attribution: which agent, which user, which action, when, and against which resource.

For compliance use cases, this is critical. SOC 2, HIPAA, and ISO 27001 audits all require complete audit trails for actions taken in production environments. The service inherits AWS’s compliance posture by design.

4. CloudWatch Metrics

Every tool call emits CloudWatch metrics. You can set alarms on unusual activity patterns, monitor API call volume per agent, and build dashboards for security review.

How to Set It Up

Setup takes about 10 minutes. Here is the practical walkthrough.

Step 1: Install the Local Proxy

The server runs remotely, but you need a lightweight proxy on your machine to handle authentication.

pip install awslabs-mcp-proxy

Or with Homebrew on macOS:

brew install awslabs/tap/aws-mcp-proxy

Step 2: Configure AWS Credentials

The proxy uses your existing AWS credentials. If you already use the AWS CLI, you are done. If not:

aws configure

Use a profile dedicated to your AI agent work if you want extra isolation:

aws configure --profile ai-agent

Step 3: Configure Your AI Agent

Each agent has its own way to add MCP servers. Here is the configuration for the most common ones.

Claude Code:

{
  "mcpServers": {
    "aws": {
      "command": "aws-mcp-proxy",
      "args": ["--profile", "ai-agent"],
      "env": {
        "AWS_REGION": "us-east-1"
      }
    }
  }
}

Cursor: Open Settings, navigate to MCP Servers, and add the same configuration.

Kiro and Kiro CLI: Built-in support, just authenticate through the standard AWS sign-in flow.

Codex: Add the server to your codex config file under the mcp_servers section.

Step 4: Test It

Once configured, ask your agent something that requires current AWS knowledge:

“What is the cheapest way to store and query vector embeddings on AWS in 2026?”

Without the server connected, the agent will probably suggest OpenSearch or Aurora with pgvector based on stale training data. With it connected, the agent will look up current documentation and recommend Amazon S3 Vectors (which most models do not know exists).

Step 5: Lock Down Permissions Before Going Further

Before letting the agent make real changes in your account, write a scoped IAM policy. Start with the principle of least privilege. Allow only what the agent needs for the specific task you are working on.

The IAM policy example earlier in this guide is a good starting template. Adjust based on your use case.

Pricing

The service is free to use. You pay only for the AWS resources your agent actually provisions or operates on.

There are no charges for:

• Tool invocations
• Documentation lookups
• Script execution in the sandbox
• The proxy or the remote server itself

The only costs you incur are the standard AWS service costs for whatever the agent does (EC2 instances, S3 storage, Lambda invocations, etc.) plus standard CloudTrail and CloudWatch costs for the logging and metrics, which are minimal.

This is a clean pricing model that removes a common barrier to adoption. Compare it to building your own MCP infrastructure, where you would be paying for compute, networking, and storage in addition to the operational overhead.

Region Availability

At GA, the service is available in:

• US East (N. Virginia)
• Europe (Frankfurt)

AWS has indicated that additional regions are coming through 2026. For now, if you are in a region without local availability, you can still use the service. Latency will be slightly higher because requests cross regions, but functionally it works the same.

What People Are Actually Building with It

The use cases falling out of early adoption fall into a few clear categories.

AI-Assisted AWS Development

The most common case. Your coding agent helps you write CDK, Terraform, or CloudFormation that uses the latest services and follows current best practices. Instead of pasting AWS docs into your prompts, the agent pulls them in directly.

Automated Cost Analysis

Agents that look at your actual AWS spend, identify waste, and generate reports. The agent has read access to Cost Explorer, Compute Optimizer, and Trusted Advisor in a controlled way.

Incident Response and SRE

When something breaks, the agent can pull CloudWatch logs, CloudTrail events, and resource configurations to help diagnose the problem. It can suggest fixes and (with appropriate permissions) implement them.

Infrastructure Audits

The agent inventories your resources, checks them against security baselines or compliance requirements, and generates audit reports. Useful for SOC 2, HIPAA, or internal compliance reviews.

Multi-Step Automation

Tasks that previously required custom scripts can now be done conversationally. “Tag all my untagged EC2 instances with their owner based on who created them in CloudTrail” goes from a 200-line Python script to a single agent conversation.

Comparison: Different Ways to Connect Agents to AWS

The AWS MCP Server is not the only way to give AI agents access to AWS. Here is how the options compare.

For most teams, the managed option is the right starting point. Use the open-source servers from the awslabs/mcp repo for specialized workflows like cost estimation in CDK projects.

What Could Go Wrong: The Risks

This is the section AWS marketing will not write. There are real risks with putting AI agents anywhere near production infrastructure.

Overly Permissive IAM Policies

The biggest risk is not the server itself. It is humans writing bad IAM policies. If you give the agent AdministratorAccess because it is easier, you have built a single point of failure into your account.

Mitigation: start with read-only. Add write permissions narrowly, by service, for specific tasks. Use IAM Access Analyzer to find overly permissive policies before the agent does something bad.

Prompt Injection Through Documentation

If a malicious actor manages to inject instructions into content the agent reads (issue descriptions, error logs, documentation it ingests), the agent might act on those instructions instead of the user’s. This is a general agent risk, not specific to this service, but it applies here.

Mitigation: scope IAM policies so even a compromised agent cannot do critical damage. Require human approval for destructive operations.

Cost Spikes from Runaway Agents

An agent in a retry loop can rack up surprising bills. Bedrock model calls for the agent’s reasoning, AWS API calls billed at standard rates, sandboxed script execution time.

Mitigation: set up AWS Cost Anomaly Detection (it is free and catches this within 24 hours). Set hard AWS Budgets on the agent’s account or assumed role.

Audit Trail Confusion

When humans and agents are both making changes through the same role, attribution gets messy. Who did what, when?

Mitigation: give each agent its own IAM role with a clear naming convention. Use session tags to differentiate humans from agents in CloudTrail.

Should You Use It?

The decision comes down to your team’s AI maturity and risk tolerance.

Use it now if:

• Your team is already using AI coding agents for AWS work
• You have mature IAM policies and CloudTrail monitoring
• You want to safely move from chat-based AI assistance to actual AI-driven automation
• You are willing to start with read-only permissions and expand carefully

Wait if:

• Your IAM hygiene is weak (broad policies, lots of admin access)
• You have no CloudTrail review process
• Your team has not adopted AI coding agents at all yet
• You are in a region where the service is not yet available and latency matters

For most teams already using Claude Code, Cursor, or Kiro on AWS work, turning this on is a no-brainer. The friction is minimal, the cost is zero, and the security model is sound if you respect it.

Frequently Asked Questions

Is it free?
Yes, the server itself is free. You pay only for the AWS resources your agent operates on, plus standard CloudTrail and CloudWatch costs.

Which AI agents work with it?
Any agent that supports the Model Context Protocol. That covers Claude Code, Kiro, Kiro CLI, Cursor, Codex, Cline, Windsurf, Claude Desktop, and most other AI coding tools released in 2025 or later.

Do I need a new IAM permission to use it?
No. At GA, the server uses IAM context keys, so you can express fine-grained access in your existing IAM policies without granting a separate MCP-specific permission.

Can the agent see my local files?
No. The run_script sandbox has no access to your local filesystem. Documentation retrieval happens server-side. The agent only sees what you explicitly share through your prompt.

What is the difference between the AWS MCP Server and the AWS Knowledge MCP Server?
The Knowledge server is a separate free service that provides documentation only, no AWS account required. The MCP Server lets agents take action against your AWS resources, with authentication and IAM-based access control.

Does it work with AWS Organizations and multi-account setups?
Yes. The agent assumes whatever role you give it, so cross-account access works the same way it does for any IAM principal. You can have an agent operate across linked accounts if your role allows it.

How is this different from just giving the agent an AWS access key?
You get a structured interface, audit logging through CloudTrail, sandboxed script execution, IAM context key support, and documentation access in one managed service. Raw access keys give the agent unstructured access with no built-in audit isolation or sandboxing.

Can I self-host an MCP server instead?
Yes. The open-source servers in the awslabs/mcp GitHub repo can be self-hosted. This makes sense for specialized workflows or air-gapped environments. For most teams, the managed option is easier.

What happens if my agent makes a destructive change by mistake?
The change is logged in CloudTrail like any other API call. If your IAM policies prevented the action, it never happened. If they allowed it, you can use CloudTrail to identify the action and roll back manually. There is no built-in undo, so use guardrails.

Is this related to Amazon Bedrock AgentCore?
They are complementary. AgentCore is the platform for building and running AI agents in production. The MCP Server is a tool that any MCP-compatible agent (including AgentCore-based ones) can use to interact with AWS services. You can use them together or separately.

Summary: Why This Is a Big Deal

This launch represents a real shift in how cloud infrastructure will be managed in the AI era. AI tools are moving from isolated chat assistants to authenticated, auditable, infrastructure-aware operators. AWS clearly wants to be the platform powering that transition.

The launch also validates the Model Context Protocol itself. Over the last year, MCP went from an experimental tooling protocol to the emerging standard for connecting LLMs with external systems. AWS adopting it at this level signals where enterprise AI infrastructure is heading.

For practitioners, the value is concrete:

• Your AI agents finally have access to current AWS knowledge and APIs
• You get this access without compromising your security posture
• You pay nothing extra for the capability
• You inherit AWS’s enterprise compliance for free

If you are building anything on AWS with AI agents, this is the path forward. Start with read-only, expand carefully, monitor everything, and you will get significant value with manageable risk.