AWS MCP Server

The AWS MCP Server is the official set of Model Context Protocol servers maintained by AWS Labs, giving AI agents access to S3, Lambda, DynamoDB, CloudWatch, and other AWS services. Released in 2025 and actively maintained by the awslabs organization, it covers both resource inspection and operational tasks across the AWS ecosystem through a modular, service-specific server architecture.

AWS is the infrastructure layer under a significant portion of the software built today. S3 holds data. Lambda runs functions. DynamoDB stores application state. CloudWatch watches all of it. For AI agents working on anything that touches AWS, having actual API access to these services rather than relying on documentation and guesswork is a meaningful difference. The AWS MCP Server, maintained by AWS Labs, is the official way to give agents that access.

Architecture: modular by design

Unlike some MCP servers that expose a single monolithic service, the AWS MCP Server follows a service-by-service pattern. The awslabs/mcp repository is a collection of individual server packages, each targeting a specific AWS service area. You configure the ones you need and leave the rest out.

This design choice is practical. AWS has hundreds of services. A single server trying to cover all of them would be unwieldy and would expose far more attack surface than any single workflow needs. By picking specific servers, you get a minimal, auditable surface. Your agent for a Lambda-heavy workflow gets Lambda and CloudWatch tools. It does not also get tools for Route 53 or ECR unless you add those explicitly.

The tradeoff is that the initial setup requires more decisions. You need to identify which service servers apply to your workflow before you start configuring. The repository README provides the current list of available servers and their install paths.

What the servers expose

The tool surface varies by service server, but across the collection you can expect coverage of the following areas:

S3 operations. List buckets, list objects within a bucket, read object contents, upload objects, copy and delete objects, and inspect bucket configuration. For any workflow involving data files, logs, or generated artifacts, S3 access is often the first thing you want. An agent that can read a file from S3 and write results back to a different prefix covers a large class of data processing tasks.

Lambda. List functions in your account, describe function configuration (runtime, timeout, memory, environment variables), invoke functions directly, and retrieve recent execution logs. The invoke capability means the agent can trigger a function and retrieve its output without you switching to the console or the CLI.

DynamoDB. Query tables, scan items with filter expressions, read specific items by key, and write or delete items. DynamoDB's query model is specific enough that the agent having accurate table descriptions (key schema, attribute names, index configuration) before it writes queries matters quite a bit. The server exposes table metadata so the agent starts with real schema context.

CloudWatch. Retrieve log groups and streams, query log events with filter patterns, and read metric data for specific namespaces and dimensions. This is where agents become genuinely useful for operational work: describe the symptom in plain language, the agent finds the relevant log streams, and filters for the events that match.

IAM and resource metadata. Depending on which servers you configure, the agent can describe IAM policies, list roles, and retrieve resource metadata across services. This is read-heavy and useful for auditing and documentation tasks.

Setup

The server uses the standard AWS credential chain, so the credential setup is whatever you already use for the AWS CLI or SDKs. If aws s3 ls works in your shell, your environment is already configured.

Set up credentials (if not already done):

aws configure

This writes your access key, secret, and default region to ~/.aws/credentials and ~/.aws/config. Alternatively, set environment variables directly:

export AWS_ACCESS_KEY_ID=your-key-id
export AWS_SECRET_ACCESS_KEY=your-secret
export AWS_REGION=us-east-1

Add the server to Claude Desktop at ~/Library/Application Support/Claude/claude_desktop_config.json. The exact package name depends on which service server you are installing; check the awslabs/mcp repository for current package names:

{
  "mcpServers": {
    "aws-s3": {
      "command": "npx",
      "args": ["-y", "@aws-labs/mcp-server-s3"],
      "env": {
        "AWS_ACCESS_KEY_ID": "your-key-id",
        "AWS_SECRET_ACCESS_KEY": "your-secret",
        "AWS_REGION": "us-east-1"
      }
    },
    "aws-lambda": {
      "command": "npx",
      "args": ["-y", "@aws-labs/mcp-server-lambda"],
      "env": {
        "AWS_ACCESS_KEY_ID": "your-key-id",
        "AWS_SECRET_ACCESS_KEY": "your-secret",
        "AWS_REGION": "us-east-1"
      }
    }
  }
}

For Claude Code, the config file lives at ~/.claude/mcp.json with the same structure.

If you have an IAM role configured (for example, on an EC2 instance or via AWS SSO), you can omit the access key environment variables and let the credential chain resolve automatically:

{
  "mcpServers": {
    "aws-s3": {
      "command": "npx",
      "args": ["-y", "@aws-labs/mcp-server-s3"],
      "env": {
        "AWS_REGION": "us-east-1"
      }
    }
  }
}

Real use cases

Lambda debugging. When a function is failing intermittently, the agent can list recent CloudWatch log streams for the function, filter for error events, and summarize the failure pattern. This replaces the manual workflow of opening CloudWatch, finding the right log group, and clicking through log streams. The agent does the retrieval and gives you the relevant events.

S3 data pipelines. For workflows that process files in S3, the agent can list a prefix, identify files matching certain criteria, read their contents, apply transformations in memory, and write the results back to a different prefix or bucket. This is particularly useful for ad-hoc data work where you do not want to spin up a full processing job.

DynamoDB exploration. When debugging an application bug that involves database state, the agent can query the DynamoDB table directly with the exact key conditions relevant to the affected user or session. No need to write a one-off query script or navigate the DynamoDB console.

Cost and usage investigation. CloudWatch metrics cover a wide range of AWS usage signals. The agent can pull metrics for a specific service over a time window to understand usage patterns, compare before and after a deployment, or identify which resources are consuming disproportionate capacity.

Infrastructure documentation. For accounts with organically grown infrastructure, the agent can systematically describe Lambda functions, DynamoDB tables, and S3 buckets, producing structured documentation from the live API rather than from memory or stale wiki pages. Pair this with the Filesystem MCP server to write the output to local files.

Incident triage. When something goes wrong, the agent can check CloudWatch alarms, pull recent log events for the affected service, and query DynamoDB for the state of specific records, all without switching between the console, CLI, and log viewer. The compound query capability is where agents add real time savings over manual investigation.

Security considerations

AWS credentials are high-value targets. The practices that matter for agent use:

Use IAM roles over long-lived access keys. If you are running the MCP server on an EC2 instance, ECS container, or any AWS compute resource, configure an IAM role for the instance rather than embedding access keys. IAM roles rotate credentials automatically and eliminate the risk of long-lived key exposure.

Create a dedicated IAM user or role for agent use. Do not use your personal AWS credentials or an admin account for the MCP server. Create a purpose-built IAM entity with a policy that grants only the specific actions (s3:GetObject, s3:PutObject, lambda:InvokeFunction, etc.) on the specific resources the workflow needs.

A minimal S3 read policy looks like this:

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

Do not embed credentials in config files under version control. Pass credentials via environment variables set outside the config file, use AWS profiles (reference the profile name rather than the keys), or use a secrets manager. The config file structure above shows the env block pattern; the actual values should come from your shell environment or a secrets tool, not hardcoded in the file.

Restrict DynamoDB and Lambda write access carefully. Lambda invocation and DynamoDB write operations are consequential. If your workflow is read-only (investigation, documentation, monitoring), scope the IAM policy to read-only actions and the agent cannot accidentally modify anything.

Enable CloudTrail for the credentials you use. AWS CloudTrail logs every API call made with your credentials. With CloudTrail enabled for the region, you get a full audit trail of every action the agent takes. For any regulated environment, this is not optional.

Comparing to the AWS CLI

The AWS CLI and the MCP server address different kinds of tasks. The CLI is faster for operations you know exactly how to execute: aws s3 cp, aws lambda invoke, aws logs filter-log-events. If you know the command, the CLI wins on speed.

The MCP server is better for compound, exploratory, and conversational tasks: "find all Lambda functions with a timeout over 30 seconds and show me their CloudWatch error rates for the last hour", "which S3 objects in this prefix were last modified before 2025-01-01 and are larger than 100MB". These queries require multiple API calls, result correlation, and judgment about what to surface. An agent handles that better than a sequence of CLI commands.

The two are complementary. Keep the CLI for scripted tasks and automation. Add the MCP server for investigation, documentation, and iterative work where the goal is clearer than the path.

Pairing with other servers

The AWS MCP Server pairs well with several other servers in the ecosystem. Combined with GitHub MCP, the agent can read Lambda function source from a repository, compare it to the deployed version, and identify discrepancies. Combined with Filesystem MCP, it can pull S3 objects to disk for local editing and push them back.

For teams using Slack MCP for incident response, pairing it with the AWS MCP Server lets the agent pull CloudWatch data and post a formatted summary to a Slack channel in a single session.

Bottom line

The AWS MCP Server is the right integration for any team doing meaningful work on AWS. The official status from awslabs means it tracks the AWS API accurately, and the modular design means you install only the surface you need rather than granting broad account access.

The setup requires real attention to IAM policy scoping. That upfront work is worth it: with properly scoped credentials, the agent becomes a fast and practical tool for debugging, investigation, and infrastructure documentation across your AWS environment.

Features

• Query and manage S3 buckets and objects
• Invoke and inspect AWS Lambda functions
• Read and write DynamoDB tables
• Query CloudWatch logs and metrics
• Retrieve IAM policies and resource metadata
• List and describe resources across AWS regions
• Authenticates via standard AWS credential chain (env vars, profiles, IAM roles)
• Modular design with separate servers per AWS service area

How to set up the AWS MCP Server MCP server

1. Configure AWS credentials via environment variables or AWS profile (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_REGION)
2. Clone or install the specific AWS MCP server package for the service you need
3. Add the server block to your Claude Desktop or Claude Code MCP config file
4. Set the AWS_REGION environment variable to target the correct region
5. Restart your MCP client and verify the AWS tools appear in the tool list