Common Anti-Patterns¶
Use this page to catch recurring Azure Storage design mistakes before they turn into incidents, audit gaps, or runaway cost.
This page's baseline at a glance — the recommended practices and the validation gate:
mermaid flowchart TD T["Common Anti-Patterns"] P1["Split workloads by security boundary"] T --> P1 P2["Treat Shared Key and broad SAS usage as"] T --> P2 P3["Validate tiering choices with actual access patterns and"] T --> P3 P4["Keep operational ownership explicit for backup"] T --> P4 V["Validation Checklist"] P1 --> V P2 --> V P3 --> V P4 --> V
Why This Matters¶
Anti-patterns are usually visible early, but they are easy to normalize when teams optimize for speed over clarity.
- Mixed-purpose accounts blur ownership and blast radius.
- Broad access paths stay in place long after the original shortcut is forgotten.
- Tiering and lifecycle mistakes compound over time because the data keeps growing.
Recommended Practices¶
- Split workloads by security boundary, access pattern, and lifecycle ownership.
- Treat Shared Key and broad SAS usage as exceptions that need review.
- Review public network exposure and firewall exceptions together.
- Validate tiering choices with actual access patterns and recovery expectations.
- Keep operational ownership explicit for backup, lifecycle, and cost decisions.
Example review command¶
az storage account show \
--resource-group $RG \
--name $STORAGE_NAME \
--query "{publicNetworkAccess:publicNetworkAccess,allowSharedKeyAccess:allowSharedKeyAccess,accessTier:accessTier,sku:sku.name}" \
--output json
| Command | Purpose |
|---|---|
az storage account show | Surface the control settings that most often reveal storage anti-patterns. |
--resource-group | Resource group that contains the storage account. |
--name | Name of the storage account to inspect. |
--query | JMESPath expression selecting high-signal anti-pattern indicators. |
--output | Output format for the result. |
Common Mistakes / Anti-Patterns¶
- One account for every workload: Shared boundaries make lifecycle, network, and permission decisions conflict.
- Long-lived broad access: Shared Key, wide SAS, and public paths accumulate risk quietly.
- Uniform tiering: Hot and archival data should not automatically share the same retention logic.
Validation Checklist¶
- [ ] Workloads are separated by security or lifecycle boundary where needed.
- [ ] Shared Key and SAS usage are reviewed and justified.
- [ ] Public network exposure is intentionally configured.
- [ ] Tiering and lifecycle rules match real access patterns.
- [ ] Ownership for operations and exceptions is explicit.