Storage account public network access controls whether the account can be reached through its public Azure Storage endpoints. When it is enabled, network rules, IP rules, virtual network rules, and trusted-services settings decide which public-path requests are allowed. When it is disabled, clients generally need private endpoints or another approved private path. This setting is not the same as authentication. A caller may have valid credentials but still be blocked by the network boundary. It is one of the clearest switches for reducing storage exposure.
public access for storage account, storage public network access, storage public endpoint access, publicNetworkAccess
Difficulty
advanced
CLI mappings
5
Last verified
2026-05-25
Microsoft Learn
Public network access is the storage account setting that controls whether requests can reach the account through public Azure Storage endpoints. Teams pair it with firewalls, virtual network rules, trusted-services exceptions, and private endpoints to decide whether only private network paths should be allowed.
Technically, public network access sits on the storage account control plane and affects data-plane reachability for public endpoints. It works alongside networkRuleSet, defaultAction, bypass settings, private endpoint connections, service endpoints, and diagnostic logging. Architects use it to define whether a storage account accepts traffic from internet-routable Azure Storage endpoints or only from private connectivity. Operators often check it before investigating authorization errors because a 403 can come from network denial rather than bad credentials. Policy can audit or deny accounts that allow public access in sensitive environments.
Why it matters
Public network access matters because many storage incidents start with data reachable from broader network paths than intended. The setting gives teams a blunt but powerful boundary: public endpoint traffic is either allowed under rules or blocked in favor of private access. It helps security teams enforce private-only storage for regulated systems, reduces exception sprawl, and gives migration teams a controlled cutover point. The danger is operational. Turning it off too early can break build agents, integration runtimes, Functions, analytics tools, or partner uploads that still use public endpoints. Good practice is to inventory callers, prove private resolution, and then disable public access deliberately.
⌁
Where you see it
Signals, screens, and Azure surfaces where this term usually becomes operational.
Signal 01
In the storage account Networking blade, the public network access option appears with firewall rules, virtual network rules, trusted-services bypass, and private endpoint settings for production accounts.
Signal 02
In CLI output, publicNetworkAccess and networkRuleSet.defaultAction reveal whether public endpoints are reachable, restricted to selected networks, or effectively blocked during reviews, incidents, and migration cutovers.
Signal 03
In Azure Policy compliance views, noncompliant storage accounts may be flagged when public network access is enabled outside approved subscriptions or environments after each deployment wave.
✦
When this becomes relevant
Specific situations where this term helps solve real Azure design, operations, migration, security, reliability, cost, or governance problems.
Disable public storage endpoints after private endpoint DNS validation proves production clients use private paths.
Keep a tightly scoped public exception during partner file uploads while planning a future private transfer pattern.
Audit every storage account that still allows public endpoint traffic in regulated or confidential workloads.
Separate network-denied 403 responses from identity-denied 403 responses during storage access incidents.
Use policy and CLI evidence to prove temporary public access exceptions were removed after migration.
◆
Real-world case studies
Different enterprise-style examples that show the term being used to hit measurable objectives.
Case study 01
University research data moves to private-only storage
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
A university research computing group used Blob Storage for genomic datasets. A grant compliance review required proof that sensitive datasets were not reachable through public storage endpoints.
🎯Business/Technical Objectives
Identify every storage account with public endpoint access enabled.
Move authorized analysis jobs to private endpoint paths without delaying active research.
Keep a temporary exception for one external sequencing partner with an expiry date.
Produce compliance evidence that public access was disabled for restricted datasets.
✅Solution Using Storage account public network access
The cloud team used CLI to export publicNetworkAccess, networkRuleSet, bypass settings, private endpoint connection state, and account tags. They classified accounts by dataset sensitivity, created private endpoints for restricted accounts, and tested DNS from research VM pools and managed notebooks. One sequencing partner kept a narrow IP-rule exception for thirty days while a private transfer process was built. After validation, the team disabled public network access on restricted accounts and added Azure Policy reporting for any future drift.
📈Results & Business Impact
Restricted accounts with public access enabled fell from 31 to zero in five weeks.
Analysis job failures during cutover stayed under 1 percent because private DNS was tested per compute pool.
The partner exception expired on schedule and was removed without a second review cycle.
Compliance evidence preparation dropped from ten staff-days to two because CLI output became the control record.
💡Key Takeaway for Glossary Readers
Public network access is a governance boundary that becomes safer when every exception has an owner and expiry.
Case study 02
Media agency stops accidental public-path restores
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
A digital media agency restored archived customer assets from Storage during campaign launches. Restore workers kept failing after a security team tightened firewall rules but left the public access setting inconsistent across accounts.
🎯Business/Technical Objectives
Separate network-denied failures from bad SAS token failures during restores.
Standardize public access posture for campaign asset accounts.
Keep partner download workflows running until private delivery was ready.
Reduce launch-day troubleshooting caused by inconsistent storage network settings.
✅Solution Using Storage account public network access
Operations exported account networking settings with CLI and found three patterns: fully public accounts, selected-network accounts, and private-only accounts. The team mapped each restore worker to its network path, replaced broad public access with selected network rules for partner downloads, and moved internal restore workers to private endpoints. They added a pre-launch check that fails if publicNetworkAccess, defaultAction, and private endpoint state do not match the campaign template. Diagnostic logs were used to distinguish network denials from expired SAS URLs.
📈Results & Business Impact
Launch-day restore incidents fell from 22 in the previous quarter to four.
Average troubleshooting time dropped from 75 minutes to 18 minutes per failed restore.
Twelve broad public accounts were converted to selected-network or private-only posture.
Partner download availability stayed above 99.5 percent during the transition period.
💡Key Takeaway for Glossary Readers
A clear public network access standard prevents storage failures from looking like random credential problems.
Case study 03
Insurance analytics locks down actuarial exports
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
An insurance analytics team exported actuarial models to storage accounts used by internal analysts and a few vendors. A leaked vendor IP allowlist caused concern that public access exceptions were too easy to forget.
🎯Business/Technical Objectives
Create an inventory of public access settings and firewall exceptions.
Move internal analysts to private connectivity while preserving vendor delivery windows.
Alert whenever production public network access is re-enabled.
Reduce the number of people allowed to change storage network posture.
✅Solution Using Storage account public network access
The platform team queried all analytics accounts and joined the output with tags for data classification and owner. Accounts holding model outputs were moved to private endpoints, while vendor-facing accounts kept selected-network access with named IP rules and expiration metadata. Azure Policy flagged public access outside approved scopes, and activity-log alerts notified security when publicNetworkAccess changed. CLI commands were added to monthly control testing so auditors could see exact settings without relying on portal screenshots.
📈Results & Business Impact
Public access exceptions fell from 47 to 11, each with documented owner and expiry.
No actuarial export jobs missed their nightly SLA during the private endpoint migration.
Unauthorized network posture changes were detected within eight minutes instead of during monthly review.
The access-change approver group shrank from 26 administrators to six platform owners.
💡Key Takeaway for Glossary Readers
Public endpoint reachability is manageable only when inventory, ownership, and alerts exist before the next exception request.
Why use Azure CLI for this?
I use CLI for public network access because it is a high-impact switch that should never depend on memory of portal clicks. CLI lets an engineer capture the current publicNetworkAccess value, default network action, bypass list, IP rules, virtual network rules, and private endpoint state in one evidence file. It also supports pre-change and post-change comparisons in deployment pipelines. In real operations, the hard part is not toggling the setting; it is proving which clients will still work afterward. CLI is the fastest way to script that proof across subscriptions, environments, and application-owned resource groups. It also records the precise rollback state for reviewers.
CLI use cases
Export publicNetworkAccess, defaultAction, bypass, IP rules, and virtual network rules for all storage accounts.
Disable public network access only after a deployment step verifies private endpoint connectivity and DNS resolution.
Find accounts where public access is enabled but no approved exception owner is documented.
Compare development, test, and production accounts for drift in firewall and public access posture.
Generate compliance evidence showing sensitive accounts are private-only or limited to selected networks.
Before you run CLI
Confirm tenant, subscription, resource group, storage account name, and whether the account supports private endpoint access for required clients.
Identify current callers, including build agents, serverless apps, data pipelines, partner systems, and support tools that may still use public endpoints.
Verify your permissions allow storage account updates; this setting can cause immediate access failures if changed accidentally.
Check policy assignments, approved exception process, expected output format, and whether trusted Microsoft services bypass is intentionally enabled.
Record the existing networkRuleSet and publicNetworkAccess values before mutation so the rollback command is precise.
What output tells you
publicNetworkAccess shows whether public endpoint traffic is enabled or disabled at the storage account level.
networkRuleSet.defaultAction shows whether selected public networks are allowed or whether unmatched requests are denied.
bypass indicates whether trusted Azure services can reach the account despite normal network restrictions.
ipRules and virtualNetworkRules identify the public IP ranges and subnets currently allowed through the storage firewall.
privateEndpointConnections helps confirm a private access path exists before public endpoint access is disabled.
Mapped Azure CLI commands
Storage account public network access CLI commands
direct
az storage account show --name <account-name> --resource-group <resource-group> --query "{publicNetworkAccess:publicNetworkAccess,networkRuleSet:networkRuleSet,privateEndpointConnections:privateEndpointConnections}"
az storage accountdiscoverStorage
az storage account update --name <account-name> --resource-group <resource-group> --public-network-access Disabled
az storage accountsecureNetworking
az storage account update --name <account-name> --resource-group <resource-group> --public-network-access Enabled
az storage accountconfigureStorage
az storage account network-rule list --account-name <account-name> --resource-group <resource-group>
In architecture, public network access defines the outer reachability posture of a storage account. It does not choose identity, encryption, redundancy, or container permissions; it decides whether the public storage endpoint can participate in the design at all. A private-first landing zone usually disables public network access and relies on private endpoints, private DNS, managed identities, and controlled network egress. A partner-facing or migration account may keep public access enabled temporarily with narrow IP rules. Architects need to document this choice because it affects app hosting, CI/CD agents, on-premises connectivity, analytics workspaces, backup tooling, and incident response options. Those dependencies must be mapped before enforcement.
Security
Security impact is direct because public network access governs whether the public endpoint can receive requests. Disabling it reduces attack surface, limits credential misuse from untrusted networks, and supports policy evidence for private-only storage. Leaving it enabled is not automatically insecure, but it demands careful defaultAction, IP rules, virtual network rules, trusted-services exceptions, and monitoring. The common failure is treating network rules as a substitute for authorization or treating authorization as a substitute for network controls. Teams should enforce Microsoft Entra where possible, limit shared key use, alert on configuration changes, and require approval before re-enabling public access. Those controls make exceptions visible quickly.
Cost
Public network access is not billed as a separate feature, but the decision affects costs around architecture and operations. Keeping public access enabled may reduce immediate migration work, yet it can increase security review effort, exception management, and incident response overhead. Disabling it usually requires private endpoints, DNS design, maybe self-hosted build agents, and changes to integration services, all of which have cost or labor impact. It can also reduce risk costs by preventing broad exposure from leaked credentials. FinOps review should include endpoint charges, network architecture, operational runbooks, and the cost of leaving temporary public exceptions permanent. Persistent exceptions should carry an explicit owner.
Reliability
Reliability impact is indirect but real. A public network access change can make healthy storage appear down to clients that still depend on public endpoints. This often affects CI/CD agents, serverless apps, data pipelines, partner upload tools, and break-glass operations. Reliability improves when the account uses a deliberate private path, but only if DNS, private endpoint connections, and dependent services are ready. Operators should plan cutovers with a test matrix, rollback path, and monitoring for failed requests. Region and redundancy choices still protect data, while public network access primarily controls reachability and blast radius from network changes. This keeps recovery choices realistic during outages.
Performance
Performance impact is mostly about routing and operational speed, not storage throughput limits. Public endpoint access may be simple for globally distributed clients, while private-only access depends on private endpoint placement, DNS, resolver paths, and network routing. A misrouted private path can add latency or fail resolution, but a well-designed private path can make traffic more predictable. The setting itself does not improve IOPS or bandwidth. Operators should measure client latency before and after private cutover, watch failed request metrics after disabling public access, and confirm deployment agents are not slowed by forced network hops or missing DNS forwarding. Measure from real workload subnets, not laptops.
Operations
Operators inspect public network access during security reviews, migration readiness, outage triage, and policy remediation. They compare the account setting with networkRuleSet.defaultAction, bypass values, private endpoint connections, service endpoint dependencies, and recent activity-log changes. A typical workflow is to export all accounts with public access enabled, classify legitimate exceptions, add private endpoints, test client DNS, then disable public access and monitor failed requests. Troubleshooting requires separating network denial from identity denial. CLI queries, Azure Policy compliance, diagnostic logs, and workbook views help teams avoid one-off portal changes that later surprise application owners. That evidence prevents the same exception from resurfacing quietly.
Common mistakes
Disabling public network access before self-hosted agents, Functions, integration runtimes, or analytics services have private connectivity.
Assuming publicNetworkAccess Disabled also fixes excessive RBAC, leaked SAS tokens, or shared key authorization.
Leaving trusted-services bypass enabled without documenting which Azure services actually need that path.
Testing from an administrator laptop instead of from the workload subnet or hosted service that uses the account.
Treating a policy violation as harmless because containers are private, even though public endpoint reachability remains enabled.