← Agent Frameworks 🕐 14 min read
Agent Frameworks

Bedrock Guardrails — Cost Patterns and FinOps Governance (2026)

TL;DR · March 2026

Bedrock Guardrails charges separately from inference tokens — per text unit (1,000 characters), per image, or per policy check — and those charges multiply per active policy per request side (input +

Bedrock Guardrails charges separately from inference tokens — per text unit (1,000 characters), per image, or per policy check — and those charges multiply per active policy per request side (input + output). At production scale a single chatbot application can spend more on guardrails than on the underlying model. Cross-account enforcement shipped GA in April 2026 and changes the multi-account governance picture significantly. CUR does not expose a dedicated guardrail usage type; cost attribution requires CloudWatch metrics or model invocation logs joined to CUR at the model/operation grain.

1. Pricing Model — Text Units, Image Units, and Policy Tiers

1.1 Text Unit Definition

One text unit = up to 1,000 characters of input or output text passed through guardrail evaluation. Text exceeding 1,000 characters is broken into multiple units, each billed at the same per-unit rate. Whitespace and punctuation count toward the character total.

1.2 Per-Policy Pricing (Standard and Classic Tiers)

AWS confirmed in the official pricing page that Standard and Classic tiers carry the same per-unit guardrail rate. Classic tier offers lower latency with reduced detection accuracy; the cost structure is identical.

Policy Type Cost per 1,000 Text Units Notes
Content filters (text) $0.15 Hate, insults, sexual, violence, misconduct, prompt attack
Denied topics $0.15 KNN semantic matching against topic definitions
Sensitive information filters (ML-based) $0.10 PII entity detection (names, SSN, credit cards, etc.)
Sensitive information filters (regex) Free Custom regex patterns only
Contextual grounding checks $0.10 Grounding + relevance scoring for RAG outputs
Automated Reasoning checks $0.17 per policy per 1,000 text units Not supported in enforcement guardrails
Word filters Free Exact-match word/phrase blocklist

InvokeGuardrailChecks API (separate lightweight endpoint, text-only):

Policy Type Cost per 1,000 Text Units
Content filters $0.07
Prompt attack $0.08
Sensitive information filters $0.10

The InvokeGuardrailChecks endpoint is approximately 50% cheaper than full inference-coupled evaluation for content and prompt-attack checks, at the cost of not supporting contextual grounding or denied topics.

1.3 Image Unit Pricing

Policy Type Cost per Image
Content filters (image) $0.00075

Image content filtering (multimodal toxicity detection) entered preview via a separate charge per image processed, regardless of image dimensions. There is no character-count equivalent for images; each image is one billable unit. At $0.75 per 1,000 images, image guardrail cost is lower than text guardrail cost for typical vision workloads — but a vision pipeline processing 100 images/second generates $270/hour in image guardrail charges alone if content filters are enabled.

1.4 December 2024 Price Reduction Context

Before December 2024, text guardrail policies were priced at $0.75/1,000 text units — 5× the current rate. The 80–85% reduction makes guardrails cost-viable at moderate scale but does not change the multiplicative billing structure. Cost models built on pre-December 2024 pricing are materially wrong and should be rerun.

2. How Guardrails Appear in CUR

2.1 No Dedicated Guardrail Usage Type in CUR

As of June 2026, Bedrock CUR does not emit a distinct line_item_usage_type for guardrail evaluation separate from the inference call that triggered it. Guardrail charges are bundled with or alongside the model invocation line items. The CUR usage type format for Bedrock inference is:

{region}-{model}-{token-type}
{region}-{model}-{token-type}-{tier}          # priority or flex tier
{region}-{model}-mantle-{token-type}-standard  # bedrock-mantle endpoint
{region}-{model}-{token-type}-cross-region-global

Examples: USE1-Claude4.6Sonnet-input-tokens, USE1-Nova2.0Lite-input-tokens-flex

Guardrail policy evaluation costs do not appear as separate line items with a guardrail segment in line_item_usage_type. This is the most common source of confusion when trying to reconcile guardrail spend.

2.2 Where Guardrail Cost Actually Lives

Guardrail charges surface in billing through two mechanisms:

  1. Blended into the inference line item when guardrails are applied inline via InvokeModel, Converse, or ConverseStream — the guardrail evaluation cost is aggregated alongside the request in the same billing period, but you cannot separate it without the GuardrailUsage response fields from model invocation logs.

  2. As a distinct ApplyGuardrail API call when using the standalone API — this appears as a separate operation (ApplyGuardrail) under the line_item_operation column in CUR 2.0, which enables cost isolation.

2.3 CUR Columns Relevant to Guardrail Cost Attribution

CUR 2.0 Column Value for Standalone Guardrail Use
line_item_product_code AmazonBedrock
line_item_operation ApplyGuardrail (standalone API only)
line_item_usage_type Region-prefixed; no model component for standalone calls
line_item_iam_principal IAM ARN of the caller (CUR 2.0 only)
line_item_unblended_cost Dollar cost

Important: CUR aggregates by usage type, operation, and pricing dimension per hour or per day — it does not emit per-request line items. You cannot tie a CUR line item to a specific conversation or user without joining to model invocation logs via the model/operation grain.

2.4 CUR Athena Query — Isolate ApplyGuardrail Spend

This query isolates standalone ApplyGuardrail API cost and computes it as a percentage of total Bedrock spend for the same account and period:

-- Guardrail cost as % of total Bedrock inference spend
-- Requires CUR 2.0 (AWS Data Exports) with AmazonBedrock product
WITH bedrock_total AS (
  SELECT
    DATE_TRUNC('day', line_item_usage_start_date)       AS usage_date,
    line_item_usage_account_id                          AS account_id,
    SUM(line_item_unblended_cost)                       AS total_bedrock_cost
  FROM cur2_database.cur2_table
  WHERE line_item_product_code = 'AmazonBedrock'
    AND line_item_usage_start_date >= DATE_ADD('day', -30, CURRENT_DATE)
  GROUP BY 1, 2
),
guardrail_spend AS (
  SELECT
    DATE_TRUNC('day', line_item_usage_start_date)       AS usage_date,
    line_item_usage_account_id                          AS account_id,
    SUM(line_item_unblended_cost)                       AS guardrail_cost,
    SUM(line_item_usage_amount)                         AS guardrail_units
  FROM cur2_database.cur2_table
  WHERE line_item_product_code = 'AmazonBedrock'
    AND line_item_operation     = 'ApplyGuardrail'
    AND line_item_usage_start_date >= DATE_ADD('day', -30, CURRENT_DATE)
  GROUP BY 1, 2
)
SELECT
  g.usage_date,
  g.account_id,
  g.guardrail_cost,
  g.guardrail_units,
  t.total_bedrock_cost,
  ROUND(100.0 * g.guardrail_cost / NULLIF(t.total_bedrock_cost, 0), 2) AS guardrail_pct_of_bedrock
FROM guardrail_spend  g
JOIN bedrock_total    t USING (usage_date, account_id)
ORDER BY g.usage_date DESC, guardrail_pct_of_bedrock DESC;

For inline guardrails (not standalone API), cost attribution requires joining model invocation logs to CUR at the model + hour grain, then using the GuardrailUsage object fields (contentPolicyUnits, topicPolicyUnits, sensitiveInformationPolicyUnits, contextualGroundingPolicyUnits) to apportion cost:

-- Multi-policy guardrail cost estimate from invocation logs
-- Assumes logs are in an Athena-queryable table (e.g., via S3 + Glue)
SELECT
  DATE_TRUNC('hour', timestamp)                               AS hour,
  model_id,
  COUNT(*)                                                     AS requests,
  SUM(guardrail_usage.content_policy_units)   * 0.00015       AS content_filter_cost,
  SUM(guardrail_usage.topic_policy_units)     * 0.00015       AS denied_topic_cost,
  SUM(guardrail_usage.sensitive_info_units)   * 0.00010       AS pii_cost,
  SUM(guardrail_usage.grounding_policy_units) * 0.00010       AS grounding_cost,
  SUM(
    guardrail_usage.content_policy_units   * 0.00015 +
    guardrail_usage.topic_policy_units     * 0.00015 +
    guardrail_usage.sensitive_info_units   * 0.00010 +
    guardrail_usage.grounding_policy_units * 0.00010
  )                                                            AS total_guardrail_cost_est
FROM bedrock_invocation_logs
WHERE timestamp >= DATE_ADD('day', -7, CURRENT_DATE)
  AND guardrail_id IS NOT NULL
GROUP BY 1, 2
ORDER BY total_guardrail_cost_est DESC;

3. Cost-Per-Request Overhead — Benchmarks

3.1 Latency Overhead

AWS evaluates all active guardrail policies in parallel, not sequentially. This means enabling 5 policies has roughly the same latency impact as enabling 2. The practical implication: once you pay the guardrail tax, adding more policies is nearly free from a latency perspective.

Configuration Latency Overhead Notes
No guardrails (baseline) 0 ms Reference
Single regex PII filter ~0.4 ms Negligible
Single ML PII filter (standard tier) 300–500 ms AWS-reported range
Full enterprise suite (3–5 policies, standard) ~30% of base latency Parallel evaluation
Classic tier (same policies) Lower than standard Reduced accuracy

For a 2-second model response, the 30% overhead means ~600 ms of guardrail evaluation added per turn. For real-time conversational applications with p95 latency SLOs below 1 second, this is a material constraint.

3.2 Cost Overhead Per Request

Model: Claude Sonnet 4.6, 1,000 input characters (~250 tokens), 1,000 output characters (~250 tokens).

Each side is 1 text unit. With 3 paid policies active (content filter, denied topics, PII):

Input evaluation:  1 text unit × ($0.15 + $0.15 + $0.10) = $0.00040
Output evaluation: 1 text unit × ($0.15 + $0.15 + $0.10) = $0.00040
Total guardrail cost per request:                           $0.00080

Claude Sonnet 4.6 inference cost for same request (~250 input + ~250 output tokens):

  • Input: 250 × $0.000003 = $0.00075
  • Output: 250 × $0.000015 = $0.00375
  • Total inference: $0.00450

Guardrail overhead as % of inference: ~18% for a short-form conversational turn with 3 policies.

For longer context (10,000 input characters = 10 text units):

Guardrail cost per request: 10 × $0.00040 + 1 × $0.00040 = $0.00440
This approaches inference cost for shorter outputs.

3.3 Scale Cost Projection

Enterprise chatbot: 100,000 conversations/day × 8 turns × 3 active policies × dual evaluation (input + output):

Text units/day:       100,000 × 8 × 2 sides = 1,600,000 text units
                      Assumes avg 1 text unit per side
Content filter:       1,600,000 × $0.00015 = $240/day
Denied topics:        1,600,000 × $0.00015 = $240/day
PII detection:        1,600,000 × $0.00010 = $160/day
Total guardrails:                             $640/day = ~$19,200/month

Scaling to 5 apps × 3 regions = 15× multiplier: $288,000/month in guardrail charges from a mid-sized enterprise AI deployment. This commonly exceeds inference costs for shorter-context use cases.

4. Policy-Level Cost Components

4.1 Content Filters ($0.15/1,000 text units)

Applied to both input and output. Detects hate, insults, sexual content, violence, misconduct, and prompt attacks across configurable severity thresholds (NONE, LOW, MEDIUM, HIGH). Each text unit is evaluated against the full content filter matrix in one call; there is no per-category charge.

4.2 Denied Topics ($0.15/1,000 text units)

Uses KNN-based semantic similarity against administrator-defined topic descriptions (up to 30 topics per guardrail). More expensive per character than PII detection despite being a simpler task at first glance, because the semantic search runs against the full topic list per text unit. Alternative: prompt engineering with system-prompt topic restrictions costs $0 but catches fewer obfuscated attempts.

4.3 Sensitive Information Redaction ($0.10/1,000 text units for ML; free for regex)

The hybrid approach — regex patterns for known formats (SSN, credit cards, phone numbers) + ML entity detection for unstructured names and addresses — is the correct cost optimization. Regex PII detection has zero guardrail charge and adds <1 ms latency. ML-based PII adds 300–500 ms and $0.10/1,000 text units. Deploy regex-only for structured data fields; add ML detection only for free-form user input.

4.4 Contextual Grounding for RAG ($0.10/1,000 text units)

Evaluates two scores: grounding (response is supported by retrieved context) and relevance (response addresses the query). Both run in a single evaluation pass; there is one charge of $0.10/1,000 text units covering both scores. Applied to output text only — input is not evaluated for grounding. This is the cheapest paid policy per text unit.

4.5 Automated Reasoning Checks ($0.17 per policy per 1,000 text units)

The most expensive policy type and the outlier. Automated reasoning is explicitly unsupported in enforcement guardrails (cross-account and account-level enforcement) — enabling it in an enforcement guardrail causes runtime failures. For workloads with formal compliance requirements (financial services, healthcare), it is evaluated per-policy: a guardrail with 3 automated reasoning policies costs $0.51/1,000 text units for that policy layer alone.

4.6 Word Filters and Regex Patterns (Free)

No charge for word/phrase blocklists or regex-based PII patterns. These are the first line of defense for known-format violations and should always be configured before activating paid ML policies.

5. ApplyGuardrail API vs. Inline Converse Guardrails

5.1 Inline Guardrails (Converse / InvokeModel)

Guardrail configuration is passed in the request body:

response = bedrock_runtime.converse(
    modelId="anthropic.claude-sonnet-4-6-20251201-v1:0",
    messages=messages,
    guardrailConfig={
        "guardrailIdentifier": "abc123guardrailid",
        "guardrailVersion":    "1",
        "trace":               "enabled"
    }
)

The guardrail evaluation runs as part of the inference pipeline:

  • If input is blocked → you pay guardrail cost only; no inference charge.
  • If output is blocked → you pay guardrail cost for input + output, plus full inference cost.
  • If request passes → you pay guardrail cost for input + output, plus full inference cost.

Cost implication: When input block rate is high (e.g., adversarial users), inline guardrails save inference cost because blocked inputs never reach the model.

5.2 ApplyGuardrail API (Standalone)

response = bedrock_runtime.apply_guardrail(
    guardrailIdentifier="abc123guardrailid",
    guardrailVersion="1",
    source="INPUT",   # or "OUTPUT"
    content=[{"text": {"text": user_input}}]
)

The standalone API allows pre-checking content against any guardrail before routing to a model — including non-Bedrock models. Use cases:

  • Applying Bedrock Guardrails to OpenAI, Vertex AI, or self-hosted models via LiteLLM
  • Asynchronous post-processing of stored content
  • A/B testing guardrail configurations without model invocations

Cost difference: When used alongside Bedrock inference, the standalone API charges guardrail evaluation twice — once for the explicit ApplyGuardrail call and again if the request also passes guardrailConfig inline. Most users discover this double-billing only when reviewing CUR.

Sequential pattern to avoid double-billing:

# Step 1: check input
check = bedrock_runtime.apply_guardrail(
    guardrailIdentifier="abc123",
    guardrailVersion="1",
    source="INPUT",
    content=[{"text": {"text": user_input}}]
)
if check["action"] == "GUARDRAIL_INTERVENED":
    return blocked_response()

# Step 2: invoke model WITHOUT inline guardrailConfig
response = bedrock_runtime.converse(
    modelId="...",
    messages=messages
    # no guardrailConfig here — avoids double-charging
)

# Step 3: check output
output_check = bedrock_runtime.apply_guardrail(
    source="OUTPUT",
    content=[{"text": {"text": response["output"]["message"]["content"][0]["text"]}}],
    ...
)

This pattern costs the same as inline guardrails but gives the caller explicit control over which content is evaluated and when.

5.3 InvokeGuardrailChecks API

The newest endpoint (2025) is a lightweight alternative to ApplyGuardrail that supports only content filters and prompt-attack detection. Pricing is 50–53% cheaper:

ApplyGuardrail InvokeGuardrailChecks
Content filters $0.15/1K text units $0.07/1K text units
Prompt attack $0.15/1K text units $0.08/1K text units
Denied topics $0.15/1K text units Not supported
PII filters $0.10/1K text units $0.10/1K text units

For workloads that only need content filtering (no topic detection or grounding), InvokeGuardrailChecks delivers 53% cost reduction on that policy layer.

6. TRACE Mode — Cost Impact

Enabling "trace": "enabled" in the guardrailConfig returns a GuardrailTrace object with per-policy assessment details, confidence scores, matched entities, and action taken per policy. This is critical for debugging false positives and tuning thresholds.

TRACE mode does not add cost. The evaluation runs regardless of whether trace data is returned; trace output is metadata attached to the same evaluation pass. The line_item_unblended_cost is identical with trace enabled vs. disabled.

However, trace output materially increases response payload size (50–500 KB per request depending on policy count and matched entities). At scale this affects:

  • API Gateway payload limits (10 MB max)
  • Lambda response size constraints
  • CloudWatch log ingest cost if traces are logged (CloudWatch Logs: $0.50/GB ingest)

Recommendation: Enable TRACE in non-production environments for tuning. In production, enable selectively via sampling (e.g., log traces for 5% of requests or only on GUARDRAIL_INTERVENED responses) to contain CloudWatch ingest costs.

7. LiteLLM Guardrails Integration

7.1 LiteLLM Proxy Configuration

LiteLLM proxy supports Bedrock Guardrails as a named guardrail in config.yaml. The guardrail runs pre-call, post-call, or during-call depending on the mode setting:

# litellm config.yaml
model_list:
  - model_name: bedrock-claude-sonnet
    litellm_params:
      model: bedrock/anthropic.claude-sonnet-4-6-20251201-v1:0
      aws_region_name: us-east-1

guardrails:
  - guardrail_name: "enterprise-content-guard"
    litellm_params:
      guardrail: bedrock
      mode: "during_call"
      guardrailIdentifier: "abc123guardrailid"
      guardrailVersion: "1"
      aws_region_name: us-east-1
      aws_role_name: os.environ/GUARDRAIL_ROLE_ARN

  - guardrail_name: "pii-redaction"
    litellm_params:
      guardrail: bedrock
      mode: "pre_call"
      guardrailIdentifier: "xyz789piiguardrail"
      guardrailVersion: "DRAFT"
      mask_request_content: true
      mask_response_content: true
      aws_region_name: us-east-1

7.2 Applying Guardrails to Non-Bedrock Models

The key use case for LiteLLM + Bedrock Guardrails: apply AWS safety controls to OpenAI, Anthropic direct, or self-hosted model calls. LiteLLM calls ApplyGuardrail via the Bedrock SDK before forwarding the request to the target model provider.

model_list:
  - model_name: gpt-4o
    litellm_params:
      model: openai/gpt-4o
      api_key: os.environ/OPENAI_API_KEY

guardrails:
  - guardrail_name: "cross-provider-guard"
    litellm_params:
      guardrail: bedrock
      mode: "during_call"
      guardrailIdentifier: "abc123guardrailid"
      guardrailVersion: "1"
      aws_region_name: us-east-1

Bedrock guardrail charges accrue to your AWS account even when the downstream model is not Bedrock. This is how enterprises apply a single approved guardrail policy across multi-provider LLM deployments.

7.3 Cost Tracking in LiteLLM

LiteLLM’s built-in cost tracking does not automatically account for Bedrock Guardrail API charges — it tracks model inference cost only. Guardrail costs must be tracked separately via:

  1. AWS Cost Explorer filtered to line_item_operation = ApplyGuardrail
  2. CloudWatch metric: aws/bedrock/guardrails/GuardrailInvocations per guardrail ARN
  3. Custom callback in LiteLLM to log guardrail response metadata and compute estimated cost from GuardrailUsage units

Cost optimization parameter: experimental_use_latest_role_message_only: true in LiteLLM’s guardrail params sends only the most recent message to the guardrail instead of the full conversation history. For multi-turn conversations this reduces text units evaluated per call — important for RAG applications with large retrieved context.

7.4 Guardrail Error Handling in LiteLLM

By default, LiteLLM raises an exception when a guardrail blocks a request, which breaks the OpenAI-compatible API contract. Use disable_exception_on_block: true to return HTTP 200 with a structured block response instead:

guardrails:
  - guardrail_name: "enterprise-content-guard"
    litellm_params:
      guardrail: bedrock
      mode: "during_call"
      guardrailIdentifier: "abc123guardrailid"
      guardrailVersion: "1"
      disable_exception_on_block: true  # Returns 200 with block metadata

8. Cost Optimization Strategies

8.1 Policy Selection Decision Tree

Does the risk require semantic understanding?
├── No: Use free word/regex filters. Stop here.
└── Yes:
    ├── Is the risk a known topic category? → Denied Topics ($0.15)
    ├── Is the risk harmful content (hate/sexual/violence)? → Content Filters ($0.15)
    ├── Does output reference source documents? → Contextual Grounding ($0.10)
    ├── Is PII present in structured fields? → Regex PII (free)
    └── Is PII in free-form text? → ML PII detection ($0.10)

8.2 KNN Topic Detection vs. Regex for Denied Topics

Denied Topics use KNN semantic similarity — they catch paraphrased and obfuscated attempts but cost $0.15/1,000 text units. Regex-based word filters are free but miss semantic variants (“How do I make a bomb” vs. “Give me instructions for synthesizing an explosive device”).

Threshold for switching: If your blocked-request rate from regex alone is below 0.1% and the adversarial risk is low (internal tooling, authenticated employees), stay with free word filters. If the application faces anonymous public users or red-team testing shows >5% bypass rate on word filters, the $0.15/1,000 text units for denied topics is justified.

8.3 Sequential Evaluation Pattern

Run ApplyGuardrail on input before calling the model. On block, return early — no inference cost. This reduces total cost when input block rate is significant:

Break-even: guardrail_cost_per_request < model_cost_per_blocked_request × block_rate
At $0.00080 guardrail overhead and $0.0045 model inference:
Break-even block rate = $0.00080 / $0.0045 ≈ 17.8%

If more than ~18% of requests would be blocked, sequential evaluation is cheaper than inline despite the added latency of the pre-check round trip.

8.4 Tier Selection: Standard vs. Classic

Both tiers cost the same per text unit. Classic tier offers lower latency (useful for p95 SLOs) at the cost of reduced detection accuracy. For customer-facing applications where adversarial users are common, Classic tier’s accuracy tradeoff is not worth the latency savings. For internal tooling with authenticated users and low adversarial risk, Classic tier reduces end-to-end latency without increasing cost.

8.5 InvokeGuardrailChecks for Content-Only Workloads

If the guardrail use case is prompt injection and content filtering only (no PII, no denied topics, no grounding), switch to InvokeGuardrailChecks. This delivers 53% cost reduction on content filter evaluation:

  • ApplyGuardrail content filter: $0.15/1,000 text units
  • InvokeGuardrailChecks content filter: $0.07/1,000 text units

At 1,000,000 text units/month: $150 → $70, saving $80/month per application.

9. Multi-Account Guardrails Governance

9.1 Architecture: Three-Layer Model

As of April 2026 (GA), Bedrock supports three simultaneous guardrail layers per request:

Organization policy (management account)
    └── Account enforcement (per-account, per-region)
            └── Application guardrail (per-request, inline or API)

All three layers evaluate concurrently. The effective policy is the union of all active guardrails with the most restrictive setting taking precedence for any shared policy type.

9.2 Organization-Level Enforcement

Set via AWS Organizations BEDROCK_POLICY policy type. Configuration is defined in the management account and propagated to member accounts or OUs automatically.

Key constraints:

  • Automated Reasoning checks cannot be used in enforcement guardrails (causes runtime failures)
  • Guardrail must be versioned (a numeric version, not DRAFT) to be used in enforcement
  • The guardrail ARN in the Organizations policy must be correct; an invalid ARN blocks all Bedrock inference for affected accounts with no graceful fallback

Billing: Guardrail charges for organization-enforced guardrails accrue to the member account making the API call, not the management account that owns the guardrail. This is the behavior many FinOps teams miss when first deploying centralized guardrails — the management account’s bill does not reflect the enforcement overhead.

9.3 Account-Level Enforcement

A single designated guardrail version is set per account per region via PutEnforcedGuardrailConfiguration. Applies to all Bedrock invocations from that account regardless of whether the caller specifies a guardrail in the request.

Use case: applying baseline data-loss-prevention controls to a dev/test account without requiring developers to configure guardrails in each application.

9.4 Centralized vs. Per-Account Cost Structure

Governance Model Guardrail Cost Owner Visibility
Org-level enforcement Member accounts (each pays their own guardrail charges) Management account has no direct cost visibility; must aggregate from member CURs
Account-level enforcement The account where enforcement is configured Visible in that account’s CUR under ApplyGuardrail operation
Per-application inline The account making inference calls CUR line item with IAM principal attribution in CUR 2.0

For multi-account visibility, the correct approach is CUR 2.0 with multi-account aggregation (AWS Data Exports), filtered to line_item_product_code = 'AmazonBedrock', grouped by line_item_usage_account_id. Guardrail-related charges surface at the member account level.

9.5 Multi-Account Guardrails Governance Athena Query

Aggregate Bedrock guardrail cost across all member accounts in an AWS Organization using a consolidated CUR:

-- Cross-account Bedrock guardrail spend (org-level view)
-- Requires consolidated CUR 2.0 with all member accounts
SELECT
  line_item_usage_account_id                               AS account_id,
  DATE_TRUNC('month', line_item_usage_start_date)          AS month,
  SUM(CASE
        WHEN line_item_operation = 'ApplyGuardrail'
        THEN line_item_unblended_cost
        ELSE 0
      END)                                                  AS guardrail_api_cost,
  SUM(CASE
        WHEN line_item_product_code = 'AmazonBedrock'
        THEN line_item_unblended_cost
        ELSE 0
      END)                                                  AS total_bedrock_cost,
  ROUND(
    100.0 * SUM(CASE
                  WHEN line_item_operation = 'ApplyGuardrail'
                  THEN line_item_unblended_cost ELSE 0
                END) /
    NULLIF(SUM(CASE
                 WHEN line_item_product_code = 'AmazonBedrock'
                 THEN line_item_unblended_cost ELSE 0
               END), 0),
    2
  )                                                         AS guardrail_pct
FROM cur2_database.cur2_table
WHERE line_item_product_code = 'AmazonBedrock'
  AND line_item_usage_start_date >= DATE_TRUNC('month', DATE_ADD('month', -3, CURRENT_DATE))
GROUP BY 1, 2
ORDER BY month DESC, guardrail_api_cost DESC;

10. CloudWatch Monitoring for Guardrail Cost Proxies

CUR provides dollar-level aggregation; CloudWatch provides real-time guardrail invocation signals. Useful guardrail CloudWatch metrics under AWS/Bedrock:

Metric Dimension Use
GuardrailInvocations GuardrailId, Action Volume of evaluations; proxy for text units billed
GuardrailInterventions GuardrailId, PolicyType Count of block/mask/anonymize actions per policy
InvocationLatency GuardrailId p50/p95/p99 latency per guardrail
TextUnitsProcessed GuardrailId Direct text unit count (multiply by per-policy rate for cost)

Alert threshold recommendation: InvocationLatency p95 > 500 ms indicates guardrail processing pressure. GuardrailInterventions / GuardrailInvocations > 20% may indicate a misconfigured topic definition creating false positives.

Key FinOps Decision Points

  1. Guardrail costs are multiplicative. Each active paid policy × each text unit × each request side (input/output). A request touching 3 paid policies costs 3× the per-unit rate per side. Switching from 3 policies to 1 cuts guardrail cost by 67% at the same request volume.

  2. CUR alone is insufficient for guardrail attribution. Inline guardrail charges are not separable from inference in CUR without joining to model invocation logs. Standalone ApplyGuardrail calls are separable via line_item_operation.

  3. Cross-account enforcement charges member accounts, not the management account. This is architecturally correct but creates a FinOps surprise when security teams deploy org-wide guardrails without informing business-unit account owners.

  4. TRACE mode adds no cost but generates large CloudWatch log payloads. Disable in production; re-enable for incident investigation.

  5. LiteLLM cost tracking does not capture guardrail charges. A full TCO model for LiteLLM proxy must separately attribute Bedrock Guardrail API calls in AWS billing.

  6. Pre-December 2024 cost models are wrong by 5×. Any guardrail cost estimate built before the December 2024 price reduction should be discarded.

Sources