# Azure Storage Account

> Azure Storage bills three meters at once: stored capacity by access tier, a redundancy multiplier (LRS through RA-GZRS), and per-transaction charges. ZopNight discovers every account via Resource Graph with SKU and tier detail, probes whether a lifecycle policy is set, and recommends tiering, redundancy downgrades, and lifecycle rules.

Source: https://zop.dev/integrations/azure/storage-account
Updated: 2026-08-19

---

Storage accounts hold blobs, files, queues, and tables and bill by capacity, redundancy tier, and transactions. Growth is silent and cumulative, so unreviewed accounts steadily inflate the bill.

## Three meters stacked on one account

The bill for a storage account is the product of three independent choices. Stored capacity meters per GB at a rate set by access tier: hot data costs several times more per GB than cool, and archive is cheaper still but charges for retrieval. Redundancy multiplies that base: locally redundant storage is the floor, while geo-redundant and read-access geo-zone-redundant options replicate every byte to a paired region and price accordingly. Transactions then meter on top, per operation, which is why a chatty application against cool-tier storage can cost more than the same workload on hot. None of these meters ever pauses; an account bills identically at 3 a.m. on a Sunday and at peak load.

## Lifecycle probing beyond Resource Graph

ZopNight discovers accounts via Azure Resource Graph with SKU, redundancy, and access-tier detail, and attributes capacity and transaction spend from Cost Management billing. One signal Resource Graph cannot answer is fetched separately: whether a management (lifecycle) policy exists on the account. The enricher records an explicit true or false, and the retiering recommendation fires only on a confirmed false. An unknown never triggers it. Recommendations cover hot-to-cool-to-archive tiering, redundancy downgrades, and lifecycle policies, and ML auto-tagging covers this type. There is nothing to stop or schedule here; the leverage is entirely in tiering, retention, and redundancy choices.

## The slow leaks unique to storage accounts

Watch for three patterns. Data written once and never read again, sitting in the hot tier for years because nobody set a lifecycle rule. Geo-redundant replication on dev and test data that could vanish tomorrow without consequence. And log or diagnostic containers that grow unbounded because deletion was never anyone's job.

## Reviewing an account's configuration in the portal

Azure portal → Storage accounts lists every account with its SKU and redundancy. Inside an account, Data management → Lifecycle management shows whether any rules exist. An empty list on an old, growing account is the clearest tiering opportunity Azure offers.