Wayne Workman

Setting Up Continue with AWS Bedrock SSO: A Quick Guide

October 10, 2025 at 10:06 PM CDT • Wayne Workman • 6 min read

How I Found Continue During a Claude Outage

So theres I was, in the middle of working on a project, when suddenly Anthropic Claude went down. No Claude 4.5 Sonnet access, no web-based chat, nothing. I was using Claude Code and it just stopped working. This got me thinking about having a backup option for these kinds of outages because when you're in the middle of something and your AI assistant just disappears, its pretty frustrating.

I started exploring alternatives that would give me Claude Sonnet 4.5 access directly in VSCode without paying for yet another subscription. AWS Bedrock was the obvious choice since I already have access to it and it has Sonnet 4.5 available. At first, I started building my own CLI solution that used AWS Bedrock directly with local tool calls for things like web search, bash commands, reading files, writing files, listing files - all the stuff you'd expect from an AI coding assistant. I learned a lot doing this.

Then I stumbled across LangChain which is MIT licensed and provides ALL of this functionality already built. And thats when it hit me: I probably didn't need to roll my own CLI tool. With stuff like LangChain existing, there had to be alternatives to Claude Code already out there. After all, the GitHub Copilot VSCode extension was recently opensourced, so surely there are a lot of alternatives floating around. I started looking for VSCode extensions that could use Bedrock, and thats when I found Continue.

What caught my attention was that Continue is licensed under Apache 2.0 and completely free to use for both personal projects and work, theres a ton of developer activity on the public GitHub repository which is always a good sign, and there was even an AWS Blog post about using Continue with Bedrock which gave me confidence this was a real, supported integration and not just some hacky workaround.

But getting Continue to work with AWS Bedrock when you're using SSO authentication isn't exactly straightforward. Theres a few gotchas that can trip you up if you dont know whats going on, which is why I'm writing this up.

Important Note

As always, this project used all personal time, personal laptop, personal AWS accounts, personal resources, and personal money. This is a personal endeavor conducted entirely during private time using personal resources, completely independent of professional employment.

Why Bedrock with SSO?

The main reason to use AWS Bedrock is privacy. AWS Bedrock stores nothing on the AWS internal side, and they have industry certifications to prove this. When you use AWS Bedrock, companies like Anthropic and OpenAI dont get your prompt history at all. Nobody does. Only you have it, and thats only if you even bother to configure AWS Bedrock region-level logging.

This is a huge deal if you're feeding proprietary code or sensitive information into your AI assistant, which you inevitably are when you're using it for real work. With Anthropic's direct API or OpenAI, your prompts go through their systems and while they say they dont train on your data, its still passing through their infrastructure. With Bedrock, that doesn't happen.

Heres something else to consider: OpenAI recently announced that your usage history can be subpoenaed by a court. Anthropic is no different in this regard, any company with logs can be compelled to turn them over. But if you are using a service like Bedrock that stores no logs, and if your normal established protocol is to not log or to keep logs for the shortest period necessary and then delete them (perhaps for GDPR compliance), then there is nothing to subpoena because there is nothing to provide other than nothingness.

The SSO approach adds another layer of security because you're using temporary credentials instead of long-lived certificates. No $400 per month private Certificate Authority needed like you'd have to pay for with IAM Roles Anywhere. Just federated identity with automatic credential expiration, which is how modern authentication should work anyway.

Why Identity Center Instead of IAM Roles Anywhere

The AWS Blog post I mentioned earlier talks about using IAM Roles Anywhere as one option for Continue authentication. I'm not using that approach and I dont recommend it unless you have a specific reason to. Here's why.

With IAM Roles Anywhere, if you want per-user auditability in your AWS Bedrock region-level logging (which you definitely want for cost tracking and compliance), you'd need to issue a separate certificate to each developer. Then when someone leaves or you need to revoke their access, you have to take explicit action to revoke their certificate. Its just more work to manage.

With AWS Identity Center temporary credentials, each developer uses their federated identity and gets temporary credentials that automatically expire. Access management is centralized, revocation happens automatically when you disable their SSO access, and the audit trail in CloudTrail shows exactly who made which Bedrock API calls. Its just cleaner and easier to manage if your environment allows internet access.

The caveat is that Identity Center doesn't offer PrivateLink support, so if you're in a locked-down environment with no internet access, you cant use Identity Center for authentication. In that case, IAM Roles Anywhere would be your only option.

Also worth mentioning: if you follow the IAM Roles Anywhere approach from the AWS Blog post, creating a private Certificate Authority costs about $400 per month. Thats definitely not in my personal project budget, and its probably overkill for most organizations unless you've got specific compliance requirements that demand it.

What You'll Need

Before you start, make sure you have these things ready:

The first thing you need to do is make sure Bedrock model access is enabled in your AWS account. As of this writing, you still need to go into the AWS Console, navigate to Bedrock, and enable models through the "Model access" page. I just enabled all the models that were available, but I only actually use Sonnet 4.5 now.

That "Model access" page is being sunset though, could happen any day now. Eventually all models will just be available for use and governed by IAM permissions like every other AWS service already is, which is how Bedrock should have worked from the start. If you're reading this in the future and dont see a "Model access" section in Bedrock, thats why - they finally ditched it.

IAM Permissions for Bedrock Access

Your AWS administrator needs to create an IAM role or permission set with Bedrock permissions. Here's a sample policy that gives you exactly what you need and nothing more:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "BedrockModelInvoke",
      "Effect": "Allow",
      "Action": [
        "bedrock:InvokeModel",
        "bedrock:InvokeModelWithResponseStream"
      ],
      "Resource": [
        "*"
      ]
    },
    {
      "Sid": "BedrockListModels",
      "Effect": "Allow",
      "Action": [
        "bedrock:ListFoundationModels"
      ],
      "Resource": "*"
    }
  ]
}

This policy allows invoking Bedrock models (both synchronous and streaming), and listing available models. Thats it. Least privilege principle applied. Your administrator should attach this policy to whatever IAM role or Identity Center permission set you'll be using.

Note that what models can be used can be restricted via this role by specifying specific model ARNs in the Resource field instead of using the wildcard, or it can be restricted organization-wide via AWS Service Control Policies (SCPs). This gives you granular control over which models developers can access and helps manage costs.

If you're using cross-region inference endpoints (and you should be because they make everything faster), you need to either list out every region that your cross-region inference endpoint uses within the IAM role or SCP, or just wildcard the region. I use the global Sonnet 4.5 cross-region inference endpoint for the fastest response times possible, so I just use the wildcard to ensure all regions work but also to allow me to play with other models too.

Setting Up Your AWS SSO Profile

You need to create a dedicated AWS CLI profile that Continue can use. The trick is using the newer sso-session configuration format which handles token refreshing better than the old way.

Edit your ~/.aws/config file and add something like this:

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

[profile continue]
sso_session = continue
sso_account_id = 123456789012
sso_role_name = continue
region = us-east-2
output = json

You'll need to replace those placeholder values with your actual information. The sso_start_url is literally the URL you visit in your browser to sign into AWS access portal for federated access. You can find it in your AWS SSO invitation email or in the IAM Identity Center dashboard. The account ID is just your 12-digit AWS account number. The role name depends on what your AWS admin set up for Bedrock access.

For my setup, I created a dedicated AWS account just for Continue (micro account strategy) so that I could easily see how much my Continue usage with Bedrock costs me. I named the account continue and created an Identity Center permission set also called continue, just to make the naming really easy to remember and understand. If you dont know what role to use in your environment, ask your AWS administrator. They probably created something like "BedrockDeveloperAccess" or "BedrockUserRole". The role needs permissions to invoke Bedrock models and list available models, but nothing else really.

Installing and Configuring Continue

Install the Continue extension from the VSCode marketplace (or JetBrains plugin marketplace if you're using IntelliJ or PyCharm). Once its installed, you'll see a Continue icon in your sidebar.

In the Continue extension, just above the chat box, theres a dropdown for "Agents". Click "Local Agent" and then click the gear icon in that dropdown. This should open your local copy of ~/.continue/config.json in your IDE. I had already pre-populated my configuration before this and it displayed it. This is where you configure which models Continue should use and theres a lot of things you can customize here but for Bedrock SSO the important parts are setting the provider to "bedrock", specifying your model, region, and the profile name you created earlier.

Here's what my config looks like:

{
  "models": [
    {
      "title": "Claude 4.5 Sonnet",
      "provider": "bedrock",
      "model": "global.anthropic.claude-sonnet-4-5-20250929-v1:0",
      "region": "us-east-2",
      "profile": "continue"
    }
  ],
  "tabAutocompleteModel": {
    "title": "Claude 4.5 Sonnet",
    "provider": "bedrock",
    "model": "global.anthropic.claude-sonnet-4-5-20250929-v1:0",
    "region": "us-east-2",
    "profile": "continue"
  },
  "embeddingsProvider": {
    "provider": "bedrock",
    "model": "amazon.titan-embed-text-v2:0",
    "region": "us-east-2",
    "profile": "continue"
  }
}

Notice I'm using us-east-2 for the region. Bedrock availability varies by region so make sure your region actually has the models you want available. Also the model ID format matters, if you use the wrong format Continue wont be able to find the model even though it exists.

The tabAutocompleteModel is what Continue uses for inline code suggestions as you type. I'm using Sonnet for this too but you could use Haiku here to save money since autocomplete suggestions dont need the most powerful model. The embeddingsProvider is for Continue's codebase indexing feature which lets it search through your code more intelligently, I just use Amazon's Titan embedding model for this since its cheap and works fine.

Authenticating and Testing

Before Continue will work, you need to authenticate with SSO. Open a terminal and run:

aws sso login --profile continue

This opens your browser and prompts you to sign in (if you're not already signed in) and authorize the AWS CLI. Once thats done, your credentials get cached locally for 8-12 hours depending on your organization's SSO settings.

To verify everything is working, try these commands:

# Check your identity
aws sts get-caller-identity --profile continue

# List available Bedrock models
aws bedrock list-foundation-models --profile continue --region us-east-2

If both commands work without errors, you're good to go. Now open VSCode, click the Continue icon, and try asking it a question. It should work right away without any additional configuration.

Daily Usage Pattern

One thing to keep in mind is that SSO credentials expire. Remember to run aws sso login --profile continue at the start of your day and you'll be good until the evening. If your credentials expire while you're working, Continue will start throwing authentication errors and you'll need to login again and reload your IDE window.

Some people automate this with a shell script that checks if credentials are valid and refreshes them automatically but I havent bothered with that yet, the manual approach works fine for me.

Why This Matters

Getting AI coding assistants working through your company's existing AWS infrastructure is actually a pretty big deal from an organizational standpoint because it means you're using infrastructure thats already approved and compliant with your security policies, billing flows through your existing AWS accounts, and you're not introducing new vendors that need to go through procurement.

For individual developers its just convenient. But for organizations looking at how to provide AI assistance to their engineering teams without the usual procurement headaches, this kind of setup makes a lot of sense. You get the benefits of AI-assisted coding with centralized billing and oversight through your existing AWS tooling, and developers dont have to expense their own API usage or wait for new vendor approvals.

Wrapping Up

The whole setup takes maybe 10-15 minutes if you have all the prerequisites ready. The hardest part is usually just figuring out what role name to use and making sure Bedrock access is enabled in your account.

Once its working, Continue with Bedrock is pretty solid. The response times are good, the context handling is excellent (especially with Sonnet 4.5), and since you're going through Bedrock you get all the benefits of AWS's infrastructure and scaling.

If you run into issues, the most common problems are wrong region configuration, expired SSO credentials, or missing IAM permissions. Double check those first before diving into more complex troubleshooting.

← Back to Blog