> For the complete documentation index, see [llms.txt](https://docs.sonarsource.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.sonarsource.com/sonarqube-server/instance-administration/ai-features/llm-providers/aws-bedrock.md).

# AWS Bedrock

Register Amazon Bedrock as an LLM provider on SonarQube Server 2026.5, using the AWS credentials available to the server.

Use the **AWS Bedrock** provider type when your models run in Amazon Bedrock and SonarQube Server already has AWS credentials available in its own environment.

AWS Bedrock offers two ways to connect:

* **AWS Bedrock Runtime**: the native API, authenticated with an AWS identity. The rest of this page, up to [#least-privilege](#least-privilege "mention"), covers this connection.
* **AWS Bedrock Mantle**: an OpenAI-compatible endpoint, authenticated with an API key or the same AWS identity. Register it with the dedicated **AWS Bedrock Mantle** provider type; see [#aws-bedrock-mantle](#aws-bedrock-mantle "mention").

To select this provider and choose a model for an AI agent, see [LLM providers](/sonarqube-server/instance-administration/ai-features/llm-providers.md#selecting-for-a-capability); for the steps that apply to every provider type, see [LLM providers](/sonarqube-server/instance-administration/ai-features/llm-providers.md).

## How this provider type authenticates <a href="#authentication" id="authentication"></a>

This type has no endpoint and no API key: SonarQube Server does not store AWS credentials in the provider configuration, and instead uses the credentials available in its own environment.

Those credentials have to be available on two sides, not one:

* SonarQube Server, which uses them to verify the region and the model when you select a model for an agent
* Each agent host, which uses them to invoke the model when the agent runs

Give both the same AWS identity, or two identities that hold the same permissions on the models you use.

Supply the credentials through any of the standard AWS mechanisms:

* An EC2 instance profile
* An ECS task role
* IAM roles for service accounts (IRSA) on EKS
* The standard AWS environment variables

## Prerequisites <a href="#prerequisites" id="prerequisites"></a>

* An AWS identity available to SonarQube Server and to your agent hosts, for example an EC2 instance profile, an ECS task role, or IAM roles for service accounts (IRSA) on EKS. Each side uses the credentials available in its own environment, so both need access to them.
* Access to the models you want to use, enabled in your AWS account for the region you're registering, and permission for that identity to invoke those models in that region.

## Fields <a href="#fields" id="fields"></a>

| Field          | Required | What to enter                                              |
| -------------- | -------- | ---------------------------------------------------------- |
| **AWS region** | Yes      | The AWS region your models run in, for example `eu-west-1` |

There's no endpoint field, because SonarQube Server derives the endpoint from the region. A region of `eu-west-1` resolves to `bedrock-runtime.eu-west-1.amazonaws.com`, the AWS Bedrock Runtime endpoint. Use that full hostname when you add Bedrock to a firewall rule, an egress proxy, or an allowlist.

## What happens when you save <a href="#saving" id="saving"></a>

Adding the provider runs no checks. SonarQube Server checks the region and the AWS permissions later, when you select a model for an agent, so complete that step to confirm your setup works.

## Entering the model identifier <a href="#model-identifier" id="model-identifier"></a>

1. Find the model in the Amazon Bedrock console, in the region you registered.
2. Copy the model identifier exactly as Bedrock names it.
3. Go to the agent's page under **Administration** > **Configuration** > **AI capabilities**, paste the identifier into the model field, and select **Save**.

## Least privilege <a href="#least-privilege" id="least-privilege"></a>

The AWS identity used by SonarQube Server and by your agent hosts needs these permissions:

* `bedrock:InvokeModel`
* `bedrock:InvokeModelWithResponseStream`

Scope the policy to the models and the region you use, rather than granting access to your whole account.

## AWS Bedrock Mantle <a href="#aws-bedrock-mantle" id="aws-bedrock-mantle"></a>

Use the **AWS Bedrock Mantle** provider type to reach Bedrock through its OpenAI-compatible endpoint instead of the native Bedrock Runtime API.

| Field          | Required | What to enter                                                                                                  |
| -------------- | -------- | -------------------------------------------------------------------------------------------------------------- |
| **AWS region** | Yes      | The AWS region your models run in, for example `eu-west-1`                                                     |
| **API key**    | No       | A Bedrock API key. Leave it empty to authenticate with the AWS identity available to SonarQube Server instead. |

SonarQube Server derives the endpoint from the region: `https://bedrock-mantle.{region}.api.aws/v1`. Unlike AWS Bedrock Runtime, SonarQube Server tests this connection when you save the provider.

If adding the provider fails, see [LLM providers](/sonarqube-server/instance-administration/ai-features/llm-providers.md#troubleshooting).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.sonarsource.com/sonarqube-server/instance-administration/ai-features/llm-providers/aws-bedrock.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.