Cursor Meets Bedrock: Route Every AI Coding Request Through Your Own AWS Account

A practitioner guide to connecting Cursor IDE to Amazon Bedrock using IAM cross account roles. Keep your AI coding inference private, observable, and cost controlled in your own AWS account.

WARISH, SEKH MOHAMMAD

120XSAP 12XAWS 15xAZURE 12xORACLE 10XSCRUM 11XOCI 12XMS 5XSECURITY 2XSOLARIS 2XDB2

Published Jun 23, 2026

Last modified Jun 25, 2026

When your engineering organization adopts AI coding assistants, one question surfaces immediately in every security review: where does our code go? For enterprises running regulated workloads or handling sensitive intellectual property, the answer matters enormously. This guide walks through connecting Cursor IDE to Amazon Bedrock using cross-account IAM roles, giving your developers access to frontier AI models while keeping every byte of data inside your own AWS account.

We built this pattern for a large enterprise with over 1,600 engineers spread across multiple business units. The lessons here come from that real-world deployment, where data residency requirements, consolidated billing, and operational visibility were non-negotiable.

The Problem with Default AI Coding Assistants

Out of the box, most AI-powered IDEs route your prompts and code context through the vendor's own infrastructure. The model provider processes your input, generates a response, and sends it back. For a solo developer working on open-source projects, this works fine. For an enterprise team writing proprietary algorithms, processing customer PII in staging environments, or building competitive differentiators in code, this data flow creates real risk.

With Cursor's default configuration, model inference runs on Cursor's infrastructure. Your code snippets, file contents, and prompts transit their backend before reaching the model. Even with strong vendor security practices, this means your data leaves your control boundary.

What Changes with Bedrock BYOK (Bring Your Own Key)

Cursor supports a "Bring Your Own Key" configuration for Amazon Bedrock. Instead of routing inference through Cursor's model accounts, the system calls Amazon Bedrock in your AWS account. This shifts the data plane:

Data Privacy: Your prompts and code context are processed within your AWS account. The data never gets exposed to third-party model providers beyond the inference call you control. You own the encryption keys, the network path, and the retention policy.

Observability: Because inference happens in your account, you get full CloudWatch metrics, Model Invocation Logging to S3, and the ability to build custom dashboards showing exactly what models your teams are calling, how many tokens they consume, and what the latency looks like.

Cost Control: Running inference in your own account means you can apply existing AWS discount programs. If your organization has a Private Pricing agreement, Migration Acceleration Program (MAP) credits, an Enterprise Discount Program (EDP) commitment, or consolidated billing across business units, those all apply to your Bedrock spend. For a 1,600-person engineering team, this can translate into significant savings versus paying per-seat model fees.

Architecture: How the Pieces Fit Together

Here is how the request flow works end to end:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
┌─────────────────────────────────────────────────────────────────────────┐
│                         DEVELOPER WORKSTATION                            │
│                                                                         │
│   ┌───────────────┐                                                     │
│   │  Cursor IDE   │──── Code context + prompt ────┐                     │
│   └───────────────┘                               │                     │
└───────────────────────────────────────────────────│─────────────────────┘
                                                    │
                                                    ▼
┌─────────────────────────────────────────────────────────────────────────┐
│                        CURSOR BACKEND (BYOK Mode)                        │
│                                                                         │
│   • Receives prompt from IDE                                            │
│   • Applies prompt processing and formatting                            │
│   • Assumes cross-account IAM role via STS                              │
│   • Calls Amazon Bedrock InvokeModel in YOUR account                    │
│                                                                         │
│   Cursor AWS Account: 289469326074                                      │
│   Role Used: roleAssumer                                                │
└─────────────────────────────────────────────────────────────────────────┘
                                                    │
                                        STS AssumeRole
                                     (with External ID)
                                                    │
                                                    ▼
┌─────────────────────────────────────────────────────────────────────────┐
│                     YOUR AWS ACCOUNT (Bedrock Account)                    │
│                                                                         │
│   ┌──────────────────────┐      ┌──────────────────────────────┐       │
│   │   IAM Role           │      │   Amazon Bedrock              │       │
│   │   (Cross-Account)    │─────▶│   InvokeModel /               │       │
│   │                      │      │   InvokeModelWithResponseStream│       │
│   │   Trust: Cursor Acct │      │                                │       │
│   │   Condition: ExtID   │      │   Models: Claude, Nova, etc.   │       │
│   └──────────────────────┘      └──────────────────────────────────┘    │
│                                                                         │
│   ┌──────────────────────┐      ┌──────────────────────────────┐       │
│   │  CloudWatch Logs     │      │  S3 Bucket                    │       │
│   │  (Invocation Logs)   │      │  (Full request/response logs) │       │
│   └──────────────────────┘      └──────────────────────────────────┘    │
│                                                                         │
└─────────────────────────────────────────────────────────────────────────┘

An important architectural note: Unlike client-side tools such as Claude Code or OpenAI Codex (which call APIs directly from the developer's machine), Cursor always routes requests through its backend infrastructure. This is where prompt processing and context assembly happen. The BYOK configuration changes where the inference call lands, but the request still transits Cursor's servers. Understanding this is critical for your security review documentation.

Step-by-Step Setup

1. Create a Dedicated AWS Account (Recommended)

We strongly recommend creating a separate AWS account within your Organization specifically for AI coding tool inference. Here is why:

Billing clarity: All Bedrock charges for Cursor appear in one account, making cost attribution straightforward.
Quota isolation: Bedrock service quotas (tokens per minute, requests per minute) are per-account. A dedicated account means your Cursor usage cannot compete with production AI workloads for throughput.
Blast radius containment: The IAM role you create has invoke permissions. Isolating it in a separate account ensures that even a misconfiguration cannot affect production resources.

At Publicis Epsilon, this isolation pattern proved essential. With multiple business units sharing AWS infrastructure, keeping the Cursor inference path in its own account eliminated cross-team quota contention and simplified chargeback.

2. Obtain the External ID from Cursor

Log into your Cursor Team Settings dashboard. Navigate to the BYOK or Bedrock configuration section.

Common mistake: Teams often grab the "Team ID" and use it as the External ID. These are different values. The External ID is a distinct string that Cursor generates specifically for the IAM trust relationship. Using the wrong value means STS AssumeRole calls will fail silently, and your developers will see generic model errors in the IDE.

Copy the External ID and keep it ready for the next step.

3. Create the IAM Policy

Create a policy that grants the minimum permissions Cursor needs:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "BedrockInvoke",
      "Effect": "Allow",
      "Action": [
        "bedrock:InvokeModel",
        "bedrock:InvokeModelWithResponseStream"
      ],
      "Resource": [
        "arn:aws:bedrock:*:*:foundation-model/*",
        "arn:aws:bedrock:*:*:inference-profile/*"
      ]
    },
    {
      "Sid": "MarketplaceModels",
      "Effect": "Allow",
      "Action": [
        "aws-marketplace:ViewSubscriptions",
        "aws-marketplace:Subscribe"
      ],
      "Resource": "*"
    }
  ]
}

The foundation-model/* resource covers standard Bedrock models. The inference-profile/* resource is necessary for cross-region inference profiles, which we discuss later. The marketplace permissions enable access to models distributed through AWS Marketplace (such as certain Anthropic or Meta model variants).

Tightening permissions: If you want to restrict which models developers can call, narrow the Resource ARNs. For example, to allow only Claude models: arn:aws:bedrock:*:*:foundation-model/anthropic.*

4. Create the IAM Role with Trust Policy

Create an IAM role and attach the policy from Step 3. The trust policy is where the security magic happens:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::289469326074:role/roleAssumer"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "YOUR_EXTERNAL_ID_FROM_CURSOR"
        }
      }
    }
  ]
}

Key elements:

Principal: This is Cursor's AWS account (289469326074) and the specific role they use to assume your role. Only this identity can assume your role.
ExternalId condition: This prevents the confused deputy problem. Even if another Cursor customer somehow knew your role ARN, they could not assume it without your unique External ID. AWS documents this pattern extensively as a security best practice for cross-account access.
No wildcard principals: The trust is scoped to one specific role in one specific account.

5. Configure in Cursor Team Settings

Back in the Cursor dashboard:

Paste your Role ARN (e.g., arn:aws:iam::111122223333:role/CursorBedrockRole)
Select your primary AWS region (e.g., us-east-1)
Test the connection using a model ID like us.anthropic.claude-sonnet-4-6

The us. prefix on the model ID enables cross-region inference, which routes requests across US regions for higher throughput. More on this below.

6. Enforce Privacy Mode

In Cursor Team Settings, enable Privacy Mode at the team level. This ensures that code snippets and prompts are not stored or used for model training. Combined with the Bedrock routing, this creates a defense-in-depth approach: even the transit path through Cursor's backend operates under privacy constraints.

7. Developer-Side Configuration

Each developer needs to enable Bedrock in their Cursor IDE settings:

Open Cursor Settings (Cmd+Shift+J on macOS, Ctrl+Shift+J on Windows/Linux)
Navigate to the Models section
Enable the Bedrock provider
The team configuration propagates automatically; no individual credentials needed

Developers do not need AWS credentials on their machines. The authentication happens server-side through the cross-account role assumption.

Verifying the Setup Works

After configuration, open the Cursor Usage Dashboard in your team settings. Look for entries tagged with "bedrock" as the provider. If you see model calls routing through Bedrock, the setup is working.

On the AWS side, check CloudWatch metrics in your Bedrock account. You should see InvocationCount and TokenCount metrics populating for the models your team is using.

If calls are not appearing:

Double-check the External ID (not the Team ID)
Verify the role ARN has no typos
Confirm the IAM policy is attached to the role
Check that the model you are testing with is available in your selected region
Review CloudTrail in the Bedrock account for failed AssumeRole attempts

Building Observability

Once traffic is flowing, set up proper observability:

Model Invocation Logging

Enable Model Invocation Logging in the Bedrock console. Configure it to write to both CloudWatch Logs and an S3 bucket:

CloudWatch Logs: Useful for real-time alerting and short-term analysis. Set a retention period (14 or 30 days) to control costs.
S3 Bucket: Long-term storage for compliance and audit. Enable lifecycle rules to transition logs to Glacier after 90 days.

With full logging enabled, you can see the complete request and response payloads. This is powerful for security auditing but also carries its own data sensitivity considerations. Ensure the S3 bucket has appropriate encryption and access controls.

CloudWatch Alarms

Set up alarms on these key metrics:

Token consumption rate: Alert when daily token usage exceeds your budget threshold. A team of 1,600 engineers can burn through tokens quickly during active development sprints.
Throttling events: If you see ThrottlingException counts rising, you are hitting service quotas and need to request increases.
Latency percentiles: Track p50 and p99 latency. Degraded latency means poor developer experience, which drives developers to disable the tool.

Proactive Quota Management

Bedrock has per-region, per-model quotas for tokens per minute and requests per minute. For a large team:

Check your current quotas in the Service Quotas console
Calculate expected usage: (number of active developers) × (average requests per hour) × (average tokens per request)
Request increases before rollout, not after developers start hitting limits

At our 1,600-engineer deployment, we requested quota increases two weeks before the general rollout. Quota increase requests can take days to process, and you do not want throttling errors to be the first experience developers have with the tool.

Cost Attribution and Chargeback

Tagging Strategy

Tag the IAM role and any associated resources with metadata that supports your billing workflow:

1
2
3
4
5
{
  "bedrock-origin": "cursor",
  "cost-center": "engineering-platform",
  "team": "developer-experience"
}

In the AWS Billing console, activate these as cost allocation tags. Once activated, they appear in Cost Explorer and your CUR (Cost and Usage Report), enabling precise cost attribution.

MAP Credits

If your organization participates in the AWS Migration Acceleration Program, Bedrock usage can qualify for MAP credits with proper tagging. Apply the MAP tags to your Bedrock resources following the MAP tagging guidelines. This can offset a meaningful portion of your inference costs during the MAP engagement period.

Consolidated Billing Benefits

With the Bedrock account in your AWS Organization, all inference costs roll up into your consolidated bill. This means:

EDP commitments apply
Volume discounts (if applicable) include this spend
Finance teams see one line item per account, making budget tracking simple

Enterprise Enforcement: Locking Down Model Access

For teams that need strict governance, Cursor's Team Settings include model controls. You can:

Restrict available models: Only expose Bedrock-routed models to developers. Remove direct Cursor-hosted model options entirely.
Pin specific model versions: Ensure all developers use the same model version for consistency in code suggestions.
Disable model switching: Prevent developers from overriding team settings at the IDE level.

This enforcement means that even if a developer tries to use a non-Bedrock model, the request simply will not go through. All inference is guaranteed to route through your AWS account.

Cross-Region Inference for Higher Throughput

When you prefix a model ID with a region code like us., Cursor uses Bedrock's cross-region inference feature. Instead of pinning all requests to a single region (e.g., us-east-1), Bedrock can distribute requests across multiple US regions (us-east-1, us-west-2, etc.) based on capacity.

Why this matters for large teams:

Throughput ceiling: A single region has finite capacity. Cross-region inference effectively multiplies your available throughput.
Resilience: If one region experiences degradation, requests automatically route to healthy regions.
No code changes: Developers use the same model ID; the routing is transparent.

To enable this, simply use model IDs with the regional prefix: us.anthropic.claude-sonnet-4-6 instead of anthropic.claude-sonnet-4-6. Ensure your IAM policy includes inference-profile/* resources, as cross-region inference uses inference profiles under the hood.

Troubleshooting Common Issues

"Model not found" errors in Cursor

Verify the model is enabled in your Bedrock account (some models require opt-in)
Check that the model ID matches exactly, including the regional prefix if using cross-region inference
Confirm the IAM policy resource ARN covers the model type (foundation-model vs. inference-profile)

Intermittent timeouts

Check CloudWatch for throttling metrics
Review your service quotas; you may need increases
If using a single region, switch to cross-region inference for better throughput distribution

"Access Denied" in CloudTrail

The External ID in the trust policy must match exactly what Cursor provides
Ensure the Principal ARN references account 289469326074 and role "roleAssumer"
Verify no SCP (Service Control Policy) in your Organization is blocking the AssumeRole

Developers not seeing Bedrock models in their IDE

They need to enable the Bedrock provider in their local Cursor settings
Team settings must be published and propagated
Try restarting Cursor after enabling the setting

High costs appearing unexpectedly

Check which models are being used. Larger models (e.g., Claude Opus) cost significantly more per token than smaller variants (e.g., Claude Haiku).
Review whether developers are sending excessively large context windows
Consider restricting available models to cost-effective options for routine coding tasks

Lessons from a 1,600-Engineer Deployment

Rolling this out at scale taught us several things:

Start with a pilot group: We began with 50 developers from one team before expanding. This let us calibrate quotas and identify configuration issues without broad impact.
Communicate the "why" to developers: Engineers are more likely to adopt a tool routed through extra infrastructure if they understand that it protects the company (and their own work) while giving them access to the same quality models.
Monitor cost per developer, not just total cost: Some developers generate 10x the tokens of others based on their workflow. Understanding this distribution helps with budgeting and identifies opportunities for efficiency guidance.
Keep the feedback loop tight: When developers hit throttling or latency issues, they stop using the tool within days. Proactive monitoring and fast quota adjustments are essential to sustained adoption.
Document the security posture: Having a clear architecture diagram and data flow documentation ready for security reviews accelerated approvals significantly. The confused deputy mitigation and data residency story resonates with security teams.

Summary

Connecting Cursor IDE to Amazon Bedrock through cross-account IAM roles gives enterprise teams the best of both worlds: a polished AI coding assistant experience for developers, with full data sovereignty, cost control, and observability for the platform team. The setup requires careful attention to IAM configuration, quota planning, and monitoring, but the result is an AI coding infrastructure that scales to thousands of engineers while meeting enterprise security and compliance requirements.

References

AWS Cross-Region Inference Documentation
https://docs.aws.amazon.com/bedrock/latest/userguide/cross-region-inference.html
AWS IAM: The Confused Deputy Problem
https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html
Amazon Bedrock Model Invocation Logging
https://docs.aws.amazon.com/bedrock/latest/userguide/model-invocation-logging.html
AWS MAP Tagging for Bedrock
https://docs.aws.amazon.com/MAP/latest/userguide/bedrock-map-tagging.html
Cursor Documentation: AWS Bedrock Configuration
https://cursor.com/docs/customizing/aws-bedrock
Amazon Bedrock Pricing
https://aws.amazon.com/bedrock/pricing/

About the Authors

Sekh Mohammad Warish is a Senior Technical Account Manager at AWS, supporting customers across SAP, GenAI, and cloud modernization. With 120+ IT certifications including 12 AWS certifications, he helps customers adopt emerging technologies and build production-ready solutions on AWS.

Nitish Tipparaju is an Enterprise Support Manager at AWS, leading technical account teams that drive GenAI adoption and operational excellence for customers. He co-leads GenAI upskilling programs and brings hands-on experience helping organizations build their first AI agents on AWS.

# agentic-ide # amazon-bedrock # generative-ai # developer-tools # ai-for-developers

Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.

Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article

Builder Center

Cursor Meets Bedrock: Route Every AI Coding Request Through Your Own AWS Account

WARISH, SEKH MOHAMMAD

The Problem with Default AI Coding Assistants

What Changes with Bedrock BYOK (Bring Your Own Key)

Architecture: How the Pieces Fit Together

Step-by-Step Setup

1. Create a Dedicated AWS Account (Recommended)

2. Obtain the External ID from Cursor

3. Create the IAM Policy

4. Create the IAM Role with Trust Policy

5. Configure in Cursor Team Settings

6. Enforce Privacy Mode

7. Developer-Side Configuration

Verifying the Setup Works

Building Observability

Model Invocation Logging

CloudWatch Alarms

Proactive Quota Management

Cost Attribution and Chargeback

Tagging Strategy

MAP Credits

Consolidated Billing Benefits

Enterprise Enforcement: Locking Down Model Access

Cross-Region Inference for Higher Throughput

Troubleshooting Common Issues

Lessons from a 1,600-Engineer Deployment

Summary

References

About the Authors