AZ-500 Objective 2.2: Plan and Implement Security for Private Access to Azure Resources

 • 43 min read • Microsoft Azure Security Technologies

Share:

AZ-500 Exam Focus: This objective covers private connectivity to Azure resources including Service Endpoints (optimized routing to Azure services with VNet access control), Private Endpoints (dedicated private IP addresses bringing services into VNet eliminating public exposure), Private Link services (exposing custom services privately), VNet integration for App Service and Functions (outbound VNet connectivity), App Service Environment (ASE) providing single-tenant isolated deployment in VNet, and SQL Managed Instance network security with dedicated subnet requirements, NSG rules for management traffic, and UDR configuration. Understanding when to use Service Endpoints vs Private Endpoints and how to secure ASE and SQL MI is essential.

Understanding Private Access to Azure Resources

Traditional cloud services expose public endpoints accessible from internet, creating security concerns even with authentication and authorization. Public endpoints increase attack surface providing entry points for threats, enable data exfiltration risks through internet paths, complicate compliance requiring additional controls for regulated data, and create network complexity managing public IP ranges and firewall rules. Azure provides comprehensive private access capabilities eliminating public exposure while maintaining functionality. Private access achieves multiple security objectives: reduces attack surface by removing public endpoints, enables network-level controls through NSGs and firewalls, meets compliance requirements mandating private connectivity, simplifies network architecture with private IPs, prevents data exfiltration by blocking internet paths, and provides defense-in-depth through network isolation layers.

Azure offers several private access technologies each with specific use cases: Service Endpoints optimize routing from VNet to Azure services over Azure backbone providing subnet-level access control while keeping service's public infrastructure. Private Endpoints provide dedicated private network interfaces with IPs from your VNet bringing Azure services or custom services fully into VNet eliminating public endpoint requirement. Private Link service exposes custom services behind Standard Load Balancer for private consumption by other VNets or tenants. VNet integration connects App Service and Functions to VNet enabling outbound private connectivity to VNet resources, Private Endpoints, and on-premises networks. App Service Environment deploys dedicated single-tenant App Service infrastructure in customer VNet providing maximum isolation and control. SQL Managed Instance deploys in customer VNet with dedicated subnet providing near-complete SQL Server compatibility with network isolation. This objective explores these technologies enabling design and implementation of comprehensive private access architecture protecting Azure workloads from network-based threats while maintaining necessary connectivity for applications.

Virtual Network Service Endpoints

Service Endpoint Architecture and Benefits

Service Endpoints extend VNet private address space and VNet identity to Azure services over Microsoft backbone network. Without service endpoints, traffic from VMs to Azure services like Storage or SQL Database travels over internet through Azure edge, using public IP addresses and internet routing. Service endpoints change routing so traffic stays on Azure backbone network, uses VNet private IPs as source, and takes optimal path to service. This provides better performance (lower latency, higher throughput), enables VNet-based firewall rules on Azure services, and maintains traffic within Azure network without internet exposure. Service endpoints configure at subnet level—when enabled for specific Azure service, all resources in that subnet use optimized path for that service. Service endpoints available for Azure Storage, SQL Database, Cosmos DB, Key Vault, Service Bus, Event Hubs, Data Lake, PostgreSQL, MySQL, MariaDB, App Service, and Cognitive Services.

Service endpoint benefits: Optimal routing improves performance by staying on Microsoft backbone with direct path to service regions. Security improvements through VNet identity—service firewalls can restrict access to specific VNets and subnets rather than all internet IPs. Ability to remove public IPs from some resources accessing services. No additional cost for service endpoints (unlike Private Endpoints). Simple configuration without gateway deployment. Works across regions—subnet in one region can access service in another with service endpoint. Service endpoint mechanics: Enable service endpoint on subnet for specific Azure service (Microsoft.Storage for all storage, Microsoft.Storage.Global for specific regions, Microsoft.Sql for Azure SQL). Configure Azure service firewall to allow access from VNet/subnet. Traffic from VMs in that subnet now routes optimally to service and originates from VNet IP space. Service sees traffic as coming from VNet enabling VNet rules in service firewall.

Service Endpoint Configuration and Limitations

Configuring service endpoints: Azure Portal—Virtual networks → Select VNet → Subnets → Select subnet → Service endpoints → Add service endpoint selecting desired Azure service (Microsoft.Storage, Microsoft.Sql, etc.). Azure CLI: az network vnet subnet update --resource-group [RG] --vnet-name [VNet] --name [Subnet] --service-endpoints Microsoft.Storage Microsoft.Sql. PowerShell: Get-AzVirtualNetwork -Name [VNet] -ResourceGroupName [RG] | Set-AzVirtualNetworkSubnetConfig -Name [Subnet] -AddressPrefix [CIDR] -ServiceEndpoint Microsoft.Storage. After enabling service endpoint on subnet, configure Azure service firewall: Storage account → Networking → Selected networks → Add existing virtual network → Select subscription, VNet, subnet. SQL Database → Networking → Virtual networks → Add existing virtual network. Key Vault → Networking → Add virtual network. Service firewall now allows access from that subnet.

Service endpoint limitations and considerations: Service endpoint provides optimized routing and VNet identity but doesn't give service a private IP address—service still has public endpoint infrastructure. DNS resolution still returns public IP address. Service endpoint applies at subnet level affecting all resources in subnet (can't enable for specific VM). Removing service endpoint doesn't automatically remove service firewall rules—must manually delete. Service endpoint policies (preview) provide additional control over which service instances accessible through endpoint. Service endpoints don't work across Azure AD tenants—if accessing service in different tenant, can't use service endpoint. Some services don't support service endpoints requiring Private Endpoints instead. Service endpoints and Private Endpoints can coexist—use service endpoints for some services and Private Endpoints for others based on requirements. Best practices: Use service endpoints for dev/test environments or cost-sensitive scenarios, enable only needed Azure services on subnet, always configure service firewall rules after enabling endpoint, document which subnets have which service endpoints, regularly review service endpoint configurations, combine with NSGs for defense in depth, and consider Private Endpoints for production sensitive workloads requiring true private IPs.

Private Endpoints

Private Endpoint Architecture and Deployment

Private Endpoint is network interface with private IP address from your VNet subnet connecting privately and securely to Azure service powered by Private Link. Unlike Service Endpoints which optimize routing while keeping public infrastructure, Private Endpoint brings service into your VNet with dedicated private IP eliminating need for public endpoint access. Private Endpoint deployed in your subnet receiving IP from subnet address space. Azure creates DNS entries resolving service FQDN to private IP (with proper DNS configuration). Traffic to service routes through Private Endpoint staying entirely within VNet and Azure backbone. Service sees connection originating from Private Endpoint not internet. Private Endpoint supports many Azure services: Storage (blob, file, table, queue, Data Lake Gen2), SQL Database and SQL Managed Instance, Cosmos DB, Key Vault, App Service and Functions, Container Registry, Event Hubs, Service Bus, Cognitive Services, Azure Search, Redis Cache, and many others. Each service type may have multiple sub-resources (blob, file for Storage; sqlServer for SQL).

Private Endpoint components: Network interface in your subnet with private IP, connection to target Azure resource, DNS configuration resolving service FQDN to private IP, optional Private DNS Zone for automatic DNS resolution, and NSG rules controlling access to Private Endpoint. Creating Private Endpoint: Azure Portal—Private Link Center → Private endpoints → Create → Select subscription, resource group, region, instance name → Select target resource type and resource → Select networking VNet and subnet → Integrate with Private DNS Zone (recommended) → Create. Azure CLI: az network private-endpoint create --resource-group [RG] --name [PE-Name] --vnet-name [VNet] --subnet [Subnet] --private-connection-resource-id [Resource-ID] --group-id [Sub-Resource] --connection-name [Connection]. PowerShell: New-AzPrivateEndpoint -ResourceGroupName [RG] -Name [PE-Name] -Location [Region] -Subnet [SubnetObject] -PrivateLinkServiceConnection [ConnectionObject].

Private Endpoint DNS Configuration

DNS resolution critical for Private Endpoints functioning correctly. Azure service FQDNs (storageaccount.blob.core.windows.net) must resolve to Private Endpoint private IP instead of public IP. Azure Private DNS Zones provide automatic DNS resolution for Private Endpoints. When creating Private Endpoint, option to integrate with Private DNS Zone—Azure creates DNS zone (privatelink.blob.core.windows.net for Storage) with A record mapping service name to private IP. VNet links to Private DNS Zone enabling VMs to resolve. Resolution process: VM queries storageaccount.blob.core.windows.net, Azure DNS resolves via CNAME to storageaccount.privatelink.blob.core.windows.net, Private DNS Zone returns private IP, VM connects to Private Endpoint using private IP. Without Private DNS Zone, manual DNS configuration required: Create Private DNS Zone manually, create A record for service pointing to Private Endpoint IP, link VNet to Private DNS Zone, or configure custom DNS server with required entries.

Hybrid scenarios with on-premises access to Private Endpoints require DNS forwarding: On-premises DNS must resolve Azure service names to Private Endpoint private IPs. Common approach: Configure on-premises DNS forwarders to Azure DNS (168.63.129.16), Azure DNS resolves via Private DNS Zones, or deploy DNS forwarders in Azure VNet, on-premises forwards to Azure VMs, Azure VMs forward to Azure DNS. DNS challenges: Split-brain DNS where same FQDN resolves differently based on location (private IP from VNet, public IP from internet), managing many Private DNS Zones for multiple services, ensuring DNS resolution works from all locations (Azure, on-premises, branch offices), testing DNS resolution regularly. Best practices: Use Azure Private DNS Zones for automatic integration, link Private DNS Zones to all VNets requiring access, implement DNS forwarders for hybrid scenarios, test DNS resolution from all locations, document DNS architecture, monitor DNS queries for troubleshooting, and consider Azure Firewall DNS proxy simplifying hybrid DNS.

Private Endpoint Security and Management

Security controls for Private Endpoints: NSGs apply to Private Endpoint subnet controlling which sources can reach Private Endpoint—create allow rules for legitimate traffic sources, deny rules for unauthorized access. Disable public access on Azure services after deploying Private Endpoint eliminating public endpoint entirely—Storage accounts, SQL databases, Key Vaults support disabling public network access. Azure Policy enforces Private Endpoint usage organization-wide—create policies requiring Private Endpoints for specific services, audit resources without Private Endpoints, auto-remediate creating Private Endpoints. RBAC controls who can create and manage Private Endpoints—limit permissions to network admins. Monitoring: Private Endpoint connections visible in target resource showing approved/pending/rejected connections. Connection approval can be automatic (same subscription/tenant with permissions) or manual (cross-subscription/tenant requiring approval). Reject unwanted Private Endpoint connection requests. Azure Monitor provides metrics and diagnostics for Private Endpoint connections.

Managing Private Endpoints at scale: Automate creation using ARM templates, Terraform, or Azure CLI in deployment pipelines. Use consistent naming conventions (PE-StorageAccount-ServiceName-Region). Tag Private Endpoints for cost tracking and management (Environment, CostCenter, Application). Inventory Private Endpoints using Azure Resource Graph queries identifying all Private Endpoints, target services, and subnets. Lifecycle management: Update Private Endpoints when services move or rebuild, remove orphaned Private Endpoints when services deleted, rotate connections for security hygiene. Cost management: Each Private Endpoint charged per hour plus data processing fees. Costs add up with many endpoints—consider consolidation strategies. Cost optimization: Share Private Endpoints across multiple applications where possible, use Service Endpoints for non-production, implement Private Endpoints only for sensitive workloads, monitor usage identifying unused Private Endpoints. Troubleshooting Private Endpoints: Verify DNS resolving to private IP (nslookup/dig), check NSG rules on Private Endpoint subnet, validate Private Endpoint connection approved, test connectivity from source VMs, review Azure service firewall settings, examine diagnostic logs, and verify subnet has available IPs.

Private Link Services

Exposing Custom Services with Private Link

Private Link service enables exposing your own services running behind Azure Standard Load Balancer for private consumption by other VNets or customers without public endpoint. While Private Endpoints connect to Microsoft services, Private Link service exposes your custom services. Architecture: Your service backend (VMs, VMSS, containers) runs in VNet, frontend by internal Standard Load Balancer, Private Link service created referencing load balancer, consumers create Private Endpoints in their VNets connecting to your Private Link service, traffic flows from consumer VNet through their Private Endpoint to your Private Link service then load balancer then backends—completely private path. Use cases: Multi-tenant SaaS with dedicated Private Endpoint per customer providing network isolation, exposing internal services to business partners without public endpoint or VNet peering complexity, cross-Azure-tenant service delivery maintaining separation, meeting customer compliance requirements for private connectivity, building private marketplace services.

Creating Private Link service: Deploy service backend in VNet (VMs in VMSS, containers in AKS), create internal Standard Load Balancer with frontend IP configuration, backend pool, health probes, and load balancing rules. Create dedicated subnet for Private Link service to provision Private Endpoint connections (minimum /28, separate from backend VMs). Create Private Link service: Portal—Private Link Center → Private Link services → Create → Select load balancer, Private Link subnet, NAT IP address configuration, auto-approval settings. CLI: az network private-link-service create --resource-group [RG] --name [PLS-Name] --vnet-name [VNet] --subnet [PLS-Subnet] --lb-name [LB-Name] --lb-frontend-ip-configs [LB-Frontend]. Private Link service receives alias (unique identifier consumers use to connect). Share alias with authorized consumers through secure channel. Private Link service also has resource ID used programmatically.

Private Link Service Configuration and Security

NAT IP configuration for Private Link service: Private Link uses NAT for consumer connections mapping consumer private IPs to NAT IPs before forwarding to load balancer. Configure NAT IP addresses: Primary IP (required, static or dynamic from Private Link subnet), Secondary IPs (optional, for scale). NAT IPs must be from Private Link subnet. Standard Load Balancer sees connections from NAT IPs not original consumer IPs—important for backend application logging and filtering. Connection approval: Automatic approval—specify subscription or Azure AD tenant IDs that can connect without manual approval (suitable for trusted internal consumers). Manual approval—all connections require manual approval before activation (suitable for external consumers or strict control requirements). Mixed mode—auto-approve specific subscriptions, manual for others. Manage connections: View pending connection requests, approve or reject connections, revoke access by removing approved connections.

Security considerations: Private Link service doesn't inherently authenticate consumers—implement application-level authentication (OAuth, certificates, API keys). Use Azure AD Workload Identity for authentication in cross-tenant scenarios. Network security—NSGs on backend VM subnets control traffic from load balancer, can't apply NSG to Private Link subnet (managed by Azure), implement application firewall for deep inspection. Logging and monitoring: Enable diagnostic logs on Private Link service capturing connection attempts, approvals, and traffic patterns. Monitor connection health detecting issues. Backend VMs log application traffic including source NAT IPs. Consumer responsibilities: Consumer creates Private Endpoint in their VNet using your service alias, connection request sent to you (auto-approved or manual), after approval consumer accesses via private IP, consumer controls their DNS resolution. Best practices: Document service clearly including connection requirements and supported protocols, implement robust authentication at application layer, monitor connections regularly reviewing approved consumers, provide clear connection request process for consumers, test failure scenarios ensuring graceful degradation, maintain service SLA meeting consumer expectations, document NAT IP behavior for consumer troubleshooting.

App Service and Functions Network Integration

VNet Integration for Outbound Connectivity

VNet integration enables Azure App Service and Azure Functions accessing resources in or through VNet including private endpoints, service endpoints, on-premises resources via VPN/ExpressRoute, and internet with routing control. Regional VNet integration (recommended) connects apps in same region as VNet using dedicated subnet. App plan types supporting VNet integration: Premium V2, Premium V3, Elastic Premium (Functions), Dedicated (various tiers), Isolated (App Service Environment has built-in VNet integration). Configuration: Create dedicated subnet for VNet integration (minimum /28, /26 recommended for production allowing scale). App Service → Networking → VNet Integration → Add VNet → Select VNet and subnet. Azure creates delegation to Microsoft.Web/serverFarms on subnet. App can now access VNet resources using private IPs. VNet integration affects outbound traffic only—app still has public endpoint for inbound unless Private Endpoint or ASE used.

Route all traffic configuration: By default, only VNet address space and private IP ranges route through VNet integration; internet traffic routes directly. Enable "Route All" forcing all outbound traffic through VNet including internet-bound. Benefits: Apply NSGs to all app traffic, route traffic through firewall using UDRs, access Private Endpoints requiring route all, implement network policies on internet access. Configuration: App Service → Configuration → General settings → Route All → On. After enabling, internet access routes through VNet—requires VNet internet connectivity via NAT gateway or forced tunneling through firewall. Prerequisites for VNet integration: App in supported tier (Premium V2/V3, Elastic Premium), VNet in same region, dedicated subnet with sufficient IPs (minimum 1 IP per plan instance), subnet delegation to Microsoft.Web/serverFarms, outbound connectivity from subnet (NAT gateway, VNet default route, or UDR to firewall).

Private Access to App Service

VNet integration provides outbound connectivity from app to VNet but app remains publicly accessible. Private inbound access requires Private Endpoint or App Service Environment. Private Endpoint for App Service: Create Private Endpoint in VNet for App Service providing private IP address. Configure Azure Private DNS Zone (privatelink.azurewebsites.net) resolving app FQDN to private IP. Optionally disable public access on App Service allowing only private endpoint connectivity. App now accessible via private IP from VNet, peered VNets, on-premises via VPN/ExpressRoute. Combined with VNet integration creates fully private app—inbound via Private Endpoint (private), outbound via VNet integration (private), no public internet exposure. Use case: Line-of-business app with sensitive data requiring complete network isolation, connecting to on-premises systems via private network, meeting compliance for private connectivity, implementing zero-trust network architecture.

DNS configuration for Private Endpoint to App Service: Default App Service DNS (myapp.azurewebsites.net) resolves to public IP. With Private Endpoint, must resolve to private IP. Azure Private DNS Zone handles automatically: Zone privatelink.azurewebsites.net, CNAME myapp.azurewebsites.net → myapp.privatelink.azurewebsites.net, A record myapp.privatelink.azurewebsites.net → Private Endpoint private IP. From VNet, resolution follows CNAME to A record returning private IP. From internet (if public access enabled), resolution returns public IP. Access restrictions complement Private Endpoints: Configure IP-based access restrictions allowing only specific IPs or VNets, deny all other traffic, use service tags for Azure services, implement allow-list security model. Combines with Private Endpoints for defense-in-depth—Private Endpoint limits network access, access restrictions provide additional IP filtering. Best practices: Use Private Endpoints for production sensitive apps, implement VNet integration for outbound connectivity, enable route all for comprehensive routing control, disable public access when using Private Endpoints exclusively, configure Azure Private DNS Zones for proper resolution, test connectivity from all required locations, monitor application with App Insights, document network architecture including Private Endpoints and VNet integration, and implement backup connectivity methods for disaster recovery.

App Service Environment Network Security

ASE Architecture and Deployment

App Service Environment (ASE) is single-tenant deployment of Azure App Service injected into customer VNet providing maximum isolation, scale, and network control. ASEv3 (current version) deploys in single subnet with simpler networking than ASEv2. ASE types: Internal Load Balancer (ILB) ASE—apps accessible only via private IP address in VNet, no public endpoint, suitable for internal apps and compliance scenarios. External ASE—apps have public-facing endpoint with public IP but backends still in VNet, suitable for internet-facing apps requiring VNet connectivity for backends. ILB ASE provides strongest isolation—all traffic private. ASE deployment requires: Dedicated subnet (minimum /24 providing 256 addresses), empty subnet at deployment time, sufficient quota for ASE (requires approval for first ASE in subscription), no network policies blocking ASE management traffic.

Creating ASE: Portal—App Service Environment → Create → Select subscription, resource group, name, region, VNet and subnet, ILB or External. ASE deployment takes 30-60 minutes provisioning dedicated infrastructure. After deployment, create App Service plans in ASE using Isolated tier. Deploy apps to plans as normal—apps automatically in VNet with ASE network properties. ASE networking: ILB ASE receives private IP from subnet (default gateway IP), custom domain required for ILB ASE (can't use azurewebsites.net publicly), configure private DNS or custom DNS resolving ASE domain to private IP. External ASE has public IP for inbound traffic and private IPs for outbound. All apps in ASE share network boundaries: Same VNet, same subnet (at subnet level), access to VNet resources, on-premises connectivity via VPN/ExpressRoute, Private Endpoints if configured. ASE provides network isolation at infrastructure level—no shared infrastructure with other customers.

ASE Network Security Configuration

NSG on ASE subnet required for traffic control. ASE management traffic must be allowed: Inbound rules—port 454-455 from AppServiceManagement service tag (Azure management), port 16001 from any for internal load balancer probes. Outbound rules—port 80 and 443 to internet for dependencies, port 1433 to SQL service tag for monitoring, port 53 for DNS. Application traffic rules: Allow inbound HTTPS (443) and HTTP (80) from required sources (internal VNet, on-premises, internet for External ASE). Allow outbound based on app requirements (databases, APIs, storage). NSG limitations: Can't block ASE management traffic or ASE won't function. Carefully plan rules avoiding operational issues. Test NSG rules thoroughly before production. Microsoft provides NSG templates ensuring correct rules.

UDRs on ASE subnet customize traffic routing: Default route (0.0.0.0/0) can force internet traffic through firewall for inspection. Specific routes for Azure services if using Private Endpoints or service endpoints. Routes to on-premises via VPN or ExpressRoute gateway. ASE management traffic must reach internet (Azure management endpoints)—0.0.0.0/0 with next hop Internet typically required unless firewall allows ASE management. Private Endpoints in ASE: Create Private Endpoints for Azure services in ASE subnet or separate subnet. ASE apps access services via Private Endpoints using private IPs. Combine with route all forcing traffic to Private Endpoints through firewall. Enables fully private architecture—ASE in VNet (private), accessing services via Private Endpoints (private), optionally routing through firewall (inspected). DNS configuration: ILB ASE requires private DNS or custom DNS. Create DNS zone for ASE domain (ase.contoso.com), A record *.ase.contoso.com pointing to ILB IP, wildcard enables all apps resolving automatically. For hybrid scenarios, configure DNS forwarding from on-premises to Azure or vice versa. Monitoring ASE networking: Enable diagnostic logs on NSG capturing flow logs, configure Network Watcher monitoring connectivity, implement Azure Monitor alerts for ASE health, review application logs for network errors, test connectivity regularly validating configurations. ASE scaling: ASE can scale to 200 instances (much larger than multi-tenant). Subnet must have sufficient IPs for scale—/24 provides 251 usable IPs supporting 200 instances. Plan subnet size for maximum anticipated scale.

SQL Managed Instance Network Security

SQL MI Subnet Requirements and Configuration

Azure SQL Managed Instance deploys in customer VNet with dedicated subnet providing network isolation and near-complete SQL Server compatibility. Managed Instance architecture: Managed Instance cluster deployed in subnet, internal load balancer for failover and routing, management endpoint for Azure control plane, connectivity endpoints for client connections. Subnet requirements: Dedicated to SQL Managed Instance (can't share with other resources including other Managed Instances initially, can share after first), minimum /28 (16 IPs) but /27 or /26 recommended for multiple instances and scaling, subnet can't be gateway subnet, subnet must be delegated to Microsoft.Sql/managedInstances, subnet must have route table and NSG with specific rules. Subnet size considerations: Each Managed Instance requires 5 IPs base plus IPs for each vCore (approximately 5-17 IPs per instance), failover operations temporarily require additional IPs, plan for growth and multiple instances. Production recommendations: /27 (32 IPs) for single instance, /26 (64 IPs) for multiple instances or large instance.

Creating SQL Managed Instance: Portal—SQL managed instances → Create → Basics (name, region, admin credentials) → Networking (VNet, subnet, connection type) → Security → Review + create. Prerequisites: VNet in same region, dedicated subnet meeting size requirements, NSG and route table with required rules. Managed Instance deployment takes 4-6 hours for first instance in subnet (subsequent instances 1-2 hours). Connection types: Public endpoint—optional public IP for connections from internet (disabled by default), requires explicit enabling and firewall rules. Private endpoint—always available, primary connection method, uses private IP from subnet. Hybrid connectivity—access from on-premises via VPN or ExpressRoute using private endpoint. Managed Instance accessible via FQDN (instance.database.windows.net) resolving to private IP within VNet, public IP if public endpoint enabled.

SQL MI Network Security Rules

NSG rules for SQL Managed Instance: Microsoft provides required rules ensuring management traffic. Inbound rules: Allow 9000, 9003, 1438, 1440-1452 from management tags (SqlManagement, CorpNetSaw) for Azure management plane. Allow 3342 from any for internal cluster communication. Application traffic: Allow 1433 from required sources (on-premises, Azure VMs, App Service VNet integration). Outbound rules: Allow 443 to AzureCloud for Azure dependencies. Allow 1433, 11000-11999 for geo-replication. Allow 5671 to Service Bus, 12000 for Storage. Deny internet outbound at end preventing unauthorized external connections. User rules: Can add additional rules after required rules (higher priority). Block specific IPs, allow from specific VNets, implement granular access control. NSG flow logs capture SQL MI traffic for security monitoring and compliance.

Route table for SQL Managed Instance: Required routes for management traffic. 0.0.0.0/0 next hop Internet ensuring management traffic reaches Azure infrastructure. If implementing forced tunneling (0.0.0.0/0 to firewall), add more specific routes for management IP ranges with next hop Internet. On-premises routes: If using VPN or ExpressRoute, add routes for on-premises prefixes with next hop Virtual Network Gateway. Managed Instance can then reach on-premises SQL Servers, Active Directory, applications. Service endpoint routes: If using service endpoints for Storage or other services, routes automatically added by Azure. Verify routes using Next Hop tool in Network Watcher. Security best practices: Keep public endpoint disabled unless required by specific scenario with strong justification and approval. Use NSG following Microsoft template—don't remove required rules. Implement additional user rules for least privilege access. Enable Advanced Threat Protection detecting anomalous activities, SQL injection, vulnerability assessment. Configure firewall rules allowing only required source IPs or VNets. Use Azure AD authentication for modern identity management. Implement TLS 1.2 encryption for all connections. Enable auditing sending logs to Storage or Log Analytics. Configure diagnostic settings for monitoring. Regular security reviews and updates. Implement failover groups for high availability and disaster recovery. Test restore procedures regularly.

Real-World Private Access Scenarios

Scenario 1: Healthcare Application with Complete Private Connectivity

Business Requirement: Healthcare provider developing patient portal application handling protected health information (PHI) requires complete network isolation, no public internet exposure, HIPAA compliance with private connectivity, integration with on-premises EHR systems, and access from hospital VPN users.

Azure Solution: Private Endpoints and App Service Environment

  • App Service Environment: Deploy ILB ASE (Internal Load Balancer) in dedicated subnet (/24) providing single-tenant isolated App Service infrastructure. ASE apps accessible only via private IP address in VNet—no public endpoint. Configure custom domain for ASE (portal.healthcare.internal). Create App Service plan in ASE using Isolated tier. Deploy patient portal application to plan—automatically in VNet with private IP only.
  • Private Endpoints for Azure Services: Create Private Endpoints for backend services in dedicated PE subnet: Azure SQL Database with Private Endpoint providing private IP eliminating public database exposure, Azure Storage (blob and file) for medical images and documents, Azure Key Vault for secrets and certificates, Azure Cosmos DB for document storage, Azure Redis Cache for session management. All services accessed via private IPs from ASE apps.
  • Azure Private DNS Zones: Configure Private DNS Zones for automatic name resolution: privatelink.database.windows.net for SQL, privatelink.blob.core.windows.net for Storage, privatelink.vaultcore.azure.net for Key Vault, privatelink.documents.azure.com for Cosmos DB. Link DNS Zones to VNet enabling proper resolution. ASE apps resolve service FQDNs to private IPs automatically.
  • On-Premises Connectivity: Implement ExpressRoute connecting hospital datacenters to Azure VNet. Configure BGP advertising on-premises and Azure prefixes. Deploy Azure VPN Gateway as backup path. On-premises EHR systems access Azure private services via ExpressRoute. Configure DNS forwarding from on-premises DNS to Azure DNS (168.63.129.16) enabling on-premises users resolving private IPs for Azure services.
  • Network Security Groups: ASE subnet NSG: Allow inbound 454-455 from AppServiceManagement, Allow inbound 443 from hospital VPN ranges and on-premises, Deny all other inbound. Private Endpoint subnet NSG: Allow inbound 1433 (SQL), 443 (Storage, Key Vault, Cosmos DB), 6379 (Redis) from ASE subnet, Allow inbound from on-premises for select services, Deny all other inbound. All subnets: Allow outbound to Azure management, Deny direct internet outbound.
  • Traffic Inspection: Deploy Azure Firewall in hub subnet. Configure UDRs on ASE and Private Endpoint subnets routing traffic through firewall: 0.0.0.0/0 next hop Firewall private IP. Firewall application rules: Allow ASE apps to Private Endpoints, Allow on-premises to Private Endpoints and ASE, Inspect HTTPS traffic with TLS inspection detecting malware. Firewall network rules: Allow specific protocols and ports, Deny all else. Enable threat intelligence blocking known malicious actors.
  • Access Control: ASE apps implement Azure AD authentication with conditional access requiring MFA and compliant devices. SQL Database uses Azure AD authentication with managed identity for app connections eliminating connection strings. Implement role-based access in application matching healthcare roles (physician, nurse, administrator). Key Vault access policies grant ASE managed identity secrets access. Enable audit logging on all Azure services capturing access to PHI.
  • Monitoring and Compliance: Enable NSG flow logs on all subnets with Traffic Analytics. Configure Azure Firewall diagnostics logging all traffic. Enable SQL Database auditing logging queries accessing patient data. Implement Azure Sentinel correlating security events across environment. Create workbook showing HIPAA compliance metrics: All services accessed privately, No public endpoints enabled, All access attempts logged, MFA enforcement rate. Generate monthly compliance reports for audit. Configure alerts: Public endpoint enabled on any service, Access from unexpected location, Failed authentication attempts, Unusual data access patterns.
  • Disaster Recovery: Implement SQL Database active geo-replication to secondary region with Private Endpoints. Configure ASE in secondary region (cold standby). Test failover quarterly verifying private connectivity maintained in DR region. Document failover procedures including DNS updates and traffic manager configuration.

Outcome: Complete network isolation with zero public internet exposure meeting HIPAA requirements. All Azure services accessed via Private Endpoints with private IPs. On-premises EHR integration via ExpressRoute with private connectivity end-to-end. Comprehensive security monitoring and audit trails. Zero PHI breaches attributed to network exposure in 24 months. Successful HIPAA audits with no findings related to network security. Patient portal handling 50,000 daily users with 99.95% availability.

Scenario 2: Multi-Tenant SaaS with Private Link Service

Business Requirement: Software company providing financial analytics SaaS platform needs to offer private connectivity option for enterprise customers requiring direct private connection from their Azure VNet to SaaS platform without public internet, isolated network paths per customer, and meeting financial industry compliance.

Azure Solution: Private Link Service with Multi-Tenant Architecture

  • SaaS Backend Architecture: Deploy application backends in VNet: Three-tier architecture (web, app, database) with VMSS in each tier for scale. Create internal Standard Load Balancer with frontend IP, backend pool with app tier VMSS, health probes, load balancing rules on port 443. Application tier connects to SQL Database with Private Endpoint and uses managed identity. Scale backend based on load—VMSS auto-scale rules adding instances during peak hours.
  • Private Link Service Setup: Create dedicated subnet for Private Link service (/28 minimum) in same VNet as backends. Create Private Link service referencing internal load balancer. Configure NAT IP addresses for SNAT (primary and secondary IPs from Private Link subnet). Enable auto-approval for trusted customer subscriptions. Enable manual approval for new customers requiring validation. Private Link service receives unique alias shared with customers through secure onboarding.
  • Customer Onboarding: Customer creates Private Endpoint in their VNet using SaaS provider's Private Link service alias. Connection request appears in SaaS provider portal with customer details. Provider validates customer (subscription verification, contract check, security review). Provider approves connection—Private Endpoint activates in customer VNet. Customer receives private IP address for accessing SaaS platform. Customer configures DNS (custom or Azure Private DNS) resolving SaaS FQDN to private IP.
  • Network Isolation Per Customer: Each customer Private Endpoint provides isolated network path—traffic from Customer A never mixes with Customer B at network layer. Private Link service maintains separate connections. Backend application implements additional tenant isolation: Database row-level security filtering by tenant ID, API authentication with tenant-specific tokens, Logging segregated by tenant, Data encryption with tenant-specific keys. Combined network and application isolation provides defense-in-depth multi-tenant security.
  • Monitoring and Management: Track all Private Endpoint connections in portal: Active connections with customer details, Pending approvals, Connection health and traffic metrics. Implement billing based on Private Endpoint connections—each customer connection tracked separately. Monitor backend load balancer health ensuring application availability. Configure alerts: New connection requests requiring approval, Connection failures indicating customer issues, Backend health degradation, Unusual traffic patterns per connection. Provide customer portal showing their connection status, usage statistics, and support options.
  • Security and Compliance: Backend application authentication required despite Private Link—implement OAuth 2.0 with customer-specific credentials. Log all API calls with customer identifier for audit trail. Backend NSGs restrict traffic to load balancer only. Enable Web Application Firewall inspecting all traffic from Private Endpoints. Implement rate limiting per customer preventing resource exhaustion. SQL Database Advanced Threat Protection detects attacks. Regular security assessments and penetration testing. Document security architecture for customer audits showing network isolation and security controls.
  • Scaling and Performance: Private Link service supports 1000+ simultaneous connections. Backend VMSS scales to handle aggregate load from all customers. Monitor performance metrics per customer identifying heavy users. Implement caching reducing database load. Optimize queries and indexes. Deploy Application Insights tracking request latency and errors by customer. Provide customer SLA guaranteeing 99.9% availability and response times.
  • Customer Support and Documentation: Provide comprehensive connection guide with screenshots and CLI commands. Offer ARM template for automated Private Endpoint deployment. Document DNS configuration options (Azure Private DNS, custom DNS). Create troubleshooting guide for common connectivity issues. Maintain support portal with customer-specific dashboards. Respond to connection issues within SLA timeframes. Conduct customer training on private connectivity benefits and configuration.

Outcome: Successful private connectivity offering differentiating SaaS product in market. 50+ enterprise customers using Private Link connections representing 60% of revenue. Zero network security incidents despite multi-tenant architecture. Customer satisfaction increased due to network isolation and performance. New customer acquisition improved—private connectivity requirement met. Compliance simplified—customers satisfy their requirements through private connection. Average customer connection setup time reduced from 2 weeks (previous VPN approach) to 1 day (Private Link).

Scenario 3: SQL Managed Instance for Lift-and-Shift Migration

Business Requirement: Enterprise migrating on-premises SQL Server estate to Azure needs near-complete SQL Server compatibility, network isolation, hybrid connectivity for phased migration, integration with on-premises Active Directory, and minimal application changes.

Azure Solution: SQL Managed Instance with Hybrid Architecture

  • Network Foundation: Create hub-spoke architecture in Azure: Hub VNet (10.0.0.0/16) with subnets for VPN Gateway, Azure Firewall, shared services. Spoke VNet (10.1.0.0/16) with dedicated subnet for SQL Managed Instance (/26 providing 64 IPs). VNet peering between hub and spoke with gateway transit enabled. Deploy ExpressRoute and VPN Gateway in hub for redundant on-premises connectivity. Configure BGP advertising Azure and on-premises prefixes automatically.
  • SQL Managed Instance Deployment: Create route table with required routes: 0.0.0.0/0 next hop Internet for management traffic, On-premises prefixes with next hop VPN Gateway. Create NSG with required rules allowing management traffic (9000, 9003, 1438, 1440-1452) plus application traffic (1433 from on-premises and Azure). Delegate subnet to Microsoft.Sql/managedInstances. Deploy SQL Managed Instance in subnet: Business Critical tier (4 vCores initially, scale later), Zone redundant for high availability, LRS backup storage. Instance takes 4 hours for initial deployment. Configure instance FQDN (sqlmi.database.windows.net) resolving to private IP within VNet.
  • Hybrid Connectivity and DNS: Configure DNS for split-brain resolution: On-premises DNS forwards Azure queries to Azure DNS, Azure custom DNS forwards on-premises queries to on-premises DNS. Enables SQL MI resolving on-premises Active Directory and applications, on-premises systems resolving SQL MI private FQDN. Test DNS resolution from both sides: From Azure: nslookup corp.onprem.local (should return on-premises IP), From on-premises: nslookup sqlmi.database.windows.net (should return SQL MI private IP). Configure SQL MI custom DNS servers pointing to Azure DNS forwarder VMs.
  • Active Directory Integration: Deploy Azure AD Connect in hub VNet synchronizing on-premises AD to Azure AD. Enable Azure AD authentication on SQL Managed Instance. Configure Windows Authentication using on-premises AD: SQL MI joins on-premises domain via Azure AD DS or extends on-premises AD to Azure. Applications use Windows Auth without code changes. AD groups define SQL roles and permissions centrally. Kerberos authentication works across ExpressRoute.
  • Migration Approach: Phase 1—Pilot: Migrate non-production databases to SQL MI testing compatibility and performance. Use Database Migration Service with minimal downtime. Validate application connectivity via ExpressRoute. Phase 2—Gradual Cutover: Migrate production databases one application at a time. Configure database-level firewall rules restricting access. Update application connection strings pointing to SQL MI. Maintain on-premises databases as backup initially. Phase 3—Decommission: After validation period, decommission on-premises SQL Servers. Archive backups to Azure. Update disaster recovery plans. Entire migration completed over 6 months minimizing risk.
  • Security Configuration: Disable public endpoint on SQL MI—access only via private connectivity. Enable Advanced Threat Protection detecting SQL injection, anomalous access, brute force. Configure SQL Auditing sending logs to Azure Storage and Log Analytics. Enable Transparent Data Encryption (TDE) with customer-managed keys in Key Vault. Implement Always Encrypted for sensitive columns (SSN, credit cards). Configure firewall rules allowing only on-premises and Azure application IPs. Enable Microsoft Defender for SQL providing vulnerability assessment and recommendations. Configure long-term retention for backups meeting compliance (7 years).
  • High Availability and Disaster Recovery: SQL MI Business Critical tier provides built-in HA with availability groups: Three replicas in availability group, Automatic failover on failure, Zone redundancy distributing replicas across zones. Configure auto-failover group to secondary region for DR: Geo-replication to paired region SQL MI, Read-only replica for reporting offload, Automatic failover on regional outage. Test failover quarterly measuring RTO and RPO. Document failover procedures and runbooks. Implement backup strategy: Automated backups (default), Long-term retention for compliance, Point-in-time restore tested monthly, Cross-region backup copies.
  • Performance and Monitoring: Configure Azure Monitor for SQL MI: Metrics (CPU, memory, storage, connections), Diagnostic logs (SQL statements, waits, errors), Alerts on performance degradation. Implement Query Performance Insight identifying slow queries. Enable SQL Insights for deep performance analysis. Configure Log Analytics workspace aggregating logs from SQL MI, applications, network (NSG flow logs). Create workbooks visualizing: Query performance trends, Connection patterns, Failed login attempts, Resource utilization. Establish performance baselines comparing to on-premises. Optimize indexes and queries based on monitoring.

Outcome: Successful lift-and-shift migration of 50 SQL Server databases to Azure with minimal application changes. Network isolation through SQL MI in VNet meeting enterprise security requirements. Hybrid connectivity enabling phased migration reducing risk. AD integration maintaining existing authentication without application rewrites. 99.99% availability achieved through Business Critical tier and zone redundancy. 50% cost reduction compared to maintaining on-premises SQL Server infrastructure. Improved disaster recovery with geo-replication (on-premises RTO was 4 hours, Azure achieves 1 hour). Enhanced security through Advanced Threat Protection detecting 12 potential attacks in first year. Monitoring improvement—SQL MI insights provide visibility exceeding previous on-premises tools.

Exam Preparation Tips

Key Concepts to Master

  • Service Endpoints: Optimize routing to Azure services over backbone, VNet identity for firewall rules, subnet-level, no private IPs, free
  • Private Endpoints: Dedicated private IP from VNet, brings service into VNet, per-resource, requires DNS configuration, charged per endpoint
  • Service Endpoints vs Private Endpoints: SE = optimized routing, public infrastructure; PE = true private IP, VNet integration
  • Private Link service: Expose custom services behind Standard LB, consumers create Private Endpoints, multi-tenant isolation
  • App Service VNet integration: Outbound connectivity to VNet, requires dedicated subnet, route all for comprehensive routing
  • Private Endpoint for App Service: Inbound private access, combine with VNet integration for full private connectivity
  • ASE: Single-tenant in VNet, ILB (private only) or External, /24 subnet, NSG and UDR requirements, Isolated tier plans
  • SQL MI: Deployed in VNet, dedicated subnet (/27 recommended), NSG for management traffic, UDR for routing, private connectivity
  • DNS for Private Endpoints: Azure Private DNS Zones for automatic resolution, CNAME to privatelink subdomain, A record to private IP

Practice Questions

Sample AZ-500 Exam Questions:

  1. Question: What is the main difference between Service Endpoints and Private Endpoints?
    • A) Service Endpoints are free; Private Endpoints have costs
    • B) Service Endpoints optimize routing but use public infrastructure; Private Endpoints provide dedicated private IPs
    • C) Service Endpoints work across regions; Private Endpoints don't
    • D) Service Endpoints support all Azure services; Private Endpoints support fewer

    Answer: B) Service Endpoints optimize routing but use public infrastructure; Private Endpoints provide dedicated private IPs - This is the fundamental architectural difference.

  2. Question: Which subnet size is minimum recommended for SQL Managed Instance in production?
    • A) /28 (16 IPs)
    • B) /27 (32 IPs)
    • C) /26 (64 IPs)
    • D) /24 (256 IPs)

    Answer: B) /27 (32 IPs) - While /28 is minimum, /27 is recommended for production allowing scaling and multiple instances.

  3. Question: What does VNet integration provide for Azure App Service?
    • A) Inbound private access to the app
    • B) Outbound connectivity from app to VNet resources
    • C) Both inbound and outbound private connectivity
    • D) DDoS protection

    Answer: B) Outbound connectivity from app to VNet resources - VNet integration is for outbound only; use Private Endpoint for inbound.

  4. Question: What is required for Private Endpoint DNS resolution to work automatically?
    • A) Custom DNS server
    • B) Azure Private DNS Zone integrated with VNet
    • C) Public DNS delegation
    • D) DNS forwarder

    Answer: B) Azure Private DNS Zone integrated with VNet - Private DNS Zone provides automatic CNAME and A record resolution.

  5. Question: Which App Service Environment type provides apps with private IP addresses only?
    • A) External ASE
    • B) Internal Load Balancer (ILB) ASE
    • C) Both External and ILB ASE
    • D) ASEv2 only

    Answer: B) Internal Load Balancer (ILB) ASE - ILB ASE provides private IP only; External ASE has public endpoint.

  6. Question: What Azure component is required to create a Private Link service?
    • A) Application Gateway
    • B) Azure Firewall
    • C) Standard Load Balancer
    • D) Traffic Manager

    Answer: C) Standard Load Balancer - Private Link service requires backend services behind Standard Load Balancer (internal).

  7. Question: Which setting must be enabled for App Service VNet integration to route all outbound traffic through VNet?
    • A) VNet injection
    • B) Route All
    • C) Private Endpoint
    • D) Gateway transit

    Answer: B) Route All - Route All setting forces all outbound traffic including internet through VNet.

  8. Question: What port must be allowed on SQL Managed Instance NSG for Azure management?
    • A) 1433
    • B) 3389
    • C) 9000-9003, 1438, 1440-1452
    • D) 443

    Answer: C) 9000-9003, 1438, 1440-1452 - These ports required for Azure management plane to manage SQL MI.

AZ-500 Success Tip: Remember Service Endpoints optimize routing with VNet identity but use public infrastructure; Private Endpoints provide dedicated private IPs bringing services into VNet. VNet integration gives App Service outbound VNet connectivity (route all for all traffic); Private Endpoint provides inbound private access to App Service. ASE is single-tenant in VNet—ILB type for private only, requires /24 subnet with NSG and UDR. SQL MI requires dedicated subnet (/27 recommended), specific NSG rules for management traffic (9000-9003, 1438, 1440-1452), and route table with 0.0.0.0/0 to Internet. Private Link service exposes custom services behind Standard Load Balancer. Azure Private DNS Zones provide automatic DNS resolution for Private Endpoints with CNAME to privatelink subdomain.

Hands-On Practice Lab

Lab Objective

Implement private access to Azure resources including Service Endpoints, Private Endpoints with DNS configuration, App Service VNet integration, and configure resource firewalls for private-only access.

Lab Activities

Activity 1: Configure Service Endpoints

  • Create resources: Create VNet "VNet-Private" (10.0.0.0/16) with subnet "app-subnet" (10.0.1.0/24). Create Azure Storage account "stprivatelab[unique]".
  • Enable service endpoint: VNet → Subnets → app-subnet → Service endpoints → Add → Microsoft.Storage → Save
  • Configure storage firewall: Storage account → Networking → Firewalls and virtual networks → Selected networks → Add existing virtual network → Select VNet-Private, app-subnet → Save
  • Create test VM: Deploy VM in app-subnet. Attempt accessing storage from VM (should succeed). Attempt from browser (should fail due to firewall).
  • Verify optimization: From VM, traceroute to storage account showing minimal hops (optimal backbone routing)

Activity 2: Create Private Endpoint with Private DNS

  • Create Private Endpoint subnet: Add subnet "pe-subnet" (10.0.2.0/24) to VNet-Private
  • Create Private Endpoint: Private Link Center → Private endpoints → Create → Name "PE-Storage-Blob", Resource type Storage account, Resource [your storage], Target sub-resource "blob", VNet-Private, pe-subnet
  • Configure DNS: During creation, Private DNS zone integration → Yes → Zone "privatelink.blob.core.windows.net" → Create
  • Verify DNS resolution: From VM: nslookup stprivatelabXXXX.blob.core.windows.net → Should return private IP (10.0.2.x) not public IP
  • Test connectivity: Access blob storage from VM using private IP. Optionally disable public network access on storage account.

Activity 3: Configure App Service VNet Integration

  • Create App Service: Create Web App with Premium V2 or V3 plan (VNet integration requires Premium)
  • Create integration subnet: Add subnet "integration-subnet" (10.0.3.0/24) to VNet-Private
  • Enable VNet integration: App Service → Networking → VNet Integration → Add VNet → Select VNet-Private, integration-subnet → Enable
  • Enable route all: App Service → Configuration → General settings → Route All → On → Save
  • Test connectivity: Use Kudu console (Advanced Tools): nameresolver [private-endpoint-resource-name] → Should resolve to private IP. tcpping [private-ip]:443 → Should succeed.

Activity 4: Create Private Endpoint for App Service

  • Create Private Endpoint to App Service: Private Link Center → Create → App Service "sites", select your web app, pe-subnet, integrate with Private DNS Zone "privatelink.azurewebsites.net"
  • Configure DNS: Verify Private DNS Zone created with A record for your app pointing to private IP
  • Test private access: From VM in VNet, browse to app using app.azurewebsites.net URL → Resolves to private IP, accessible
  • Optionally disable public access: App Service → Networking → Access restrictions → Deny all public access (allows only Private Endpoint)
  • Verify isolation: From internet, browsing to app URL should fail (if public access disabled) or show access restriction error

Activity 5: Review and Validate Configuration

  • Service Endpoints: Verify subnet has service endpoint enabled, storage firewall allows VNet, VM can access storage
  • Private Endpoints: Check Private Endpoints created in pe-subnet, Private DNS Zones linked to VNet, DNS resolution returns private IPs
  • VNet integration: App Service connected to integration-subnet, route all enabled, app can access Private Endpoints
  • Network topology: Document complete setup: Service Endpoints for service optimization, Private Endpoints for Storage and App Service, App Service with both VNet integration (outbound) and Private Endpoint (inbound)
  • Clean up: Remove resources to avoid charges: Private Endpoints first, then DNS Zones, App Service, Storage, VMs, VNet

Lab Outcomes

After completing this lab, you'll have hands-on experience with private access technologies. You'll understand how Service Endpoints optimize routing and provide VNet-based firewall rules, Private Endpoints bring services into VNet with dedicated private IPs, Azure Private DNS Zones automate DNS resolution for Private Endpoints, App Service VNet integration provides outbound connectivity to VNet resources, and Private Endpoints to App Service enable inbound private access. These practical skills demonstrate private access capabilities tested in AZ-500 exam and provide foundation for implementing comprehensive private connectivity in production Azure environments.

Frequently Asked Questions

What are virtual network Service Endpoints and when should you use them?

Virtual network Service Endpoints extend VNet private address space and identity to Azure services over direct backbone connection, optimizing traffic routing and enabling VNet-based access control. Without service endpoints, traffic to Azure services (Storage, SQL, Key Vault) travels over public internet with public IP addresses, even from VMs within VNet. Service endpoints provide optimal routing—traffic stays on Azure backbone network never traversing public internet, reducing latency and improving throughput. Traffic originates from VNet private IPs enabling service firewall rules restricting access to specific VNets and subnets. Service endpoints available for Azure Storage, SQL Database, Cosmos DB, Key Vault, Service Bus, Event Hubs, Data Lake, App Service, and Cognitive Services. Configuration: Enable service endpoint on subnet for specific service (Microsoft.Storage, Microsoft.Sql, etc.), configure service firewall allowing VNet/subnet access. Benefits: Optimal routing improving performance, ability to remove public IPs from resources (some services), VNet identity for firewall rules, simple configuration without gateway deployment, no additional cost for service endpoints. Considerations: Service endpoint only affects routing and access control—traffic still uses service's public endpoint infrastructure (not truly private), service endpoint provides subnet-level control not per-resource, service must support service endpoints, and removing service endpoint doesn't remove service firewall rules requiring manual cleanup. When to use: Accessing Azure services from VNet needing better performance than internet path, implementing VNet-based access control on Azure services, services not supporting Private Endpoints, cost-sensitive scenarios avoiding Private Endpoint charges. When not to use: Requiring truly private IP addresses on Azure services (use Private Endpoints), DNS resolution to private addresses needed, strict network isolation requirements, or services requiring dedicated private connectivity. Service endpoints complement Private Endpoints—can use both depending on requirements.

What are Private Endpoints and how do they differ from Service Endpoints?

Private Endpoint is network interface with private IP address from your VNet connecting to Azure service or custom Private Link service, bringing service into your VNet making it accessible via private IP without public endpoint. Unlike Service Endpoints which optimize routing but still use public infrastructure, Private Endpoint provides true private connectivity. Private Endpoint network interface placed in your subnet receives private IP from subnet address range, creates DNS entries resolving service FQDN to private IP (with proper DNS configuration), eliminates need for public endpoint access, and works with Azure DNS Private Zones for automatic DNS resolution. Supports Azure Storage, SQL Database, Cosmos DB, Key Vault, App Service, Azure Cognitive Services, Container Registry, and many other services. Configuration: Create Private Endpoint in VNet/subnet specifying target resource and sub-resource (blob, file, SQL, etc.), configure Private DNS Zone for automatic name resolution or custom DNS, approve connection at target resource (automatic or manual approval), verify DNS resolution returning private IP. Benefits: True network isolation with traffic staying entirely within VNet, no public IP exposure possible, granular control per resource (unlike service endpoints), works with on-premises via VPN or ExpressRoute with private connectivity, supports custom DNS and Azure Private DNS integration, prevents data exfiltration by blocking public access, meets compliance requirements for private connectivity. Comparison to Service Endpoints: Service Endpoints optimize routing and provide subnet-level access control but traffic still uses public infrastructure; Private Endpoints provide dedicated private IP address eliminating public exposure entirely. Service Endpoints free; Private Endpoints charged per endpoint per hour plus data processing. Service Endpoints simpler to configure; Private Endpoints require DNS configuration. Service Endpoints subnet-level; Private Endpoints per-resource. Both can coexist for hybrid approach. When to use Private Endpoints: Strict network isolation requirements, compliance mandating no public endpoints, connecting on-premises to Azure services privately, per-resource access control needed, DNS resolution to private IPs required. When to use Service Endpoints: Cost optimization, simpler configuration acceptable, subnet-level control sufficient, services not supporting Private Endpoints. Best practice: Use Private Endpoints for production sensitive workloads requiring maximum isolation; use Service Endpoints for development/test or cost-sensitive scenarios.

Share:

Written by Joe De Coppi - Last Updated November 14, 2025

Previous: Objective 2.1 Plan Implement Security Virtual Networks

Next: Objective 2.3 Plan Implement Security Public Access Azure Resources