Quick Summary
This guide explains what the AWS MCP Server does, how the AWS MCP Server architecture works in practice, how it differs from self-hosted alternatives, and how teams use it with MCP Proxy for AWS to securely connect AI agents with AWS services.
Table of Contents
AI agents are moving quickly from experimental assistants to systems that can provision infrastructure, automating workflows, and interact directly with cloud-based environments. With the growing adoption, enterprises need to secure and standardise ways for agents to access external tools and services without exposing sensitive credentials.
Gartner predicts that by the end of 2026, 40% of enterprise applications will embed task-specific AI agents, a massive increase from less than 5% in 2025. That shift, from experimental chatbots to autonomous workflows, is what’s pushing teams toward standardised access protocols like MCP.
MCP (Model Context Protocol) is an open standard that lets AI agents connect to external tools & data sources through a common protocol. But a protocol is just a specification, and, to actually use it with AWS, you need a server that implements it.
On May 6, 2026, Amazon Web Services announced the launch of the AWS MCP Server, a fully managed MCP Server for AWS that gives AI coding agents secure, authenticated, and audit-logged access to AWS services without exposing raw credentials. Before this, teams relied on community-built MCP servers or custom proxy layers to broker AWS access. But, with this, the teams can connect agents like Claude Code, Cursor, Codex, Kiro, and other MCP-compatible clients directly through AWS managed identity and authentication controls.
Read further, as we discuss how the AWS MCP Server works, its architecture, and how to get started.
AWS MCP Server is a managed implementation of the MCP protocol designed specifically for AI agents operating inside AWS environments. It acts as a secure layer between AI coding assistants and AWS services, allowing agents to interact with AWS APIs using existing IAM permissions instead of hardcoded credentials.
Until recently, the default way to connect AI agents with cloud infrastructure was handling long-lived API keys or over-permissioned IAM users. It might have worked for the product demos and internal experiments, but it created a massive governance problem when agents started handling real production workloads.
The AWS MCP Server eliminates the model where raw credentials would be exposed. Instead of running a custom proxy layer to broker AWS access, teams now connect agents directly to AWS’s managed MCP Server, which handles authentication through existing IAM, logs every call through CloudTrail, and applies the same security boundaries.
The AWS MCP Server also addresses outdated model knowledge by giving agents query time access to live AWS documentation, API references, and AWS ‘What’s New’ updates. Instead of relying solely on static model memory, it can retrieve current AWS guidance in real time before generating infrastructure code or executing workflows.
Most MCP servers expose every API as its own tool. The agent’s context window fills up with tool definitions before it gets to the actual work. AWS kept it to 11 tools, split between reading AWS state and acting on it.
search_documentation: find relevant AWS docs, API references, and Skillsread_documentation: pull the full content of a doc page in markdownrecommend: getting related documentation suggestions from a starting pageretrieve_skill: load a curated AWS best-practice workflow for a specific domain (Skills are contributed by AWS service teams)list_regions: list all AWS regionsget_regional_availability: check whether a service, feature, or API is available in a given regionsuggest_aws_commands: get syntax help for AWS APIs, including ones too new to be in the model’s training datacall_aws: execute any of 15,000+ AWS APIs using existing IAM credentialsrun_script: run Python in a sandboxed environment with AWS API access, for multi-step workflowsget_presigned_url: generate pre-signed S3 URLs for uploads and downloadsget_tasks: poll long-running operations started by call_aws or run_scriptAWS usually groups these tools in two categories, AWS Knowledge Tools and AWS API tools, but the distribution above maps more closely to how an agent actually uses them in a workflow.
Hire AWS Developers from Bacancy to design, deploy, and scale secure AI agent systems on AWS based on custom requirements.
Many engineering teams are already running their own MCP infrastructure on AWS using Lambda, ECS Fargate, Kubernetes, or even Bedrock AgentCore Runtime. The AWS MCP Server is not meant to replace those architectures completely; it solves a different problem.
At its core, AWS MCP Server is designed to standardise how AI agents can communicate securely with AWS services. Custom MCP servers are built to expose proprietary tools, internal APIs, business workflows, or domain-specific systems that AWS cannot manage for you.
When the goal is to operate across AWS infrastructure securely and at scale, a managed MCP server for AWS is the better choice aligned with the primary goals. Use the AWS MCP Server when the following details match your requirements:
You benefit from lower operational AWS MCP Server pricing with a fully managed architecture maintained directly by AWS. It works by eliminating architectural complexity of infrastructure while preserving AWS native governance controls.
If your agents need access to systems outside the standard AWS service boundary, a custom MCP server is ideal for you. If these requirements match your needs, then you can proceed with custom MCP server development. However, before starting, it is worth knowing the cost of building an MCP server.
In these cases, teams often decide to deploy custom MCP infrastructure on Lambda ECS Fargate, Kubernetes, or internal platform runtimes, maintaining complete control over execution behaviour and network boundaries. If you are looking to build a custom MCP infrastructure that can scale, you will need an experienced team of MCP developers who understand both MCP protocol design and AWS-native architecture.
In a real-world setting, the decision is not about choosing between AWS MCP Server or a Custom MCP server. Because most engineering teams eventually adopt a hybrid architecture that combines both. The AWS MCP Server brings security, IAM-governed access to AWS services S3, Lambda, EC2, DynamoDB, CloudWatch, and CloudFormation. Also, it provides built-in authentication, CloudTrail audit logging, and centralized governance without requiring teams to manage custom infrastructure layers.
At the same time, organisations need AI agents to interact with systems which exist outside the AWS service boundary. This is where the role of a custom MCP server becomes more prominent. Teams use them to expose internal microservices, proprietary databases, private APIs, business workflows, and organisation-specific tooling that AWS cannot directly manage.
Following this hybrid approach, organizations can preserve AWS native security and governance through IAM and CloudTrail while still providing AI agents controlled access to the broader internal ecosystem for real production-based workflows.
The AWS MCP Server architecture has three moving parts, which include a managed remote server, the MCP Proxy for AWS that runs locally, and an AI coding agent.
The flow matters because AWS MCP Server architecture differs from traditional self-hosted MCP implementations. AI coding assistants like Claude Code, Cursor, or Kiro send requests through a local MCP Proxy for AWS, the proxy authenticates requests using existing AWS IAM credentials and SigV4 signing. The managed AWS MCP Server receives signed requests and executes AWS API operations inside AWS infrastructure.
The biggest advantage of a managed MCP server for AWS is its easy yet lightweight setup process after general availability. In most cases, the complete setup just takes a few minutes.
curl -LsSf https://astral.sh/uv/install.sh | sh
aws login or aws configure ssoBoth methods renew tokens, which avoids the most common failure mode, and expired credentials silently break agents mid-session. aws login requires AWS CLI v2.32.0 or later (released November 2025); older CLI versions won’t recognise the command, so use aws configure sso if you can’t upgrade.
For Claude Code:
claude mcp add-json aws-mcp --scope user \
'{"command":"uvx","args":["mcp-proxy-for-aws@latest","https://aws-mcp.us-east-1.api.aws/mcp","--metadata","AWS_REGION=us-west-2"]}'
For Cursor, add the same uvx mcp-proxy-for-aws@latest configuration to ~/.cursor/mcp.json
For Kiro, place it inside: .kiro/settings/mcp.json
Once the setup gets done, restart Claude Code, Cursor, or Kiro. Open the MCP tools panel, and confirm the AWS tools that are available.
The value proposition of AWS MCP Server is not just the size of its AWS API access, but rather how dramatically it changes day-to-day engineering workflows. The majority of teams are not looking for AI agents that can just call AWS APIs in theory. They need agents that can perform safely, automating infrastructure work, reducing operational costs, and making better decisions using live AWS context instead of using outdated training data. Here are the key use cases of AWS MCP Server:
Among others, the major problem with AI-generated infrastructure code is its outdated architectural knowledge. Consider that if an agent is asked to store embeddings on S3 without access to live AWS documentation, it may generate an outdated implementation based entirely on its training data. In many cases, the model may not even know newer AWS services or features that exist there.
Using AWS MCP Server, agents can use search documentation and read documentation, retrieving current AWS guidance in real time before generating code. Instead of relying on any outdated patterns, the agent can identify newer AWS native services and implement the recommended architecture directly.
Sandboxed Python execution in AWS MCP Server Architecture is one of the most practical parts of this environment. By using run script capabilities, AI agents can execute their multi-step workflows against AWS services that don’t require access to developers’ local machine, shell environment, or file system.
As the execution environment stays isolated, even a faulty or malicious workflow cannot access local developer resources. It makes the MCP server for AWS safer than allowing unrestricted local automation.
The AWS MCP Server also changes how engineering and SRE teams approach overall operational debugging. Instead of manually correlating CloudWatch alarms, Lambda logs, and CloudTrail events, teams can delegate much of the investigative workflow to an AI agent.
As all actions are logged with full IAM and aws: ViaAWSMCPService / aws: CalledViaAWSMCP context keys attached, teams can retain complete audit visibility into everything the agent investigates or executes. It makes the production debugging more governed than traditional automated scripts.
The AWS MCP server also works well with AWS-focused IaC validation systems. When paired with CloudFormation, CDK, or AWS IaC MCP tooling, agents can validate the overall infrastructure templates against AWS security best practices before deployment. With the integration of live AWS documentation with infrastructure validation, AWS MCP Server eliminates multiple governance and security issues commonly introduced by AI-generated IaC.
Before adopting the AWS MCP Server for development, engineering teams need to evaluate several operational considerations carefully.
The biggest advantage of having managed the MCP Server for AWS is that it is free to use. Teams only pay for the AWS resources and AI model usage generated by the agent workflow. The major costs come from foundation model token consumption, AWS infrastructure provisioned by agents, large-scale automation workflows, GPU or high compute EC2 deployments.
Security remains one of the most crucial aspects of deploying AI agents in an AWS environment. The AWS MCP server is integrated directly with IAM controls, allowing organizations to define whole policies, specifically for the actions executed through the MCP layer. The best practices of this include dedicated IAM roles for development, staging, and production. The explicit deny over policies for destructive production actions, no shared long-lived access keys, and strict least privilege permissions.
In May 2026, the AWS MCP Server is hosted in us-east-1 and eu-central-1, but API calls can target any AWS region via the AWS_REGION metadata flag during AWS MCP Server setup. For organizations that follow strict compliance, residency, or regulatory requirements, based on regional hosting considerations that need to be reviewed carefully before any rollout.
Production needs strong observability from day one. The AWS MCP Server integrates CloudWatch and CloudTrail, allowing teams to monitor API request volume, authorisation failures, rate limiting, agent-driven infrastructure activity, and workflow execution behaviour.
AWS MCP Server works with any MCP-compatible AI coding agent. Based on our first impressions, we’d recommend Claude Code for enterprise engineering work, Cursor for IDE-centric workflows, and Kiro for AWS-native automation. The differences come down to IDE fit and workflow; the AWS MCP Server support is the same across all of them.
Setting up AWS MCP Server might look straightforward, but building production-ready AI agents around it is not. Teams might complete the initial AWS MCP Server setup in a few hours, but the challenging part begins afterwards, while designing secure IAM boundaries, implementing environment-specific control, instrumenting observability pipelines, validating the agent behaviour, and ensuring a workflow that can pass an enterprise security review.
This is where Bacancy’s AWS consulting services help. We help organizations build production-ready MCP Server for AWS workflows, supporting teams across the full lifecycle of AWS-native agent development. Here’s what we will cover:
As AI agents have moved from experimentation into real production workflows, the concern is no longer about whether agents can automate AWS operations or not. The challenge is about building systems that remain secure, observable, compliant, and operation-ready. It needs more than a basic AWS MCP Server setup.
Yes, the AWS MCP Server works well with multi-account AWS organizations when configured with a proper IAM role and account-level permissions. Many teams deploy separate IAM roles for development, staging, and production accounts while using least privilege access policies to control what AI agents can access across environments.
The MCP Proxy for AWS introduces minimal latency because of its primary responsibility to manage authentication and request signing through IAM and SigV4 before forwarding the request to the managed AWS MCP Server. In real-world cases, the larger latency factors come from model reasoning, AWS API execution, or long-running automation tasks rather than the proxy layer itself.
The AWS MCP Server and Amazon Bedrock solve different problems. The AWS MCP Server focuses on making AI agents secure, providing governed access to AWS APIs through IAM authentication, CloudTrail logging, and MCP-compatible tooling. On the other hand, Amazon Bedrock Agentcore is designed for building and orchestrating AI agents, including workflows, memory, reasoning, and agent runtime.
Yes, for any tool that actually calls AWS APIs (call_aws, run_script, get_presigned_url, get_tasks), you need valid AWS credentials and an IAM role with the appropriate permissions. The documentation tools (search_documentation, read_documentation) are the exception they don’t require authentication.
Yes, one of the biggest advantages of AWS MCP Server Architecture is that it inherits standard IAM controls. Organizations can create IAM roles, or apply explicit deny policies blocking destructive actions such as resource, infrastructure modification, or privilege escalation. Teams generally start with read-only access during early AWS MCP Server setup and gradually expand permissions only after validating agent behaviour in the lower environment.
Most of the AWS MCP Server connection issues are related to authentication or expired credentials. The common troubleshooting steps include verifying AWS SSO or IAM authentication, refreshing expired AWS tokens, confirming the MCP Proxy for AWS is installed correctly, checking region metadata configuration, and restarting Claude Code or Kiro after setup changes.
The induction of AWS MCP Server replaces two specific servers from AWS Labs: AWS API MCP Server and AWS Knowledge MCP Server. AWS recommends removing both before installing AWS MCP Server, since the duplicate tools confuse AI agents and can impact overall performance.
Your Success Is Guaranteed !
We accelerate the release of digital product and guaranteed their success
We Use Slack, Jira & GitHub for Accurate Deployment and Effective Communication.