Azure paused the 128 KiB minimum billable object size: what changed on 1 July 2026

Summary. Microsoft has paused the 128 KiB minimum billable object size for Azure Blob Storage cool, cold and archive tiers. Azure Update 559756, added to the roadmap on 14 April 2026 and last modified on 8 June 2026, states that billing behaviour "will not change on July 1, 2026, for either new or existing storage accounts." The original plan would have billed every sub-128 KiB object in those three tiers as a full 128 KiB, a 32x multiplier on a 4 KiB object. For a 500 million object log archive in the cool tier, that was the difference between $19.07 and $610.35 a month in East US 2, or ₹1,980 and ₹63,375 a month in Central India, at the pay-as-you-go rates published on 17 July 2026. No action is required from customers now. AWS has billed a 128 KB floor on S3 Standard-IA for years and still does; Google Cloud Storage has no minimum object size on any class. That gap is the reason to keep packing small files anyway.

What Microsoft actually said

Azure Update 559756 is titled "Minimum billable object size for cooler storage tiers". It covers Azure Blob Storage and Azure Data Lake Storage, sits under Storage and Analytics in the Azure Updates feed, and is categorised as a Pricing and Offerings update. It was added to the roadmap on 14 April 2026 and last modified on 8 June 2026.

The current text is short. Microsoft is pausing the introduction of the minimum billable object size for the cool, cold and archive access tiers, so billing behaviour did not change on 1 July 2026 for new or existing storage accounts. Microsoft says it will publish a revised approach and timeline in a future Azure Update, and that no action is required from customers at this time.

Two things follow from that. Your July 2026 bill for small objects in cool, cold or archive tiers looks exactly like your June bill. And the policy is paused, not cancelled: Microsoft explicitly reserved the right to come back with a revised approach.

The Microsoft Learn page for access tiers for blob data, last updated on 15 June 2026, is consistent with the pause. Its pricing and billing section documents storage capacity costs, data access costs, transaction costs, geo-replication transfer and tier-change charges. It contains no minimum billable object size at all.

What the original policy would have done

The policy Microsoft announced in April 2026 was straightforward. Objects in the cool, cold and archive tiers smaller than 128 KiB would be billed as 128 KiB objects at the rate of the corresponding tier. The hot tier was never in scope. Transactions were not affected. The rollout had two stages: new storage accounts created on or after 1 July 2026, then all storage accounts on 1 July 2027.

Greg DeMichillie, an analyst at Directions on Microsoft, assessed the policy in a report published on 22 April 2026, six weeks before the pause. He wrote that the only customers likely to see significant impact are "those storing very large numbers of very small files", naming text-based configuration files such as YAML or JSON, and small web-optimised JPGs. His conclusion was that those customers "may find it more cost effective to use the hot tier", even though the hot tier is between 1.8x and 9x more expensive per byte than the cooler tiers.

That last point is worth holding on to, because the arithmetic behind it survives the pause.

The 32x arithmetic

Azure bills Blob Storage in binary gigabytes, where 1 GB is 2^30 bytes, which the IEC calls a gibibyte. A 128 KiB floor on a 4 KiB object multiplies the billed capacity by exactly 32.

Take a realistic small-object workload: 500 million JSON events of 4 KiB each, landed in the cool tier and kept for a year. Actual capacity is 1,907.35 GiB. Under the floor, billed capacity would have been 61,035.16 GiB.

These are the pay-as-you-go rates Microsoft published on 17 July 2026 for locally redundant storage, first 50 TB per month:

Applied to the 500 million object archive:

The bottom row is the one that catches people out. Under a 128 KiB floor, cool storage for 4 KiB objects costs an effective $0.32 per actual GiB, which is 17.4x the hot tier's $0.0184. The cheap tier becomes the expensive tier. That is exactly the inversion DeMichillie flagged, and it is why the mitigation was never "move it to archive".

The delta for this workload was $591.28 a month, or $7,095 a year. In Central India it was ₹61,395 a month, about ₹7.37 lakh a year. Real money, but only at scale: the same floor on a million 4 KiB files costs about $1.18 a month. If your small-object count is in the low millions, this was always noise.

Why half the internet still says it landed

Search for this policy today and you will be told, confidently, that the 128 KiB floor took effect on 1 July 2026. Several vendor blogs and cost-optimisation posts published after 8 June still say so, including one dated 30 June that reproduces the Azure Update metadata, correctly cites the 8 June modification date, and never mentions the pause that update now contains.

The mechanism is ordinary. The April announcement was widely covered. The June revision changed the body text of the same Azure Update ID rather than publishing a new one, so nothing re-triggered the news cycle. Aggregators that scraped the April text kept serving it. Summarisers trained on that corpus repeat it.

The practical lesson for anyone doing cloud cost work: for a billing change, read the Azure Update itself, and read it on the day you act. Azure Update 559756 renders as an empty shell to most scrapers because the feed is client-rendered, which is precisely why so much downstream coverage is stale. The primary source is the only source that is current.

This is not a one-off. Our write-up on cloud egress fees and AI inference bills ran into the same pattern: widely repeated per-GB figures that no longer matched the vendors' own pricing pages.

How Azure now compares with AWS and Google

Here is the part that matters for architecture, because Azure's pause puts it out of step with AWS and in step with Google.

AWS documents the 128 KB floor on its own S3 pricing page: smaller objects may be stored but are charged for 128 KB at the appropriate storage class rate. Glacier Flexible Retrieval and Deep Archive skip the floor but charge 40 KB of metadata per archived object, which is what funds the real-time S3 LIST and Inventory view. Glacier Instant Retrieval has the 128 KB floor and no 40 KB charge.

Google is the outlier in the other direction. Its storage classes documentation, updated on 10 July 2026, states plainly that all classes have no minimum object size. Google's lever is duration instead: Archive carries a 365-day minimum, versus 180 days on Azure archive and Deep Archive.

So two of the three hyperscalers already price small objects punitively in cold tiers, one of them for years. Azure tried to join them and stepped back. The pressure that produced the April announcement has not gone away, and Microsoft said it would return with a revised approach. Plan as though some version of this lands.

Keep packing small files anyway

The honest engineering read: the pause removes a deadline, not a reason. Small objects in cool and cold tiers were already a bad shape before anyone mentioned 128 KiB, because per-transaction charges apply to every tier and rise as the tier gets colder. A million tiny objects means a million transactions to write and a million to read.

Packing them fixes the transaction bill today and pre-empts the floor whenever it returns. A daily rollup of a JSON event stream into hourly Parquet or gzip archives is the standard move:

            # Roll one day of small JSON events into hourly gzip archives before tiering.
# Cuts object count ~3,600x for a 1-events-per-second stream.
DAY="2026-07-16"
for H in $(seq -w 0 23); do
  az storage blob download-batch \
    --account-name "$ACCOUNT" \
    --source raw-events \
    --pattern "${DAY}/${H}/*.json" \
    --destination "./stage/${H}" --auth-mode login

  tar -czf "./out/events-${DAY}-${H}.tar.gz" -C "./stage/${H}" .

  az storage blob upload \
    --account-name "$ACCOUNT" \
    --container-name packed-events \
    --name "${DAY}/events-${DAY}-${H}.tar.gz" \
    --file "./out/events-${DAY}-${H}.tar.gz" \
    --tier Cool --auth-mode login
done
          

The trade-off is retrieval granularity. Once events are inside an hourly tarball you cannot fetch one event without pulling the archive. For log and audit data read in bulk or never, that is free. For anything with random single-object reads, columnar Parquet keeps predicate pushdown and still collapses the object count.

Whatever you pack into, respect the retention minimums in the table above. Azure charges a prorated early deletion penalty if a blob leaves cool before 30 days, cold before 90 or archive before 180. Move a blob to cool and delete it after 21 days and you pay the equivalent of 9 more days. Rewriting the whole object counts as deletion for this purpose, so a "pack it again" job that overwrites yesterday's archive can trigger the penalty.

Use Smart tier instead of guessing

Smart tier is Microsoft's own answer to this problem, and it is the mitigation the April announcement named. It moves data between hot, cool and cold automatically based on usage patterns. For small-object estates the useful property is that it can keep small objects on hot, where no floor was ever proposed and per-byte rates are highest but transaction rates are lowest.

Set the account default rather than tiering by hand:

            az storage account update \
  --name "$ACCOUNT" \
  --resource-group "$RG" \
  --access-tier Smart
          

If you prefer explicit control, a lifecycle rule that only tiers objects above the old threshold gives you the same protection deterministically. This one leaves anything under 128 KiB on hot:

            {
  "rules": [
    {
      "enabled": true,
      "name": "tier-large-objects-only",
      "type": "Lifecycle",
      "definition": {
        "filters": {
          "blobTypes": ["blockBlob"],
          "prefixMatch": ["packed-events/"]
        },
        "actions": {
          "baseBlob": {
            "tierToCool": {
              "daysAfterModificationGreaterThan": 30
            },
            "tierToArchive": {
              "daysAfterModificationGreaterThan": 180
            }
          }
        }
      }
    }
  ]
}
          

Point the prefix at your packed container, not the raw one. That single decision, tier the archives and never the raw events, makes the floor irrelevant to you whether or not it returns.

Note the limits. Lifecycle management cannot rehydrate an archived blob back to an online tier. Data in a premium block blob account cannot be tiered at all; you must copy it to the hot tier of a different account using Put Block From URL or a version of AzCopy that supports it. And rehydrating from archive takes up to 15 hours, which is a design constraint, not a billing one.

India-specific considerations

Central India pricing runs above East US 2 on every online tier: cool is ₹1.03834 per GB against ₹0.94394 for the same tier billed in rupees out of East US 2, and hot is ₹1.8879 against ₹1.7369. Archive is the exception, identical at ₹0.18879. So the small-file penalty, when it returns, will land slightly harder on teams that keep data in-country.

For most Indian teams that is not a reason to move the data. Teams that landed on Central India for latency or data residency chose it for reasons a per-GB delta of a few paise does not overturn. Stay there and fix the object shape instead. Packing is the cheaper lever by an order of magnitude.

The pattern we see most often in Indian log and telemetry estates: a Data Lake Storage Gen2 account, an event stream writing one blob per message, and a lifecycle rule that moves everything to cool at 30 days. That estate was never going to be hurt much by a 128 KiB floor unless the object count ran into the hundreds of millions, but it is already paying more in transactions than in capacity. The floor was a distraction from the real bill. We cover the wider version of this in our guide to cutting AWS, Azure and GCP spend for Indian teams and in our FinOps comparison across the three hyperscalers.

What to do this week

Nothing urgent. Microsoft said no action is required, and that is accurate for July 2026.

What is worth an hour: count your sub-128 KiB objects in cool, cold and archive. If the answer is under about ten million, close the ticket and note the date. If it runs to hundreds of millions, the transaction bill alone probably justifies packing now, and you will have pre-paid the migration for whenever the revised policy lands.

Then set a watch on Azure Update 559756 itself. Microsoft changed the body of an existing update once already without publishing a new one. It can do that again, and the secondary coverage will lag by weeks. Subscribe to the update rather than to a newsletter about the update.

The real cost here was never the 128 KiB. It was the four months teams spent planning a migration for a policy that got pulled.

FAQ

How eCorpIT can help

eCorpIT is a CMMI Level 5 certified technology consultancy in Gurugram, and a Microsoft partner. Our senior engineering teams review Azure Blob and Data Lake estates for object shape, tier placement and lifecycle rules, then quantify what a repack actually saves against what it costs to build. If your storage bill is dominated by transactions rather than capacity, or you are unsure how a paused billing change affects your 2027 forecast, talk to our cloud team and we will size it against your real object counts.

References

1. Azure Update 559756: Minimum billable object size for cooler storage tiers - Microsoft Azure, added 14 April 2026, last modified 8 June 2026.

1. Access tiers for blob data - Microsoft Learn, last updated 15 June 2026.

1. Azure Blob Storage pricing - Microsoft Azure, rates retrieved 17 July 2026.

1. Azure Storage Gets Minimum Billing Size - Greg DeMichillie, Directions on Microsoft, 22 April 2026.

1. Amazon S3 pricing - Amazon Web Services, retrieved 17 July 2026.

1. Storage classes - Google Cloud Documentation, last updated 10 July 2026.

1. Optimize Azure Blob Storage costs with smart tier - Microsoft Learn.

1. Optimize costs by automating Azure Blob Storage access tiers - Microsoft Learn.

1. Set Blob Tier (REST API) - Microsoft Learn.

1. Overview of blob rehydration from the archive tier - Microsoft Learn.

1. Best practices for using blob access tiers - Microsoft Learn.

1. Cooler Storage Minimum Billable Object Size Update - Christos Panagiotidis, 30 June 2026, cited as an example of post-pause coverage that omits the pause.

Last updated: 17 July 2026.