AWS integration with Cursor, Claude, and Grok

Three different meanings of “AWS integration”

Before touching a config file, it is worth being precise about what you are trying to do, because these tools sit at different layers.

• Route a tool’s model traffic through your AWS account. This is Amazon Bedrock as a model provider — you pay AWS for the tokens, the requests stay inside your account’s billing and logging, and you control model access through IAM. Both Cursor and Claude Code support this, but in different ways and with different limits.
• Give the agent tools that operate on AWS. This is MCP — letting the agent read AWS documentation, call AWS APIs, or scaffold CDK. It is independent of which model you run and is the same whether your model is Bedrock-hosted or not.
• Run a specific model that happens to be on Bedrock. xAI’s Grok models are available on Bedrock, but that is a model-access question, not a Cursor or Claude Code feature.

Cursor and Amazon Bedrock

Cursor’s documented Bedrock support is bring-your-own-key routing: you point Cursor at your Bedrock account so requests use your AWS credits and stay within your infrastructure. There are two ways to configure it.

• In the IDE. Under Cursor Settings → Models, the AWS Bedrock provider takes AWS access and secret keys directly.
• Through the dashboard, as an IAM role. Teams and Enterprise can register an IAM role ARN, region, and a test model ID on cursor.com. Cursor documents this as the recommended approach — the role grants Cursor permission to invoke Bedrock on your behalf, which avoids handing long-lived keys to every developer.

This is the part worth internalising before you trust a billing dashboard: only requests made with an explicit Bedrock model ID selected go through your AWS account. Cursor’s documentation is explicit that standard model names and Auto continue to route through Cursor’s own providers. With the toggle on, Bedrock models appear in the picker under their raw IDs — for example us.anthropic.claude-sonnet-5, or the matching eu., apac., or ca. prefix if your team configured a non-US region. Pick one of those, not Auto.

Two limits to plan around. First, Cursor’s Bedrock path reliably covers Anthropic Claude models; the us.anthropic.* entries are the supported route, and non-Anthropic Bedrock models (Nova, Llama, Qwen) are a known gap rather than a supported configuration. Second, on Teams and Enterprise plans a small per-token Cursor platform fee applies to BYOK requests on top of what AWS bills you — the model tokens go to your AWS account, but the routing itself is not free on those plans.

Claude Code on Amazon Bedrock

Claude Code treats Bedrock as a first-class provider rather than an add-on, and the setup reflects that. The minimal configuration is a single flag plus whatever your AWS credentials already provide:

# Enable Bedrock, then let the AWS default credential chain do the auth
export CLAUDE_CODE_USE_BEDROCK=1
export AWS_REGION=us-east-1

# Optional: pin the models to inference-profile IDs your account has enabled
export ANTHROPIC_DEFAULT_OPUS_MODEL='us.anthropic.claude-opus-4-8'
export ANTHROPIC_DEFAULT_SONNET_MODEL='us.anthropic.claude-sonnet-4-6'

There is no separate key to paste. Claude Code signs requests with the standard AWS default credential provider chain — an SSO profile, environment variables, an instance role, whatever your shell already resolves — and caches the resolved credentials in memory until shortly before they expire. You can put the same values under an env block in ~/.claude/settings.json instead of exporting them, and /status reports the provider and the resolved region so you can confirm what is actually in effect.

Region resolution follows AWS SDK precedence: AWS_REGION, then AWS_DEFAULT_REGION, then the region on your active profile, then us-east-1 as a fallback. The model IDs use cross-region inference-profile prefixes — us., eu., apac., and so on, or us-gov. in GovCloud — so pin them to match the region you actually run in.

The IAM policy Claude Code documents for the token or role is small:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowModelAndInferenceProfileAccess",
      "Effect": "Allow",
      "Action": [
        "bedrock:InvokeModel",
        "bedrock:InvokeModelWithResponseStream",
        "bedrock:ListInferenceProfiles",
        "bedrock:GetInferenceProfile"
      ],
      "Resource": [
        "arn:aws:bedrock:*:*:inference-profile/*",
        "arn:aws:bedrock:*:*:application-inference-profile/*",
        "arn:aws:bedrock:*:*:foundation-model/*"
      ]
    }
  ]
}

GetInferenceProfile is the one people miss. Claude Code uses it to resolve an application inference profile to its backing foundation model and pick the correct request shape. Without it requests still succeed — Claude Code retries once with the alternate shape — but each new model costs an extra round-trip, which shows up as mysterious first-call latency. First-time model access in the account may also need the Bedrock model-access form (and, for some models, a marketplace subscription); that is an account setup step, separate from this per-principal policy.

If your organisation fronts Bedrock with a proxy or an LLM gateway, Claude Code has documented hooks for both: HTTPS_PROXY for a corporate proxy, and ANTHROPIC_BEDROCK_BASE_URL (plus CLAUDE_CODE_SKIP_BEDROCK_AUTH=1 when the gateway handles AWS auth) for a gateway. Those are the seams where centralised usage tracking and budgets get added without changing anything in the repo.

Grok and AWS

“Grok” is the most overloaded word in this whole area, and untangling it is most of the value here. There are three distinct things, and only one of them runs on your AWS account.

xAI’s Grok models are genuinely on Bedrock: Grok 4.3 launched there in June 2026 and Grok 4.6 in August 2026, with the usual Bedrock machinery — model invocation logging to S3 or CloudWatch, cost itemisation in Cost Explorer, and cross-region inference profiles like us.xai.grok-4.6 and global.xai.grok-4.6. Grok 4.3 is served through the bedrock-mantle endpoint; Grok 4.6 is available on both bedrock-mantle and bedrock-runtime, the latter with the Converse, Chat Completions, and Responses APIs.

AWS MCP servers — the integration that pays off fastest

Independent of which model you run, the highest-leverage AWS integration for a coding agent is MCP. AWS publishes an open-source collection, awslabs/mcp, of servers that give the agent real AWS tools — reading current AWS documentation, calling AWS APIs, pricing lookups, CDK and IaC scaffolding, and more. They install the same way in both tools: an mcpServers block keyed to a uvx command that runs the published package.

Prerequisites are the same everywhere: install uv from Astral, install a Python 3.10+ runtime with it, and have working AWS credentials. The servers read your AWS profile and region from their env block, so they inherit the same access your CLI already has.

Cursor reads .cursor/mcp.json in a project (or ~/.cursor/mcp.json globally):

{
  "mcpServers": {
    "awslabs.aws-documentation-mcp-server": {
      "command": "uvx",
      "args": ["awslabs.aws-documentation-mcp-server@latest"],
      "env": {
        "AWS_PROFILE": "your-aws-profile",
        "AWS_REGION": "us-east-1",
        "FASTMCP_LOG_LEVEL": "ERROR"
      }
    }
  }
}

Claude Code takes the same servers from the CLI, which writes the equivalent entry for you:

claude mcp add aws-docs uvx awslabs.aws-documentation-mcp-server@latest
claude mcp add aws-api uvx awslabs.aws-api-mcp-server@latest
claude mcp add aws-pricing uvx awslabs.aws-pricing-mcp-server@latest

The JSON body is close enough to copy between the two — both key everything under mcpServers. What does not travel is the file path (.cursor/mcp.json versus .mcp.json), Claude Code’s three config scopes, which Cursor does not have, and Cursor’s envFile and ${env:NAME} interpolation, which Claude Code does not document. Give AWS credentials to the server explicitly through AWS_PROFILE rather than assuming a stdio server inherits your full shell — over stdio it only inherits a limited subset. If a server does not appear, fully quit and relaunch the tool; neither hot-reloads MCP config.

Because these servers execute locally as stdio processes, the same rule from the rest of this site applies inside a Cursor Cloud Agent: the agent’s VM only has what its install script put there, so a uvx-based AWS server needs uv installed in the environment, and its AWS credentials must arrive as agent secrets rather than from your laptop’s profile. When something is red, the log panel has the real error.

Which one do you actually want?

• Keep model spend and logs inside AWS, in the editor. Cursor with the Bedrock toggle, selecting an explicit us.anthropic.* model ID. Expect Claude models, not the full Bedrock catalogue.
• Keep model spend inside AWS, from the terminal. Claude Code with CLAUDE_CODE_USE_BEDROCK=1. This is the most complete Bedrock integration of the three, with caching, gateway, and inference-profile controls.
• Let the agent operate on AWS. The awslabs/mcp servers, in either tool. Orthogonal to the model choice — do this regardless of where your model runs.
• Run Grok on your AWS bill. Call the Bedrock xai.grok-* models directly. Not via Cursor’s picker.

What to read next

A Bedrock-hosted model does not change which tool owns which config file — see Using Claude with Cursor for the split, and MCP server stuck red in Cursor when an AWS MCP server will not connect. If you are wiring these servers into a Cloud Agent, the credentials-and-install story is in Cursor Cloud Agents: repo vs environment, and the three faces of Grok are covered from the product side in Grok Bot: info, FAQ, and examples.