This chapter covers Azure Storage firewall and virtual network rules, a critical topic for the AZ-104 exam. You will learn how to restrict access to Azure Storage accounts using IP-based firewall rules and virtual network service endpoints or private endpoints. Approximately 10-15% of exam questions in the 'Storage' domain touch on these security controls, often testing your ability to choose the right configuration for a given scenario. Mastering this topic is essential because it directly impacts data security and network isolation in Azure.
Jump to a section
Imagine a gated community with a central clubhouse (the storage account). The clubhouse has a security guard at the front desk (the storage firewall). The guard has a list of approved visitor IDs (IP addresses) — only visitors whose IDs match the list can enter the lobby. But the clubhouse also has several private rooms (containers, file shares, tables, queues) that only residents of specific streets (virtual networks) can access. To enable this, the guard has a special phone line (service endpoint) that connects directly to each street's gatehouse (subnet). When a resident from an approved street calls ahead, the guard recognizes the caller ID (source IP from the VNet) and allows entry to the private room without needing an individual ID on the list. However, if the resident moves to a different street (another VNet) or uses a public road (internet), the guard no longer recognizes the caller ID and blocks access. To make it even more secure, the guard can also require that the resident's car (private endpoint) be physically parked in a designated spot inside the community (managed subnet), providing a direct, private driveway to the clubhouse, bypassing the public road entirely. The guard then only allows cars with a special permit (private endpoint network policy) to use that driveway. This layered system ensures that only authorized visitors and trusted streets can access the clubhouse's private rooms, while all other traffic is denied at the front desk.
What Are Storage Firewall and Virtual Network Rules?
Azure Storage accounts are secured by default — they allow access from any network. The storage firewall is a network access control mechanism that lets you restrict inbound traffic to your storage account based on source IP addresses or virtual network (VNet) origins. Virtual network rules extend this by allowing traffic from specific subnets within a VNet, using either service endpoints or private endpoints. The goal is to ensure that only trusted clients can access your storage data, reducing the attack surface.
How the Storage Firewall Works
When a request arrives at the storage account endpoint (e.g., https://mystorageaccount.blob.core.windows.net), the firewall evaluates the request's source IP address against the configured rules. The default action is to deny all traffic that does not match an allow rule. Rules are evaluated in the following order:
Allow all traffic from selected virtual networks — These rules are evaluated first. If the source IP falls within a subnet that has a service endpoint or private endpoint configured, and the subnet is in the allowed list, the request is permitted.
Allow all traffic from selected IP addresses — If the request did not match a virtual network rule, the firewall checks if the source IP is in the list of allowed IP ranges (IPv4 CIDR). If it matches, the request is permitted.
Allow traffic from Azure services — If this option is enabled, traffic from other Azure services (e.g., Azure Data Factory, Azure Backup) is allowed, regardless of source IP. This is a blanket exception.
Default deny — If no rule matches, the request is denied with a 403 (Forbidden) status code.
Key Components and Defaults
Default action: By default, all networks (including internet) are allowed. Once you add a rule, the default switches to deny.
IP rules: You can specify up to 200 IP address ranges (IPv4 CIDR) per storage account. Each rule can be a single IP (e.g., 203.0.113.0) or a range (e.g., 203.0.113.0/24).
Virtual network rules: You can add up to 200 VNet rules per storage account. Each rule references a specific subnet (VNet ID + subnet name). The subnet must have a service endpoint configured for Microsoft.Storage.
Service endpoints: When you enable a service endpoint on a subnet, Azure adds the subnet's public IP range to the firewall rule. Traffic from that subnet appears to originate from the VNet's public IPs (which are part of the Azure backbone), so the firewall can match it.
Private endpoints: A private endpoint assigns a private IP address from your VNet to the storage account. Traffic to the storage account stays within the Microsoft backbone and never traverses the internet. Private endpoints are not subject to IP firewall rules — they are controlled by network policies (NSG) and private endpoint connection approval.
Exceptions: You can enable "Allow trusted Microsoft services to access this storage account" to bypass firewall rules for specific Azure services (e.g., Azure Backup, Azure Site Recovery). This is a security risk if not carefully managed.
Configuration and Verification
Using Azure Portal:
Navigate to your storage account -> Networking -> Firewalls and virtual networks.
Select "Selected networks" to enable firewall rules.
Add IP ranges under "Firewall" -> "Add your client IP address" (auto-adds your current public IP).
Add virtual networks under "Virtual networks" -> "Add existing virtual network" (select VNet and subnet; the subnet must have a service endpoint for Microsoft.Storage).
Optionally, check "Allow trusted Microsoft services..."
Save.
Using Azure CLI:
# Add IP rule
az storage account network-rule add --account-name mystorageaccount --resource-group myrg --ip-address 203.0.113.0/24
# Add VNet rule (subnet must have service endpoint)
az storage account network-rule add --account-name mystorageaccount --resource-group myrg --vnet-name myvnet --subnet mysubnet
# List rules
az storage account network-rule list --account-name mystorageaccount --resource-group myrg
# Remove rule
az storage account network-rule remove --account-name mystorageaccount --resource-group myrg --ip-address 203.0.113.0/24Using PowerShell:
# Add IP rule
Add-AzStorageAccountNetworkRule -ResourceGroupName myrg -AccountName mystorageaccount -IPAddressOrRange "203.0.113.0/24"
# Add VNet rule
$vnet = Get-AzVirtualNetwork -ResourceGroupName myrg -Name myvnet
$subnet = Get-AzVirtualNetworkSubnetConfig -Name mysubnet -VirtualNetwork $vnet
Add-AzStorageAccountNetworkRule -ResourceGroupName myrg -AccountName mystorageaccount -VirtualNetworkResourceId $subnet.Id
# List rules
Get-AzStorageAccountNetworkRule -ResourceGroupName myrg -AccountName mystorageaccountInteraction with Related Technologies
Azure Private Link: Private endpoints provide a more secure alternative to service endpoints. They are not subject to IP firewall rules — you must manage access via network policies (NSG) on the subnet where the private endpoint is deployed, and through private endpoint connection approval.
Azure DNS: When using private endpoints, DNS resolution changes. A private DNS zone (e.g., privatelink.blob.core.windows.net) must be linked to your VNet to resolve the storage account's private IP.
Network Security Groups (NSGs): NSGs do not apply to storage account endpoints directly. However, when using private endpoints, NSGs can filter traffic to the private endpoint's IP within the VNet.
Azure Firewall: If you route traffic through Azure Firewall, the firewall rules must allow outbound traffic to the storage account's public IP (if using service endpoints) or private IP (if using private endpoints).
Service Endpoint Policies: You can use service endpoint policies to filter traffic from a VNet to specific storage accounts, adding an extra layer of security.
Exam-Relevant Details
Service endpoints do not provide a private IP — they rely on the VNet's public IP range.
Private endpoints give the storage account a private IP in your VNet, eliminating internet exposure.
Firewall rules are evaluated at the storage account level, not at the container/queue level.
By default, storage accounts allow access from all networks. Adding a rule changes the default to deny.
You cannot mix IP rules and virtual network rules in a way that creates a conflict — they are additive (any match allows).
The "Allow trusted Microsoft services" exception includes services like Azure Backup, Azure Site Recovery, and Azure Data Factory, but not all Azure services. The list is documented in Microsoft documentation.
Common Misconfiguration
A common error is adding a VNet rule without first enabling a service endpoint on the subnet. The rule will appear as "unused" and will not work. Another mistake is forgetting to add the client's public IP when testing from a non-VNet location (e.g., a developer's machine), resulting in 403 errors. Also, enabling the "Allow trusted Microsoft services" exception without understanding which services are trusted can inadvertently open access to Azure services that the organization does not use.
1. Create a Storage Account
Begin by creating an Azure Storage account in your resource group. During creation, you can configure the firewall defaults — by default, 'Allow access from' is set to 'All networks'. This means no firewall rules are applied. For production, you will later change this to 'Selected networks'. The storage account endpoint (e.g., blob.core.windows.net) is publicly resolvable, but the firewall blocks traffic at the network layer.
2. Enable Service Endpoint on Subnet
Navigate to the virtual network (VNet) that contains your application VMs. Select the subnet where your VMs reside. Under 'Service endpoints', enable 'Microsoft.Storage'. This adds a route in the subnet's route table that directs traffic to Azure Storage via the Microsoft backbone, and Azure adds the subnet's public IP prefix to the storage account's firewall rules when you associate the subnet. Without this step, VNet rules will not work.
3. Add Virtual Network Rule to Storage Account
In the storage account's 'Firewalls and virtual networks' blade, select 'Selected networks'. Under 'Virtual networks', click 'Add existing virtual network'. Choose the VNet and the subnet that has the service endpoint enabled. Click 'Add' and 'Save'. Now traffic from that subnet is allowed. The firewall rule is stored as the subnet's resource ID (e.g., /subscriptions/.../virtualNetworks/myVNet/subnets/mySubnet).
4. Add IP Firewall Rules for Other Clients
If you have clients outside the VNet (e.g., on-premises via VPN or internet), you must add their public IP addresses or CIDR ranges under 'Firewall' -> 'Add IP address'. For example, add your corporate office's public IP range (e.g., 203.0.113.0/24). You can also add your current client IP automatically using the 'Add your client IP address' button. Each rule is a separate entry.
5. Configure Private Endpoint (Optional)
For maximum security, create a private endpoint for the storage account (e.g., blob). In the storage account, go to 'Private endpoint connections' -> '+ Private endpoint'. Select the resource type 'Microsoft.Storage/storageAccounts' and the target sub-resource (blob, file, queue, table). Choose a VNet and subnet (different from the one used for service endpoints). The subnet must have a private endpoint network policy (e.g., 'Network policies for private endpoints' set to 'Enabled' if you want to use NSGs). Azure creates a private IP for the storage account in that subnet and a private DNS zone linked to the VNet.
6. Test and Verify Connectivity
From a VM inside the allowed subnet, test access using Azure CLI or PowerShell (e.g., `az storage blob list --account-name mystorageaccount --container-name mycontainer`). If successful, you'll get a listing. From a VM outside the allowed networks, the same command should fail with a 403 error. Verify that the firewall rules are applied by checking the 'Firewalls and virtual networks' blade — the 'Selected networks' option should be active, and the rules listed.
Enterprise Scenario 1: Secure Storage for a Financial Application
A financial services company hosts a critical application on Azure VMs in a VNet. The application reads and writes sensitive customer data to Azure Blob Storage. The security team mandates that the storage account must not be accessible from the internet. The solution: Configure a service endpoint on the application subnet and add a VNet rule to the storage account. Additionally, they add IP firewall rules for the on-premises data center's public IP range (e.g., 203.0.113.0/24) to allow backup jobs to run from on-prem. They also enable 'Allow trusted Microsoft services' for Azure Backup. In production, they monitor the firewall logs (via Azure Monitor) for denied requests. A common issue: developers forget to add their own public IPs when working remotely, causing 403 errors. The fix is to add a DevOps IP range or use a VPN into the VNet.
Enterprise Scenario 2: Multi-tier Application with Private Endpoints
A healthcare SaaS provider uses Azure Storage for storing medical images. Compliance requires that all traffic to storage stays within the Microsoft backbone. They deploy private endpoints for blob and file storage in a dedicated subnet. The application VMs in another subnet access storage via private IPs (resolved through private DNS zones). They disable all public network access (set firewall to 'Selected networks' and remove all IP rules). They also add an NSG on the private endpoint subnet to only allow traffic from the application subnet on port 443. Troubleshooting: A common mistake is forgetting to link the private DNS zone to the VNet, causing DNS resolution to fail (the VM resolves the storage account to a public IP instead of the private IP). They also had to ensure that the storage account's firewall does not block the private endpoint — private endpoints bypass firewall rules, so this is not an issue.
Enterprise Scenario 3: Hybrid Cloud with ExpressRoute
A manufacturing company uses Azure File Shares for lift-and-shift of on-premises file servers. They connect via ExpressRoute to Azure. They configure the storage account firewall to only allow traffic from the on-premises network (IP range) and from the VNet that hosts the file server VMs (via service endpoint). They also enable SMB over port 445. Performance: Service endpoints do not add latency because traffic stays on the Azure backbone. However, they encountered a problem: the on-premises network used NAT, so the source IP seen by Azure was the NAT device's public IP, which changed over time. They had to use a stable public IP range or use a private endpoint with a VPN/ExpressRoute for a more stable connection. They eventually migrated to private endpoints for better reliability.
What AZ-104 Tests on Storage Firewall and Virtual Network Rules
This topic falls under exam objective '2.3 Configure storage security' (part of 'Manage Azure storage'). The exam expects you to:
Understand the difference between service endpoints and private endpoints.
Know how to configure firewall rules (IP and VNet) via portal, CLI, and PowerShell.
Recognize the default behaviour: all networks allowed until a rule is added.
Identify the impact of enabling 'Allow trusted Microsoft services'.
Troubleshoot connectivity issues (403 errors).
Common Wrong Answers and Why Candidates Choose Them
'Service endpoints provide a private IP for the storage account' — This is false. Service endpoints use the VNet's public IP range. Candidates confuse them with private endpoints. The exam will present a scenario where a company needs to eliminate internet exposure — the correct answer is private endpoint, not service endpoint.
'NSGs can be applied directly to the storage account endpoint' — NSGs do not apply to PaaS endpoints. Candidates think they can filter traffic to storage with NSGs, but NSGs only apply to subnets or NICs. The correct approach is firewall rules or private endpoint NSGs.
'Adding a VNet rule automatically enables the service endpoint on the subnet' — This is backwards. You must enable the service endpoint first, then add the rule. The exam often tests this sequence.
'Firewall rules apply to the storage account's sub-resources separately' — Firewall rules are applied at the storage account level. You cannot allow access to blobs but deny access to queues from the same IP. The exam may present a scenario requiring separate rules for different sub-resources — but that is not possible with firewall rules alone.
Specific Numbers and Terms That Appear on the Exam
Maximum of 200 IP rules and 200 VNet rules per storage account.
Default action: allow all (until first rule added, then default deny).
Service endpoint must be for 'Microsoft.Storage'.
Private endpoint target sub-resources: blob, file, queue, table, web, dfs.
The 'Allow trusted Microsoft services' exception includes services like Azure Backup, Azure Site Recovery, and Azure Data Factory.
The firewall evaluates rules in this order: VNet rules, then IP rules, then trusted services exception.
Edge Cases and Exceptions
When using private endpoints, the storage account firewall does not block traffic from the private endpoint — it bypasses the firewall. However, you can disable public network access entirely by setting 'Public network access' to 'Disabled' in the storage account's networking blade. This is a separate toggle.
If you have both a service endpoint and a private endpoint for the same storage account, traffic from the VNet will use the private endpoint if the client is in the same VNet (due to DNS resolution). The service endpoint rule is not used.
The 'Allow trusted Microsoft services' exception does not cover all Azure services. For example, Azure App Service (Web Apps) is not included unless it is configured with a VNet integration.
You cannot use IP firewall rules to allow traffic from a specific Azure region's public IPs, because Azure public IPs are not predictable. Use service endpoints or private endpoints instead.
How to Eliminate Wrong Answers
If the question mentions 'eliminate internet exposure', the answer must involve private endpoints (or disabling public network access). Service endpoints do not eliminate internet exposure.
If the question mentions 'on-premises network', the answer may involve IP firewall rules (if on-prem has static public IPs) or private endpoints with ExpressRoute/VPN.
If the question asks about 'troubleshooting 403 errors', check if the client IP is allowed, or if the VNet rule is configured correctly (service endpoint enabled).
Storage firewall default is allow all; adding a rule changes default to deny.
Maximum 200 IP rules and 200 VNet rules per storage account.
Service endpoints require explicit enablement on the subnet before adding VNet rules.
Private endpoints bypass the storage firewall; use 'Public network access' toggle to disable public endpoint.
NSGs do not apply to storage account public endpoints; they can be used with private endpoints.
The 'Allow trusted Microsoft services' exception includes specific services only.
Firewall rules are evaluated at the storage account level, not per sub-resource.
To troubleshoot 403 errors, verify client IP is allowed, service endpoint is enabled, and trusted services exception is correctly configured.
These come up on the exam all the time. Here's how to tell them apart.
Service Endpoints
No private IP assigned; traffic uses VNet's public IP range.
Traffic stays on Azure backbone but still uses public IPs.
Configured at the subnet level (enable Microsoft.Storage service endpoint).
No additional cost.
Cannot eliminate internet exposure (public IPs still resolvable).
Private Endpoints
Assigns a private IP from the VNet to the storage account.
Traffic stays entirely within Microsoft backbone and never touches the internet.
Configured as a separate Azure resource (Private Endpoint) in a subnet.
Incurs hourly cost and data processing charges.
Eliminates internet exposure; public endpoint can be disabled.
Mistake
Service endpoints give the storage account a private IP in the VNet.
Correct
Service endpoints do not assign a private IP. They allow traffic from the subnet to be routed through the Azure backbone and appear to come from the VNet's public IP range. Private endpoints are required for a private IP.
Mistake
Adding a VNet rule automatically enables the service endpoint on the subnet.
Correct
You must explicitly enable the service endpoint on the subnet before adding the VNet rule. Otherwise, the rule will not work and may appear as 'unused'.
Mistake
NSGs can filter traffic to a storage account's public endpoint.
Correct
NSGs only filter traffic within a VNet or at a NIC. They cannot filter traffic to a PaaS endpoint's public IP. Use firewall rules or private endpoints instead.
Mistake
The storage firewall allows you to set separate rules for blobs, files, queues, and tables.
Correct
Firewall rules apply to the entire storage account. You cannot differentiate by sub-resource. To achieve granularity, use separate storage accounts or use private endpoints with different NSGs.
Mistake
Enabling 'Allow trusted Microsoft services' allows all Azure services to access the storage account.
Correct
Only a specific set of trusted services are allowed (e.g., Azure Backup, Azure Data Factory). Not all Azure services are included. The list is documented by Microsoft.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Service endpoints allow traffic from a VNet subnet to access Azure Storage over the Azure backbone, but the traffic still uses the VNet's public IP range. Private endpoints assign a private IP address from your VNet to the storage account, keeping traffic entirely within the Microsoft network and eliminating internet exposure. For AZ-104, remember that service endpoints are free and simpler, while private endpoints provide better security and compliance at an additional cost.
NSGs can only filter traffic within a VNet or at a NIC. They cannot filter traffic to a storage account's public endpoint. However, if you use a private endpoint, you can apply NSGs to the subnet where the private endpoint is deployed to control inbound traffic to the private endpoint. For public endpoints, you must use the storage firewall (IP rules or VNet rules).
First, check if the storage account firewall is enabled (Selected networks). If yes, ensure the VM's source IP is allowed: if the VM is in a VNet, verify that a VNet rule exists for its subnet and that the subnet has a service endpoint enabled for Microsoft.Storage. If the VM is outside the VNet, add its public IP to the IP firewall rules. Also, check if the 'Allow trusted Microsoft services' exception is needed. Finally, if using a private endpoint, verify DNS resolution points to the private IP and that the private endpoint connection is approved.
The VNet rule will be added but will not be effective. In the Azure portal, the rule may appear with a status of 'Unused' or 'Not configured'. Traffic from that subnet will not be allowed because the source IP will not match the rule (the subnet's traffic will still appear from its public IP, which is not in the allowed list). You must enable the service endpoint on the subnet first.
No. The storage firewall applies to the entire storage account. You cannot differentiate between sub-resources (blob, file, queue, table) using firewall rules. To achieve granular access, you must use separate storage accounts for each sub-resource, or use Azure AD authentication with role-based access control (RBAC) at the container level (but that is not firewall-based).
No, Azure App Service (Web Apps) is not included in the list of trusted Microsoft services by default. To allow an App Service to access a storage account behind a firewall, you must either add the App Service's outbound IP addresses to the IP firewall rules, or use VNet integration (service endpoints or private endpoints). The trusted services list includes Azure Backup, Azure Site Recovery, Azure Data Factory, and a few others.
Set the storage account's 'Public network access' to 'Disabled' in the Networking blade. This blocks all traffic from the internet, including traffic from Azure services. Access is only possible via private endpoints. Note that this is a separate setting from the firewall rules. Even if you have VNet rules, public network access must be disabled to fully eliminate internet exposure.
You've just covered Storage Firewall and Virtual Network Rules — now see how well it sticks with free AZ-104 practice questions. Full explanations included, no account needed.
Done with this chapter?