From Compute Cleanup to Storage Tiering: What Changed in v1.10
This release widened provider coverage and pushed analysis beyond delete-or-keep decisions into the harder storage question: what should move to a cheaper tier, and when?
Provider depth
15-provider release line
Coverage expanded beyond the big three so mixed estates can stay in one operating rhythm.
Storage review
Archive instead of delete
The product now looks for lifecycle gaps and tiering opportunities where data still matters but standard storage is too expensive.
Safety
A new archive action
The recommendation language now separates cost optimization from destructive cleanup more clearly.
Most teams already know how to delete obvious idle compute. The harder part is storage: old data that still matters, but no longer belongs on the most expensive tier.
That is the core of v1.10. The release expands provider coverage and pushes the product from compute-only cleanup into storage lifecycle analysis, where the decision is often not delete, but move, retain, and lower the bill without creating data-loss risk.
Wider provider coverage without changing the workflow
Real cloud estates are rarely cleanly standardized. Some teams live on AWS, Azure, and GCP. Others keep regional workloads on Alibaba Cloud, Tencent Cloud, Baidu Cloud, Oracle, IBM, or smaller providers that still matter in day-to-day operations.
The point of broader support is not logo count. It is fewer tab switches and fewer review meetings split by provider.
Engineering notebook: every provider speaks a different dialect
The hard work here was not just adding endpoints. Authentication and request signing differ by provider. AWS uses SigV4, Tencent mixes TC3 and older COS signatures, Baidu has its own canonical rules, and Oracle depends on RSA-SHA256 request signing with private-key handling. The product hides that complexity so the operator does not need to.
Why storage tiering matters more than another delete rule
Plenty of tools can tell you that an empty bucket should be removed. That is useful, but not where most enterprise storage waste sits. The bigger problem is older data that is still retained for reporting, audit, or recovery, while standard storage pricing continues month after month.
Storage tiering analysis looks for that pattern. If a large bucket has no transition or expiration policy, the product can flag it for review and estimate the savings from moving colder data into cheaper classes.
What the review checks actually examine
- Lifecycle policy coverage: large buckets without transition or expiration rules are surfaced because they usually deserve an explicit decision.
- Potential savings: the report estimates the difference between standard tiers and colder archive tiers, so the meeting can start with a number instead of a guess.
- Provider-aware detection: tiering advice adapts to what each platform already exposes, such as storage class metadata or provider-specific bucket behavior.
A safer vocabulary for operators
One reason storage reviews go nowhere is operator anxiety. If the UI only knows how to say delete, teams will postpone the discussion. The newer archive action changes that. It tells the operator exactly what kind of move is being suggested: keep the data, lower the storage cost.
That distinction matters in weekly review because it reduces the emotional weight of the recommendation and helps non-engineering reviewers understand the difference between cost reduction and destructive cleanup.
These buckets are cold but still needed. Move them to archive tier and save without taking deletion risk.
Why this release line mattered
With v1.10, the product moved from finding obviously dead resources to supporting a broader review loop: find, tier, verify, and defend the decision in front of the team that owns the data.
For compute-side optimization in the same operating model, review Rightsizing Launch. For recurring leak patterns that pair with storage reviews, see 5 Hidden Cloud Costs.
Review storage cost without turning every finding into a delete debate
Save your first $1,000 before the next billing cycle.