How do you detect and alert on unexpected S3 access-pattern or cost changes before a misconfigured lifecycle policy or public bucket becomes an incident?

Think about a family storage unit rental where you'd want three different kinds of alerts: one for your bill went up unexpectedly, something changed in usage, one for someone unrelated to the family is now able to access the unit, a lock got left open, and one for a bunch of items were moved out overnight, unusual activity. Each of those is a genuinely different kind of problem requiring a different detection method — checking the monthly bill alone would never catch an unlocked door, and checking the lock alone would never catch a slow, creeping cost increase from someone quietly hoarding more and more storage over time.

S3 buckets accumulate exactly these three independent risk categories over time, and AWS provides separate purpose-built tools for each because they're genuinely different problems. Cost Anomaly Detection and budget alerts exist for the usage-and-spend-changed-unexpectedly category, built on AWS's cost and usage data using anomaly detection rather than fixed thresholds, so it catches gradual drift, not just hard limit breaches. CloudTrail data events and S3 Server Access Logs exist for the who-is-actually-touching-this-data category. AWS Config rules plus IAM Access Analyzer exist for the is-this-bucket's-permission-configuration-actually-safe category, continuously evaluating policy and ACL state rather than only checking at creation time and never again.

Internally, a typical detection setup enables S3 Server Access Logging, or CloudTrail data events, which are more detailed but higher-volume and higher-cost, writing to a dedicated logging bucket, feeds that into an analysis pipeline, Athena queries over the access logs or a SIEM ingestion, and separately runs AWS Config's s3-bucket-public-read-prohibited and s3-bucket-public-write-prohibited managed rules continuously, which evaluate bucket policy and ACL state on every change and flag non-compliant buckets within minutes, not at the next scheduled audit weeks later. Cost Anomaly Detection runs its own ML-based baseline over historical spend per service and linked account, firing when actual spend deviates meaningfully from the learned pattern, catching a runaway lifecycle rule, one accidentally configured to keep transitioning already-archived objects repeatedly and incurring repeated retrieval charges, that a fixed dollar-threshold budget alert might miss entirely if the absolute dollar amount involved is still small.

In production, teams route AWS Config non-compliance findings, especially public-bucket rules, to a page-immediately channel since public exposure of something like a payments-api-logs bucket is a live security incident, while cost anomalies typically route to a next-business-day review channel unless the anomaly is extreme, since cost issues are important but rarely require middle-of-the-night response. Access pattern analysis via Athena over access logs is usually a weekly or on-demand investigation tool rather than continuous alerting, because usage volume alone is noisy, but it becomes essential once an anomaly from either of the other two signals points you toward a specific bucket worth investigating further.

The non-obvious gotcha: a bucket can be perfectly private, no public policy, AWS Config green across the board, while still leaking data through an overly permissive IAM role attached to an unrelated service. If user-auth-service's IAM role was granted s3:* on all buckets months ago to unblock a deploy and never tightened afterward, that role can read a completely unrelated, correctly-locked-down bucket, and neither the bucket-policy checks nor a public-access scan would ever catch this, because the exposure lives in the IAM role's permissions, not the bucket's own configuration. A full picture requires reviewing IAM policies granting S3 access fleet-wide, not just auditing bucket policies in isolation.