Connect Amazon Web Services to Claude: Inventory, Storage & Compute

If you need to connect Amazon Web Services to Claude to automate cloud inventory reporting, audit security groups, or query cross-region infrastructure, you need a Model Context Protocol (MCP) server. This server acts as the translation layer between Claude's function-calling capabilities and the massive surface area of the AWS APIs. You can either build and maintain this infrastructure yourself, or use a managed integration platform like Truto to dynamically generate a secure, authenticated MCP server URL.

If your team uses ChatGPT, check out our guide on connecting Amazon Web Services to ChatGPT or explore our broader architectural overview on connecting Amazon Web Services to AI Agents.

Giving a Large Language Model (LLM) read and write access to a sprawling cloud provider like AWS is a massive engineering challenge. You are not just dealing with one API; you are dealing with dozens of disjointed microservices, XML and JSON dialects, regional fragmentation, and aggressive throttling. Every time AWS introduces a new resource type or deprecates an old field format, you have to update your server code, redeploy, and test the integration.

This guide breaks down exactly how to use Truto to generate a secure, managed MCP server for Amazon Web Services, connect it natively to Claude Desktop, and execute complex infrastructure workflows using natural language.

The Engineering Reality of the AWS API

A custom MCP server is a self-hosted integration layer. While the open MCP standard provides a predictable way for models to discover tools, the reality of implementing it against the Amazon Web Services API is painful. AWS is notoriously fragmented, with APIs written decades apart that follow completely different design patterns.

If you decide to build a custom Amazon Web Services MCP server, here are the specific integration challenges you will face:

Protocol and Schema Dialect Fragmentation AWS APIs are split across multiple protocol types. Services like EC2 and Elastic Load Balancing use an old XML Query API. When converting these responses to JSON for an LLM, every scalar leaf comes back wrapped as {_text: value}, and nested lists collapse into bare objects instead of one-item arrays when exactly one entry exists. Your MCP tools have to normalize this before passing it to Claude, otherwise the LLM will hallucinate structure. In contrast, modern AWS services use JSON RPC over POST, requiring entirely different request and parsing logic.

The '404 as Data' Pattern in Security Services In standard APIs, a 404 Not Found means an error in the request path. In AWS security services like Security Hub, Macie, or GuardDuty, a 404 (or InvalidAccessException) often simply means the service is not enabled in that specific region or account. This is valid data - it tells you a security control is missing. If your MCP server blindly maps 404s to integration failures, you turn every programmatic query about security posture into noisy errors.

Pagination Chaos AWS has no standardized pagination strategy. IAM and S3 use Marker and IsTruncated. EC2 uses NextToken and MaxResults. Redshift uses Marker and MaxRecords. S3 demands pagination explicitly; unpaginated requests are rejected outright for accounts with a bucket quota above 10,000, and BucketRegion is only returned on paginated requests. Your MCP server must abstract these differences away from Claude so it can just pass cursors natively.

Regional Isolation and Global Sweeps Most AWS resources are regional. If you want to know if GuardDuty is enabled or if EC2 instances are running, you cannot ask a global endpoint. You must sweep up to 30 individual regions. A naive MCP implementation will force Claude to invoke the exact same tool 30 times sequentially, blowing up your context window and taking several minutes.

Generating the Amazon Web Services MCP Server

Instead of building custom tools to navigate XML wrapping, regional sweeps, and 404 handling, you can use Truto. Truto abstracts the AWS API behind standardized proxy methods and dynamically generates MCP tool definitions derived from live integration schemas.

Truto does not cache your infrastructure data. When Claude calls a tool, the MCP server proxies the request directly to AWS using the authenticated account's credentials, meaning the LLM gets real-time, accurate state.

Factual Note on Rate Limits

When operating across dozens of AWS accounts, you will hit rate limits (e.g., AWS Organizations allows 1-2 requests per second for certain endpoints). Truto does not retry, throttle, or apply backoff on rate limit errors. When the upstream Amazon Web Services API returns an HTTP 429, Truto passes that error directly to the caller.

However, Truto normalizes the upstream rate limit information into standardized headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset) per the IETF specification. The caller (your MCP client or agent framework) is responsible for reading these headers and executing its own retry and backoff logic.

Method 1: Via the Truto UI

If you want to immediately drop an MCP server URL into Claude Desktop, use the dashboard.

1. Log into your Truto environment.
2. Navigate to the Integrated Accounts page and select your connected Amazon Web Services account.
3. Click the MCP Servers tab.
4. Click Create MCP Server.
5. Name your server (e.g., AWS_Infra_Prod) and select your configuration (method filters, tags, expiration).
6. Copy the generated MCP Server URL.

Method 2: Via the Truto API

If you are dynamically spinning up agents per tenant, you can provision MCP servers programmatically.

curl -X POST https://api.truto.one/integrated-account/{integrated_account_id}/mcp \
  -H "Authorization: Bearer YOUR_TRUTO_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "AWS Cloud Ops Agent",
    "config": {
      "methods": ["read"],
      "tags": ["compute", "storage", "security"]
    }
  }'

The API returns a secure, authenticated endpoint:

{
  "id": "mcp_abc123",
  "name": "AWS Cloud Ops Agent",
  "url": "https://api.truto.one/mcp/a1b2c3d4e5f6...",
  "expires_at": null
}

Connecting the MCP Server to Claude

Once you have the Truto MCP URL, you need to expose it to your LLM environment.

Method 1: Via the Claude UI (Claude for Work)

If your organization uses Claude Enterprise or Team plans, you can add the connector globally.

1. Open Claude and go to Settings -> Integrations.
2. Click Add MCP Server or Add custom connector.
3. Paste the Truto MCP URL you generated.
4. Save. Claude will immediately handshake with the server and discover the AWS tools.

Method 2: Via Manual Configuration (Claude Desktop)

If you are testing locally using the Claude Desktop application on macOS or Windows, you can route it through the official Server-Sent Events (SSE) transport wrapper provided by Anthropic.

Open your claude_desktop_config.json file:

• macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
• Windows: %APPDATA%\Claude\claude_desktop_config.json

Add the following configuration, injecting your unique Truto MCP URL:

{
  "mcpServers": {
    "aws_cloud_ops": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-sse",
        "--url",
        "https://api.truto.one/mcp/a1b2c3d4e5f6..."
      ]
    }
  }
}

Restart Claude Desktop. The application will initialize the connection, read the JSON schema definitions for the AWS tools, and surface them to the model.

Amazon Web Services Hero Tools for Claude

Truto maps the complex AWS API surface into highly scoped, LLM-friendly tools. Here are the highest-leverage tools available for your agent.

1. List All Organizations Accounts

Tool: list_all_amazon_web_services_organizations_accounts

This tool executes a global sweep of every account in the AWS Organization. It materializes the organizational unit grouping path directly in the response so you do not have to recursively walk the OU tree. Note that JoinedTimestamp represents the date the account joined the organization, not the date the account was created.

"Fetch every AWS account in the current organization. Identify any accounts where the state is not ACTIVE, and list out the grouping path for each to show which Organizational Unit they belong to."

2. List All S3 Buckets

Tool: list_all_amazon_web_services_s_3_buckets

Retrieves every S3 bucket in the account. Truto abstracts the strict pagination requirements that AWS enforces for high-volume environments and ensures BucketRegion and BucketArn are properly returned. Note that directory buckets (S3 Express One Zone) exist in a disjoint namespace and do not appear here.

"List all S3 buckets in this AWS account. Filter the response down to buckets created in the last 90 days and group them by their designated AWS region."

3. List All EC2 VPCs

Tool: list_all_amazon_web_services_ec_2_vpcs

Lists all Virtual Private Clouds in a specified region. This tool brings back the blockPublicAccessStates configuration, which is critical because VPC Block Public Access can override an internet gateway route, meaning a subnet with an igw- route may actually be safely unreachable.

"Check the VPCs in the us-east-1 region. Tell me which VPCs currently have VPC Block Public Access turned on, and list the default route table ID for each."

4. List All EC2 Security Group Rules

Tool: list_all_amazon_web_services_ec_2_security_group_rules

Retrieves individual security group rules. This is the only endpoint that provides a real per-rule description and a stable securityGroupRuleId. The standard security groups endpoint only nests rules inline without addressable IDs.

"Audit the security group rules in us-west-2. Find any ingress rule where the protocol is '-1' (all protocols) or where the destination port is 22, and print out the associated security group ID and rule description."

5. List All KMS Keys

Tool: list_all_amazon_web_services_kms_keys

Provides a list of Key Management Service (KMS) key IDs and ARNs. This tool does not return full metadata. Because AWS requires individual DescribeKey calls to determine if a key is customer-managed versus AWS-managed, use this list to grab IDs before diving into specific key metadata tools.

"Retrieve the list of all KMS key ARNs in the eu-central-1 region. Extract just the IDs so we can pass them into a loop to check their rotation status."

6. List All Lambda Functions

Tool: list_all_amazon_web_services_lambda_functions

Fetches full configuration objects for Lambda functions in a specific region, including runtime, handler, VPC configuration, and environment variables. If fields like VpcConfig or DeadLetterConfig are null, it means they are explicitly not configured.

"List all Lambda functions in the ap-southeast-2 region. Identify any function running on a deprecated Node.js runtime and check if they have a VPC configuration attached."

To see the full schema, JSON mappings, and complete inventory of infrastructure, IAM, and security endpoints, visit the Amazon Web Services integration page.

Workflows in Action

When Claude has access to properly abstracted AWS tools, it can reason through complex, multi-step cloud engineering tasks without hallucinating ARN formats or getting stuck on XML pagination logic.

Workflow 1: Public Exposure Security Audit

A DevOps engineer asks Claude to investigate if a specific web application is dangerously exposed to the internet.

"Investigate the VPCs in the us-east-1 region. Find the VPC tagged 'prod-web', check its security groups for any wide-open ingress rules, and verify if VPC Block Public Access is active."

sequenceDiagram
    participant User
    participant Claude as Claude (LLM)
    participant Truto as Truto MCP Server
    participant AWS as Upstream API (AWS)

    User->>Claude: "Investigate the 'prod-web' VPC..."
    Claude->>Truto: Call list_all_amazon_web_services_ec_2_vpcs(region="us-east-1")
    Truto->>AWS: EC2 DescribeVpcs
    AWS-->>Truto: XML Response (wrapped and paginated)
    Truto-->>Claude: JSON Array of VPCs
    Claude->>Claude: Identify VPC with tag 'prod-web'
    Claude->>Truto: Call list_all_amazon_web_services_ec_2_security_groups(region="us-east-1", vpcId="vpc-123")
    Truto->>AWS: EC2 DescribeSecurityGroups
    AWS-->>Truto: XML Response
    Truto-->>Claude: JSON Array of Security Groups
    Claude->>Truto: Call list_all_amazon_web_services_ec_2_security_group_rules(region="us-east-1", groupId="sg-456")
    Truto->>AWS: EC2 DescribeSecurityGroupRules
    AWS-->>Truto: XML Response
    Truto-->>Claude: JSON Array of Rules (with descriptions)
    Claude-->>User: Outputs analysis of 0.0.0.0/0 rules and BPA status

What happens: Claude first calls the VPC list tool to find the target VPC and checks its blockPublicAccessStates. Using the VPC ID, it pulls the associated security groups. Realizing that the standard security group object doesn't provide stable rule descriptions, Claude intelligently pivots to call the specific ec_2_security_group_rules tool to read the exact rule configurations and reports back on any 0.0.0.0/0 exposure.

Workflow 2: Cross-Account S3 Encryption Check

A security auditor needs to verify encryption standards across a sprawling AWS Organization without logging into the console for each child account.

"Get all the AWS accounts in our Organization. Pick the first production account, list all its S3 buckets, and tell me if they are utilizing KMS encryption or standard SSE-S3."

1. Truto Tool Call (list_all_amazon_web_services_organizations_accounts): Claude fetches the global list of accounts and their organizational unit paths.
2. Reasoning: Claude filters the response in memory for an account with "production" in the path or name and extracts the target account ID.
3. Context Switching: Truto MCP handles the authenticated context. (If configured with cross-account assumed roles, the underlying integration executes the next call in the target account).
4. Truto Tool Call (list_all_amazon_web_services_s_3_buckets): Claude fetches the bucket list for the target account.
5. Truto Tool Call (list_all_amazon_web_services_s_3_bucket_encryption): Claude iterates through the bucket names, calling the encryption endpoint to check if SSEAlgorithm is AES256 (SSE-S3) or aws:kms (Customer Managed/AWS Managed Key).

What the user gets back: A concise, formatted report listing the buckets in the target account and identifying any buckets that are relying on default SSE-S3 instead of KMS-backed encryption.

Security and Access Control

Giving an LLM access to AWS infrastructure is highly sensitive. Truto's MCP server architecture is fully self-contained and allows strict governance over what the LLM can execute.

• Method Filtering: You can restrict an MCP server to read-only operations by passing config.methods: ["read"] during creation. This ensures Claude can call list and get operations (like fetching S3 buckets or VPCs) but cannot execute create, update, or delete actions (like terminating an EC2 instance).
• Tag Filtering: Scope the MCP server to specific functional areas using config.tags: ["storage"]. This restricts Claude from even knowing that compute or IAM tools exist in the environment.
• Authentication (require_api_token_auth): By default, possessing the MCP URL grants access to the tools. Setting this flag to true requires the MCP client to also pass a valid Truto API token in the Authorization header, enforcing identity validation at execution time.
• Expiration (expires_at): Ideal for temporary audit workflows or contractor access. Set an ISO timestamp, and Truto will automatically clean up the database records and revoke the underlying distributed key-value entries when the alarm fires, cutting off the LLM's access entirely.

Moving Past Manual Console Audits

The Amazon Web Services API is arguably the most complex B2B API in existence. Its mix of XML Query dialects, JSON RPC implementations, and highly specific pagination rules makes building custom LLM tools a miserable maintenance burden.

By leveraging Truto's managed MCP servers, you offload the normalization, parsing, and authentication mechanics. Truto translates Claude's JSON-RPC intent into accurate AWS API calls and returns clean, structured data. This allows your engineering and DevOps teams to stop writing boilerplate REST wrappers and start building agentic workflows that actually manage infrastructure.