How to reduce Amazon S3 costs: the three settings that cut most bills

Where the money goes on a bucket of business files

For files that people keep rather than process, storage is the big line. Requests and data transfer matter for applications that read and write constantly, but a bucket of contracts, drawings and exports mostly just sits there, and AWS charges for every gigabyte-month it sits.

That is why the three settings below work. They do not change how people use the files. They change what is stored and which rate it is stored at.

Amazon S3 pricing explained: what AWS actually meters

Setting 1: stop keeping every old version forever

When versioning is on, saving a new copy of a file keeps the old one, and deleting a file keeps it too, hidden behind a delete marker. That is what makes deleted files recoverable, and it is worth keeping on. The cost is that a bucket people edit every day slowly fills with copies nobody will ever open.

The fix is a lifecycle rule that expires old versions after a set number of days while keeping a few of the newest ones, and that removes delete markers once nothing is left behind them. Pick the number of days from how far back people actually ask to recover a file, and keep at least one older version so a bad save can still be undone.

Expiring versions is permanent. Before adding the rule, check whether any bucket has Object Lock or a legal reason to keep history, and leave those out. One more caution: putting a lifecycle configuration replaces the whole configuration on the bucket, so copy any rules that already exist into the new one.

aws s3api get-bucket-versioning --bucket your-bucket

aws s3api put-bucket-lifecycle-configuration --bucket your-bucket --lifecycle-configuration '{
  "Rules": [{
    "ID": "expire-old-versions",
    "Status": "Enabled",
    "Filter": {},
    "NoncurrentVersionExpiration": { "NoncurrentDays": 90, "NewerNoncurrentVersions": 1 },
    "Expiration": { "ExpiredObjectDeleteMarker": true }
  }]
}'

S3 lifecycle rules explained, with examples for versioned bucketsHow to recover deleted or overwritten files in S3

Setting 2: throw away uploads that never finished

Large files go into S3 in parts. If the upload is interrupted, the parts that arrived stay in the bucket, invisible in the console's file list but billed at the full storage rate until someone aborts the upload. On a bucket that receives big files over flaky connections, this can quietly add up to a meaningful share of the bill.

The check is one command, and the fix is a lifecycle rule that aborts any upload still unfinished after a few days. Seven days is a common choice: long enough for a slow upload to finish, short enough that abandoned parts never linger.

aws s3api list-multipart-uploads --bucket your-bucket

aws s3api put-bucket-lifecycle-configuration --bucket your-bucket --lifecycle-configuration '{
  "Rules": [{
    "ID": "abort-unfinished-uploads",
    "Status": "Enabled",
    "Filter": {},
    "AbortIncompleteMultipartUpload": { "DaysAfterInitiation": 7 }
  }]
}'

How to upload files to S3 from the console, the CLI and an SDK

Setting 3: let cold files pay the cold rate

S3 Standard costs $0.023 per GB-month, whether a file was opened this morning or has not been touched since 2023. For most business buckets, the majority of bytes are in the second group. S3 Intelligent-Tiering moves each object down to cheaper tiers on its own as it goes unread: to Infrequent Access at $0.0125 after 30 days without a read, and to Archive Instant Access at $0.004 after 90. Every one of those tiers still opens the file instantly, there is no retrieval fee, and an object that gets read moves back up automatically. The only charge for the service is monitoring at $0.0025 per 1,000 objects a month.

Two details decide whether it is worth it for a given bucket. Objects under 128 KB are not monitored or moved, so a bucket of a million tiny files gains nothing, which is also why lifecycle transition rules skip objects under 128 KB by default. And moving existing objects into Intelligent-Tiering is a transition request at $0.01 per 1,000 objects, a one-time cost that a bucket of large files earns back in the first month.

If you can accept a wait before a file opens, Intelligent-Tiering can also use two archive tiers: Archive Access at $0.0036 after 90 days unread and Deep Archive Access at $0.00099 after 180. A file in those tiers has to be restored before anyone can open it, which takes hours, so turn them on bucket by bucket and only where people will not be surprised by the wait.

aws s3api put-bucket-lifecycle-configuration --bucket your-bucket --lifecycle-configuration '{
  "Rules": [{
    "ID": "tier-cold-files",
    "Status": "Enabled",
    "Filter": { "ObjectSizeGreaterThan": 131072 },
    "Transitions": [{ "Days": 0, "StorageClass": "INTELLIGENT_TIERING" }]
  }]
}'

S3 Glacier Deep Archive: when it saves money and when it costs moreArchiving files in Amazon S3: a guide

What the three changes are worth

Take a bucket holding 10 TB of business files in S3 Standard, about a million objects, where half the data has not been read in the last month. At list prices it costs $235.52 a month for storage.

Move it to Intelligent-Tiering and the unread half drops to the Infrequent Access rate after 30 days: $117.76 for the half still in use, $64.00 for the cold half, plus $2.50 of monitoring, or $184.26 a month. After 90 days the cold half reaches Archive Instant Access, and the bill is $140.74, about 40% below where it started. Opt the same bucket into Deep Archive Access and the cold half costs $5.07 instead of $20.48, taking the total to about $125, a 47% cut, in exchange for a restore wait on files nobody has opened in six months.

Old versions and unfinished uploads come on top of that. They are pure waste, so every gigabyte the two lifecycle rules remove is a full $0.023 saved with nothing given up. How much that is depends entirely on the bucket, which is why the first step is to measure rather than guess.

• The share of data that is truly cold is the one number that decides the saving. A bucket people read all day gains little from tiering.
• Buckets of small files gain almost nothing from tiering and still pay monitoring on anything over 128 KB. Leave them in Standard.
• The archive tiers roughly double the saving on cold data but add a restore wait. Default to instant access and opt in per bucket.

Check your own account before changing anything

Everything above can be read from the account without touching a file. Start with the bill, then look at the buckets that make up most of it.

• In Cost Explorer, filter to Amazon S3 and group by usage type. TimedStorage lines are storage by class; the rest is requests, retrievals and transfer. This is the only reliable split of where the money goes.
• In the S3 console, open each large bucket's Metrics tab for bytes by storage class and the object count, which is what the 128 KB rule and the monitoring fee depend on.
• Check whether versioning is on, and whether any lifecycle rule already expires old versions. If versioning is on and no rule exists, old versions are accumulating.
• Run list-multipart-uploads on buckets that receive large files. Any upload older than a week is waste.
• Find out how much of the data is actually read. S3 server access logs or a CloudTrail trail that records GetObject can answer it for a bucket; without that, the bill's data transfer lines give an upper bound.