> ## Documentation Index
> Fetch the complete documentation index at: https://www.qovery.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# AWS Bedrock Access

> Provision scoped AWS Bedrock access — an IAM policy limited to the models you name, plus an optional IAM user with keys — so an application on any cloud (AWS, Azure, Scaleway or GCP) can call Bedrock models

Qovery creates it in your account with a third-party provider, using credentials you enter in the form, as a [Blueprint](https://www.qovery.com/docs/configuration/blueprints.md) service in one of your environments.

| | |
| - | - |
| Catalog name | `aws-bedrock-access` |
| Category | AI |
| Provider | EXTERNAL |
| Engine | terraform |
| Major versions (latest release) | `default` (1.0.3) |
| Source | [EXTERNAL/bedrock/default](https://github.com/Qovery/service-catalog/tree/EXTERNAL/bedrock/default/1.0.3/EXTERNAL/bedrock/default) |

> [!TIP]
>
> **New to this?** You don't need to know Terraform or Kubernetes. Qovery sets up AWS Bedrock Access in your account with the provider: you fill in a form, or paste the prompt below into your coding agent. The values it publishes, listed under Outputs, reach your other services as environment variables. Qovery tells you when a newer version of the Blueprint is available. Check the requirements in the Reference section before you start, and try it first in a development environment.

## Create it

> [tab] Console
>
> 1. Open the environment, then **New service** › **Blueprint**.
> 2. Find **AWS Bedrock Access** in the catalog and pick the major version.
> 3. Fill in the variables. Required ones are marked; the others use their defaults.
> 4. Create the service, and deploy it now or later.

> [tab] CLI and API
>
> List the catalog to get the latest tag, then create the service from it. `qovery api` signs the requests with your CLI session.
>
> ```bash theme={null}
> ORG_ID="REPLACE_WITH_ORGANIZATION_ID"
> ENV_ID="REPLACE_WITH_ENVIRONMENT_ID"
>
> qovery api "organization/$ORG_ID/blueprint/catalog" | jq '.. | objects | select(.name? == "aws-bedrock-access")'
>
> cat > blueprint.json <<'EOF'
> {
>   "name": "aws-bedrock-access",
>   "tag": "EXTERNAL/bedrock/default/1.0.3",
>   "icon": "app://qovery-console/bedrock",
>   "variables": [
>     {
>       "name": "aws_access_key_id",
>       "value": "REPLACE_WITH_AWS_ACCESS_KEY_ID",
>       "is_secret": true
>     },
>     {
>       "name": "aws_secret_access_key",
>       "value": "REPLACE_WITH_AWS_SECRET_ACCESS_KEY",
>       "is_secret": true
>     },
>     {
>       "name": "name_prefix",
>       "value": "REPLACE_WITH_NAME_PREFIX"
>     },
>     {
>       "name": "allowed_model_ids",
>       "value": "REPLACE_WITH_ALLOWED_MODEL_IDS"
>     }
>   ],
>   "spec_overrides": {
>     "engine_version": "1.9.7"
>   }
> }
> EOF
> BLUEPRINT_ID=$(qovery api "environment/$ENV_ID/blueprint" --method POST --input - < blueprint.json | jq -r .id)
> rm blueprint.json   # it can hold secret values
> qovery api "blueprint/$BLUEPRINT_ID/deploy" --method POST
> qovery api "blueprint/$BLUEPRINT_ID"   # status of the latest deployment
> ```
>
> Replace each `REPLACE_WITH_` value. Add optional variables to `variables` the same way.

> [tab] Coding agent
>
> Paste this into Claude Code, Cursor, Codex or another coding agent with the [Qovery agent skills](https://www.qovery.com/docs/getting-started/quickstart/agent-skills.md) installed (`curl -fsSL https://skill.qovery.com/install.sh | bash`).
>
> ```text Prompt wrap theme={null}
> Add the Qovery Blueprint AWS Bedrock Access (aws-bedrock-access) to one of my Qovery environments and deploy it. Ask me for aws_access_key_id, aws_secret_access_key, name_prefix and allowed_model_ids.
> Ask me before deploying to a production environment.
> Docs: https://www.qovery.com/docs/configuration/blueprints/aws-bedrock-access.md
> ```

You don't add any file to your repository. Qovery creates the Blueprint from the Console or the API.

## Variables and outputs

Generated from `qbm.yml` at `EXTERNAL/bedrock/default/1.0.3`, the manifest the Console form is built from.

> [accordion] All 8 variables
>
> | Name | Type | Required | Default | Secret | Description |
> | - | - | - | - | - | - |
> | `aws_access_key_id` | string | Yes | | Yes | Key of the principal Terraform runs as. Needs IAM write on users, policies and access keys, delete and detach included; see the README. |
> | `aws_secret_access_key` | string | Yes | | Yes | Matches aws\_access\_key\_id |
> | `aws_region` | string | | `us-east-1` | | Region Bedrock is called in. Model availability differs per region: check yours is offered there. |
> | `name_prefix` | string | Yes | | | Names the IAM user (\<prefix>-bedrock) and its policy (\<prefix>-bedrock-invoke). Must be unique within the AWS account. |
> | `allowed_model_ids` | string | Yes | | | Comma-separated model ids, e.g. anthropic.claude-sonnet-4-5-20250929-v1:0; a cross-region id (us.…) also covers its base model. \* allows every model. |
> | `allow_list_foundation_models` | bool | | `true` | | Also allow read-only discovery calls (List/Get FoundationModel, InferenceProfile), which most SDK samples and model pickers make before invoking. |
> | `create_iam_user` | bool | | `true` | | Create an IAM user with a long-lived key, needed outside AWS where there is no role to assume. On an AWS cluster, turn off and use attach\_to\_role\_name. |
> | `attach_to_role_name` | string | | | | Unset = attach to nothing. Else an existing IAM role in the account (IRSA, EC2 instance profile) to attach the invoke policy to. |

Outputs become environment variables that other services in the environment can use. By default Qovery also creates an alias for each output, prefixed with the Blueprint's name; see [Aliases Qovery creates for outputs](https://www.qovery.com/docs/configuration/environment-variables.md#aliases-qovery-creates-for-outputs) for the naming rules and the cases where no alias is created.

> [accordion] All 8 outputs
>
> | Name | Secret | Description |
> | - | - | - |
> | `aws_region` | | Region the credentials are scoped to call Bedrock in |
> | `account_id` | | AWS account the Bedrock access was created in |
> | `policy_arn` | | ARN of the Bedrock invoke policy, for attaching to further principals |
> | `iam_user_name` | | IAM user holding the invoke policy (empty when create\_iam\_user is false) |
> | `access_key_id` | Yes | Access key id for the created IAM user — set it as AWS\_ACCESS\_KEY\_ID |
> | `secret_access_key` | Yes | Secret access key for the created IAM user — set it as AWS\_SECRET\_ACCESS\_KEY |
> | `bedrock_endpoint` | | Bedrock runtime endpoint for the region, built from the partition DNS suffix |
> | `allowed_model_arns` | | Model and inference profile ARNs the credentials may invoke |

> [!WARNING]
>
> Secret variables and outputs are encrypted and masked in Qovery, but Terraform can also keep their values, and values derived from them, in its state. With the Qovery-managed state backend (the default), Qovery stores the state. If you use your own backend, protect it and keep state files out of version control.

## Reference

From the Blueprint's [README](https://github.com/Qovery/service-catalog/blob/EXTERNAL/bedrock/default/1.0.3/EXTERNAL/bedrock/default/README.md).

Provisions scoped access to [Amazon Bedrock](https://aws.amazon.com/bedrock/): an IAM policy
(`aws_iam_policy`) allowing invocation of the models you name, and by default an IAM user with a
long-lived access key (`aws_iam_user`, `aws_iam_access_key`), via the official `hashicorp/aws`
provider (`~> 6.0`).

**Available on every cloud.** This is an `EXTERNAL` blueprint: the AWS credentials come in as
variables rather than from the cluster, so a GCP, Azure or Scaleway cluster can consume Bedrock, and
an AWS cluster can reach a Bedrock account other than its own. The generated access key is the
point — a workload outside AWS has no IAM role to assume, so a static key is the only way in. On an
AWS cluster, set `create_iam_user = false` and pass `attach_to_role_name` to stay keyless.

It provisions **access**, not models: Bedrock model access is granted per account in the console and
is not manageable through this provider. Enable the models you want first, or every invocation
returns `AccessDeniedException` regardless of the IAM policy.

### Credentials

An AWS access key pair in `aws_access_key_id` + `aws_secret_access_key` (both sensitive), supplied
as variables (`credentials.default: env`). The principal needs:

| Action | Why |
| - | - |
| `iam:CreatePolicy`, `iam:DeletePolicy` | the invoke policy |
| `iam:CreateUser`, `iam:DeleteUser`, `iam:CreateAccessKey`, `iam:DeleteAccessKey`, `iam:AttachUserPolicy`, `iam:DetachUserPolicy` | the IAM user and its key (`create_iam_user = true`) |
| `iam:TagUser`, `iam:TagPolicy` | every resource here is tagged |
| `iam:AttachRolePolicy`, `iam:DetachRolePolicy` | attaching to an existing role (`attach_to_role_name`) |
| `iam:GetUser`, `iam:GetPolicy`, `iam:ListAttachedUserPolicies`, `sts:GetCallerIdentity` | reads Terraform makes on every plan |

No `bedrock:*` permission is needed — the blueprint only writes IAM.

### Variables

#### Required

| Name | Type | Sensitive | Description |
| - | - | - | - |
| `aws_access_key_id` | string | yes | Access key id of the AWS principal Terraform authenticates as. Needs IAM write access on users, policies and access keys — including the delete and detach actions, or destroy fails. The blueprint README lists the full set. |
| `aws_secret_access_key` | string | yes | Matching secret access key |
| `name_prefix` | string | | Prefix for the resources this blueprint names: the IAM user (\<prefix>-bedrock) and its policy (\<prefix>-bedrock-invoke). Must be unique within the AWS account. |
| `allowed_model_ids` | string | | Comma-separated Bedrock model ids the credentials may invoke, e.g. anthropic.claude-sonnet-4-5-20250929-v1:0. A cross-region id (us.anthropic.…) is expanded to both the inference profile and the underlying foundation model. Pass \* to allow every foundation model in the account — deliberately not the default, since that also covers every model added in future. |

#### Optional

| Name | Type | Default | Description |
| - | - | - | - |
| `aws_region` | string | `us-east-1` | Region Bedrock is called in. Model availability differs per region — check the model you want is offered there before changing it. |
| `allow_list_foundation_models` | bool | `true` | Also allow read-only discovery calls (ListFoundationModels, GetFoundationModel, ListInferenceProfiles, GetInferenceProfile). Most SDK samples and model pickers call these before invoking. |
| `create_iam_user` | bool | `true` | Create an IAM user with a long-lived access key. This is what makes Bedrock reachable from a cluster outside AWS, which has no IAM role to assume. Set false on an AWS cluster and use `attach_to_role_name` instead. |
| `attach_to_role_name` | string | | Existing IAM role in the same account to attach the invoke policy to — the keyless path for a workload that already has an AWS identity (IRSA, EC2 instance profile). Unset = attach to nothing. |

### Outputs

| Name | Sensitive | Description |
| - | - | - |
| `aws_region` | | Region the credentials call Bedrock in |
| `account_id` | | AWS account the access was created in |
| `policy_arn` | | Invoke policy ARN, for attaching to further principals |
| `iam_user_name` | | IAM user holding the policy (empty when not created) |
| `access_key_id` | yes | Set as `AWS_ACCESS_KEY_ID` |
| `secret_access_key` | yes | Set as `AWS_SECRET_ACCESS_KEY` |
| `bedrock_endpoint` | | Bedrock runtime endpoint, built from the partition DNS suffix |
| `allowed_model_arns` | | Model and inference profile ARNs the credentials may invoke |

### Notes

* **Invocation logging is deliberately not managed here.** Bedrock keeps one logging configuration
  per account per region, so a per-service blueprint that owned it would overwrite whatever the
  account already had on create and remove logging for every other workload in that region on
  destroy. Configure it once at the account level instead
  (`aws_bedrock_model_invocation_logging_configuration` in your account baseline, or the console).
* **A cross-region model id is expanded to two ARNs.** Invoking `us.anthropic.claude-…` is
  authorized against both the inference profile in your account and the underlying foundation model
  in whichever region the request is routed to, so the foundation-model ARN is emitted with a region
  wildcard. Pinning it to `aws_region` would deny every cross-region invocation — which is how the
  Claude models are normally called.
* **`allowed_model_ids` is required, with no default.** `*` is accepted but has to be typed: it
  grants every foundation model in the account, including ones added after the key is issued. An
  empty or comma-only value is rejected rather than being treated as `*`.
* **The access key is long-lived.** It is surfaced as a sensitive output and stored encrypted by
  Qovery. Rotating it means tainting `aws_iam_access_key.app` and redeploying. Prefer
  `create_iam_user = false` plus `attach_to_role_name` wherever the workload already has an AWS
  identity.
* **`force_destroy` is set on the IAM user**, so destroying the blueprint removes the user together
  with the keys it still holds instead of failing.
* Guardrails, knowledge bases and provisioned throughput are out of scope: each is a substantial
  configuration of its own and belongs in its own blueprint.


## Related topics

- [Blueprints](https://www.qovery.com/docs/configuration/blueprints.md)
- [SOC2](https://www.qovery.com/docs/getting-started/security-and-compliance/soc2.md)
- [AWS ECR](https://www.qovery.com/docs/configuration/integrations/container-registries/aws-ecr.md)
- [AWS EKS](https://www.qovery.com/docs/configuration/integrations/kubernetes/eks/managed.md)
- [AWS Parameter Store](https://www.qovery.com/docs/configuration/integrations/secret-managers/aws-parameter-store.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.