AWS MCP Server: Secure, Governed AWS Access for AI Agents

AI coding agents are becoming more capable, but AWS work still creates a difficult access problem: how do you let an agent inspect current AWS documentation, understand services, and call AWS APIs without handing it broad, unmanaged credentials?

That is the problem the AWS MCP Server is designed to solve. AWS announced general availability on May 6, 2026, describing it as a managed server that gives AI coding agents secure access to AWS services through the Model Context Protocol while keeping IAM guardrails, CloudWatch metrics, and CloudTrail logging in the control model.

Quick answer: what is the AWS MCP Server?

The AWS MCP Server is a managed remote MCP server from AWS that lets AI agents and coding assistants interact with AWS through a small set of tools. Agents can search AWS documentation, retrieve service guidance, call AWS APIs using existing IAM credentials, run sandboxed Python workflows, and load AWS-maintained Skills for guided tasks.

In simpler terms, it is a governed bridge between an AI coding agent and AWS. Instead of relying only on a model's training data or giving an assistant direct shell access, teams can route AWS work through MCP tools that support AWS authentication, authorization, documentation retrieval, and observability.

Why AI agents need better AWS access

AI agents often struggle with AWS for three reasons.

• Their training data gets stale. AWS services, APIs, regions, and best practices change constantly. An agent may know yesterday's pattern but miss a new API parameter or regional constraint.
• They can make confident infrastructure mistakes. Agents may choose the wrong service, over-broaden IAM, retry failed commands, or produce infrastructure that works in a demo but fails operational review.
• Direct access is hard to govern. If a developer gives an assistant broad local credentials or shell access, it becomes harder to distinguish human activity from agent activity or enforce agent-specific rules.

The AWS MCP Server does not remove all risk. It does, however, give platform and security teams a more governable path for agent access.

How the AWS MCP Server works

A typical flow looks like this:

1. A developer asks an MCP-compatible AI client to perform an AWS-related task.
2. The agent calls tools exposed by the AWS MCP Server.
3. Documentation tools can retrieve current AWS information.
4. API actions are authenticated through existing AWS credentials.
5. AWS services authorize requests using IAM policies.
6. Activity can be observed through CloudWatch metrics and audited through CloudTrail logs.

The server works with Claude Code, Kiro, Cursor, Codex, and any MCP-compatible client. It is available in US East (N. Virginia) and Europe (Frankfurt), can make API calls to any AWS Region, and has no additional server charge beyond the AWS resources and data transfer your agents use.

Core AWS MCP Server tools

The value of the AWS MCP Server comes from a compact tool surface. The current Agent Toolkit documentation lists several tools that matter for pilots:

Tool	What it does	Why it matters
aws___search_documentation	Searches AWS documentation, API references, best practices, service guides, and Skills.	Lets agents work from current AWS information instead of model memory alone.
aws___read_documentation	Retrieves AWS documentation pages and converts them into Markdown.	Helps assistants reason from official documentation inside the task flow.
aws___retrieve_skill	Loads AWS-maintained Skills with workflows, context, best practices, decision frameworks, and procedures.	Gives agents guided execution for AWS tasks where sequence and judgment matter.
aws___call_aws	Executes authenticated AWS API calls with syntax validation and error handling.	Turns the agent from a passive advisor into a tool that can inspect or operate AWS within IAM limits.
aws___run_script	Runs Python code in a sandboxed environment with AWS API access.	Supports multi-step checks, parallel API calls, retries, and cross-service inspection without giving the agent local shell access.
aws___get_tasks	Polls long-running tasks started by API or script tools.	Lets agents track operations that do not finish in a single request.

Security model: IAM still controls what agents can do

The most important point is simple: AWS MCP Server does not replace IAM.

The AWS setup guide makes one boundary clear: invoking the MCP server does not require a separate IAM permission. Authorization still happens at the AWS service level using the existing IAM roles and policies behind the credentials in use.

That is good news for security teams, but it also means over-permissioned credentials remain dangerous. If the credentials available to the agent can delete production resources, the agent may be able to request those actions unless policy blocks them.

IAM context keys for MCP-initiated actions

A major governance feature is support for IAM global condition context keys. AWS adds two keys to requests made through managed AWS MCP servers:

• aws:ViaAWSMCPService: set to true when the request passes through an AWS managed MCP server.
• aws:CalledViaAWSMCP: contains the service principal of the AWS managed MCP server, such as aws-mcp.amazonaws.com.

These keys let teams treat agent-initiated actions differently from direct human or automation calls. For example, you can block destructive S3 actions when they come through the AWS MCP Server:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyDestructiveS3ActionsViaAwsMcp",
      "Effect": "Deny",
      "Action": [
        "s3:DeleteBucket",
        "s3:DeleteObject",
        "s3:PutBucketPolicy",
        "s3:PutBucketPublicAccessBlock"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:CalledViaAWSMCP": "aws-mcp.amazonaws.com"
        }
      }
    }
  ]
}

This policy is only a starting example. Production policies should be scoped to your accounts, roles, resources, environments, and approval model.

CloudWatch vs CloudTrail: what each one proves

CloudWatch and CloudTrail are both relevant, but they are not interchangeable.

CloudWatch metrics help teams observe MCP server activity patterns. CloudTrail is the audit record for AWS API calls. Design around that split: CloudWatch shows MCP activity, while CloudTrail captures the API-call history your audit process will need.

That distinction matters. Do not describe CloudWatch metrics as a complete API-call audit trail. For investigations, compliance evidence, and historical API-call review, design around CloudTrail.

What the AWS MCP Server is best for

The AWS MCP Server is a strong fit when a team wants AI coding agents to help with AWS tasks while keeping access inside familiar AWS governance patterns.

• Developers who want agents to use current AWS documentation.
• Platform teams standardizing AI coding tools across AWS environments.
• Security teams that need IAM-based controls for agent-initiated activity.
• DevOps and SRE teams that want agents to inspect resources or troubleshoot issues.
• Organizations experimenting with AI coding assistants but concerned about unmanaged credentials.
• Teams that want to reduce reliance on general-purpose shell access for AWS operations.

It is not a substitute for security architecture, least-privilege IAM, change approval, cost controls, human review, or environment separation.

When not to use it yet

Do not start with broad production write access. The AWS MCP Server may not be the right first step if your organization has not defined IAM boundaries for agent access, cannot separate development from production permissions, lacks CloudTrail coverage, or has not decided which agent actions require human approval.

A safer path is documentation access first, then read-only API access, then limited write actions in non-production, and only later carefully scoped production workflows.

How to pilot AWS MCP Server safely

Start narrow: one development team, one non-production AWS account, and a small set of use cases. Good first use cases include documentation lookup, service discovery, read-only environment inspection, and infrastructure suggestions that a human reviews before applying.

1. Remove conflicting older MCP servers. AWS recommends removing existing AWS API MCP Server or AWS Knowledge MCP Server entries before configuring AWS MCP Server.
2. Use renewable credentials. Prefer IAM Identity Center or another renewable credential flow over static IAM access keys.
3. Start read-only. Let agents inspect documentation, regions, service information, and non-sensitive resources before allowing writes.
4. Use IAM context keys. Apply policies that distinguish MCP-initiated actions from direct calls.
5. Block destructive operations. Deny deletion, public exposure, and production modification through MCP until reviewed.
6. Monitor CloudWatch and CloudTrail. Use CloudWatch for MCP activity visibility and CloudTrail for API-call auditing.
7. Review outputs before expanding permissions. Expand only after useful workflows, acceptable error rates, and rollback paths are proven.

The pilot goal is not to prove that an agent can do everything. The goal is to identify which AWS workflows can be accelerated safely.

AWS MCP Server vs direct AWS CLI access

The AWS CLI is still essential, but direct CLI or shell access creates governance challenges for agents. An assistant may issue commands in a way that is difficult to distinguish from a human developer using the same local environment. It may also combine AWS commands with local files, shell tools, or unrelated tools outside a dedicated control path.

With AWS MCP Server, agent activity can be routed through a managed MCP interface, authorized by IAM, and distinguished with MCP-specific context keys. That does not eliminate risk, but it gives security and platform teams a clearer control model.

AWS MCP Server vs custom MCP servers

A custom MCP server may be better when you need to expose internal tools, proprietary APIs, non-AWS systems, or business-specific workflows to agents.

The AWS MCP Server is better suited when the problem is AWS access itself: current AWS documentation, AWS API execution, AWS service discovery, IAM authorization, and AWS observability. Many organizations will eventually use both.

Common mistakes to avoid

• Giving agents too much permission too early. Start with the smallest useful permission set.
• Treating MCP as a complete security boundary. Your real controls still depend on IAM, credentials, account boundaries, logs, review processes, and approval rules.
• Confusing observability with auditability. CloudWatch metrics help with activity visibility; CloudTrail is the API-call audit record.
• Skipping credential lifecycle planning. Expired credentials can break workflows and push teams toward unsafe shortcuts.
• Measuring only task completion. A successful pilot should prove that actions are scoped, observable, reviewable, and reversible.

FAQ

Is AWS MCP Server free?

The AWS MCP Server is available at no additional charge. You still pay for AWS resources your agents create or use and applicable data transfer costs.

Does AWS MCP Server let agents access all AWS services?

AWS describes call_aws as the tool for authenticated API calls across most AWS APIs, with credential management included. What an agent can actually do still depends on the IAM credentials and policies in use.

Does AWS MCP Server require separate IAM permissions?

No separate IAM permission is required to invoke the MCP server. Authorization occurs at the AWS service level using existing IAM roles and policies.

Can I block agents from deleting resources?

Yes, if IAM policies are designed to do that. Use condition keys such as aws:ViaAWSMCPService and aws:CalledViaAWSMCP to apply rules to MCP-initiated requests.

Which clients work with AWS MCP Server?

The server works with Claude Code, Kiro, Cursor, Codex, and any MCP-compatible client.

Should I use AWS MCP Server in production immediately?

No. Start with documentation access, read-only workflows, non-production accounts, clear IAM boundaries, CloudWatch and CloudTrail visibility, and human review for write actions.

Final takeaway

The AWS MCP Server is important because it moves AI coding agents closer to useful AWS work without forcing teams to abandon cloud governance.

It gives agents current AWS knowledge, authenticated API access, sandboxed workflow execution, and AWS-native observability. More importantly, it lets platform and security teams apply familiar controls through IAM, context keys, CloudWatch, and CloudTrail.

How Elevata helps

Elevata helps platform, security, and engineering teams design safe AI-agent access on AWS: IAM boundaries, MCP policy design, CloudTrail review, sandbox accounts, cost controls, developer workflows, and rollout gates.

If your team is piloting AWS MCP Server or AI coding agents on AWS, book an AI agent access readiness review.