S3 lifecycle policy cost is the cost a missing rule causes: a bucket without a lifecycle configuration keeps every noncurrent version, every abandoned multipart upload, every soft-deleted file and every log file forever, at the price of the class it was written to. The saving comes from a lifecycle rule that deletes these objects by age or moves them to a cheaper storage class without anyone touching them, and from the rule working every month once written. The fix belongs to the team that owns the bucket, because only there is it known which versions and how many days a restore needs.

Symptom

The bill shows object storage growing faster than the data the application writes. On AWS it is lineItem/UsageType EUC1-TimedStorage-ByteHrs under AmazonS3, which does not separate current versions, noncurrent versions and upload parts; only S3 Storage Lens shows the shares. On Azure it is the meters Hot LRS Data Stored and their siblings under MeterCategory Storage, soft-deleted and versioned blobs included. On Google Cloud Cloud Storage carries the SKU Standard Storage per region, noncurrent versions and soft-deleted objects within their period included. The classes and their mechanics are in storage tiers and lifecycle; this page covers the gap where no rule applies and the rule that closes it.

The data theapplication writesOne storage line:TimedStorage-ByteHrs, DataStored or Standard StorageNoncurrent versions,open upload parts, soft-deleted objects: no ruleappliesThe line grows faster thanthe data written and doesnot separate the shares
One storage line grows faster than the data the application writes, because it carries the versions, upload parts and soft-deleted objects no rule removes

How to detect it

AWS

Whether a bucket has a rule, whether versioning is on and which uploads are open:

aws s3api get-bucket-lifecycle-configuration --bucket <bucket>
aws s3api get-bucket-versioning --bucket <bucket>
aws s3api list-multipart-uploads --bucket <bucket> --query 'Uploads[].[Key,Initiated,UploadId]' --output table

The first request answers NoSuchLifecycleConfiguration when no rule exists. S3 Storage Lens shows the shares in its free metrics: buckets with incomplete multipart uploads older than seven days, noncurrent version bytes, and versioned buckets without a rule (S3 Storage Lens). Trusted Advisor runs three checks for it: "Amazon S3 Bucket Lifecycle Policy Configured", "Amazon S3 Incomplete Multipart Upload Abort Configuration" and "Amazon S3 version-enabled buckets without lifecycle policies configured" (read on 2026-10-21). In billing data the candidate is a bucket as lineItem/ResourceId whose TimedStorage-ByteHrs grows every month while requests stay flat (AWS Cost and Usage Report).

Azure

The storage account's policy and its versioning and soft delete settings:

az storage account management-policy show --account-name <account> --resource-group <rg>
az storage account blob-service-properties show --account-name <account> --resource-group <rg> \
  --query "{versioning:isVersioningEnabled, softDeleteDays:deleteRetentionPolicy.days, lastAccess:lastAccessTimeTrackingPolicy.enable}"

An account without a policy answers with an error; an account with versioning and soft delete and no delete rule for previous versions keeps everything. The metric BlobCapacity per access tier and BlobType shows how much sits in the hot tier; Azure Advisor has no recommendation on lifecycle rules, only on the move to premium at a high transaction share. In the cost export the candidate is a storage account whose Data Stored meter grows in the hot tier with no Cool or Archive meter beside it (Azure cost exports).

Google Cloud

The lifecycle configuration, versioning, soft delete period and Autoclass per bucket:

gcloud storage buckets describe gs://<bucket> --format="default(lifecycle_config,versioning_enabled,soft_delete_policy,autoclass)"

A bucket without lifecycle_config keeps everything; noncurrent versions stay until a rule with isLive: false. The recommender google.storage.bucket.SoftDeleteRecommender flags buckets whose soft delete period costs more than it protects (Recommenders). In the billing export the candidate is a bucket as resource.name whose Standard Storage usage grows with no Nearline or Coldline SKUs beside it (Google Cloud billing export).

How to fix it

  1. Settle the three questions the rule needs per bucket: how many noncurrent versions and how many days a restore demands, after how many days an object goes cold, and whether objects under 128 KB are among them, for which the colder classes on AWS bill a minimum size.

  2. Set the rule. On AWS as JSON with put-bucket-lifecycle-configuration; this set aborts open uploads after seven days, removes expired delete markers, keeps three noncurrent versions for 30 days and moves objects from 128 KB to Standard-IA after 30 days (lifecycle rule for incomplete multipart uploads):

    {
  "Rules": [
    {"ID": "hygiene", "Status": "Enabled", "Filter": {"Prefix": ""},
     "AbortIncompleteMultipartUpload": {"DaysAfterInitiation": 7},
     "Expiration": {"ExpiredObjectDeleteMarker": true},
     "NoncurrentVersionExpiration": {"NoncurrentDays": 30, "NewerNoncurrentVersions": 3}},
    {"ID": "tier", "Status": "Enabled", "Filter": {"ObjectSizeGreaterThan": 131072},
     "Transitions": [{"Days": 30, "StorageClass": "STANDARD_IA"}]}
  ]
}

    On Azure as a policy with az storage account management-policy create --account-name <account> --resource-group <rg> --policy @policy.json, with tierToCool at daysAfterModificationGreaterThan 30 for base blobs and delete at daysAfterCreationGreaterThan 30 for previous versions; the policy starts within 24 hours (lifecycle management). On Google Cloud with gcloud storage buckets update gs://<bucket> --lifecycle-file=lifecycle.json, with AbortIncompleteMultipartUpload at age 7, Delete at isLive false and numNewerVersions 3, SetStorageClass NEARLINE at age 30 (Object Lifecycle Management).

  3. Where the access pattern is unknown, automatic tiering instead of fixed periods: S3 Intelligent-Tiering moves objects to the Infrequent Access tier after 30 days without access and to Archive Instant Access after 90, for a monthly monitoring charge per object, objects under 128 KB excepted (Intelligent-Tiering); Autoclass on Google Cloud moves to Nearline after 30 days and, with Archive as the terminal class, to Coldline after 90 and to Archive after 365, without retrieval or early deletion fees, for a management fee (Autoclass).

  4. Write the rule into the template new buckets come from, and set the Trusted Advisor checks or a Storage Lens metric as a guard against the next bucket without a rule.

Deletions take effect within a day on AWS, up to 24 hours after the rule on Azure and Google Cloud; the amount falls in the next daily export.

yesnoPer bucket: how manyversions and days a restoredemands, when an object goescold, objects under 128 KBAccess patternknown?Set the rule: abort openuploads, remove deletemarkers, expire noncurrentversions, move to acolder classAutomatic tiering insteadof fixed periods:Intelligent-Tieringor AutoclassWrite the rule into thetemplate; Trusted Advisor orStorage Lens as a guardDeletions within a day ofthe rule; the amount fallsin the next daily export
Three questions per bucket set the rule, an unknown access pattern takes automatic tiering, and the template keeps the next bucket from going without a rule

Risks and side effects

  • Minimum durations: Standard-IA and One Zone-IA 30 days, Glacier Instant Retrieval and Flexible Retrieval 90, Deep Archive 180 on AWS; cool 30, cold 90, archive 180 on Azure, charged pro rata; Nearline 30, Coldline 90, Archive 365 on Google Cloud. An object deleted or brought back before the period pays the rest.
  • Minimum size: Standard-IA and Glacier Instant Retrieval bill at least 128 KB per object, and Intelligent-Tiering does not monitor smaller objects; a bucket full of thumbnails saves nothing from tiering.
  • Every transition is a request: S3 bills transition requests, Azure the Set Blob Tier call as a write operation, Google Cloud a class A operation. Tiering millions of small objects at once costs more in the first month than it saves.
  • A delete rule in a versioned bucket creates only delete markers on AWS when the rule for noncurrent versions is missing; soft delete on Azure and Google Cloud keeps deleted data on the bill for the configured period.
  • An object in the archive tier is not there at once: rehydration takes up to 15 hours on Azure, retrievals from Glacier Flexible Retrieval and Deep Archive hours, each with retrieval costs.

How to verify the saving

Before: per bucket, the stored byte-hours per class in the last full month, TimedStorage-ByteHrs and TimedStorage-SIA-ByteHrs, the Data Stored meters per tier, the Storage SKUs per class, plus the Storage Lens figures for noncurrent versions and open uploads. After: the same figures in the first full month after the rule; the hot class's byte-hours have to fall, the cold class's rise, and the sum shrink, the first month's transition requests and early deletion fees included. The estimate from Storage Lens or your own inventory is the "estimated" value, the team's release makes it accepted, the rule implemented, and the following month's invoice realises it in the pattern of estimated, accepted, implemented, verified. The number of buckets without a rule is the figure that stays at zero afterwards.

Sources

Read on 2026-10-21. Lifecycle rule for incomplete multipart uploads, S3 Storage Lens, S3 Intelligent-Tiering, S3 pricing, minimum durations and sizes, Trusted Advisor cost optimization checks, Azure Blob Storage lifecycle management, Azure Blob Storage access tiers, Object Lifecycle Management, Manage object lifecycles, Storage classes, Autoclass, Recommenders.