AWS Bedrock Access

Qovery creates it in your account with a third-party provider, using credentials you enter in the form, as a Blueprint 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

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

Console
CLI and API
Coding agent

Open the environment, then New service › Blueprint.
Find AWS Bedrock Access in the catalog and pick the major version.
Fill in the variables. Required ones are marked; the others use their defaults.
Create the service, and deploy it now or later.

List the catalog to get the latest tag, then create the service from it. qovery api signs the requests with your CLI session.

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.

Paste this into Claude Code, Cursor, Codex or another coding agent with the Qovery agent skills installed (curl -fsSL https://skill.qovery.com/install.sh | bash).

Prompt

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.

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 for the naming rules and the cases where no alias is created.

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

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. Provisions scoped access to Amazon 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.

Overview

Account & Organization

Clusters & Cloud

Source Control

Projects & Environments

Services

Deployment & CI/CD

Environment Variables & Secrets

Observability

Notifications

Networking & Advanced

AWS Bedrock Access

Create it

Variables and outputs

Reference

Credentials

Variables

Required

Optional

Outputs

Notes

​Create it

​Variables and outputs

​Reference

​Credentials

​Variables

​Required

​Optional

​Outputs

​Notes

Create it

Variables and outputs

Reference

Credentials

Variables

Required

Optional

Outputs

Notes