# Bedrock Invocation Logging Disabled

> 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.

Source: https://zop.dev/integrations/aws/recommendations/bedrock-invocation-logging-disabled
Updated: 2026-08-19

---

## 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

```bash
aws bedrock get-model-invocation-logging-configuration --region us-east-1
```

An 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.