AWS WAF を用いた Amazon Bedrock AgentCore Runtime のセキュリティ強化

When you deploy generative AI agents with Amazon Bedrock AgentCore as production API endpoints, you might want to enforce web application firewall policies, rate limiting, protection against common web threats, or audit controls via AWS WAF.

AWS WAF integrates with Elastic Load Balancing Application Load Balancers (ALBs), Amazon CloudFront distributions, and Amazon API Gateway REST APIs. Amazon CloudFront is designed for caching and content delivery. Since agent invocations are real-time and dynamic, caching doesn’t apply. Amazon API Gateway adds its own authentication and request transformation layer, which can create a double-authentication problem with the built-in SigV4 and OAuth handling in AgentCore. That leaves an internet-facing ALB as the integration point: It passes headers through transparently, supports VPC-internal routing, and attaches directly to an AWS WAF WebACL. From there, you route traffic to AgentCore through a VPC Interface Endpoint for the Bedrock AgentCore data plane service.

This is where the challenge appears. ALBs require health checks to verify that backend targets are responsive. But AgentCore Runtime requires authentication, SigV4 or OAuth, on API calls, including health check requests. Standard ALB health checks send unauthenticated requests, so they fail out of the box. You need a way to make health checks work without credentials while still passing authenticated production traffic through to AgentCore.

This post shows you two architecture patterns that address this problem. Both use an internet-facing ALB with AWS WAF and route traffic through a VPC Interface Endpoint to AgentCore Runtime. Pattern 1 places an AWS Lambda proxy between the ALB and the VPC Endpoint, giving you full control over request transformation. Pattern 2 targets the VPC Endpoint ENI IP addresses directly from the ALB, removing the Lambda hop entirely. You also learn how to close the direct-access backdoor with a resource policy so that traffic flows through AWS WAF only. Both patterns have been tested end-to-end with SigV4 and OAuth (Amazon Cognito JWT) authentication.

Architecture overview

The two patterns share a common foundation. A client application sends an authenticated request, either a SigV4 signature or an OAuth Bearer token, to an internet-facing ALB. AWS WAF inspects the request before the ALB forwards it to VPC Endpoint ENIs on HTTPS port 443. AgentCore validates the authentication and routes the request to the runtime container on its internal port 8080. The difference between the patterns is what sits between the ALB and the VPC Endpoint.

High-level architecture, Client → AWS WAF → ALB → VPC Endpoint (PrivateLink) → AgentCore Runtime container

The architecture has four components:

• AWS WAF attaches to the ALB and provides rate limiting, SQL injection protection, XSS filtering, and bot control through managed rule groups like AWSManagedRulesCommonRuleSet.

• ALB is internet-facing with an HTTPS listener on port 443, routing traffic to VPC Endpoint ENI IP targets.

• VPC Interface Endpoint (com.amazonaws..bedrock-agentcore) provides private connectivity to AgentCore through PrivateLink.

• AgentCore Runtime is the managed container running your agent code, listening on internal port 8080 and supporting both SigV4 and OAuth authentication.

*Note: Use com.amazonaws..bedrock-agentcore (data plane) for Runtime invocations. There are three separate endpoint services: bedrock-agentcore (data plane for Runtime, Memory, Tools), bedrock-agentcore-control (control plane), and bedrock-agentcore.gateway (Gateway only). Using the wrong endpoint will not route to your Runtime.*

Prerequisites

To follow along with this walkthrough, you need:

• An AWS account with Amazon Bedrock AgentCore enabled.

• An AgentCore Runtime deployed (public or VPC mode).

• A VPC with public and private subnets across at least two Availability Zones.

• An AWS Certificate Manager (ACM) certificate in the same Region, for the ALB’s HTTPS listener.

• An Amazon Cognito User Pool (for the OAuth pattern) or AWS credentials (for the SigV4 pattern).

• Familiarity with ALB, VPC Endpoints, and AWS WAF.

The following sections describe two patterns for integrating AWS WAF with AgentCore. If you need request transformation, custom logging, or authentication translation between the ALB and AgentCore, start with Pattern 1. If you want the simplest architecture with the lowest latency and no additional components, skip to Pattern 2.

Pattern 1: ALB with Lambda proxy

In this pattern, a Lambda function sits behind the ALB and forwards requests, including the authentication header, to AgentCore through the VPC Endpoint. The Lambda function gives you a compute layer where you can transform requests, translate between authentication methods, or add custom logging before the request reaches AgentCore.

Pattern 1 architecture, Client (JWT) → AWS WAF → ALB → Lambda Proxy → VPC → VPC Endpoint → AgentCore Runtime (OAuth authorizer)

Choose Pattern 1 if you need:

• Request transformation, header manipulation, payload changes, or protocol translation.

• Custom logging or audit trails at the proxy layer.

• Translation between multiple authentication methods.

• An explicit compute layer between the ALB and backend (some security policies require this).

Create the VPC Endpoint

Create a VPC Interface Endpoint for the AgentCore data plane service in your private subnets:

aws ec2 create-vpc-endpoint \
  --vpc-id vpc-xxxxxxxxx \
  --service-name com.amazonaws.us-east-1.bedrock-agentcore \
  --vpc-endpoint-type Interface \
  --subnet-ids subnet-aaaa subnet-bbbb \
  --security-group-ids sg-xxxxxxxxx

*Note: VPC Interface Endpoints incur hourly charges per Availability Zone plus data processing charges per GB. See VPC pricing.*

Configure the VPC Endpoint security group to allow inbound HTTPS (port 443) only from the ALB’s security group. This restricts access so that traffic routed through the ALB can reach the VPC Endpoint. For example:

aws ec2 authorize-security-group-ingress \
  --group-id  \
  --protocol tcp \
  --port 443 \
  --source-group 

Create the Lambda proxy

The Lambda function receives requests from the ALB and forwards them to AgentCore through the VPC Endpoint. For OAuth, it passes the Authorization header (the Bearer token) through unchanged, along with the original request path and body, so the JWT reaches AgentCore as-is. For SigV4, the signature is bound to the original request host and becomes invalid after the request is forwarded to the VPC Endpoint, so the proxy re-signs the request using its own execution-role credentials.

The following Python snippet shows the core forwarding logic. The function reads the Authorization header from the ALB event, constructs the target URL using the VPC Endpoint DNS name, and forwards the request with the original headers and body intact. This forwarding path works as-is for OAuth Bearer tokens. SigV4 requests require the additional re-signing step, which is included in the accompanying repository.

import json
import urllib3
import os

http = urllib3.PoolManager()
VPCE_DNS = os.environ["VPCE_DNS_NAME"]

def handler(event, context):
    path = event.get("path", "/")
    headers = event.get("headers", {})
    body = event.get("body", "")
    method = event.get("httpMethod", "POST")

    target_url = f"https://{VPCE_DNS}{path}"

    resp = http.request(
        method,
        target_url,
        headers={
            "Authorization": headers.get("authorization", ""),
            "Content-Type": headers.get("content-type", "application/json"),
        },
        body=body,
    )

    return {
        "statusCode": resp.status,
        "headers": {"Content-Type": "application/json"},
        "body": resp.data.decode("utf-8"),
    }

For brevity, the preceding snippet focuses on the forwarding logic. The complete production-ready implementation, including SigV4 signing, query string handling, ALB health check responses, and structured error handling, is available in the accompanying GitHub repository.

*Note: The Lambda proxy incurs charges per request and for compute duration (GB-seconds). See AWS Lambda pricing.*

Configure ALB with Lambda target group

Create a Lambda target group, register the proxy function, and create an HTTPS listener on the ALB. The ALB handles TLS termination and forwards the decrypted request to the Lambda function.

*Note: Application Load Balancers incur hourly charges plus Load Balancer Capacity Unit (LCU) charges based on traffic. See Elastic Load Balancing pricing.*

Attach AWS WAF

Associate an AWS WAF WebACL with the ALB. A typical starting configuration includes AWSManagedRulesCommonRuleSet for protection against common web threats, a rate-based rule to throttle excessive requests per source IP, and AWSManagedRulesBotControlRuleSet if your agents are exposed to browser-based clients. You can add or remove managed rule groups based on your threat model. These are examples, not a prescriptive minimum.

*Note: AWS WAF incurs charges per WebACL per month, per rule, and per million requests inspected. See AWS WAF pricing.*

*Note: Lambda target groups don’t use path-based health checks. The ALB verifies the function is invocable by calling it directly, so no special health check configuration is needed.*

Pattern 1 trade-offs

Aspect

Impact

Latency

Adds 50–200 ms per request (Lambda cold start). Mitigate with provisioned concurrency.

Cost

Lambda invocation cost per request.

Complexity

Additional component to deploy, monitor, and maintain.

Flexibility

Full control over request/response transformation and custom logging.

*Note: The Lambda proxy adds approximately 50–200 ms of latency per request. For latency-sensitive workloads, consider Pattern 2, which removes this overhead.*

Pattern 2: ALB directly to VPC Endpoint

In this pattern, the ALB targets the VPC Endpoint ENI IP addresses directly on HTTPS port 443. There is no Lambda function and no Network Load Balancer. The ALB passes authentication headers through to AgentCore transparently. This architecture has fewer components and removes the Lambda proxy hop.

Pattern 2 architecture, Client (JWT or SigV4) → AWS WAF → ALB → VPC Endpoint ENIs (HTTPS 443) → AgentCore Runtime

Choose Pattern 2 if you want:

• A simpler architecture with fewer components.

• No request transformation between the ALB and AgentCore.

• Minimal latency with no additional hops.

• Your client application to handle SigV4 or OAuth signing directly.

Create the VPC Endpoint

Create a VPC Interface Endpoint for com.amazonaws..bedrock-agentcore in your private subnets, using the same command shown in Pattern 1, Step 1.

Retrieve the VPC Endpoint ENI IP addresses

Get the private IP addresses of the ENIs created by the VPC Endpoint. These IPs become the targets for your ALB target group.

# Get the ENI IDs
aws ec2 describe-vpc-endpoints \
  --vpc-endpoint-ids vpce-xxxxxxxxx \
  --query "VpcEndpoints[0].NetworkInterfaceIds"

# Get the private IPs
aws ec2 describe-network-interfaces \
  --network-interface-ids eni-aaaa eni-bbbb \
  --query "NetworkInterfaces[].PrivateIpAddress"

Create an IP target group with a health check

This step is the key configuration that makes Pattern 2 work. Create an IP-type target group on HTTPS port 443 with a health check that doesn’t require authentication.

aws elbv2 create-target-group \
  --name agentcore-vpce-tg \
  --target-type ip \
  --protocol HTTPS \
  --port 443 \
  --vpc-id vpc-xxxxxxxxx \
  --health-check-protocol HTTPS \
  --health-check-port 443 \
  --health-check-path / \
  --matcher HttpCode=200-499

*Note: This target group is available at no additional cost, but the associated Application Load Balancer incurs hourly plus LCU charges, and the VPC Interface Endpoint incurs hourly and data processing charges. See Elastic Load Balancing pricing.*

The health check uses path / with a matcher of 200–499. AgentCore returns a 404 on / because it isn’t a valid API path, but the ALB accepts responses in the 200–499 range as healthy. This works because the goal is to verify that the VPC Endpoint is responding. The specific status code doesn’t matter. This approach requires no authentication for health checks.

Register the targets

Register the VPC Endpoint ENI IPs as targets:

aws elbv2 register-targets \
  --target-group-arn  \
  --targets Id=10.0.1.100,Port=443 Id=10.0.2.200,Port=443

Create the HTTPS listener

Create an HTTPS listener on the ALB that forwards to the target group. The ALB handles TLS termination using your ACM certificate:

aws elbv2 create-listener \
  --load-balancer-arn  \
  --protocol HTTPS \
  --port 443 \
  --certificates CertificateArn= \
  --default-actions Type=forward,TargetGroupArn=

Attach AWS WAF

Associate an AWS WAF WebACL with the ALB, using the same approach described in Pattern 1, Step 4.

How authentication passes through the ALB

The ALB passes the Authorization header through without modification. Both SigV4 signatures and OAuth Bearer tokens reach AgentCore transparently.

For SigV4 (AWS SDK), point the SDK to the ALB endpoint URL. The SDK handles signing automatically:

import boto3

client = boto3.client(
    "bedrock-agentcore",
    endpoint_url="https://"
)

response = client.invoke_agent_runtime(
    agentRuntimeArn="arn:aws:bedrock-agentcore:...",
    payload='{"input": "hello"}'
)

For OAuth (browser or curl), pass the JWT as a Bearer token:

curl -X POST https:///runtimes//invocations \
  -H "Authorization: Bearer " \
  -H "Content-Type: application/json" \
  -d '{"input": "hello"}'

*Note: When using the client_credentials grant in Amazon Cognito, the JWT contains a client_id claim but no aud claim. Configure the AgentCore OAuth authorizer with allowedClients (which matches client_id) instead of allowedAudience.*

Pattern 2 trade-offs

Aspect

Impact

Latency

No Lambda latency overhead, direct passthrough.

Cost

No additional compute cost.

Complexity

Minimal components, ALB + VPC Endpoint only.

Flexibility

No request transformation capability.

Closing the direct-access backdoor with resou