Amazon Bedrock AgentCore security: AWS WAF patterns and trade-offs

Amazon Bedrock AgentCore Runtime requires SigV4 or OAuth authentication on API calls, which causes standard Application Load Balancer health checks to fail because they send unauthenticated probes. AWS documents two architectures that attach AWS WAF to an internet-facing ALB and route traffic to AgentCore through a VPC Interface Endpoint com.amazonaws..bedrock-agentcore: Pattern 1 inserts a Lambda proxy, Pattern 2 has the ALB target the VPC Endpoint ENI IP addresses directly.

How do the two patterns work?

Pattern 1 places a Lambda function behind an internet-facing ALB that has AWS WAF attached; the ALB terminates TLS on port 443 and forwards requests to the Lambda proxy, which forwards authenticated headers and payloads to the VPC Interface Endpoint and AgentCore Runtime (internal port 8080). Pattern 2 configures an IP target group on HTTPS port 443 that registers the VPC Endpoint ENI private IPs, letting the ALB pass authentication headers through directly.

Both patterns share a common core: client → AWS WAF → ALB (HTTPS 443) → VPC Endpoint (PrivateLink) → AgentCore Runtime container (internal port 8080). Pattern 1 adds a Lambda proxy that can re-sign SigV4 requests or forward OAuth Bearer tokens unchanged. Pattern 2 requires clients to present valid SigV4 or OAuth credentials directly because there is no proxy re-signing step.

What are the technical specifics and trade-offs?

Pattern 1 offers request transformation, header manipulation, custom logging, and authentication translation at the expense of added latency, cost, and operational complexity; AWS notes the Lambda proxy "adds approximately 50–200 ms per request." Pattern 2 removes the compute hop for minimal latency but requires the ALB target group to use IP targets pointed at the VPC Endpoint ENIs and a health check that does not require authentication.

Key configuration details from the walkthrough: create a VPC Interface Endpoint for com.amazonaws..bedrock-agentcore in private subnets and restrict the VPCE security group to allow inbound HTTPS (port 443) only from the ALB security group. For Pattern 2 the sample target-group command uses protocol HTTPS, port 443, health-check-path / and matcher HttpCode=200-499; AgentCore returns a 404 on / but the ALB accepts any 200–499 response as healthy. For SigV4, the Lambda proxy must re-sign requests because signatures are bound to the original host; for OAuth, the Lambda can forward the Authorization header unchanged.

Costs and operational notes are explicit: VPC Interface Endpoints incur hourly and data processing charges, Lambda invokes add per-request and GB-second compute costs, and Application Load Balancers incur hourly plus LCU charges. Lambda target groups do not require path-based health checks because the ALB tests the function by invoking it directly.

Why it matters

AWS WAF provides rate limiting, SQL injection protection, cross-site scripting filtering, and bot control through managed rule groups such as AWSManagedRulesCommonRuleSet, so integrating WAF ahead of AgentCore enforces web-layer protections and audit controls for real-time agent invocations. The two patterns give teams a trade-off between operational control and latency: use Pattern 1 when you need request transformation or centralized logging, and Pattern 2 when you want the simplest, lowest-latency path while still applying WAF rules at the ALB.

What to watch

Confirm that your VPC Endpoint resource policy blocks direct access so traffic must flow through AWS WAF and the ALB, and validate end-to-end behavior for both SigV4 and OAuth because the AWS walkthrough notes both patterns were tested end-to-end with SigV4 and Amazon Cognito JWT authentication. Monitor ALB health-check results using the matcher HttpCode=200-499 and watch latency and cost metrics if you adopt the Lambda proxy.