Amazon Bedrock

Connect your AWS account so Gateway serves Amazon Bedrock models (for example Claude, Nova, Llama, and Qwen) on your own account. There are three ways to authenticate. Pick the one that fits your security posture.

Whichever method you choose, the IAM identity behind it needs permission to invoke Bedrock models:

1
{
2
  "Version": "2012-10-17",
3
  "Statement": [
4
    {
5
      "Effect": "Allow",
6
      "Action": ["bedrock:InvokeModel", "bedrock:InvokeModelWithResponseStream"],
7
      "Resource": "*"
8
    }
9
  ]
10
}

The AWS-managed AmazonBedrockLimitedAccess policy already grants these actions, so attaching it is enough for either method below. You also need to enable model access for the specific Bedrock models you want in the AWS Region you use.

API key

A Bedrock API key is a bearer token you pass instead of AWS credentials. It is the fastest way to get started.

In AWS: open the Amazon Bedrock console, select API keys in the left navigation, and generate a key. AWS offers two kinds:

• Short-term keys last up to 12 hours (or the length of your console session) and inherit the permissions of the IAM principal that created them, which suits a quick test
• Long-term keys last until an expiry date you set and create a backing IAM user, which suits exploration

By default AWS attaches the AmazonBedrockLimitedAccess policy to the key, which covers the invoke permissions above. See Generate an Amazon Bedrock API key for the exact console steps.

In Gateway: add an Amazon Bedrock credential, choose the API key method, paste the key, and set the region. The region must match the AWS Region you generated the key from, because the key can only call that Region.

Access keys

Static IAM user credentials (an access key ID and secret) that Gateway uses to sign each Bedrock request.

In AWS:

1. Create an IAM user, for example bedrock-gateway
2. Attach the invoke policy above, or the AmazonBedrockLimitedAccess managed policy
3. Create an access key for that user and copy the access key ID and secret

In Gateway: add an Amazon Bedrock credential, choose the Access keys method, and enter the access key ID, secret access key, and region. Access keys are not tied to a single Region, so choose whichever Region has the models you want enabled.

IAM role

The most secure option: instead of a long-lived secret, Gateway assumes a role in your account with short-lived credentials at request time. Because the assume is cross-account, your role has to trust the Merge data-plane principal, scoped to your organization with an external ID.

The dialog shows you the exact principal ARN and external ID to use when you select this method. Both are needed for the trust policy below. Do not copy the placeholders here; use the values from the dialog, because the principal differs by environment and the external ID is unique to your organization.

In AWS, create a role with this trust policy (substitute the two values from the dialog):

1
{
2
  "Version": "2012-10-17",
3
  "Statement": [
4
    {
5
      "Effect": "Allow",
6
      "Principal": { "AWS": "<MERGE_PRINCIPAL_ARN_FROM_DIALOG>" },
7
      "Action": "sts:AssumeRole",
8
      "Condition": {
9
        "StringEquals": { "sts:ExternalId": "<EXTERNAL_ID_FROM_DIALOG>" }
10
      }
11
    }
12
  ]
13
}

Attach the invoke policy above (or AmazonBedrockLimitedAccess) to the role for permissions.

In Gateway: add an Amazon Bedrock credential, choose the IAM role method, and paste the role ARN. Access keys are not required; Gateway assumes the role using its own identity, which your trust policy authorizes.

Reference

• API keys for Amazon Bedrock
• Get started with Amazon Bedrock API keys
• AWS service terms

Next steps