Provisioned throughput running in regions with Bedrock invocation logging off
What does ZopNight detect here?
Model invocation logging is 1 account-level switch per region, yet its absence is surfaced against each provisioned throughput so the gap appears where model owners actually work. Without it there is no prompt/response record for audit, abuse investigation, or usage analysis, and enabling it changes nothing about the model bill.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1609 |
| Category | governance |
| Severity | low |
| Metric | none — pure configuration read |
| Source | bedrock_invocation_logging.go |
An account setting, reported per resource
Bedrock’s invocation logging is configured once per account and region, not per model, not per throughput. ZopNight still attaches the finding to each provisioned throughput in an unlogged region, which looks odd until you consider who reads recommendation lists: the team that owns a PT sees the gap next to their resource and can escalate it, whereas an account-level finding belongs to everyone and therefore to no one. Fixing the one switch clears the finding from every PT in the region simultaneously.
What is lost while it is off
With logging disabled, prompts and responses pass through Bedrock and vanish. That forecloses three things organisations discover they needed only after the fact: auditability (what did the model actually say to a customer in an incident), abuse detection (who is probing the model with jailbreak attempts), and usage analysis such as prompt-cache hit studies that need real traffic to reason about. Provisioned throughput implies sustained production traffic, which is precisely the traffic least sensible to run unrecorded.
Evidence and abstention
Discovery calls the region’s logging-configuration API once and stamps the result onto each PT as an explicit boolean. The rule fires only when that field is present and false. A PT whose metadata lacks the field (the probe failed or was denied) produces no finding: an unverified region is never reported as unlogged. Severity is low and the dollar value is zero; this is governance, and the rule does not pretend otherwise.
Check a region’s configuration
aws bedrock get-model-invocation-logging-configuration --region us-east-1An empty response means logging is not configured; a populated one shows the destination and which data types are captured.
Enabling it with the right destination
Pick CloudWatch Logs for queryability or S3 for cheap long retention (both is allowed), call
put-model-invocation-logging-configuration, and validate with a test invocation. The logs
contain full prompts and responses. Treat the destination as sensitive data with retention
and access policies to match, since the same record that enables auditing is itself a store
of whatever your users typed.