AWS Bedrock Guardrails Pricing: Filters, Text Units, and Total Cost
AWS Bedrock Guardrails pricing is additive by safeguard. Text content is divided into units of up to 1,000 characters, image filtering is metered per image, and enabled filters create separate charge lines. The total also includes model inference and any independent ApplyGuardrail calls. Logging and testing add costs, as does application work. Accurate estimates therefore start with characters processed on each request and response, then apply the exact safeguards enabled.
AWS Bedrock Guardrails pricing adds the charges for each safeguard applied to content. The Amazon Bedrock pricing page defines a text unit as up to 1,000 characters. A 5,600-character input becomes six text units. Content filters and denied topics can each add a separate metered line. The same applies to sensitive-information detection and contextual grounding. Automated Reasoning can add another line.
That arithmetic makes request count a poor budget unit. The same 10,000 requests can carry short chat prompts or multi-page transcripts, and a response can add more units than its input. I would reject a forecast that says only "one guardrail call per request." It omits the dimensions AWS actually bills.
TL;DR
- Bedrock Guardrails charges by enabled safeguard, with text usually metered in 1,000-character units.
- Input and output length both matter when the guardrail evaluates prompts and model responses.
- Image filters use a per-image meter; free regex and word filters can sit beside paid safeguards.
- Model inference and logs remain additional cost lines. So do retries and testing, along with application integration.
The safeguard-by-safeguard meter
AWS states that Guardrails pricing is based on the filters used and is the same for its Standard and Classic tiers. The public schedule prices each 1,000 text units at $0.15 for content filters and denied topics. Sensitive-information filters and contextual-grounding checks carry a listed rate of $0.10 for the same volume. Automated Reasoning checks cost $0.17 for 1,000 units under each policy.
Image content filtering uses a different meter, displayed as $0.00075 per image processed when reviewed on 11 October 2026. Regular-expression sensitive-information filters and word filters are listed as free. These figures come directly from the AWS page and should be rechecked for the deployment region and contract before approval.
The charging rule is additive. If one guardrail uses content filters and sensitive-information detection, both paid safeguards contribute to the charge. A disabled filter contributes no safeguard charge. The estimate therefore needs the guardrail configuration alongside traffic volume; monthly requests by themselves fail to reproduce the bill.
Text-unit rounding changes the estimate
Each text unit can contain up to 1,000 characters. AWS rounds longer inputs into blocks: the first 1,000 characters consume one unit, and adding character 1,001 requires a second. Input-size distribution matters when requests are numerous and short.
Count every segment the guardrail evaluates. If the application checks a user prompt before inference and checks the model response afterward, the monthly estimate includes units from both directions. The AWS Guardrails documentation says guardrails can evaluate input prompts and foundation-model completions against the configured filters.
Contextual grounding has a wider base. AWS combines characters in the reference source and query with characters in the model response to calculate its text units. A small user question attached to a long source passage may therefore carry a larger grounding charge than the prompt length suggests. The visible detail is a character counter rolling past 1,000 and opening another unit before the model invoice is considered.
A practical monthly model records:
- Evaluated input characters and rounded input units.
- Evaluated output characters and rounded output units.
- Images sent to image content filtering.
- Enabled paid safeguards on each route.
- Automated Reasoning policies applied to each eligible response.
- Retries and duplicate checks caused by application behavior.
ApplyGuardrail creates an independent call path
Bedrock can apply a guardrail during a supported model invocation. AWS also provides the ApplyGuardrail API, which assesses text independently of a foundation-model invocation. The application marks content as INPUT or OUTPUT and supplies a guardrail identifier and version.
The API response exposes usage fields for topic, content, word, sensitive-information, and contextual-grounding policy units. It also returns an action such as GUARDRAIL_INTERVENED or NONE. Those usage fields are useful for reconciliation because they show the units generated by the assessment rather than forcing finance to infer them from request count.
AWS publishes a separate schedule for the InvokeGuardrailChecks API. The pricing page puts text content at $0.07 per 1,000 units. Prompt-attack evaluation carries a $0.08 rate for that volume, while sensitive-information processing is listed at $0.10. AWS also notes that this API path can use prompt-attack filtering separately from content filters.
Architecture determines call count. An application might check input before retrieval and then run a model with a guardrail. It might also check a final response before display. Draw those calls as three boxes. Each box has its own evaluated content and enabled filters, even though the user experiences one interaction.
Model inference and supporting AWS services remain separate
Guardrail charges sit beside the foundation-model charge. Model input tokens, output tokens, provisioned throughput, or batch inference follow the selected Bedrock model's commercial terms. Guardrails use characters for their text-unit meter, so the model token counter and guardrail unit counter should remain separate ledgers.
CloudWatch logs, CloudTrail events, storage, data transfer, KMS use, and application compute may add costs under their own AWS schedules. The exact set depends on the logging and deployment design. AWS Bedrock audit logs are operationally useful, but storing and querying them belongs in the total-cost model.
Testing adds another line. Guardrail versions need representative prompts and expected responses. They also need regression runs after filter changes. Automated Reasoning policies need policy creation and maintenance. Sensitive-information patterns need false-positive review. These activities consume engineer and reviewer time even when a specific filter carries no usage charge.
My preferred budget separates model inference from Guardrails safeguards. It also tracks independent guardrail API calls and AWS logging and storage. Engineering and review operations form the final two totals. Blending them into one "Bedrock" number hides the source of a variance and makes configuration changes hard to price.
Provider controls and enterprise policy answer different questions
Amazon Bedrock Guardrails provides configurable content filters, denied topics, word filters, sensitive-information handling, contextual-grounding checks, and Automated Reasoning for configured calls. AWS owns those filter definitions and returns the assessment generated inside the Bedrock service. That is the provider-control layer.
Enterprise authorization can require a different decision: may this authenticated user or agent send this classified content to this model route under the current organizational policy? The answer depends on identity and policy context supplied by the application. Bedrock's filter result can become one input to that decision, but a harmful-content score alone lacks the caller's enterprise entitlement.
The distinction is architectural rather than competitive. DeepInspect vs Bedrock Guardrails covers the control boundaries, and model guardrails explains why model-side safety and request-layer authorization serve different roles. Teams can retain both where an HTTP request deliberately passes through an enterprise policy proxy before reaching Bedrock.
Budget controls that survive production traffic
Tag the guardrail identifier and version in cost and usage records. Export the usage fields returned by independent assessments. Split request and response units because response length often varies more than prompt length. Keep separate route profiles for chat, document summarization, RAG, image moderation, and automated reasoning.
Set alerts on units by safeguard rather than calls alone. A sudden rise in contextual-grounding units may come from larger retrieved sources. A rise in content-filter units may come from longer generated answers. Neither change requires more users.
Finally, test the forecast with real character distributions. Averages conceal the rounding effect at each 1,000-character boundary. A sample with p50 and p95 input and output sizes gives procurement a range that matches the production shape and lets engineering explain the AWS bill without opening every individual trace.
DeepInspect
DeepInspect governs authenticated user or agent traffic that an application deliberately routes through its HTTP proxy. It evaluates supplied identity, route, data classification, and policy context before forwarding an allowed request. It can record the policy decision beside the Bedrock guardrail identifier and AWS correlation data.
DeepInspect leaves AWS's text units, image checks, enabled-filter charges, model inference, and logging costs intact. Bedrock Guardrails remains responsible for its configured AWS safeguards. DeepInspect supplies the separate enterprise authorization decision and per-decision record for the routed request.
Book a technical deep dive at deepinspect.ai.