Storage network access — public network access, firewall rules, private endpoints and perimeters
How a storage account decides which networks reach its data — publicNetworkAccess (Enabled, Disabled, SecuredByPerimeter), defaultAction and bypass, IP rules and why they can't admit same-region Azure callers, VNet rules with service endpoints, resource instance rules, trusted services, fixed rule limits, private endpoints per sub-resource with their privatelink DNS zones, network security perimeter limitations, and the control-plane exemption.
markdownreferencev1X03P-XYC6stage: designtrust: officialtrust: fieldservice: storageinterface: iacinterface: cliAuthorizationFailure firewallpublicNetworkAccess DisabledSecuredByPerimeternetworkAcls defaultAction Denybypass AzureServices Logging MetricsIP network rule private address not allowed/31 /32 storage IP rulesame region IP rule no effectservice endpoint Microsoft.Storagevirtual network rule storageresource instance ruletrusted Azure services storage400 IP rules200 resource instance rulesprivate endpoint blob dfsprivatelink.blob.core.windows.netprivatelink.dfs.core.windows.netnetwork security perimeter storageTransition mode Enforced modeaz storage account network-rule adddefaultAction Allow with publicNetworkAccess Disabled
Storage network access
Network rules decide whether a request reaches the account at all; authorization comes after. A request the network refuses gets 403 AuthorizationFailure This request is not authorized to perform this operation., whatever role the caller holds. Firewall rules apply to the data plane only: control-plane calls (create a container through ARM, change settings, list keys) aren't filtered, which is why the portal can list containers it can't open.
The settings
| Property | Values | Effect |
|---|---|---|
publicNetworkAccess | Enabled, Disabled, SecuredByPerimeter | Disabled: only private endpoints (and previously configured resource instances and trusted-service exceptions, which stay in effect). SecuredByPerimeter: the network security perimeter's rules decide |
networkAcls.defaultAction | Allow (spec default), Deny | Deny turns the firewall on: only listed IPs, subnets, resource instances and bypassed services get in |
networkAcls.bypass | AzureServices (default), Logging, Metrics, None | Exceptions for trusted services and for reading logs and metrics |
networkAcls.ipRules | Public IPv4 addresses or CIDR | See restrictions below |
networkAcls.virtualNetworkRules | Subnet IDs | The subnet needs the Microsoft.Storage service endpoint; any subscription or tenant |
networkAcls.resourceAccessRules | Resource ID + tenant ID | Admits one Azure resource (or all of a type in a tenant, subscription or group) through the firewall |
A template that sets publicNetworkAccess: Disabled but leaves defaultAction: Allow is closed (public network access wins), but Defender for Storage and Advisor still flag it. Set defaultAction: Deny too; the portal, CLI and PowerShell do that for you.
IP rules: restrictions that cause most 403s
- Public internet addresses only. RFC 1918 ranges (10.x, 172.16–31.x, 192.168.x) aren't allowed.
- No /31 or /32 prefixes: add those addresses individually. IPv4 only in Learn's rules (CLI 2.91 shows
--ipv6-addressas preview). - IP rules have no effect on callers in the same Azure region. Same-region services reach the account over private Azure addresses, so you can't admit (or block) App Service, Functions or a VM in that region by its public outbound IP. Use a VNet rule (VNet-integrated app, subnet with the service endpoint) or a private endpoint.
- Clients in the paired region inside a VNet with a service endpoint also bypass IP rules.
Field report, consistent with this: a 403 AuthorizationFailure where the logs showed the caller as a 10.x address that no IP rule could cover.
Who else gets in
- Resource instance rules admit a resource's network traffic, not its data: the resource's system-assigned managed identity still needs a data role.
- Trusted Azure services (
bypass: AzureServices): a fixed list of services registered in the same Entra tenant, for listed operations (Azure Backup, Data Box, Data Explorer, Event Grid, Event Hubs Capture, File Sync and others). App Service and Functions aren't on it. - SAS IP restrictions (
sip) narrow a SAS; they never grant access the firewall denies.
Fixed limits per account: 400 IP rules, 400 virtual network rules, 200 resource instance rules.
Private endpoints
- One private endpoint per target sub-resource: Blobs, Data Lake Storage, Files, Queues, Tables or Static Websites. For read access to a geo-redundant secondary, a separate endpoint for the secondary instance; failover needs none, the endpoint follows the new primary.
- ADLS Gen2 needs both
blobanddfs. Some operations (managing ACLs, creating and deleting directories) need thedfsendpoint. - DNS: the public name gets a CNAME to
<acct>.privatelink.<service>.core.windows.net; the private DNS zone (privatelink.blob.core.windows.net,privatelink.dfs.core.windows.net,privatelink.file.core.windows.net,privatelink.queue.core.windows.net,privatelink.table.core.windows.net) must be linked to every VNet that resolves it, or custom DNS must forward to it. Clients keep using the normal<acct>.blob.core.windows.netURL. - Private endpoints aren't affected by firewall rules. Don't cache the account's IP address, and honour DNS TTLs.
- DNS failures look like timeouts, not 403s: the networking family covers diagnosis.
Network security perimeter
publicNetworkAccess: SecuredByPerimeter puts the account under a perimeter's inbound and outbound rules. In Enforced mode only HTTPS works: NFS, SMB and SFTP are blocked. Not supported with a perimeter: object replication, static website, Azure Backup, unmanaged disks. For customer-managed keys the Key Vault must be reachable from inside the perimeter. In Transition mode the firewall still applies as a fallback, so success there doesn't prove the perimeter allows the traffic.
CLI
# Turn the firewall on, then admit a subnet (service endpoint required) and a public IP
az storage account update -n <acct> -g <rg> --default-action Deny --bypass AzureServices
az storage account network-rule add -n <acct> -g <rg> --vnet-name <vnet> --subnet <subnet>
az storage account network-rule add -n <acct> -g <rg> --ip-address <public-ip>
az storage account network-rule list -n <acct> -g <rg>These change what can reach the account's data: confirm with your human before running them on a live account.