- Name: Can be anything. Example:
toqan_bedrock - Access key id: Retrieve this from your IAM in AWS.
- Secret access key: Also retrieve this from your IAM in AWS.
- Region: Make sure that you select the right region. Example: us-east-1
Retrieve access keys in AWS
Policies / Permissions in AWS
In order for the model to work, make sure that the following two permissions are included in the policy which is attached to the user in AWS.- Bedrock: InvokeModel
- Bedrock: InvokeModelWithResponseStream
IAM role
The AI Studio exposes the Pod Identity (On-Premise) auth mode on on-premise deployments only. A Bedrock model on such a deployment can authenticate with an IAM role instead of an access key and secret, so no long-lived AWS credentials are stored with the model. In the AI Gateway sidebar, open Models, select Model, and choose AWS Bedrock. Set Auth Mode to Pod Identity (On-Premise), which sendsauth_mode: "pod-identity" in the API.
Credentials then come from the AWS default credential chain of the deployment: the role attached to the gateway through EKS Pod Identity or IAM Roles for Service Accounts (IRSA), or the instance metadata service.
Assume a role in another account
Set Assume Role ARN to have Toqan Router assume a role in a different AWS account. The optional External ID acts as a shared secret that the target role’s trust policy requires before it grants access.
The assumed role needs the Bedrock permissions listed above. Without an Assume Role ARN, requests sign with the credentials the deployment resolves from its environment.
Trust policy on the target role
The target role’s trust policy must allow the identity the deployment runs as, and that identity needssts:AssumeRole permission on the target role.
JSON
<deployment_account_id> and <deployment_role_name> with that identity, which aws sts get-caller-identity reports from inside the deployment. When an External ID is set, add "Condition": { "StringEquals": { "sts:ExternalId": "<external_id>" } } to the statement.
Custom models via inference profile
A Bedrock custom model is added by inference-profile ARN. Both profile types are accepted:
A prefix such as
eu. in a system-defined profile id is the geography AWS routes requests through. An application profile carries no prefix. The EU Claude Sonnet 4.5 profile, with an example account id:
bedrock:GetInferenceProfile alongside the two invoke permissions above.
Without that permission, a chat model still validates and reports its type as chat; the developer and prices stay empty. An embedding profile fails validation.
A cross-region profile sends requests to the other regions in its geography. Allow the invoke actions on the foundation models there too.
Add the profile in the console
1
Enter the profile
In Models, click Model and choose AWS Bedrock. Set Auth Mode to AWS Integration, select the AWS integration, and paste the Inference Profile ARN. The Region fills from the ARN.
2
Validate the connection
Click Validate Connection. The gateway resolves the foundation model and fills the model type, developer, capabilities and prices it knows for it.
3
Name the model
Set the Model slug and a Display name. The slug completes the model id the gateway accepts:
<workspace>@aws/<slug>. See Referencing Private Models in Code.Add the profile through the API
model_id is the slug, and the ARN goes in configuration.model_id:
<workspace>@aws/claude-sonnet-4-5-eu. Field reference: Create an AWS Bedrock custom model.
This endpoint stores what the body carries: it detects no type, capability or price, so send model_type, the capability flags and the per-token input_cost / output_cost, or run validation first to read the type, developer and capabilities to carry into the body. region must be the region in the ARN, and integration_id is the id of the AWS integration in the workspace.