When working with Azure Storage Accounts configured in a private network, you may occasionally face connectivity issues, especially during programmatic operations like inserting entities into a Table Storage. Recently, while inserting a new entity, we encountered the following error:
ERROR:
The request may be blocked by network rules of storage account.
Please check network rule set using
'az storage account show -n accountname --query networkRuleSet'.
If you want to change the default action to apply when no rule matches,
please use 'az storage account update'.
This error clearly indicates that the network rules on the storage account are blocking the request. Here’s how we debugged and resolved the issue.
🧪 Problem Context
Our setup involves:
- A private endpoint-enabled Azure Storage Account.
- IP whitelisting done dynamically during the pipeline using GitHub Actions.
- The following command used to allow the runner’s IP address:
az storage account network-rule add \
--resource-group ${{ vars.RESOURCEGROUP_NAME }} \
--account-name ${{ vars.STORAGEACCOUNT_NAME }} \
--action Allow \
--ip-address ${{ steps.ip.outputs.ipv4 }} \
-o none --only-show-errors
Despite successfully executing this command, any immediate operation (like inserting into Table Storage) would fail with the aforementioned error.
🔍 Root Cause
Azure’s network rule updates—such as IP whitelisting—are not instantaneous. Even though the az command returns success, the rules can take 5 to 30 seconds to fully propagate across Azure’s networking stack.
This propagation delay means that your request may still be blocked right after whitelisting, resulting in transient errors.
✅ Resolution
To work around this, we added a short delay after the IP whitelist command before initiating any storage operations. Here’s a sample shell script update:
echo "Whitelisting IP: ${{ steps.ip.outputs.ipv4 }}"
az storage account network-rule add \
--resource-group ${{ vars.RESOURCEGROUP_NAME }} \
--account-name ${{ vars.STORAGEACCOUNT_NAME }} \
--action Allow \
--ip-address ${{ steps.ip.outputs.ipv4 }} \
-o none --only-show-errors
echo "Waiting for network rule to propagate..."
sleep 30 # Adjust between 5-30 seconds based on testing
# Now perform the table insert operation
💡 Pro Tips
- Use retries: If you’re automating this via scripts or CI/CD pipelines, consider implementing a retry mechanism instead of a fixed sleep.
- Log current rules: Use the following command to verify if the IP is indeed whitelisted:
az storage account show -n <account-name> --query networkRuleSet.ipRules - Audit Logs: Check Azure Activity Logs for insights into rule application times.
🧾 Conclusion
When dealing with Azure Storage Accounts in a private network, remember that network rule changes aren’t immediate. Always plan for a short delay or retry logic to handle propagation time. This small adjustment can save hours of confusion and debugging.
Techy Chalkboard in bits and pieces 
You must be logged in to post a comment.