S3 is charging you for every copy you kept.

How do I reduce my AWS S3 storage costs?

Read storage, requests, and data transfer as separate lines. Expire incomplete multipart uploads and versions you do not need. Transition only when the colder class still matches how you read the data. Then shrink objects you will keep, so every remaining copy and download is smaller. Confirm rates on the current S3 pricing page.

AWS publishes S3 pricing as storage by class, requests, and data transfer, plus features such as Intelligent-Tiering's monitoring charge. Those levers are easy to apply blindly. A lifecycle transition is itself a request. A class with a minimum duration can cost you for days you already deleted. Read the pricing page dated the day you plan the change. We do not copy its dollar table onto this site.

Incomplete multipart uploads are the classic leak. You pay for parts that never became an object until you abort them or a lifecycle rule does. Old versions are the other leak. Versioning keeps the bytes behind a delete. If the bucket is versioned, a lifecycle rule has to expire noncurrent versions on purpose. Neither cleanup is compression. Both of them stop you paying for data you already abandoned. Do that first if the storage lens or inventory says those bytes are large. Then look at what you still mean to keep.

Google Cloud Storage and Azure Blob Storage price capacity by class, operations, and outbound transfer. Leaving AWS with the same object sizes moves the bill. Ask how many copies, how long, how often you read, and how often you send. Put the official pricing page, dated, in the ticket.

Which S3 storage class should I use?

Use a hot class for data you read constantly. Use infrequent or archive classes only when you can wait, or pay, to read it back, and when you will keep it past any minimum duration. Intelligent-Tiering is AWS's automatic option and has a monitoring charge. The right class is an access decision. It does not shrink the object.

S3 Standard, Standard-IA, Intelligent-Tiering, Glacier Instant Retrieval, Glacier Flexible Retrieval, and Glacier Deep Archive are different contracts, not a ladder of free savings. AWS documents minimum storage duration and extra metadata overhead on some archival classes. Veeam's own guidance, pointing at that AWS page, tells operators to keep Glacier archives for months rather than days because early deletion is still billed. If your backups rotate every two weeks, a deep archive class can be the expensive choice. The backup page goes further on that trap.

Intelligent-Tiering moves objects between access tiers when access patterns change. AWS describes a monitoring and automation charge per object in exchange for moving them. That trade favors larger objects you might or might not read. It is a poor fit for a flood of tiny files. Watch access with storage class analysis before you write a lifecycle rule you cannot reverse.

None of these classes change the number of bytes in the object. They change the price of holding and reading those bytes. If you replicate the bucket, you pay the destination class too. If you download the object, transfer is priced on what you send. Compression sits beside the class choice. A smaller object in a cold class is smaller to store and smaller to restore. A smaller object you then delete was not a compression problem.

Does compression reduce S3 costs, or should I just tier?

Compress objects you will keep and still read as the same file. Tier objects you rarely read and can restore under that class's rules. Delete objects you do not need. The three moves stack. Compression does not waive request prices or a minimum duration. Tiering does not make a hot, often-downloaded object cheap.

A lifecycle rule that transitions a 100 GB object to a colder class still transitions 100 GB, and the restore still retrieves 100 GB, subject to that class's retrieval pricing. If a lossless pass made it 40 GB, both the idle bill and the restore move less data. We are not telling you the pass will make it 40 GB. That number is an illustration of the shape, not a measurement. Your ratio belongs in the calculator, labeled as your assumption, or in a sample we measure.

Already compressed objects are the limit. Archives that are zipped, images that are already encoded, and many video files have spent their redundancy. Running gzip again, or sending them to us, may change almost nothing. Logs, JSON, CSV, raw checkpoints, and uncompressed backups often still have room. You cannot know from the extension alone when a container format wraps mixed data. Measure a real prefix of the bucket.

Put the compressor where the copies fan out. Compress before replication if the replica should store the smaller form. Compress before the backup product walks the files if every retained generation should be smaller. Compressing a Glacier object that is already cold, after years of hot storage, does not refund the years. Order of operations is the whole game. The steps below are the order we would want in a ticket.

Why do tiny S3 objects cost more than their size suggests?

You pay per request to put, get, list, and transition an object, and some archival classes bill a minimum size or extra metadata. A million tiny files can cost more to manage than to store. Pack them when you can. Compression helps the bytes inside each object. It does not, by itself, reduce the count of requests.

The S3 pricing page describes additional metadata charged for objects in Glacier Flexible Retrieval and Deep Archive, and a minimum billable size on Glacier Instant Retrieval. Small objects feel that overhead directly. Lifecycle rules that transition every object also pay the transition request. AWS's own cost guidance says to think about that before you move a whole bucket. Inventory and Storage Lens show object counts. If the count is the story, concatenating logs into larger objects, or packing a dataset into fewer files, changes the request math in a way a storage class will not.

Compression and packing solve different problems and work well together. Packing reduces how many requests you issue. Compression reduces how many bytes each packed object holds. A pipeline that gzips each 2 KB event and then puts it as its own object has done the less useful half. A pipeline that batches an hour of events, compresses the batch, and puts one object has changed both meters. Your logging tool may already batch. Look at the object sizes in the bucket before you buy another tier.

Listing is its own tax. Jobs that list a prefix on a schedule, security tools that inventory daily, and backup products that walk every key all issue requests. Fewer objects make those walks cheaper and faster. This is not a qzip feature claim. It is a reason to look at object counts on the bill before you only negotiate the gigabyte rate.

A practical order of work.

1. 1. Split the bill

   From the AWS bill and the S3 pricing page, separate storage by class, requests, retrieval, and data transfer. Note incomplete multipart uploads and noncurrent versions if the bucket is versioned.

2. 2. Expire what you do not need

   Abort abandoned multipart uploads and expire versions and objects your policy does not require. Do this before you pay to transition data you meant to delete.

3. 3. Match the class to the read

   Use lifecycle or Intelligent-Tiering only where access patterns and minimum duration fit. Read the current class rules on the AWS docs the day you decide.

4. 4. Shrink what you keep

   Lossless-compress representative objects you will still store, replicate, or send. Record the ratio on that sample, including the decompressor if you care about the total. Do not reuse the enwik9 number.

Questions.

Provider docs, not our price list.

• Amazon S3 pricing
• How AWS describes S3 cost optimization
• S3 Lifecycle rules
• S3 storage classes
• Google Cloud Storage pricing
• Azure Blob Storage pricing

Links checked Oct 21, 2026. Rates and rules on those pages can change.