Bedrock guardrails with no DRAFT-version invocations in 30 days

A guardrail that filters nothing is a policy gap, not a bill

Bedrock Guardrails are billed by use. The Bedrock pricing page charges per 1,000 text units for most filter types (word filters are free), where a text unit holds up to 1,000 characters. A guardrail no model call references costs nothing, so the concern here is different: someone built a content or PII policy, and production traffic may be skipping it.

Seeing guardrail usage yourself

Listing without an identifier returns the DRAFT version of every guardrail; passing a guardrail ARN lists all of its versions:

aws bedrock list-guardrails \
  --query 'guardrails[].[id,name,version,status,updatedAt]' --output table

aws bedrock list-guardrails --guardrail-identifier GUARDRAIL_ARN \
  --query 'guardrails[].[version,status]'

Guardrail metrics live in the AWS/Bedrock/Guardrails namespace, dimensioned by GuardrailArn and GuardrailVersion (guardrail metrics reference). Check each version you publish, not just DRAFT:

aws cloudwatch get-metric-statistics --namespace AWS/Bedrock/Guardrails \
  --metric-name Invocations \
  --dimensions Name=GuardrailArn,Value=GUARDRAIL_ARN Name=GuardrailVersion,Value=1 \
  --start-time 2026-08-26T00:00:00Z --end-time 2026-09-25T00:00:00Z \
  --period 86400 --statistics Sum

The evidence behind a finding

ZopNight reads the Invocations series for the guardrail’s DRAFT version over 30 days. The finding appears when that series shows no activity, or when there is no series at all, since CloudWatch records nothing for a guardrail nobody calls. Any invocation in it clears the guardrail, and if ZopNight holds no metrics for the account at all, it stays silent.

The version blind spot to check before deleting

AWS recommends creating a numbered version when a guardrail is ready for production and invoking that version from the application. Those calls are recorded under the version string, for example 1, never under DRAFT. ZopNight only sees the DRAFT series today, so a guardrail that is used in production purely through a numbered version will still appear here as unused. The finding text says so, and the remediation asks you to confirm real usage first.

Why the saving reads $0

With no standing charge, deleting an unused guardrail saves roughly nothing. The finding is an advisory with a concrete choice: wire the guardrail into the calls it was built for, or remove it so the inventory reflects which policies are actually enforced.

Resolving an unused guardrail

1. Identify the model invocations this guardrail was designed to protect.
2. Check every published version’s Invocations metric, as shown above.
3. Either attach the guardrail to those calls (preferred for production models) or delete it with aws bedrock delete-guardrail --guardrail-identifier GUARDRAIL_ARN.
4. Record an owner for each remaining guardrail so policy does not drift.