Azure Blob Storage Footguns¶
1. Treating a storage account like an S3 bucket¶
The storage account is a broader blast-radius boundary that can contain Blob, Queue, Table, and Files services and shares redundancy/network/key settings.
2. Confusing management-plane Contributor with data access¶
Contributor can create containers or change network settings but may still receive 403 reading blob contents. Assign a Storage Blob Data ... role.
3. Using account keys in application configuration¶
Account keys are effectively root-like credentials for the account's supported data services. Rotation is disruptive if clients embed them.
4. Assuming SAS issuance is centrally auditable¶
SAS use can be logged, but the act of generating many SAS tokens is not inherently visible to the account owner. Restrict who can generate them and prefer short-lived user delegation SAS. (Microsoft Learn: SAS overview)
5. Forgetting Shared Key is allowed by default¶
Disabling it is a deliberate configuration change and can break tools, Terraform modules, mounts, legacy SDKs, and Functions storage dependencies.
6. Archive is offline¶
An archived blob cannot be read directly. Rehydration can take hours and incurs retrieval/rehydration charges.
7. Early deletion charges¶
Moving or deleting Cool, Cold, or Archive data before the minimum retention period can result in charges for the remaining period.
8. Versioning/soft delete cost explosion¶
Every overwrite or delete can preserve another full billable copy. High-churn large blobs are especially dangerous.
9. Lifecycle policy timing is nondeterministic¶
A rule becoming eligible does not guarantee immediate transition/deletion.
10. HNS is effectively irreversible¶
Enabling hierarchical namespace changes semantics, API behavior, ACL design, and feature compatibility.
11. Private endpoint DNS is the usual failure point¶
A private endpoint without correct DNS can leave clients resolving the public endpoint and failing with 403/timeouts.
12. Service endpoints are not private endpoints¶
A service endpoint keeps the service's public endpoint and changes trust/routing from the subnet. Private Link gives the service a private IP in your VNet.
13. Geo-replication is asynchronous¶
GRS/GZRS can lose the newest writes during a regional failure and failover.
14. RA-GRS reads are not automatic application failover¶
The application must use the secondary endpoint or a client strategy that supports it.
15. Redundancy is account-wide¶
Mixing high-durability data and cheap scratch data in one account can force the expensive redundancy choice onto both.
16. Public access has two gates¶
Account-level permission for anonymous access and container-level public access both matter.
17. Blob name "folders" are not directories without HNS¶
Rename of a virtual directory can require copy/delete of many objects.
18. Immutability can make mistakes permanent until expiry¶
Once a time-based retention policy is locked, shortening it or deleting protected data is intentionally constrained.
19. Soft delete and immutability interact¶
Retention and deletion behavior must be tested; do not assume enabling every protection feature creates a simple recovery model.
20. Object replication has feature restrictions¶
HNS, archive state, encryption configuration, and account failover can constrain support. Verify the current matrix before design.