Using Claude Code, AWS MCP Server and AWS Organizations

Using Claude Code with a new AWS MCP server has changed my life.

Until the combo of the two came along, writing good CloudFormation templates meant you wrote templates by hand, relying on patterns from deep inside the repos you built for previous clients and lots — lots — of Google searches and hours and hours in the AWS doc.

It’s interesting and fulfilling work — but when you are working for clients who have hard deadlines and you’re on the clock, it’s pressure-filled.

But now that that AWS has made an MCP server generally available, you can use Claude Code with SSO in an AWS Organizations environment to achieve astonishing design and delivery productivity. The thing that I think is so amazingly useful: Claude Code can use the MCP server to deploy across member accounts in an AWS Organizations.

I asked Claude to draft a blog post specifically on the intracies of using the MCP server in a multi-account environment. An edited version of it is below.

What is the AWS MCP server?

The AWS MCP server is a managed, remote Model Context Protocol server that AWS runs. Instead of bolting dozens of bespoke tools onto an agent, it exposes a small, fixed surface:

• call_aws — invoke essentially any of the 15,000+ AWS API operations using your existing IAM credentials. New APIs land within days of launch, so the agent is never limited to what was current at model-training time.
• search_documentation / read_documentation — pull current AWS documentation and guidance at query time, so answers reflect today’s services rather than stale training data.
• run_script — write and run Python server-side in a sandbox that inherits your IAM permissions but has no network or local filesystem access. This lets the agent chain multi-step API calls (paginate, filter, correlate) without burning conversation context.
• Skills — curated, service-team-authored guidance for common tasks, which keeps the tool list predictable and cuts down on hallucinated API shapes.

There are two important security features of the AWS MCP server:

1. Human and agent permissions are separable. Because every call is ordinary IAM, you can hand the agent a read-only role while your humans keep mutating rights — or, as below, scope it to exactly the permission set you trust.
2. Everything is observable. MCP calls emit CloudWatch metrics under the AWS-MCP namespace, and every API call lands in CloudTrail, so agent activity is auditable and separable from human activity.

A great fit with Claude Code

Claude Code consumes MCP servers natively. When you register the AWS MCP server, its tools appear to Claude namespaced as mcp__<account-name>__call_aws, mcp__<account-name>__search_documentation, and so on. The proxy runs locally under your shell’s AWS credentials, so Claude never sees a key — it only sees a tool it can call, and the proxy attaches your identity on the way out.

That namespacing is the hinge of the whole multi-account design. The server name becomes the account selector. Register one AWS MCP server per account — each pinned to a different AWS profile — and Claude targets an account simply by choosing the matching tool prefix. No account IDs pasted into prompts, no profile juggling mid-task. [This is the heart of the thing that makes the MCP server so flexible in AWS Organizations environments — human ed.]

The pieces you need:

• An AWS Organization with separate member accounts for each environment (for example: management, a shared-services/infra account, staging, and production).
• IAM Identity Center as the access plane, with sign-in federated from an external IdP (Entra ID, Okta, Ping, etc.). Administrators authenticate to the IdP; Identity Center brokers short-lived credentials for a permission set in each account.
• A permission set that grants the administrator the AWS-managed AdministratorAccess policy (optionally fenced by a permissions boundary) in each member account they are entitled to.

In ~/.aws/config, that translates into one sso-session shared by every profile, and one profile per account that differs only by sso_account_id and the permission set (sso_role_name). A single aws sso login against that session hydrates short-lived credentials for all of them. [More magic — human ed.]

Using this technique, you register one AWS MCP server per profile. The result: an authenticated administrator can say to Claude Code —

“Deploy vpc-tgw.yaml into staging and production, then show me the stack status in each.”

— and Claude will call mcp__aws-mcp-stage__call_aws to create or update the stack in the staging account, then mcp__aws-mcp-prod__call_aws to do the same in production, using the same federated identity chain for each. The credentials are short-lived, scoped by the permission set, and every CloudFormation call is written to CloudTrail under the human administrator’s federated principal. If you’d rather review first, Claude Code’s per-call approval gating means each mutating call_aws can be inspected before it runs.

How to configure it

1. Install the prerequisites. The proxy is launched with uvx, so install the uv package manager (uvx ships with it). No global Python setup is required.

2. Define your SSO profiles in ~/.aws/config — one shared session, one profile per account. An example is below.)

3. Register one AWS MCP server per account profile. Either drop the JSON below into your MCP configuration, or add them from the CLI, one per account. Here’s an example you might use for a staging account:

claude mcp add-json aws-mcp-stage --scope user '{"command":"uvx","args":["mcp-proxy-for-aws@latest","https://aws-mcp.us-east-1.api.aws/mcp","--metadata","AWS_REGION=us-east-1"],"env":{"AWS_PROFILE":"org-admin-stage"}}'

Repeat for additional accounts, for example org-admin-prod, org-admin-infra, and org-admin-mgmt, changing the server name and AWS_PROFILE each time. Be sure to strictly observe the naming convention you choose for your accounts.

4. Authenticate once for the whole session: aws sso login --sso-session org-sso. This is the only interactive step — it sends the administrator through the external IdP and caches short-lived credentials for every profile.

5. Verify inside Claude Code with /mcp. Each aws-mcp-<account> server should report connected. From there, Claude can search live AWS docs, validate templates, and deploy — per account — by picking the right tool prefix.

It’s really secure

The agent inherits exactly the permission set IAM Identity Center already grants the administrator — presumably AdministratorAccess, fenced by whatever permissions boundary you attach — and nothing more. Credentials are short-lived and federated through your external IdP, so there is no static key for Claude (or anyone) to leak. Anything that changes AWS can be gated for human approval in Claude Code, read-only exploration can be left to flow freely, and the AWS-MCP CloudWatch namespace plus CloudTrail give you a clean, separable audit trail of everything the agent did, attributed to the human who authorized it.

---

Example configuration file for multi-account AWS MCP server setup

Replace the four AWS_PROFILE values and (optionally) the server names to match your own account layout.

mcp.json (Claude Code MCP server config — the primary artifact):

{
  "mcpServers": {
    "aws-mcp-mgmt": {
      "command": "uvx",
      "args": [
        "mcp-proxy-for-aws@latest",
        "https://aws-mcp.us-east-1.api.aws/mcp",
        "--metadata",
        "AWS_REGION=us-east-1"
      ],
      "env": {
        "AWS_PROFILE": "org-admin-mgmt"
      }
    },
    "aws-mcp-infra": {
      "command": "uvx",
      "args": [
        "mcp-proxy-for-aws@latest",
        "https://aws-mcp.us-east-1.api.aws/mcp",
        "--metadata",
        "AWS_REGION=us-east-1"
      ],
      "env": {
        "AWS_PROFILE": "org-admin-infra"
      }
    },
    "aws-mcp-stage": {
      "command": "uvx",
      "args": [
        "mcp-proxy-for-aws@latest",
        "https://aws-mcp.us-east-1.api.aws/mcp",
        "--metadata",
        "AWS_REGION=us-east-1"
      ],
      "env": {
        "AWS_PROFILE": "org-admin-stage"
      }
    },
    "aws-mcp-prod": {
      "command": "uvx",
      "args": [
        "mcp-proxy-for-aws@latest",
        "https://aws-mcp.us-east-1.api.aws/mcp",
        "--metadata",
        "AWS_REGION=us-east-1"
      ],
      "env": {
        "AWS_PROFILE": "org-admin-prod"
      }
    }
  }
}

Supporting ~/.aws/config. Note that sso-start-url is the name of your IAM Identity Center access portal URL.

[sso-session org-sso]
sso_start_url = https://my-org.awsapps.com/start
sso_region    = us-east-1
sso_registration_scopes = sso:account:access

[profile org-admin-mgmt]
sso_session    = org-sso
sso_account_id = 111111111111
sso_role_name  = AdministratorAccess
region         = us-east-1

[profile org-admin-infra]
sso_session    = org-sso
sso_account_id = 222222222222
sso_role_name  = AdministratorAccess
region         = us-east-1

[profile org-admin-stage]
sso_session    = org-sso
sso_account_id = 333333333333
sso_role_name  = AdministratorAccess
region         = us-east-1

[profile org-admin-prod]
sso_session    = org-sso
sso_account_id = 444444444444
sso_role_name  = AdministratorAccess
region         = us-east-1

---