KubeQuest

Appearance

Azure Storage Networking ​

Scott Duffy Lecture 5 AZ-104

Public vs Private Networking ​

Key Concept

Network access is SEPARATE from authentication. You can have a storage account key and still have restricted network access. Think of it like a locked door on a busy street -- the door is locked (authentication via key), but anyone on that street (public network) can walk up and try the door. Restricting network access is like moving the door off the busy street entirely.

Azure Storage accounts offer three levels of network access control. These settings govern who can reach the storage endpoint, not who is authorized once they get there.

Three Network Access Options ​

1. Enabled from All Networks (Default) ​

  • Public internet access for anyone with the correct URL and access key
  • Like a locked door -- secure as long as no one has the key
  • There is no way to hack Azure to bypass this authentication layer
  • No subnet-based restrictions are applied
  • Every storage account starts in this state

WARNING

Even though "enabled from all networks" sounds risky, the storage account is still protected by key-based authentication. However, this does expose the endpoint to the public internet, which increases the attack surface. For production workloads with sensitive data, consider restricting network access.

2. Selected Networks ​

  • Restrict access to specific Azure virtual networks and subnets
  • Only resources running on the specified subnet can access the storage account (still need a valid key)
  • You can also add specific public IP addresses or CIDR ranges for internet-based access
  • More private than the default setting
  • Commonly used when your applications run inside Azure VNets

TIP

When you select "Selected networks," Azure automatically enables a service endpoint on the chosen subnet. This routes traffic from that subnet to storage over the Microsoft backbone network rather than the public internet.

3. Disabled (Private Access Only) ​

  • Requires Private Link / Private Endpoint setup
  • Creates a proxy connection from your VNet directly into the storage account
  • The most secure option available
  • Uses Azure-internal private connectivity with a private IP address in your VNet
  • The storage account has no public endpoint exposure at all

DANGER

When you disable public access entirely, all existing connections over the public endpoint will break immediately. This includes Azure Portal access, CLI tools from your local machine, and any applications not routed through a private endpoint. Plan your migration carefully.

Network Access Models Diagram ​

txt
direction: right

title: {
  label: Azure Storage Network Access Models
  near: top-center
  shape: text
  style.font-size: 24
  style.bold: true
}

# Model 1 - Public Access
internet: Internet {
  shape: cloud
  style.fill: "#E8F0FE"
}
sa1: Storage Account\n(All Networks) {
  shape: cylinder
  style.fill: "#4CAF50"
  style.font-color: white
}
internet -> sa1: Public endpoint\n(key required) {
  style.stroke: "#4CAF50"
  style.stroke-width: 2
}

# Model 2 - Selected Networks
vnet-sub: VNet / Subnet {
  shape: rectangle
  style.fill: "#FFF3E0"
}
specific-ip: Specific IP\n(203.0.113.0/24) {
  shape: rectangle
  style.fill: "#FFF3E0"
}
sa2: Storage Account\n(Selected Networks) {
  shape: cylinder
  style.fill: "#FF9800"
  style.font-color: white
}
vnet-sub -> sa2: Service endpoint\n(Microsoft backbone) {
  style.stroke: "#FF9800"
  style.stroke-width: 2
}
specific-ip -> sa2: Allowed IP rule {
  style.stroke: "#FF9800"
  style.stroke-width: 2
}

# Model 3 - Private Endpoint
vnet-pe: VNet {
  pe: Private Endpoint\n(10.0.1.5) {
    shape: hexagon
    style.fill: "#E3F2FD"
  }
}
sa3: Storage Account\n(Private Only) {
  shape: cylinder
  style.fill: "#F44336"
  style.font-color: white
}
vnet-pe.pe -> sa3: Private Link\n(no public path) {
  style.stroke: "#F44336"
  style.stroke-width: 2
}
blocked: Public Internet {
  shape: cloud
  style.fill: "#FFCDD2"
}
blocked -> sa3: Blocked {
  style.stroke: red
  style.stroke-dash: 5
  style.stroke-width: 2
}

Choosing the Right Network Access Level ​

Network Routing ​

Azure provides two routing options that control how traffic travels from the client to the storage account.

  • Traffic travels over the Microsoft Global Network backbone
  • Example: A computer in Japan connects to Microsoft's Japan network edge, then traverses the private Microsoft backbone all the way to US-based storage
  • Better latency and better security
  • Traffic never touches the public internet once it enters a Microsoft edge node

Internet Routing (Alternative) ​

  • Traffic travels over the public internet (still encrypted via TLS)
  • Enters the Azure network only in the target region where the storage account lives
  • Less efficient path with potentially higher latency
  • No real advantage unless you have a very specific routing requirement

TIP

In almost all cases, stick with Microsoft network routing. Internet routing exists for niche scenarios where you need traffic to traverse specific ISP paths or have contractual requirements around routing. The Microsoft backbone is faster, more reliable, and more secure.

Routing Comparison ​

Service Endpoints vs Private Endpoints ​

Detailed Comparison

Understanding the difference between service endpoints and private endpoints is critical for the AZ-104 exam and real-world architecture decisions.

FeatureService EndpointPrivate Endpoint
Traffic pathMicrosoft backbone (public IP)Private IP in your VNet
DNS resolutionPublic endpoint (unchanged)Private DNS zone (custom)
On-premises accessNo (VNet-only)Yes (via VPN/ExpressRoute)
Cross-regionLimited (same region)Yes (works across regions)
CostFreePer hour + per GB processed
IP addressStorage keeps public IPGets a private IP (e.g., 10.0.1.5)
NSG supportVia service tagsVia private IP rules
Setup complexitySimple (subnet toggle)More involved (DNS, NIC, approval)

When to Use Which

  • Service Endpoints: Quick, free way to secure traffic from Azure VNets to storage. Good for straightforward setups where on-premises access is not needed.
  • Private Endpoints: Required when you need on-premises access to storage over VPN/ExpressRoute, cross-region connectivity, or the strictest possible isolation with a private IP.

NSG Integration with Storage ​

Network Security Groups (NSGs) can be used alongside storage firewall rules to provide defense-in-depth:

  • Use the Storage service tag in NSG outbound rules to allow or deny traffic to Azure Storage
  • Service tags simplify rule management -- no need to track individual storage IPs
  • NSG rules apply at the subnet or NIC level, while storage firewall rules apply at the storage account level
  • Both layers must allow the traffic for it to succeed

WARNING

NSG rules and storage firewall rules are evaluated independently. Traffic must be permitted by both the NSG (outbound from the VM) and the storage firewall (inbound to the storage account) for a connection to succeed.

Service Endpoint Policies ​

John Savill

Service endpoints allow a subnet to reach Azure Storage over the Microsoft backbone. But by default, a subnet with a service endpoint can reach ANY storage account. Service Endpoint Policies restrict which specific storage accounts a subnet can communicate with -- preventing data exfiltration.

Key Distinction

Service endpoints are configured on both the subnet AND the storage account firewall (allows inbound). Service endpoint policies are configured on the subnet only -- they restrict outbound traffic from the subnet to specific storage accounts.

AspectService EndpointService Endpoint Policy
Configured onSubnet + Storage account firewallSubnet only
DirectionAllows inbound to storageRestricts outbound to specific accounts
PurposeRoute traffic over backbonePrevent data exfiltration
GranularityAll storage accounts in regionSpecific storage account resource IDs

Exam Tip

If an exam question asks about preventing a VM from copying data to an unauthorized storage account while allowing access to approved accounts, the answer is Service Endpoint Policies. Service endpoints alone do NOT prevent exfiltration.

bash
# Create a service endpoint policy
az network service-endpoint policy create \
  --name myPolicy \
  --resource-group myRG \
  --location eastus

# Add definition to allow a specific storage account
az network service-endpoint policy-definition create \
  --name allowStorageA \
  --policy-name myPolicy \
  --resource-group myRG \
  --service "Microsoft.Storage" \
  --service-resources "/subscriptions/{sub-id}/resourceGroups/{rg}/providers/Microsoft.Storage/storageAccounts/{account}"

# Associate policy with subnet
az network vnet subnet update \
  --name mySubnet \
  --vnet-name myVNet \
  --resource-group myRG \
  --service-endpoint-policy myPolicy

Resource Instance Rules ​

John Savill

Resource instance rules allow specific Azure PaaS resource instances (e.g., a particular Azure SQL Database, Synapse workspace, or Data Factory) to access a storage account through the firewall. More granular than subnet-based rules because it targets individual resource instances.

AspectVNet/Subnet RulesResource Instance Rules
ScopeAll resources on a subnetSpecific Azure resource instance
IdentitySubnet IDResource ID + system-assigned managed identity
Use caseVMs in a subnet need storageA specific SQL Database or Data Factory needs storage
ConfigurationNetworking > Virtual networksNetworking > Resource instances

INFO

Resource instance rules require the Azure resource to have a system-assigned managed identity. The rule is based on the resource's identity, not its network location. This works even if the resource is NOT in a VNet.

Best Practice

Combine resource instance rules with "Disabled" public network access for maximum security: no public endpoint, no VNet rules, but specific Azure PaaS services can still access the storage account via their managed identity.

Configuring Storage Firewall ​

bash
# Add a VNet/subnet rule (enables service endpoint automatically)
az storage account network-rule add \
  --account-name myaccount \
  --resource-group myRG \
  --vnet-name myVNet \
  --subnet mySubnet

# Add an IP address rule (CIDR notation supported)
az storage account network-rule add \
  --account-name myaccount \
  --resource-group myRG \
  --ip-address 203.0.113.0/24

# Set the default action to Deny (block all unlisted traffic)
az storage account update \
  --name myaccount \
  --resource-group myRG \
  --default-action Deny

# List current network rules
az storage account network-rule list \
  --account-name myaccount \
  --resource-group myRG

# Remove an IP rule
az storage account network-rule remove \
  --account-name myaccount \
  --resource-group myRG \
  --ip-address 203.0.113.0/24
powershell
# Add a VNet/subnet rule
$subnet = Get-AzVirtualNetwork -Name "myVNet" -ResourceGroupName "myRG" |
  Get-AzVirtualNetworkSubnetConfig -Name "mySubnet"

Add-AzStorageAccountNetworkRule `
  -ResourceGroupName "myRG" `
  -AccountName "myaccount" `
  -VirtualNetworkResourceId $subnet.Id

# Add an IP address rule
Add-AzStorageAccountNetworkRule `
  -ResourceGroupName "myRG" `
  -AccountName "myaccount" `
  -IPAddressOrRange "203.0.113.0/24"

# Set the default action to Deny
Update-AzStorageAccountNetworkRuleSet `
  -ResourceGroupName "myRG" `
  -AccountName "myaccount" `
  -DefaultAction Deny

# List current network rules
Get-AzStorageAccountNetworkRuleSet `
  -ResourceGroupName "myRG" `
  -AccountName "myaccount"

# Remove an IP rule
Remove-AzStorageAccountNetworkRule `
  -ResourceGroupName "myRG" `
  -AccountName "myaccount" `
  -IPAddressOrRange "203.0.113.0/24"

Screenshot ​

Network configuration in Azure Portal

Azure Portal showing the Networking blade of a storage account with the three access options: Enabled from all networks, Enabled from selected virtual networks and IP addresses, and Disabled.

Lab ​

Lab Objectives

Practice configuring storage account network restrictions and verifying access behavior when firewall rules change.

Steps ​

  1. Configure storage account with "Selected networks"

    • Navigate to your storage account in the Azure Portal
    • Go to Networking > Firewalls and virtual networks
    • Select Enabled from selected virtual networks and IP addresses
    • Under Firewall, add your current public IP address
    • Click Save

  2. Test access from your allowed IP

    • Open Azure Storage Explorer or use the Azure Portal
    • Browse blobs, files, or tables in the storage account
    • Access should work normally since your IP is allowed

  3. Remove your IP from the firewall and test again

    • Go back to Networking and remove your IP from the firewall list
    • Click Save and wait 30 seconds for propagation
    • Try accessing the storage account again
    • You should receive a 403 Forbidden or network error

  4. Re-add your IP

    • Add your public IP back to the firewall rules
    • Confirm access is restored

  5. (Optional) Create a private endpoint and test access

    • Navigate to Networking > Private endpoint connections
    • Click + Private endpoint
    • Select the target sub-resource (e.g., blob)
    • Choose a VNet and subnet for the private endpoint
    • Enable private DNS zone integration
    • Verify DNS resolves to the private IP using nslookup <account>.blob.core.windows.net

Lab Cleanup

Remember to delete any private endpoints after the lab to avoid ongoing charges. Private endpoints are billed per hour plus per GB of data processed.

Microsoft Learn References ​

Released under the MIT License.

Copyright © 2026 OpsAlchemy