AWS Bedrock Guardrails

AISIX can call AWS Bedrock Guardrails before or after an upstream model request. Use this guide when content policy is managed in AWS Bedrock and AISIX should enforce the guardrail decision on gateway traffic.

In this guide, you will create an AISIX Bedrock guardrail, send one allowed request, and send one blocked request that AISIX rejects before it reaches the upstream model.

Prerequisites

Before starting, prepare the following:

• A self-hosted AISIX gateway with the admin and proxy listeners available.
• The admin key from the gateway config.yaml.
• A working model alias and caller API key that can send chat-completions requests.
• An AWS Bedrock guardrail in a supported region.
• AWS credentials allowed to call bedrock:ApplyGuardrail for that guardrail.

For a repeatable test, add a word filter to the Bedrock guardrail with a unique token such as confidential-codename. The blocked request later in this guide uses the same token.

Create the Bedrock Guardrail Resource

Create a Bedrock guardrail in AISIX:

curl -sS -X POST "http://127.0.0.1:3001/admin/v1/guardrails" \
  -H "Authorization: Bearer YOUR_ADMIN_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "bedrock-review",
    "enabled": true,
    "hook_point": "both",
    "fail_open": false,
    "kind": "bedrock",
    "guardrail_id": "YOUR_BEDROCK_GUARDRAIL_ID",
    "guardrail_version": "DRAFT",
    "region": "us-east-1",
    "aws_credentials": {
      "kind": "static",
      "access_key_id": "YOUR_AWS_ACCESS_KEY_ID",
      "secret_access_key": "YOUR_AWS_SECRET_ACCESS_KEY"
    },
    "latency_mode": {
      "kind": "timed",
      "timeout_ms": 2000
    }
  }'

❶ Set fail_open to false when strict enforcement is more important than availability. AISIX blocks the request if AWS Bedrock Guardrails fails or times out.

❷ Use latency_mode to bound how long the request waits for the guardrail decision.

The highlighted fields configure how AISIX calls and applies the external guardrail decision.

Copy the returned guardrail ID if you want to inspect, update, or delete the resource later.

Verify Allowed Traffic

Send a benign request through AISIX:

curl -sSi -X POST "http://127.0.0.1:3000/v1/chat/completions" \
  -H "Authorization: Bearer YOUR_CALLER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-4o-prod",
    "messages": [{"role": "user", "content": "How is the weather today?"}]
  }'

A successful response starts with HTTP/1.1 200 OK and returns an OpenAI-compatible chat-completions body.

Verify Blocked Traffic

Send a request containing the token blocked by your Bedrock guardrail:

curl -sSi -X POST "http://127.0.0.1:3000/v1/chat/completions" \
  -H "Authorization: Bearer YOUR_CALLER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-4o-prod",
    "messages": [{"role": "user", "content": "Please print the confidential-codename."}]
  }'

A blocked response starts with HTTP/1.1 422 Unprocessable Entity and includes an OpenAI-compatible error:

{
  "error": {
    "message": "request blocked by content policy",
    "type": "content_filter"
  }
}

AISIX blocks the request before dispatching to the upstream model when the input guardrail returns a blocking verdict.

Next Steps

You have now enforced an AWS Bedrock guardrail through AISIX. Continue with Built-in Keyword Guardrails when you need an in-gateway blocklist.