Skip to article
Storage Storage networking

Storage network rules

The selected-network rules that control which sources can reach an Azure Storage account public endpoint.

Source: Microsoft Learn - Azure Storage firewall rules Reviewed 2026-05-26

Exam trap
Assuming a network rule grants blob or queue permissions when it only controls reachability.
Production check
Show networkRuleSet and verify defaultAction is Deny only after required allow rules exist.
Practice this topic Microsoft Learn
Article details and learning context
Aliases
storage account network rules, storage firewall rules, storage network ACLs, selected network access, storage account firewall allowlist
Difficulty
Intermediate
CLI mappings
5
Last verified
2026-05-26
Review level
field-manual
Article depth
field-manual-complete
Compare related concepts Search related resources Browse the glossary

Understand the concept

In plain English

Storage network rules are the allow-list settings behind the storage firewall. They decide which networks, public IP ranges, specific Azure resource instances, or trusted service paths can try to reach a storage account through its public endpoint. They do not give anyone permission to read blobs, files, queues, or tables. Credentials and identity still matter. The rules simply narrow the network locations where those credentials can be used, which is why operators treat them as a boundary control rather than a data permission.

Why it matters

This matters because storage exposure is often wider than teams believe. A storage account can have strong RBAC and still accept public endpoint traffic from every network unless the firewall is configured. Network rules give the team a measurable boundary: these subnets, IP ranges, or resource instances can reach the account, and everything else is denied. They also explain many production incidents. A valid SAS token can fail after a NAT address changes, and a backup job can stop when a subnet rule is missing. Good network rules make audits clearer, migrations safer, and credential compromise less useful to an attacker.

Official wording and source

Azure Storage network rules define which sources can connect to a storage account's public endpoint. Microsoft Learn describes virtual network rules, IP network rules, resource instance rules, and trusted service exceptions. When rules are configured, only explicitly allowed sources can access the account; authorization still applies.

Open Microsoft Learn

Technical context

In Azure architecture, storage network rules live on the storage account networkRuleSet in the control plane. They affect data-plane reachability for Blob, File, Queue, Table, DFS, and static website endpoints that still use public endpoint access. The rule set includes defaultAction, publicNetworkAccess, bypass, ipRules, virtualNetworkRules, and resourceAccessRules. It interacts with service endpoints, private endpoints, DNS, NAT egress, Azure Policy, diagnostic logging, and data authorization. It is managed at the account level, not at individual container or queue scope.

Exam context

Compare with

Storage firewall network rule Storage private endpoint Service endpoint for Storage

Where it is used

Where you see it

  1. In the storage account Networking blade, selected network settings show default action, public network access, IP rules, virtual network rules, resource instances, and trusted services.
  2. In Azure CLI output, networkRuleSet reveals bypass, ipRules, virtualNetworkRules, resourceAccessRules, and whether unmatched public endpoint traffic is allowed or denied. during audits, migrations, incident response, and automated drift checks clearly for review.
  3. In diagnostic logs or failed clients, missing rules often appear as access failures immediately after firewall lockdown, NAT changes, subnet moves, or hosted agent changes.

Common situations

  • Restrict a production storage account so only approved application subnets and corporate egress ranges can reach the public endpoint.
  • Keep one legacy on-premises uploader working during a private endpoint migration without opening the account to all networks.
  • Remove stale vendor IP exceptions after a project ends and prove the cleanup with exported networkRuleSet evidence.
  • Troubleshoot why a valid SAS token works from one network but fails from a new hosted build agent.
  • Audit storage accounts for defaultAction Allow, broad CIDR ranges, or trusted-service bypass settings without clear ownership.

Illustrative Azure scenarios

These examples show how the concept can affect design and operations. They are illustrative scenarios, not customer claims.

Scenario 01 Logistics operator limits scanner uploads Scenario, objectives, solution, measured impact, and takeaway.
Scenario

A port logistics operator used Azure Storage for container scan images collected from handheld devices. The account still accepted public endpoint traffic from any network, including retired warehouse Wi-Fi ranges.

Goals
  • Limit uploads to active warehouse NAT ranges and one operations subnet.
  • Keep scanner synchronization above the shift-change service target.
  • Remove retired network exceptions before a customs audit.
  • Create clear evidence for security and operations teams.
Approach using Storage network rules

Engineers exported networkRuleSet configuration for each scan account and matched every IP rule to a live facility. Retired Wi-Fi ranges were removed, while active warehouses were routed through two documented NAT gateways. The operations subnet received a virtual network rule after service endpoints were verified. Before switching defaultAction to Deny, the team ran upload tests from each warehouse shift and recorded success metrics. Diagnostic logs were monitored for denied requests, and a temporary emergency rule process required a named incident commander and 24-hour expiry. The final runbook explained that scanner credentials were still required; network rules only controlled where those credentials could be used.

Potential outcomes
  • Removed 18 stale IP rules and reduced allowed public sources by 72 percent.
  • Maintained 99.4 percent scan upload success during the first full week after lockdown.
  • Cut access review preparation from four days to one afternoon using CLI exports.
  • Passed the customs data audit without reopening broad public network access.
What to learn

Storage network rules turn vague perimeter intent into testable, owned, and reviewable access paths.

Scenario 02 University research cluster separates lab access Scenario, objectives, solution, measured impact, and takeaway.
Scenario

A university research computing group stored climate simulation outputs in Azure Blob Storage. Multiple labs needed access, but graduate students had added broad temporary IP ranges during grant deadlines.

Goals
  • Permit access only from approved lab VPN egress and the HPC subnet.
  • Stop personal networks from reaching unpublished research data.
  • Preserve nightly dataset export jobs during firewall cleanup.
  • Give principal investigators a quarterly review report.
Approach using Storage network rules

The cloud team grouped rules by lab, owner, and funding project. Personal broadband IPs were removed first, then the team introduced a virtual network rule for the HPC subnet that produced nightly exports. Lab VPN egress ranges stayed as IP rules because some analysis tools still ran off campus. A script compared approved rule inventory with live networkRuleSet output and highlighted any new exception. Researchers tested download and upload workflows from the VPN and from the HPC scheduler before the default action changed. The review packet included rule owner, grant identifier, affected storage accounts, and the last successful workflow test.

Potential outcomes
  • Reduced unmanaged individual IP exceptions from 37 to zero.
  • Kept nightly exports under the two-hour processing window after rules changed.
  • Blocked three attempted accesses from personal networks during the first month.
  • Gave 14 principal investigators a reusable review report with no portal screenshots.
What to learn

For research storage, network rules protect collaboration only when exceptions map to real labs and tested workflows.

Scenario 03 Animation studio protects render cache storage Scenario, objectives, solution, measured impact, and takeaway.
Scenario

An animation studio used Azure Storage for render cache files shared between cloud render nodes and an on-premises asset pipeline. The firewall rules had grown during several rushed production releases.

Goals
  • Allow render nodes and the asset pipeline without exposing cache storage broadly.
  • Remove abandoned vendor and contractor IP ranges.
  • Avoid missed render deadlines during rule cleanup.
  • Detect emergency access changes during final delivery week.
Approach using Storage network rules

Platform engineers separated the cache accounts by show and listed the network rules for each one. Cloud render subnets were converted to virtual network rules, while the on-premises asset pipeline used a single static egress range. Old contractor IP entries were disabled during a controlled render test, then removed after no denied traffic appeared. The team documented a break-glass path for deadline emergencies, but any addition triggered an Activity Log alert and a daily review by production engineering. CLI output was attached to the delivery readiness checklist so supervisors could see that cache storage was reachable only from approved production paths.

Potential outcomes
  • Removed 21 obsolete contractor and vendor IP entries across five cache accounts.
  • Completed a 6,000-frame render test with no network-related job failures.
  • Detected one unauthorized portal-added IP rule within five minutes.
  • Reduced final-week storage access questions from 31 tickets to nine.
What to learn

Storage network rules are production controls when creative deadlines depend on fast access and controlled exceptions.

Azure CLI

As an Azure engineer, I use CLI for storage network rules because the portal is too slow for estate reviews and too easy to misread during incidents. CLI shows defaultAction, publicNetworkAccess, bypass, IP rules, subnet rules, and resource access rules in one repeatable output. That output can be copied into a change record, compared across subscriptions, or turned into a policy report. It also makes rollback practical. When a production account is locked down, I want exact before-and-after JSON, not screenshots and memory.

Useful for

  • List network rules across storage accounts and export the allowed IP ranges, subnets, and bypass settings for an access review.
  • Add one approved IP rule during a migration window, then remove it after traffic moves to a private endpoint.
  • Compare production and staging networkRuleSet values before promoting a Bicep template or Terraform module.
  • Confirm publicNetworkAccess and defaultAction before blaming RBAC for a storage access failure.
  • Generate evidence showing which source networks could reach regulated storage at a specific change date.

Before you run a command

  • Confirm tenant, subscription, resource group, storage account name, and whether the target account is production.
  • Identify the real caller source as public NAT address, subnet resource ID, resource instance, private endpoint, or trusted service path.
  • Check whether the workload should use a private endpoint instead of adding another public endpoint exception.
  • Capture the current networkRuleSet as JSON so rollback does not depend on portal screenshots.
  • Coordinate with network and application owners before setting defaultAction to Deny or disabling public network access.

What the output tells you

  • defaultAction tells whether sources not listed in rules are allowed or denied through the public endpoint.
  • ipRules and virtualNetworkRules show the exact public ranges and subnet IDs that can attempt data-plane access.
  • bypass indicates whether trusted Azure services or logging paths have exceptions outside the normal rule list.
  • publicNetworkAccess shows whether the public endpoint is enabled, selected-network controlled, or disabled for normal clients.
  • Provisioning states and subnet IDs help confirm whether a rule references the intended network resource.

Mapped commands

Storage network rule operations

manages 
az storage account show --name <storage-account> --resource-group <resource-group> --query networkRuleSet
az storage accountdiscoverStorage
read-only Microsoft Learn 
az storage account network-rule list --account-name <storage-account> --resource-group <resource-group>
az storage account network-rulediscoverStorage
read-only Microsoft Learn 
az storage account network-rule add --account-name <storage-account> --resource-group <resource-group> --ip-address <cidr-or-ip>
az storage account network-rulesecureStorage
security-impacting Microsoft Learn 
az storage account network-rule add --account-name <storage-account> --resource-group <resource-group> --subnet <subnet-resource-id>
az storage account network-rulesecureStorage
security-impacting Microsoft Learn 
az storage account update --name <storage-account> --resource-group <resource-group> --default-action Deny
az storage accountsecureStorage
security-impacting Microsoft Learn

Architecture context

Architecturally, storage network rules sit between open public access and a private endpoint-only design. I use them when a storage account still needs public endpoint access from known locations, such as an on-premises NAT range, an integration subnet, a partner egress address, or an Azure resource that cannot be isolated another way. The design must define the intended traffic path, the owner of each exception, and the exit plan for temporary rules. Private endpoints may still be the target state. Network rules are the governed exception set that keeps public endpoint access controlled while that architecture evolves.

Security
Security impact is direct because network rules reduce where storage credentials can be used. They help contain leaked account keys, broad SAS tokens, compromised build agents, and overprivileged identities by requiring an approved network source. They also create concrete audit evidence for selected-network access. The risk is false confidence: a network rule does not authenticate the caller, encrypt data, or inspect payloads. Security teams should pair rules with Microsoft Entra authorization, short-lived SAS, Shared Key restrictions where possible, Defender alerts, and policy checks that prevent defaultAction from drifting back to Allow. Reviews should also confirm who approves temporary exceptions, where evidence is recorded, and when every exception expires.
Cost
The rules themselves are not separate billing meters, but the architecture around them changes cost. Tightening public access may require private endpoints, DNS zones, NAT Gateway, VPN, ExpressRoute, or more diagnostic log ingestion. Loose rules can create incident response, audit, and data exposure costs that are harder to measure. Overly strict rules can create failed jobs, retry storms, and emergency engineering time. FinOps review should connect each rule to an owner and data path. A rule with no owner is not free; it is security debt waiting to become operational cost. The review should separate justified private connectivity spend from accidental public endpoint troubleshooting labor.
Reliability
Reliability impact appears whenever a workload depends on reaching storage. A missing IP rule can break nightly imports, a subnet rule can fail if service endpoints are removed, and a public endpoint lockdown can interrupt backup, monitoring, deployment, or support tooling. Reliable changes start with dependency mapping and tests from the actual runtime network, not just an administrator workstation. Teams should stage allow rules before changing the default action, keep rollback commands ready, and include disaster recovery sources. Correct rules reduce exposure; careless rule edits create outages that look like application or credential failures. A named rollback owner should be assigned before any deny-by-default network change is enforced.
Performance
Storage network rules do not increase account throughput or lower latency directly. Their performance effect is indirect because they determine which network path a client can use. A workload forced through a slow VPN or unstable NAT path may see retries and delayed processing. A workload using a planned subnet or private path has more predictable routing. During performance incidents, operators should separate storage service limits from firewall denies, DNS mistakes, SNAT exhaustion, and client retry behavior. CLI inventory also improves operational speed by finding the one misconfigured account quickly. Teams should compare the rule set with observed client locations before blaming storage latency alone.
Operations
Operators inspect storage network rules during provisioning, access reviews, migrations, and 403 investigations. They list current rules, identify the real caller source address, verify subnet service endpoints, remove stale partner ranges, and confirm whether private endpoints should be used instead. The work is cross-team because network, security, application, and data owners all affect the final rule set. Mature operations keep rules in infrastructure code, require ticket ownership and expiry dates, export evidence with CLI, and alert on changes to defaultAction, bypass, or publicNetworkAccess. Without review, exceptions become hidden access debt. Operators should also record the ticket, approver, and expected cleanup date for every temporary allow entry.

Common mistakes

  • Assuming a network rule grants blob or queue permissions when it only controls reachability.
  • Using a large corporate CIDR because the actual NAT or hosted agent egress address was not found.
  • Changing defaultAction before adding backup, monitoring, deployment, failover, and support sources.
  • Leaving temporary partner or migration IP ranges in place long after the project ends.
  • Forgetting that private endpoints bypass the storage firewall differently from public endpoint network rules.