How to Set Up an MCP Server for AWS

Direct answer: The simplest way to set up an MCP server for AWS is to add AWS’s managed MCP Server HTTPS endpoint to an MCP-compatible agent, choose an authentication method, and test a low-impact operation with the same IAM identity you already use for AWS. Documentation search can work without authentication. AWS API calls, Python execution in a sandbox, and curated skills use your authenticated AWS identity and its existing permissions.

AWS also documents a self-hosted architecture. That is a separate infrastructure project for teams that need to operate their own MCP implementation, control network placement, or connect private tools and data.

What you are setting up

The managed AWS MCP Server is a service in the AWS Agent Toolkit. It acts as a managed, stateless proxy between an MCP client and AWS services. Your agent connects to one MCP endpoint; AWS authenticates requests and evaluates them against the caller’s IAM permissions.

Need	Best fit	Authentication
Search AWS documentation and retrieve service information	AWS managed MCP Server	Documentation search may be unauthenticated
Read or change AWS resources	AWS managed MCP Server	AWS identity credentials, OAuth, and IAM authorization
Expose your own tools, private data, or custom business logic	Self-hosted MCP server on AWS	You operate the OAuth and application authorization model

Prerequisites

An AWS account.
An MCP-compatible agent or client.
For AWS Sign-In OAuth, an agent that supports OAuth 2.1.
An IAM identity with only the permissions the agent needs.
A decision about whether you need documentation-only access or authenticated AWS actions.

Set up the managed AWS MCP Server

1. Select the regional endpoint

The AWS General Reference currently lists these HTTPS endpoints:

https://aws-mcp.us-east-1.api.aws/mcp
https://aws-mcp.eu-central-1.api.aws/mcp

Endpoint availability and regional support can change, so verify the current endpoint list in AWS documentation when you publish or deploy. Use the region closest to your agent’s normal operating location when that is practical.

2. Add the endpoint to your MCP client

MCP clients do not all use the same configuration file or field names. Open your agent’s MCP settings, add a remote HTTPS server, and enter the AWS MCP endpoint for your selected region. Follow that client’s documented procedure for remote MCP servers; do not copy a desktop-client JSON example into another product unless its documentation specifies the same schema.

At minimum, the entry needs:

The remote server URL.
The authentication method supported by your client.
Any region or account context required by that client.

3. Choose authentication

Documentation search without authentication

AWS says documentation search can be used without authentication. This is useful for questions such as “Which IAM action controls this operation?” or “What parameters does this AWS service accept?” It does not authorize the agent to inspect or change your resources.

Interactive AWS Sign-In OAuth

For a workstation user, choose the client’s AWS Sign-In OAuth flow. The agent opens an authorization experience, and you approve access using your AWS identity. AWS documents these required permissions for interactive authorization:

signin:AuthorizeOAuth2Access
signin:CreateOAuth2Token

OAuth is an authentication and delegation step. It does not add permissions to the AWS principal. Every downstream API call is still limited by that identity’s IAM policies.

Non-interactive client credentials

Applications that already have AWS credentials can use the non-interactive client-credentials flow. AWS documents signin:CreateOAuth2Token as the required permission. The application signs the token request with existing AWS SigV4 credentials through CreateOAuth2TokenWithIAM, then uses the resulting authorization with the MCP server.

This flow is appropriate for automation, but store credentials in a secrets manager or workload identity system. Do not put long-lived access keys in an agent configuration file committed to source control.

4. Verify the AWS identity before using the agent

Run this command in the same environment that will provide credentials to the agent:

aws sts get-caller-identity

Confirm the returned account, ARN, and principal are the ones you intend to authorize. If the command fails, fix the AWS credential chain before troubleshooting MCP.

5. Test a low-impact operation

Ask the agent to perform a read-only task that the principal is explicitly allowed to perform. Examples include listing a small set of resources or describing a single configuration. Avoid testing with deletion, replacement, policy edits, or broad inventory requests.

Use a prompt that states the boundary clearly:

Use the AWS MCP Server to describe this one resource only. Do not create, modify, or delete anything. Report the AWS account and region used before making the request.

IAM and request controls

The managed server authenticates requests with SigV4 and forwards them using the customer’s AWS identity. IAM remains the authority for AWS API access. Use a dedicated role or permission set when possible, and grant only the actions and resources required by the agent’s tasks.

AWS documents two condition context keys that can distinguish requests mediated by the managed MCP service:

aws:ViaAWSMCPService
aws:CalledViaAWSMCP

These keys can help you write policies that treat MCP-mediated calls differently from direct calls. Review the exact condition-key semantics in the current AWS IAM documentation before applying them to production policies.

Temporary STS credentials, IAM roles, federated identities, and assumed roles are supported. The preview-era actions aws-mcp:InvokeMcp, aws-mcp:CallReadOnlyTool, and aws-mcp:CallReadWriteTool are no longer required and have no effect. Remove policies that rely on those actions and use the documented condition keys where appropriate.

Managed server versus a self-hosted MCP server

Choose the managed service when you want AWS documentation and AWS API tools without operating another application. Choose self-hosting when you need your own MCP implementation, private integrations, custom authorization, or control over network placement and deployment.

Area	Managed AWS MCP Server	Self-hosted server
Operations	AWS operates the MCP service	You patch, deploy, scale, and monitor the server
Identity	AWS Sign-In OAuth or existing AWS credentials	You design the OAuth and application authorization flow
Network placement	Use AWS’s regional managed endpoint	Choose your VPC, ingress, subnets, and egress controls
Tools	AWS-provided capabilities	Your own tools, data sources, and business logic
Audit and metrics	CloudWatch metrics and CloudTrail audit logging	You configure application logs, metrics, traces, and audit retention

Self-host an MCP server on AWS

AWS’s sample deployment pattern uses Cognito for OAuth, CloudFront and WAF at the edge, an Application Load Balancer, private VPC subnets, ECS or Fargate containers published through ECR, CloudWatch logs, Secrets Manager, and DynamoDB for short-lived OAuth and session data.

Treat those components as an architecture example, not a mandatory checklist. A smaller internal service may need fewer components; a public multi-tenant service may need stronger isolation and additional controls.

Deployment sequence

Package the MCP server as a container and publish the image to ECR.
Run the service on ECS or Fargate in private subnets across availability zones.
Place an Application Load Balancer in front of the service.
Use CloudFront and WAF when you need an internet-facing edge with filtering and rate controls.
Configure Cognito or another supported OAuth provider for client authorization.
Store secrets in Secrets Manager, never in the image or task definition as plain text.
Store short-lived authorization and session records in DynamoDB with explicit expiration.
Send application and access logs to CloudWatch and define health checks for the load balancer.
Test token expiry, revoked sessions, failed upstream calls, and task replacement before production use.

The AWS example describes 24-hour session records, 10-minute authorization-code mappings, and 30-day refresh-token records. Those values belong to that sample architecture; choose retention periods based on your security and product requirements.

Security checklist

Use a separate IAM role or permission set for agent activity.
Start with read-only permissions and add write actions one at a time.
Restrict resources with ARN and condition constraints where supported.
Review which tools the agent can invoke, especially tools that mutate infrastructure.
Use short-lived credentials and rotate or revoke long-lived secrets.
Keep self-hosted services private where possible and protect public ingress with authentication and WAF rules.
Enable CloudTrail for AWS API auditing and CloudWatch for service logs and metrics.
Document what data the agent may send to tools and what tool responses may contain.

Troubleshooting

Symptom	Likely cause	Fix
The client cannot connect	Wrong endpoint, unsupported remote transport, or network egress blocked	Copy the current regional HTTPS endpoint, confirm the client supports remote MCP, and allow outbound HTTPS.
Documentation works but AWS actions fail	The request needs authenticated credentials	Complete AWS Sign-In OAuth or configure the client-credentials flow, then retry with an IAM principal that has the required action.
`aws sts get-caller-identity` fails	Missing, expired, or misconfigured AWS credentials	Fix the local credential chain, profile, role assumption, or federated login first.
AccessDenied from an AWS service	The principal’s IAM policy, resource policy, SCP, permission boundary, or region restriction denies the action	Use CloudTrail and IAM policy simulation to identify the denying policy. OAuth cannot enlarge these permissions.
OAuth redirect or token exchange fails	The client does not support OAuth 2.1 correctly, or the requested Sign-In permissions are missing	Update the client, use its AWS-specific OAuth procedure, and grant only the documented Sign-In permissions.
A policy references `aws-mcp:InvokeMcp`	It uses preview-era actions that no longer apply	Remove those actions and evaluate the documented MCP condition keys instead.
Self-hosted sessions disappear unexpectedly	Session TTL, clock skew, task replacement, or incomplete shared storage	Use centralized session storage, synchronize clocks, inspect TTL settings, and test task replacement.
The agent performs an unsafe change	Write permissions or destructive tools were granted too broadly	Reduce IAM permissions, remove destructive tools, and require explicit confirmation in the agent workflow.

Performance, reliability, and cost considerations

Managed service

Choose a supported region near the agent and the AWS services it uses.
Keep prompts and tool scopes narrow so the agent makes fewer discovery calls.
Use read-only tests before introducing write operations.
Record request IDs, account, region, and tool name in your own operational logs where permitted.
Use CloudWatch metrics and CloudTrail to investigate latency, throttling, and failed authorization.

AWS’s managed MCP Server does not remove downstream AWS service limits. API throttling, retries, eventual consistency, and regional service failures still apply to the AWS service being called.

Self-hosted service

Run more than one task across availability zones when the workflow requires high availability.
Configure load-balancer health checks that verify the process is able to serve MCP traffic.
Keep session state outside individual containers so tasks can be replaced safely.
Set timeouts and bounded retries for upstream AWS calls.
Budget for compute, load balancing, WAF, logging, storage, data transfer, and operational work. The AWS reference architecture does not establish a universal price.

Or skip the browser setup

If your agent also needs screenshots of AWS consoles, documentation pages, or other websites, ScreenshotNeo provides a separate screenshot API and MCP server. It can remove cookie banners, newsletter popups, and chat widgets before capture; bot checks, blank pages, failed loads, timeouts, and cache hits are not billed. Its MCP server includes take_screenshot, get_page_info, and capture_pdf for Claude, Cursor, and other MCP clients.

One-call example (see the ScreenshotNeo API documentation):

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

ScreenshotNeo includes 1,000 screenshots per month free with no card; paid plans start at $5 for 3,000 shots. Create a free ScreenshotNeo account.

FAQ

Do I need to deploy an MCP server myself?

No. AWS provides a managed MCP Server endpoint. Self-hosting is for custom tools, private data, or control over the server architecture.

Can the server change AWS resources?

It can make authenticated AWS API calls that the caller’s IAM policies allow. Grant write permissions only when the workflow requires them.

Does OAuth give the agent administrator access?

No. OAuth does not enlarge the AWS principal’s permissions. IAM policies and other AWS policy controls still decide whether each API call succeeds.

Which AWS regions can I use?

The current reference lists managed endpoints in us-east-1 and eu-central-1. Recheck AWS documentation for the latest availability.

Can I use temporary credentials?

Yes. AWS documents support for STS temporary credentials, IAM roles, federated identities, and assumed roles.

What should I log?

For managed access, use CloudTrail for AWS API auditing and CloudWatch metrics. For a self-hosted server, also capture application events, authentication outcomes, tool names, latency, and errors without logging secrets.