Create Service Endpoints Between Virtual Machines and Blob Storage
Pluralsight Hands-On Lab — Storage
At a Glance
| Platform | Pluralsight |
|---|
| Category | Azure Networking & Storage |
|---|
| Lab Type | Guided + Challenge Mode |
|---|
| Environment | Azure Portal, Azure Cloud Shell (Bash) |
|---|
| Completed | 2026 |
|---|
Overview
Azure Service Endpoints allow a subnet to present its virtual network identity to Azure Storage, enabling network-level access control without requiring private endpoints or public IP management. In this lab, I inherited a storage account open to all networks and was tasked with restricting it to a specific application subnet. I established a baseline, applied the restriction, validated the intended workload still succeeded, then diagnosed and restored access for a second VM on a different subnet that was blocked by the change — walking through the full service endpoint troubleshooting cycle using Azure Cloud Shell and the VM run command agent.
What I Did
- Inspected the virtual network (vnet-export) and confirmed two subnets — snet-application (10.0.1.0/24) and snet-operations (10.0.2.0/24) — with no service endpoints enabled on either
- Confirmed both VMs had no public IPs and used a NAT gateway for outbound connectivity, and that the storage account accepted traffic from all networks
- Established a baseline using Azure Cloud Shell and az vm run-command to curl the blob from vm-application, confirming HTTP 200 and CSV content while the account was fully open
- Restricted the storage account to selected networks, added vnet-export/snet-application as an allowed network — which triggered automatic enablement of the Microsoft.Storage service endpoint on that subnet — and saved the rule
- Verified the Microsoft.Storage service endpoint appeared in snet-application's Service Endpoints table, and confirmed snet-operations remained empty
- Reran the curl command from vm-application and confirmed HTTP 200 — the request now succeeded via the service endpoint identity rather than anonymous public access
- Ran the same curl command from vm-operations and received HTTP 403 AuthorizationFailure — confirming snet-operations was excluded from the network rule
- Restored access by adding snet-operations to the storage account's allowed networks, enabling its Microsoft.Storage service endpoint in the same flow, and saving
- Reran the curl from vm-operations and confirmed HTTP 200, completing the troubleshooting cycle
← Back to Pluralsight Labs