To secure AWS Bedrock and ensure only authorized applications or users can access it, use IAM policies to control permissions and network restrictions to limit access points. Here’s how to approach this:
1. IAM Policies for Access Control
Start by defining granular IAM policies that specify which users, roles, or applications can invoke Bedrock APIs. For example, attach a policy to an IAM role that allows only the bedrock:InvokeModel action on specific Bedrock models (e.g., arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-v2). Use conditions like aws:SourceIp to restrict API calls to specific IP ranges or aws:MultiFactorAuthPresent to require MFA. For applications, use IAM roles with temporary credentials (via AWS STS) instead of long-term access keys. Example policy:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "bedrock:InvokeModel",
"Resource": "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-v2",
"Condition": {"IpAddress": {"aws:SourceIp": "192.0.2.0/24"}}
}
]
}
2. Network Restrictions with VPC Endpoints Use AWS PrivateLink to create a VPC endpoint for Bedrock. This ensures traffic between your VPC and Bedrock stays within the AWS network, avoiding exposure to the public internet. Configure the VPC endpoint’s security group to allow access only from specific subnets or resources (e.g., EC2 instances or Lambda functions). Combine this with IAM policies for layered security. For on-premises systems, use AWS Direct Connect or VPN to extend network controls.
3. Additional Layers For applications exposed via APIs, use Amazon API Gateway as a proxy to Bedrock. Enable IAM authentication or API keys on the Gateway. For serverless apps, use Lambda functions with Bedrock permissions, and restrict Lambda execution roles to specific triggers (e.g., API Gateway). Enable AWS CloudTrail to audit Bedrock API calls and use AWS Config to monitor IAM policy compliance. Regularly rotate credentials and review policies to minimize exposure.