Lifecycle Rules, Versioning, and a Storage Firewall Change
Fabrikam stores 85 TB of scanned engineering drawings in a GPv2 storage account (StorageV2, LRS, West Europe) as block blobs in the hot tier. About 4% of the archive is read each month, and 70% of the data has not been touched for 400 days. The team enabled blob soft delete (14 days), versioning, and a lifecycle rule: 'base blobs not modified in 180 days → cool, 365 days → archive, delete after 2,550 days'. Two weeks later the monthly Azure bill rose by €2,900 and the capacity report shows the account at 118 TB. A developer investigating a restore complains that versioning is 'eating the storage' and wants to turn off soft delete to save money. A second workload writes 300 small files per minute to a container through a private endpoint from an AKS cluster in a peered VNet. The network team wants to enable 'Selected networks' on the storage account firewall to restrict access to the corporate range.
1. Capacity grew from 85 TB to 118 TB and the bill rose. Explain what produced the extra data and why the lifecycle rule is not delivering the expected savings on the cold 70%.
Read the worked answer
Where the 33 TB came from. With versioning enabled, every overwrite and every delete writes a new version and retains the old one. A lifecycle rule that targets base blobs does not touch previous versions, snapshots, or soft-deleted blobs. On a write-heavy container, versions accumulate indefinitely and are billed at the tier of the base blob. Soft delete (14 days) additionally retains deleted base blobs and deleted versions. The arithmetic fits: a modest daily rewrite rate on 85 TB produces tens of TB of versions within weeks.
Why the cold data is not cheap yet. Three separate effects. First, lifecycle management evaluates and runs roughly once per day, so tiering is not instant. Second, the archive tier is only economical if the data is genuinely cold: archive blobs cannot be read without rehydration, which takes hours and, at high priority, costs extra; a 4%-per-month read rate is a poor fit for archive. Third, archive has an early-deletion charge of 180 days, and cool has a 30-day minimum, so blobs that are tiered and then deleted or rehydrated quickly are billed a penalty.
What to change. Add lifecycle rules for previousVersions (delete after 30 days, or tier them), and for snapshots if any exist. Consider moving only the provably cold subset to archive, keeping the rest in cool. Use blob inventory to measure the real distribution before tuning thresholds. Confirm the rule's daysAfterModificationGreaterThan semantics on versioned blobs: every write resets the clock on the base blob, so frequently rewritten blobs never reach the cool transition.
Soft delete is not the cost driver. Disabling it would not delete the 33 TB that already exists (those blobs expire at the end of their retention window), and it would remove the only recovery path for a mistaken or malicious delete.
2. Evaluate the developer's request to turn off soft delete to reduce cost, and propose a cheaper alternative that keeps a defensible recovery capability.
Read the worked answer
What soft delete actually costs. Blob soft delete has no separate per-GB fee; you pay standard storage rates for the soft-deleted blobs, versions, and snapshots that are retained for the configured window. With a 14-day window and versioning enabled, the retained set is bounded by 14 days of churn, whereas previous versions have no such bound. So disabling soft delete attacks the smaller, time-limited component and leaves the unbounded one untouched. The expected saving is a fraction of the €2,900 increase, while the loss is real.
What is lost. Soft delete is the difference between recovering from an accidental or ransomware-driven delete and restoring tens of TB from another region. With versioning also on, disabling soft delete removes protection for versions, not just base blobs. That is a compliance and business-continuity regression traded for a rounding error.
Cheaper controls that keep recovery. (1) Lifecycle rules on previousVersions and snapshots, which is where the growth actually is; 30 days of versions is usually enough for the restore scenarios the developer described. (2) Reduce soft delete retention to 7 days only if the business accepts that window, and document it. (3) Apply an immutability policy (time-based retention or legal hold) on the archive container so those blobs cannot be deleted or modified at all, which is stronger than soft delete and removes the need for long version retention there. (4) Prevent versioning on containers that are write-once by policy, and use blob inventory plus cost analysis to attribute spend per container before changing anything.
Also check the small-file workload. 300 files per minute through a private endpoint is 432,000 writes per day; with versioning on that container, versions will dominate storage within a month. That container, not the soft delete setting, is the first thing to measure.
3. The network team wants to enable 'Selected networks' on the storage account firewall to restrict access to the corporate range. What breaks, what does not, and what is the correct configuration?
Read the worked answer
What the setting does. Switching the storage firewall to 'Selected networks' flips the public endpoint's default action from Allow to Deny. Only the virtual networks, subnets, and public IP ranges you list, plus the 'Allow trusted Microsoft services' exception if enabled, can reach the account over the public endpoint. Traffic through a private endpoint arrives over the private IP in your VNet and is governed by the private endpoint connection and NSGs, not by the public firewall rules - so the AKS workload does not break because of the firewall change.
What does break, if you are not careful. Anything that resolves the account to its public IP. If the private DNS zone privatelink.blob.core.windows.net is only linked to the VNet hosting the private endpoint and not to the peered VNet where the AKS cluster runs, pods resolve the public FQDN, get the public IP, and are then blocked by the new default-deny. Split-horizon DNS is the usual culprit, and AKS with its own DNS configuration is a common place to get it wrong. Corporate users hitting the public endpoint also stop working unless their egress range is listed.
Correct sequence. (1) Verify the private endpoint connection is Approved. (2) Link the private DNS zone to every VNet that must resolve the account, including the peered AKS VNet, and confirm from inside a pod that the name resolves to the 10.x private address. (3) Add the AKS subnet and any corporate egress range to the firewall's selected networks if they still need the public path. (4) Only then set the default action to Deny. (5) If no workload needs the public endpoint, go further and set Public network access to Disabled, which is the stronger posture.
Verify before and after. Test resolution and a PUT/GET from the AKS subnet and from a corporate device; check storage diagnostic logs or the StorageBlobLogs table for authorization failures after the change.