Skip to article
Security Data operations

Private Link for data services

Private Link for data services means your applications connect to databases, storage, and analytics services through private endpoints instead of public endpoints.

Source: Microsoft Learn - What is Azure Private Link? Reviewed 2026-05-20

Exam trap
Treating all data services the same even though each has different group IDs, DNS zones, limits, and firewall behavior.
Production check
List private endpoints for the data service and confirm target resource ID, group ID, approval state, and private IP.
Practice this topic Microsoft Learn
Article details and learning context
Aliases
None listed
Difficulty
intermediate
CLI mappings
5
Last verified
2026-05-20
Learning paths Graph Security concept cluster Private Link for data services
Compare related concepts Search related resources Browse the glossary

Understand the concept

In plain English

Private Link for data services means your applications connect to databases, storage, and analytics services through private endpoints instead of public endpoints. The data service still exists as an Azure platform service, but the client reaches a private IP in a virtual network. This pattern is common for regulated databases, data lakes, RAG stores, and integration pipelines. It does not remove the need for database logins, managed identities, keys, firewalls, or encryption. It controls the network path for sensitive data movement.

Why it matters

Data services are high-value targets because they hold customer records, financial data, operational telemetry, training data, and business history. Private Link for data services matters because it reduces public endpoint exposure while keeping managed Azure database and storage capabilities. It also gives auditors clearer evidence than broad firewall exceptions: which service instance is approved, which subnet can reach it, what private IP is used, and whether public access is disabled. The pattern prevents a common architecture gap where the application is private but its database, data lake, or queue still accepts public network traffic. Used well, it improves both security and operational clarity.

Official wording and source

Private Link for data services is the pattern of reaching Azure data platforms, such as Storage, SQL, Cosmos DB, PostgreSQL, MySQL, or analytics services, through private endpoints. It keeps data-plane traffic on private network paths while preserving service-specific authentication, authorization, DNS, and firewall controls.

Open Microsoft Learn

Technical context

Technically, this pattern spans networking and the data plane. Each data service has its own Private Link behavior, target subresources, DNS zones, public access settings, and firewall model. Storage may need blob and dfs endpoints, SQL uses server-level private endpoints, Cosmos DB uses API-specific endpoints, and PostgreSQL or MySQL private access affects server connectivity. Architects coordinate VNets, private DNS, managed identity, RBAC, database authentication, diagnostic logs, replication, failover, and data movement tools so every client reaches the intended private service instance.

Exam context

Compare with

Storage account Storage firewall

Where it is used

Where you see it

  1. Database, storage, and analytics networking blades show private endpoint connections, public access settings, firewall rules, target subresources, and approved client network relationships. during reviews now
  2. Azure CLI output from SQL, Storage, Cosmos DB, PostgreSQL, private endpoint, and DNS commands exposes endpoint IDs, private IPs, group IDs, and service states. too
  3. Pipeline failures, database connection errors, storage diagnostic logs, DNS lookups, and application dependency telemetry reveal whether data traffic follows the private route. during incidents clearly

Common situations

  • Move regulated databases to private access while preserving managed Azure SQL, Cosmos DB, PostgreSQL, or MySQL capabilities.
  • Protect data lake ingestion by requiring private blob and dfs paths for analytics jobs and integration runtimes.
  • Standardize private database connectivity for landing zones so application teams avoid one-off public firewall exceptions.
  • Support hybrid data migration over ExpressRoute or VPN without opening broad public data service access.
  • Prepare failover designs by documenting which replicas, secondary endpoints, or read regions need private connectivity.

Illustrative Azure scenarios

These examples show how the concept can affect design and operations. They are illustrative scenarios, not customer claims.

Scenario 01 Airline reservation data moves behind private endpoints Scenario, objectives, solution, measured impact, and takeaway.
Scenario

An airline modernized reservation analytics using Azure SQL and Azure Storage. The security team required private data-plane connectivity before passenger itinerary data could be processed in the new environment.

Goals
  • Keep SQL and storage traffic on private network paths.
  • Support analytics jobs, web APIs, and migration tools from different subnets.
  • Disable public access without breaking nightly data loads.
  • Produce evidence for travel-data compliance reviews.
Approach using Private Link for data services

The platform team created private endpoints for the Azure SQL server and the storage account blob and dfs subresources. Private DNS zones were linked to the analytics VNet, API VNet, and migration subnet. Self-hosted integration runtimes were tested separately because they resolved endpoints through a different DNS path than the web APIs. Public network access was disabled after read-only validation queries, sample writes, and nightly load tests succeeded. Managed identities controlled data access, SQL auditing captured sensitive operations, and CLI evidence exported endpoint IDs, DNS records, public access settings, and firewall configuration. Recovery scripts were included so private access covered both operations and analytics.

Potential outcomes
  • Passenger analytics workloads moved without public database or storage firewall exceptions.
  • Nightly data load failures during the migration window dropped by 58%.
  • Compliance evidence preparation fell from six days to two days.
  • Teams identified DNS misconfiguration before production cutover rather than during live loads.
What to learn

Private Link for data services must cover every data client path, not just the main application subnet.

Scenario 02 Biotech analytics platform protects research datasets Scenario, objectives, solution, measured impact, and takeaway.
Scenario

A biotech company processed sequencing data, lab metadata, and model outputs in Azure. Researchers needed fast analytics, but legal and privacy teams required private access to Storage, Cosmos DB, and PostgreSQL dependencies.

Goals
  • Prevent public endpoint dependency for sensitive research datasets.
  • Keep pipeline workers, notebooks, and APIs connected to the same private data services.
  • Support separate DNS zones for storage, document, and relational data paths.
  • Reduce manual security exceptions for new research projects.
Approach using Private Link for data services

Engineers deployed private endpoints for the storage account blob and dfs paths, Cosmos DB account, and PostgreSQL flexible server. The hub DNS service forwarded private zones to spoke VNets used by notebooks, pipeline workers, and application APIs. Public access was disabled after each runtime passed targeted tests: metadata queries for PostgreSQL, document reads for Cosmos DB, and file operations for Data Lake Storage. The team documented authentication separately, using managed identity and database roles rather than assuming Private Link granted access. A reusable module created endpoints, DNS links, and evidence exports for each new research workspace.

Potential outcomes
  • New research workspaces launched with private data connectivity by default.
  • Manual firewall exception requests dropped by 82%.
  • Pipeline connection failures from DNS drift fell sharply after central zone management.
  • Security reviews focused on data roles and retention instead of debating public network exposure.
What to learn

Private data connectivity becomes scalable when endpoint, DNS, and identity patterns are packaged together for repeatable projects.

Scenario 03 Tax agency validates failover access for private databases Scenario, objectives, solution, measured impact, and takeaway.
Scenario

A tax agency ran a revenue processing application on Azure SQL, queues, and storage. Disaster recovery testing exposed that primary data paths were private, but secondary and recovery tooling still depended on public access.

Goals
  • Make primary and recovery data services reachable through private paths.
  • Test queue, storage, and database access from recovery subnets.
  • Remove hidden public endpoint dependencies before peak filing season.
  • Create repeatable evidence for continuity auditors.
Approach using Private Link for data services

The agency inventoried every data dependency used by the application, recovery scripts, and support tooling. Engineers created missing private endpoints for storage queues, blob recovery containers, and the SQL failover group listener path. Private DNS links were added for recovery VNets, and CLI tests validated the exact FQDNs used by scripts. Public network access was tightened only after a full recovery rehearsal. Diagnostic logs and activity records were exported to prove which connections were private, which identities performed recovery operations, and which DNS zones supported failover. Support engineers rehearsed the process using read-only tests before seasonal change freezes.

Potential outcomes
  • Recovery rehearsal completed without temporary public firewall openings.
  • Hidden public data dependencies were reduced to zero before peak season.
  • Continuity evidence collection time dropped by 63%.
  • Operators corrected two stale recovery scripts before they could affect production recovery.
What to learn

Private Link for data services has to include recovery, failover, and operations tooling, not just steady-state application traffic.

Azure CLI

As an Azure engineer with ten years of data platform operations, I use Azure CLI for Private Link on data services because each service exposes networking differently. SQL, Storage, Cosmos DB, PostgreSQL, and MySQL do not all use the same commands, DNS zones, or public access flags. CLI gives me a consistent way to inventory private endpoints, compare public access posture, validate DNS records, and export evidence across the whole data estate. It also prevents a classic mistake: fixing the application network while the database, storage subresource, or integration runtime still resolves through the wrong path. That evidence speeds recovery.

Useful for

  • Inventory private endpoints attached to SQL, Storage, Cosmos DB, PostgreSQL, MySQL, and analytics resources in a subscription.
  • Compare public network access settings across data services before enforcing a private-only policy.
  • Validate private DNS records for database and storage FQDNs used by applications, pipelines, and migration tools.
  • Create or inspect service-specific private endpoints with the correct target subresource or group ID.
  • Export private connectivity, firewall, identity, and diagnostic evidence for data-protection audits.

Before you run a command

  • Confirm tenant, subscription, resource group, data service type, target server or account, VNet, subnet, and expected region.
  • Check permissions for both network resources and data service resources because endpoint creation and approval may be split.
  • Know service-specific destructive risks before changing public access, firewall rules, private endpoint approvals, or DNS records.
  • Verify provider registration for Microsoft.Network and the target data provider, such as Microsoft.Sql, Microsoft.Storage, or Microsoft.DBforPostgreSQL.
  • Use JSON output when comparing multiple services because group IDs, DNS zones, and public access fields vary by provider.

What the output tells you

  • Data service output shows service SKU, location, public access posture, firewall settings, provisioning state, and sometimes replica or failover configuration.
  • Private endpoint output shows the target resource, group ID, approval state, subnet, network interface, and assigned private IP.
  • DNS output confirms whether client-facing database or storage hostnames resolve to private endpoint records in linked networks.
  • Diagnostic and metric output helps separate network path failure from authentication denial, query timeout, storage throttling, or service outage.
  • Resource IDs and timestamps create audit evidence for who changed connectivity, when approval occurred, and which application path was affected.

Mapped commands

Private Link for data services CLI Commands

direct 
az network private-endpoint list --resource-group <resource-group>
az network private-endpointdiscoverAnalytics
read-only Microsoft Learn 
az sql server show --name <server-name> --resource-group <resource-group>
az sql serverdiscoverDatabases
read-only Microsoft Learn 
az storage account show --name <storage-account> --resource-group <resource-group>
az storage accountdiscoverStorage
read-only Microsoft Learn 
az cosmosdb show --name <account-name> --resource-group <resource-group>
az cosmosdbdiscoverDatabases
read-only Microsoft Learn 
az network private-dns record-set a list --zone-name <private-dns-zone> --resource-group <dns-resource-group>
az network private-dns record-set adiscoverAI and Machine Learning
read-only Microsoft Learn

Architecture context

As an Azure architect, I design Private Link for data services by walking the full data path. A web app may need private access to Azure SQL, Storage, Key Vault, and a queue; an analytics job may need blob, dfs, Synapse, and Event Hubs. Each dependency gets the correct private endpoint, DNS zone, and public access decision. I also test from managed compute, build agents, self-hosted integration runtimes, and on-premises networks. The architecture must account for read replicas, failover groups, geo-redundant storage, and data copy tools. The goal is not simply private everything; it is private access that remains supportable during migration, failover, and incident response.

Security
Security impact is direct because this pattern protects data-plane paths to services that store or process sensitive information. Private Link reduces exposure to public endpoint scanning and can support data exfiltration controls, but risk remains if database permissions are broad, keys are leaked, managed identities are overprivileged, public access remains open, or DNS routes clients incorrectly. Service-specific controls still matter: SQL auditing, Storage firewall, Cosmos RBAC, Key Vault secrets, PostgreSQL SSL, and diagnostic retention. Security reviews should inspect private endpoint approval, public access posture, encryption, identity, firewall rules, data classification, logging, and how cross-tenant or hybrid clients are approved. Review exceptions regularly.
Cost
Cost impact is direct through Private Link charges and indirect through the number of data services and environments. A single application may require private endpoints for SQL, Storage blob, Storage dfs, queues, Key Vault, and monitoring dependencies. Endpoint sprawl, duplicated DNS zones, stale test databases, and retained diagnostic logs can all raise cost. However, standardized private data access can reduce audit effort, exception handling, and incident time. FinOps should track endpoint count by data product, data processed, idle data services that still have endpoints, logging retention, and whether nonproduction environments need the same private connectivity depth as production. Review monthly.
Reliability
Reliability impact is direct because data services are often application-critical. Private Link failures can look like database outages, storage hangs, queue delays, or ETL failures even when the service is healthy. DNS mistakes, wrong target subresources, rejected connections, subnet IP exhaustion, region mismatches, or disabled public access can all break workloads. Reliable designs test connectivity from every client path, document failover behavior, and confirm secondary or replica access where needed. Operators should monitor private endpoint state, DNS records, database connection failures, storage latency, retry counts, self-hosted integration runtime health, and whether failover changes require new private connectivity. Test recovery paths.
Performance
Performance impact is usually indirect and service-specific. Private Link changes the network path, but data performance still depends on database tier, storage SKU, partitioning, query design, connection pooling, regional placement, and client retries. DNS resolver placement and hub-spoke routing can add latency before a query or storage request starts. Data pipelines may slow down if self-hosted integration runtimes or build agents resolve endpoints differently from applications. Operators should measure database connection time, query latency, storage request latency, throughput, retry counts, resolver timing, and cross-region dependency paths before blaming Private Link or the data service alone. Measure before cutovers and migrations.
Operations
Operators manage this pattern by keeping an inventory of private endpoints per data service, DNS zones, public access settings, service firewall rules, and approved client networks. Troubleshooting starts with the exact client and the exact data endpoint: database server, storage subresource, Cosmos account, replica, or analytics workspace. CLI helps compare settings across services and export evidence for auditors. Runbooks should include connection strings without secrets, expected FQDNs, private IPs, authentication mode, failover behavior, and rollback choices. Data platform, network, security, and application teams must share ownership because no single team controls the whole path. Keep service ownership current during every release.

Common mistakes

  • Treating all data services the same even though each has different group IDs, DNS zones, limits, and firewall behavior.
  • Securing the primary database path while leaving migration tools, replicas, queues, or storage dependencies on public endpoints.
  • Disabling public access before self-hosted integration runtimes, build agents, backup jobs, or hybrid clients are tested.
  • Confusing network success with data access success when database roles, RBAC, keys, or managed identities are wrong.
  • Forgetting failover or read-replica private access and discovering the gap during a continuity event.