Storage cost optimisation means applying the levers in order of effort: first delete what nobody reads any more, then move block storage to a cheaper type and the performance it actually needs, then shift objects into colder storage classes by rule or automatic tiering, and finally limit how long snapshots are kept. Each step lowers either the stored quantity or the price per gigabyte. Retrieval fees, minimum storage durations and per-object charges can still turn a planned saving into extra cost, and storage nobody can see is storage nobody deletes.
How it works
| Step | Lever | What changes | What it can cost |
|---|---|---|---|
| 1 | Delete: orphaned volumes and snapshots, incomplete uploads, old versions, soft-deleted data | Quantity | Early deletion fees in cold classes |
| 2 | Block storage: type, size, provisioned IOPS and throughput | Price per GB, performance charges | A restart or a copy, depending on the provider |
| 3 | Objects into colder classes, by rule or automatic tiering | Price per GB | Retrieval, transitions, minimum duration, per-object monitoring |
| 4 | Limit and archive snapshots | Quantity, price per GB | Minimum duration and retrieval in the archive |
See it first
On AWS, S3 Storage Lens shows storage across accounts and buckets. The preconfigured dashboard uses free metrics with 14 days of history, among them the bytes of incomplete multipart uploads and of noncurrent versions; the paid advanced metrics keep 15 months and add recommendations. Storage Class Analysis watches a data set's access for 30 days or longer before it recommends when data can move from Standard to Standard-IA, and it costs extra. Azure offers Storage insights in Azure Monitor, with capacity, transactions and availability across storage accounts and no charge for the view itself, and blob inventory reports in CSV or Parquet, billed by objects scanned. Google Cloud produces inventory reports per bucket, charged per million objects; Storage Insights datasets require a paid Storage Intelligence subscription. The Recommender has a soft delete recommendation for buckets and the idle persistent disk recommendation for disks.
Delete
Parts of an S3 multipart upload bill for storage until the upload is completed or aborted; AWS recommends a lifecycle rule with AbortIncompleteMultipartUpload for them. Soft-deleted data keeps billing too: Azure charges soft-deleted blobs at the rate of active data, and Cloud Storage keeps deleted objects for 7 days by default and bills them like live ones; the window can be set per bucket to 7 to 90 days, or turned off with 0. Unused disks and snapshots are covered in idle and orphaned resources.
Block storage
AWS states a 20% lower price per GiB for gp3 than for gp2. With Elastic Volumes a volume changes type without being detached and without restarting the instance, up to four times within a rolling 24-hour period. AWS Compute Optimizer recommends type, size, IOPS and throughput from the metrics of the last 14 days. Azure requires a VM restart to change a disk's type, at most twice a day; a Premium SSD's performance tier can be changed without resizing, but lowered only once every 12 hours, and Premium SSD v2 allows four performance changes in 24 hours. On Google Cloud a Persistent Disk's type cannot be changed directly: snapshot it, create a disk of the target type, delete the old one. Hyperdisk IOPS and throughput can be changed once every 4 hours, Hyperdisk ML throughput once every 6 hours, and a Hyperdisk cannot be made smaller.
Objects
Rules, such as S3 Lifecycle or Azure lifecycle management, fit when the access pattern is known; automatic tiering, such as S3 Intelligent-Tiering or Google Autoclass, fits when it is not. Classes, minimum durations and fees for all of them are covered in storage classes and lifecycle rules. Two points decide whether Intelligent-Tiering pays: objects under 128 KB are never moved and are always charged at Frequent Access rates, though without the monitoring fee; and its optional Archive Access and Deep Archive Access tiers take objects only after at least 90 and 180 days without access, after which a read needs a restore.
Snapshots
Snapshot cost falls through retention and archiving; how each provider bills snapshots is covered in backup and disaster recovery. Amazon Data Lifecycle Manager creates, keeps and deletes EBS snapshots and EBS-backed AMIs by policy, and Google snapshot schedules delete old snapshots under a retention policy. According to AWS, EBS Snapshots Archive lowers snapshot storage cost by up to 75% for snapshots kept 90 days or longer and rarely read. It pays only for snapshots that really stay that long: the archive bills at least 90 days, and a restore can take up to 72 hours. Google archive snapshots also bill for at least 90 days, plus retrieval when a disk is created from them.
What it means for your cost
Deleting lowers the quantity on the same line, while a type or class change moves cost to another usage type, meter or SKU and pays off only in the months after the change.
Block storage is billed on provisioned size and performance, so a type change starts with the question of what performance the workload actually uses. Azure Advisor lists reservations for Managed Disks, Blob Storage and Azure Files among its cost recommendations; as with compute, they come after the clean-up, because a reservation locks in the quantity it covers.
Where it goes wrong
- Large gp2 volumes moved without checking IOPS. Symptom: after the move to gp3 the volume is slower or dearer than expected. Cause: gp2 delivers 3 IOPS per GiB and 250 MiB/s from 334 GiB, gp3 includes 3,000 IOPS and 125 MiB/s, and everything above that costs extra.
- Deletion with no effect. Symptom: after a large deletion a bucket's storage does not fall. Cause: soft delete keeps the data at full price for the configured window.
- Invisible upload leftovers. Symptom: Storage Lens shows more bytes than any object listing. Cause: incomplete multipart uploads with no abort rule.
- Archived too early. Symptom: a
SnapshotArchiveEarlyDeleteline appears. Cause: an archived snapshot was deleted or permanently restored before 90 days. - A disk change in production hours. Symptom: a service goes down during the change. Cause: Azure needs a VM restart, Google a new disk from a snapshot.
- Small objects in tiering. Symptom: Intelligent-Tiering saves nothing on a bucket full of small objects. Cause: objects under 128 KB never change tier.
Example
A gp2 volume of S GiB costs G × S a month, where G is the gp2 price per GiB; its baseline is 3 × S IOPS. As gp3 the same volume costs 0.8 × G × S for storage according to AWS, with 3,000 IOPS included. If the workload needs the full gp2 baseline, I × (3 × S − 3,000) comes on top for S between 1,000 and 5,334 GiB, where I is the price per additional IOPS and month; from 5,334 GiB, where gp2 reaches its maximum of 16,000 IOPS, it is I × 13,000. The same applies to throughput above 125 MiB/s. Without a throughput charge and for S between 1,000 and 5,334 GiB the saving is 0.2 × G × S − I × (3 × S − 3,000). Whether the workload really uses those IOPS shows in its measured values, which Compute Optimizer also evaluates; the prices for G and I are on the EBS pricing page for the Region.
Sources
Read on 2026-10-16. AWS General Purpose SSD volumes, modify a volume using Elastic Volumes, EBS volume recommendations in Compute Optimizer, EBS Snapshots Archive, its considerations and its pricing, Amazon Data Lifecycle Manager, S3 Storage Lens metrics and recommendations, the Storage Lens metrics glossary, storage class analysis, S3 Intelligent-Tiering, Amazon S3 pricing, multipart upload and a lifecycle rule for incomplete uploads; Microsoft convert managed disks between disk types, change the performance tier, deploy Premium SSD v2, Advisor cost recommendations, Storage insights, Blob Storage lifecycle management, blob inventory and soft delete for blobs; Google Cloud modify a Persistent Disk, modify a Hyperdisk, snapshot schedules, disk and image pricing, soft delete, Autoclass, Cloud Storage pricing, inventory reports, Storage Insights datasets and recommenders.