Purpose
A persisted, filterable record of every S3 request against this Relayer — who did
what to which object, allowed or denied, with HTTP status.
When you use it
- Investigating “who deleted that file?”
- Debugging a client that’s getting errors.
- Compliance review / exporting activity.
Controls
- Durability banner — one of three states depending on the store: “Audit
records are persisted to disk. Durable since <UTC timestamp>.” when durable;
“No durable records yet…” when durable-but-empty; or a memory-only warning
(“held in memory and will be lost on service restart”) otherwise. - Export CSV — downloads the current tab’s rows (badge shows the row count).
The Denied tab exports its denied slice; every other tab exports the shared
filtered set. Capped at 25,000 rows, with a notice when the cap is hit. - Tabs: All Events (count) · By Principal · By Object · Denied (count
badge). By Principal and By Object have no count. - Filters: Principal (user name) · Resource (path) · Action · Result
(All / Allow / Deny — there is no AUTH_FAILED option) · Write method
(“Changes only” hides GET/HEAD reads; the sub-label reads PUT·POST·DELETE) ·
Time range (Last 1h / 24h / 7d / Custom, plus from/to date-time pickers) ·
Origin (disabled placeholder — “Available after durable audit lands”). - Denied tab extra: a notice lists principals with two or more denials as
clickable badges that filter to that principal. - Table columns: Timestamp · Principal (
ownerfor the built-in install
credential) · Action (e.g.s3:PutObject) · Resource (ARN) · Result
(allow / deny badges; other values such as AUTH_FAILED render unstyled) ·
Status (HTTP code).
Common tasks
- Trace an object’s history: By Object tab, or filter Resource by its path.
- See only writes: tick “Changes only”.
- Audit failed access: Denied tab, or Result = Deny — and read the Gotchas
entry below about AUTH_FAILED.
Gotchas
- AUTH_FAILED vs DENY: requests with valid credentials that a policy refused
show as DENY; requests whose authentication failed show as AUTH_FAILED. The
Denied tab counts and shows only rows whose result is exactlydeny— its
count badge and its table both exclude AUTH_FAILED. During credential problems
the Denied tab can read 0/low while All Events is full of AUTH_FAILED rows, and
the Result dropdown has no AUTH_FAILED option to filter by — scan or filter All
Events by principal/resource instead when hunting credential issues. - Rows for buckets named
probe-bsign-…are the gateway’s own health self-probes,
not user traffic. - ALLOW with HTTP 404 is normal — an allowed request for something that doesn’t
exist (e.g. a client checking for an object before upload).
Screenshots
