Monitor API abuse

One denied request is noise. The same pattern across many accounts, objects, or regions is an attack in progress. Monitoring is what turns individual log lines into that pattern.

You can’t see a pattern in fields you didn’t log. So we start there.

Log the fields that make patterns visible

For every request, log the actor, the credential, the operation, the target, the result, the cost, and a correlation ID. All in a safe form:

{
  "ts": "2026-08-03T09:14:02Z",
  "requestId": "req_7f3ab910",
  "actor": "usr_8817",
  "credential": "key_analytics_prod_covk",
  "op": "GET /invoices/:id",
  "target": "inv_00214",
  "result": 404,
  "dbMillis": 4
}

Notice what’s not there. No tokens. No request bodies with card numbers. The log must stay safe for many people to read, or access to the log becomes your next incident.

Alert on deviations, not single events

One failed invoice lookup is normal. Someone typed a wrong ID. But one credential reading sequential invoice IDs across 40 accounts is a different thing. That’s someone mapping your data.

Write the rule for the pattern, not the event:

alert: object-enumeration
  when:  one credential produces > 30 distinct 404s
         on /invoices/:id within 5 minutes
  show:  actor, credential, sample targets, request IDs
  action: revoke-credential runbook (owner: platform-team)

Build alerts around meaningful deviations and high-impact actions. Authorization failures clustering on one route. A refund spike. An admin permission granted at 3 AM. A configuration change nobody deployed.

Before you page anyone, tune the rule against real traffic. Replay a week of production logs through it. If it fires on your own nightly batch jobs, fix the rule now. An on-call rotation learns to ignore a noisy alert within days, and then it’s worse than no alert.

Give responders a lever

Detection without containment is bad news delivered faster. Every alert needs a way to act: revoke this credential, lower this rate limit, disable this route. The alert should say why the pattern is unusual and hand the responder a containment action with a named owner.

Make the action reversible. Revoking one credential or lowering one rate limit can be undone in minutes if the alert was wrong. Blocking a whole IP range cannot, and a false positive there hurts real customers. When in doubt, pick the smaller lever.

Try this on your own logs: generate a normal access pattern, then a cross-account enumeration pattern. Prove the second one creates exactly one alert, with actor, targets, request IDs, an owner, and a revocation step you’ve tested.