Rarely requested S3 buckets not using Intelligent-Tiering, where the tier savings exceed the monitoring fee
What does ZopNight detect here?
ZopNight flags S3 buckets not already on `INTELLIGENT_TIERING` when request metrics show fewer than 1,000 requests a day. The saving is cold Standard data priced at the Standard to Infrequent Access tier gap, net of the $0.0025 per 1,000 objects monitoring fee, and buckets with no request metrics produce no finding.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-071 |
| Category | rightsizing |
| Severity | low |
| Metric | AllRequests (S3 request metrics) |
| Threshold | < 1,000 requests/day and positive net tier saving |
| Evaluation window | 30d |
| Source | ZopNight |
| Permissions used | s3:GetMetricsConfiguration · s3:GetLifecycleConfiguration · cloudwatch:GetMetricStatistics |
Where it applies
Automatic tiering in exchange for a per-object fee
S3 Intelligent-Tiering moves each object to its Infrequent Access tier after 30 consecutive days without access, and to Archive Instant Access after 90 days, then back to Frequent Access when it is read. There are no retrieval fees. What you pay instead is a monitoring and automation charge per object: AWS’s US East (N. Virginia) price list shows $0.0025 per 1,000 objects a month, with the Infrequent Access tier at $0.0125 per GB against $0.023 for Frequent Access. Objects under 128 KB are not monitored and always bill at Frequent Access rates.
For a bucket that is read rarely and holds large objects, the tier savings dwarf the fee. For a hot bucket, the fee buys nothing.
Checking request activity and current classes
Request activity comes from S3 request metrics, which are opt-in and billed like custom CloudWatch metrics:
aws s3api list-bucket-metrics-configurations --bucket my-bucket
aws cloudwatch get-metric-statistics --namespace AWS/S3 --metric-name AllRequests \ --dimensions Name=BucketName,Value=my-bucket Name=FilterId,Value=EntireBucket \ --start-time 2026-08-26T00:00:00Z --end-time 2026-09-25T00:00:00Z \ --period 86400 --statistics SumThe FilterId value is the ID of your metrics configuration.
Conditions for recommending Intelligent-Tiering
- The bucket is not already on Intelligent-Tiering.
- Request metrics exist for it, and the measured daily request rate is below 1,000.
- ZopNight’s per-class storage breakdown for the bucket gives a positive saving after the per-object monitoring fee.
Buckets that are not flagged
A bucket without request metrics is skipped, because ZopNight will not assume a bucket is cold without evidence. Busy buckets at or above 1,000 requests a day are skipped too. When the bucket’s storage is not mostly in Standard, or the object count makes the monitoring fee larger than the tier gain, the net saving is not positive and nothing is shown.
Net tier saving
saving = sum over cold capacity of (Standard rate - target tier rate) x GB - monitoring fee per 1,000 objectscapped at the bucket's monthly costSwitching a bucket to Intelligent-Tiering
- Add a lifecycle rule that transitions current objects to
INTELLIGENT_TIERINGafter 0 days:
{"Rules":[{"ID":"to-intelligent-tiering","Status":"Enabled","Filter":{}, "Transitions":[{"Days":0,"StorageClass":"INTELLIGENT_TIERING"}]}]}- Apply it with
aws s3api put-bucket-lifecycle-configuration. - Upload new objects with
--storage-class INTELLIGENT_TIERINGso they start there. - Optionally activate the Archive Access tiers for data that can wait minutes to hours.