Fabrikam: Private Endpoint Reachability and Cold Blob Tiering

The firewall is not the whole story - name resolution is.

The private endpoint exposes the blob service on a private IP inside a VNet-Prod subnet. With no public networks allowed, requests arriving at the public endpoint are rejected. On-premises clients resolve stfabprod.blob.core.windows.net through on-premises DNS, which returns the public IP. The VPN carries the packet, but it arrives at the public front end from the on-premises egress address, so the storage firewall rejects it - 403, not a timeout, because the request reached the service and was refused.

Fix (DNS first, then confirm the path):

1. Deploy an Azure DNS Private Resolver inbound endpoint in VNet-Prod (or a forwarder VM pair) and note its private IP.
2. On the on-premises DNS servers, create a conditional forwarder for blob.core.windows.net (or the narrower privatelink.blob.core.windows.net) to that resolver IP.
3. Ensure the private DNS zone is linked to the VNet that hosts the resolver - it already is (VNet-Prod).
4. Verify with nslookup stfabprod.blob.core.windows.net from an on-premises client: it must return the private endpoint IP, not a public address.

Adding the on-premises public IP to the storage firewall would also stop the 403, but it re-exposes the account publicly and defeats the private endpoint.

No - it over-cools the active set and under-tiers the dormant set.

The 40 TB read monthly should stay hot-tiered; paying cool-tier storage and access charges buys nothing. The 80 TB read twice a year is a candidate for a colder tier, and the requirement that it be retrievable within 24 hours is the constraint that decides between cold and archive.

Practical shape:

• Hot for the 40 TB working set. Consider reserved capacity for the predictable baseline - it is a commitment on capacity, not on tier, so it does not block later re-tiering.
• Cold or Archive for the 80 TB compliance set. Archive rehydration at standard priority can take up to 15 hours, which fits inside 24 hours; high priority is faster but costs more and only suits smaller blobs.
• Apply rules with prefix or blob-index-tag filters rather than account-wide, and split the two data sets into separate accounts or containers so retention and lifecycle rules do not collide.

Watch the penalties: cool has a 30-day minimum, cold 90 days, archive 180 days. Blobs deleted, overwritten or re-tiered before the minimum incur early-deletion charges - so a rule that thrashes between tiers can cost more than it saves. Test on a sample container for a billing cycle before enabling account-wide.

State the rehydration path and its worst case.

• Archive blobs are offline. Retrieval requires a rehydrate operation to hot/cool/cold; standard priority is documented at up to 15 hours, and high priority is typically under an hour for smaller blobs.
• 15 hours < 24 hours, so the objective is met - but only if the operational runbook includes: who raises the rehydrate request, how the completion is detected (blob ArchiveStatus clears), and a buffer for a partial failure and retry.

What would invalidate the assurance:

1. Blobs that have not yet finished the asynchronous tier change - a lifecycle rule set to archive is not instantaneous, so check ArchiveStatus across the container.
2. Early deletion if a blob is re-tiered or overwritten inside the 180-day archive minimum - it does not break retrievability but changes cost.
3. Immutability or legal-hold policies that a rehydrate does not override (it should not), and any lock that prevents the restore workflow from running.
4. A large simultaneous request: rehydration is per blob and throughput-bound, so a bulk 80 TB pull is a different problem from a single-record retrieval. Quantify the realistic request size in the assurance.