Continuous Replication and network connectivity in Azure for databases.

Problem statement: when Azure creates a replica for Azure MySQL server that has connectivity only through a private endpoint, it does not create the replica with another private endpoint but somehow replicates the database snapshot from primary. Does it need a private endpoint to the replica to facilitate automatic continuous replication?

Solution:

Even experts find themselves in opposite directions when answering this question because replication traffic and operational requirements go hand in hand. The short answer is no — you do not need to create a private endpoint on the replica for replication to function.

When Azure creates a read replica for a MySQL Flexible Server that is reachable only through a private endpoint, the replication traffic never flows through your VNet, your private endpoint, or any customer‑visible network surface. The private endpoint only governs how your clients reach the server. It does not govern how Azure’s internal control plane and data plane communicate with the managed MySQL instances. Azure MySQL Flexible Server is built on a managed compute fabric where the primary and replica servers live inside the same Azure-managed network boundary, even if they are in different regions. The replication channel is established entirely inside that boundary, using Azure’s internal service network, not your VNet. That means the replication protocol — which is MySQL’s native asynchronous binlog-based replication — is carried over an internal, non-customer-routable link. The wire traffic never touches your private endpoint, so the existence or absence of a private endpoint on the replica is irrelevant to the replication channel.

The initial snapshot is not copied through your private endpoint either. Azure uses an internal storage-layer snapshot mechanism to seed the replica. This is not a logical dump and not a network copy through your VNet. It is a block-level clone operation inside Azure’s storage fabric. Because the snapshot is taken and materialized inside the managed service boundary, there is no scenario in which Azure would need to traverse your private endpoint to hydrate the replica.

Once the replica is seeded, continuous replication begins. MySQL’s binlog replication requires the replica to connect to the primary’s replication endpoint. In a self-managed MySQL deployment, that would require network reachability between the two servers. But in Azure’s managed service, the replication endpoint is exposed only inside Azure’s internal network. The primary and replica are placed in a topology where they can reach each other without ever touching customer VNets. Azure enforces isolation at the service boundary, not by routing replication traffic through customer-controlled network constructs. This is why the private endpoint is irrelevant to replication: the private endpoint is a consumer-facing ingress point, not a service-to-service communication path.

The opposing view — that replication should require a private endpoint on the replica — cannot hold because it would imply that Azure routes internal service traffic through customer VNets, which would violate Azure’s network isolation model, break multi-tenant guarantees, and create circular dependencies where replication availability depends on customer-managed routing, NSGs, firewalls, or DNS. Azure’s managed database services are explicitly designed so that internal operations, including replication, backups, failover, and patching, are independent of customer networking. If replication depended on your private endpoint, a misconfigured NSG or DNS zone could break Azure’s ability to maintain replicas, which would contradict the service’s reliability guarantees.

If you inspect the replica’s network configuration, you will see that Azure does not create a private endpoint for it unless you explicitly request one for client access. Replication still works. If you delete the private endpoint on the primary, replication still works. If you isolate your VNet completely, replication still works. The only consistent explanation is that replication is not using your private endpoints at all.

So the answer is no, you do not need to add a private endpoint to the replica. Replication is an internal Azure operation that bypasses customer networking entirely, and the architecture of the service makes the opposite scenario impossible without breaking Azure’s isolation and reliability guarantees. However, you will need a private endpoint for client connections to the replica just like the primary and this is an operational requirement for some deployments.