aws-bedrock
AWS Bedrock provider for BAML
The aws-bedrock
provider supports all text-output models available via the Converse API.
Quick Start
Authentication
AWS Bedrock uses standard AWS authentication methods. Choose the one that best fits your environment:
Environment Variables
AWS Profile
AWS Services (Lambda/ECS/EC2)
Explicit Credentials
The simplest way to authenticate. Set these environment variables:
Credential Resolution
BAML follows a specific order when resolving AWS credentials:
-
Explicit BAML Configuration
BAML -
Environment Variables
-
AWS Configuration Files
-
Instance Metadata (EC2/ECS only)
- IAM Role credentials
- Instance profile credentials
Important Rules
-
All or Nothing
- If you provide any credential explicitly, you must provide all required credentials
- This won’t work:
BAML
-
Session Token Requirements
- When using
session_token
, you must provide all three:access_key_id
secret_access_key
session_token
- When using
-
Profile Exclusivity
- When using
profile
, you cannot specify other credentials:BAML
- When using
-
Environment Variable Override
- Explicit values in BAML always override environment variables:
BAML
- Explicit values in BAML always override environment variables:
-
AWS Lambda/ECS/EC2
- In AWS services, credentials are automatically provided by the runtime
- Explicitly provided credentials will override the automatic ones
- Best practice: Don’t specify credentials in AWS environments, use IAM roles instead
Using Custom Environment Variables
You can map your own environment variable names:
BAML
Environment
Cross-Account Access
To use Bedrock from a different AWS account:
- Set up the target account role (where Bedrock is):
- Configure the source account (where your application runs):
AWS Profile
Environment Variables
ClientRegistry
IAM Permissions
Basic Permissions
The following IAM permissions are required for basic Bedrock access:
Additional Permissions
Depending on your setup, you might need additional permissions:
Cross-Account Access
VPC Endpoints
Resource-Based
See Cross-Account Access section for the required trust relationships and permissions.
Best Practices
- Follow the principle of least privilege
- Use resource-based policies when possible
- Consider using AWS Organizations SCPs for enterprise-wide controls
- Regularly audit IAM permissions using AWS IAM Access Analyzer
Configuration Options
BAML-specific request options
These unique parameters (aka options
) are modify the API request sent to the provider.
You can use this to modify the region
, access_key_id
, secret_access_key
, and session_token
sent to the provider.
The AWS region to use. Default: AWS_REGION
environment variable
AWS access key ID. Default: AWS_ACCESS_KEY_ID
environment variable
AWS secret access key. Default: AWS_SECRET_ACCESS_KEY
environment variable
Temporary session token. Required if using temporary credentials. Default: AWS_SESSION_TOKEN
environment variable
AWS profile name from credentials file. Default: AWS_PROFILE
environment variable
The role to use if the role is not in the allowed_roles. Default: "user"
usually, but some models like OpenAI’s gpt-4o
will use "system"
Picked the first role in allowed_roles
if not “user”, otherwise “user”.
Which roles should we forward to the API? Default: ["system", "user", "assistant"]
usually, but some models like OpenAI’s o1-mini
will use ["user", "assistant"]
When building prompts, any role not in this list will be set to the default_role
.
Which role metadata should we forward to the API? Default: []
For example you can set this to ["foo", "bar"]
to forward the cache policy to the API.
If you do not set allowed_role_metadata
, we will not forward any role metadata to the API even if it is set in the prompt.
Then in your prompt you can use something like:
You can use the playground to see the raw curl request to see what is being sent to the API.
Whether the internal LLM client should use the streaming API. Default: true
Then in your prompt you can use something like:
Which finish reasons are allowed? Default: null
Will raise a BamlClientFinishReasonError
if the finish reason is not in the allow list. See Exceptions for more details.
Note, only one of finish_reason_allow_list
or finish_reason_deny_list
can be set.
For example you can set this to ["stop"]
to only allow the stop finish reason, all other finish reasons (e.g. length
) will treated as failures that PREVENT fallbacks and retries (similar to parsing errors).
Then in your code you can use something like:
Which finish reasons are denied? Default: null
Will raise a BamlClientFinishReasonError
if the finish reason is in the deny list. See Exceptions for more details.
Note, only one of finish_reason_allow_list
or finish_reason_deny_list
can be set.
For example you can set this to ["length"]
to stop the function from continuing if the finish reason is length
. (e.g. LLM was cut off because it was too long).
Then in your code you can use something like:
Provider request parameters
These are other options
that are passed through to the provider, without modification by BAML. For example if the request has a temperature
field, you can define it in the client here so every call has that set.
Consult the specific provider’s documentation for more information.
The model to use.
Run aws bedrock list-foundation-models | jq '.modelSummaries.[].modelId'
to see available models.
Note: You must request model access before use.
Model-specific inference parameters. See AWS Bedrock documentation.
Troubleshooting
Common Errors
AccessDeniedException
Solution:
- Check IAM permissions
- Verify execution role permissions in Lambda/ECS
- Ensure credentials have Bedrock access
UnrecognizedClientException
Solution:
- Verify credentials are set correctly
- Check if session token is required and provided
- Ensure credentials haven’t expired
ValidationException (Region)
Solution:
- Check model availability in your region
- Request model access if needed
- Consider using a different region
ValidationException (Model Access)
Solution:
- Request model access through AWS Console
- Wait for approval (1-2 business days)
- Verify model ID is correct
Environment-Specific Setup
Lambda
- Set appropriate memory and timeout
- Configure execution role with Bedrock permissions
- Consider VPC endpoints for private subnets
ECS/EC2
- Use task roles (ECS) or instance profiles (EC2)
- Configure VPC endpoints if needed
- Check security group outbound rules
Local Development
- Set AWS credentials in environment or config files
- Use
AWS_PROFILE
to manage multiple profiles - Run
aws configure list
to verify configuration