Cloud private endpoints let you connect to managed services like Azure Storage, AWS S3, or Google Cloud SQL over your virtual network instead of the public internet. The concept sounds clean. The implementation frequently isn't. Australian IT teams who work through private endpoint deployments for the first time often discover that the configuration decisions are more consequential than the documentation suggests, and that the most common failure modes are invisible until something breaks at the worst time.
What private endpoints actually do
A private endpoint places a network interface inside your VNet or VPC that maps to a specific managed service instance. Traffic from your workloads travels to that interface, stays inside your cloud backbone, and never crosses the public internet. The managed service itself doesn't move. Its public endpoint still exists. What changes is that your network's DNS resolves the service name to the private IP, not the public one.
That DNS dependency is where most deployments start to go wrong. Private endpoints require private DNS zones to be configured correctly. If the DNS resolution falls back to the public IP, your traffic exits over the internet even though you have a private endpoint in place. Many Australian teams configure the endpoint, see a green tick in the portal, and assume traffic is now private. It might not be. DNS resolution needs to be verified separately, and this step gets skipped more often than it should.
The easiest check is to resolve the service hostname from inside the VNet and confirm it returns a private IP. In Azure environments, for example, a storage account endpoint like myaccount.blob.core.windows.net should return a 10.x.x.x address, not a public one. If it returns a public IP, the private DNS zone linkage is broken or missing.
Common misconfiguration patterns
Three specific patterns surface repeatedly in Australian environments. First, teams create private endpoints without disabling public network access on the backing service. A private endpoint alone does not block public access. You must explicitly disable the public endpoint on the service, typically through a firewall rule or network ACL on the resource itself. Without that step, the private endpoint exists but the service remains reachable from the internet.
Second, private DNS zones get created in one subscription but linked only to VNets in that same subscription. When workloads in a spoke subscription try to resolve the private endpoint hostname, DNS falls through to a public resolver. This is particularly common in hub-and-spoke topologies, which are standard across Australian enterprise cloud environments. The DNS zone needs to be linked to every VNet that will consume it, including those in separate subscriptions.
Third, on-premises connectivity is often overlooked. If your organisation routes traffic from on-premises offices or data centres through ExpressRoute or a VPN gateway into the cloud, those on-premises clients also need to resolve private endpoint hostnames correctly. That means conditional forwarders on your on-premises DNS servers pointing at your cloud private DNS resolvers. Without that, on-premises workloads reach the same service over the public internet while cloud workloads use the private path. Security teams checking traffic logs often don't catch this split for months.
The multi-region problem
Australian deployments increasingly span multiple regions for resilience, typically across Sydney and Melbourne availability zones or across AWS ap-southeast-2 and a secondary region. Private endpoint behaviour in multi-region architectures adds another layer of complexity.
Private endpoints are regional constructs. A private endpoint for a storage account in Sydney doesn't automatically give your Melbourne VNet private access to that account. Each region that needs private access requires its own private endpoint, and both need to share the same private DNS zone, or the DNS zone needs to be linked to both regional VNets. Miss that linkage and Melbourne traffic silently reverts to the public endpoint.
This matters for multi-region cloud strategy in Australian businesses, where the assumption is often that global resources like storage accounts or managed databases are accessible uniformly. They are, but not privately, unless each region's private endpoint and DNS configuration is set up independently.
Network security group interactions
Private endpoints sit on a subnet, and network security groups apply to subnets. A common mistake is applying NSG rules intended for VM traffic to the subnet where private endpoints live, inadvertently blocking traffic to the endpoint interface. Azure, for instance, requires that NSG policies on private endpoint subnets are explicitly managed; the default is that NSG rules don't apply to private endpoint traffic, but that behaviour can be changed with a subnet property, and teams who turn it on without understanding the effect block their own traffic.
AWS PrivateLink has equivalent considerations with VPC security groups applied to interface endpoints. The security group attached to the VPC endpoint must allow inbound traffic on the service port from the source security group. Getting that group pairing wrong produces connection timeouts that look identical to network failures rather than misconfigured access controls.
These kinds of misconfiguration are closely related to the broader problem of cloud IAM misconfigurations in Australian teams: the configuration exists, the permissions look correct, and yet traffic is silently blocked or rerouted in ways that aren't immediately obvious from the console.
Cost implications teams don't anticipate
Private endpoints are not free. Each private endpoint in Azure carries an hourly charge plus a per-GB inbound and outbound data processing fee. AWS PrivateLink charges per endpoint hour and per GB processed. For high-throughput services like blob storage or managed databases with heavy query traffic, the data processing fee adds up quickly.
The tradeoff is usually worth it. Keeping traffic off the public internet reduces egress costs when traffic would otherwise exit the VNet, reduces attack surface, and often satisfies compliance requirements under the Australian Privacy Act or sector-specific frameworks. But teams who deploy private endpoints assuming they're a free security control are surprised when the bill arrives. Size the data processing costs before committing to the architecture, particularly for services that handle large file transfers or streaming data.
How to validate a private endpoint deployment
Validation is the step most teams abbreviate. A solid validation process for a private endpoint deployment covers four checks:
- DNS resolution from inside the VNet returns a private IP for the service hostname
- DNS resolution from on-premises returns the same private IP (via conditional forwarder)
- The service's public endpoint is disabled or restricted to an explicit allowlist
- Network flow logs or NSG flow logs confirm traffic is traversing the private path, not exiting to the public internet
That last check requires flow logging to be enabled, which is not on by default. Enable VPC Flow Logs or NSG Flow Logs when you deploy the endpoint, not after an incident prompts the question. The question "was this traffic going where we thought?" is much harder to answer retroactively without flow log history.
Sovereign cloud and data residency context
Private endpoints are relevant to Australian data residency requirements, but they don't satisfy them on their own. Keeping traffic inside a VNet is not the same as keeping data within Australian borders. A private endpoint to a storage account that replicates data to a second region outside Australia still allows data to leave the country, regardless of how the network path is configured.
Australian organisations operating under the Privacy Act, the Notifiable Data Breaches scheme, or sector-specific rules like APRA CPS 234 need to confirm that the underlying service's storage and replication configuration aligns with residency requirements, not just the network path. Private endpoints are a network control. Data residency is a data control. Both matter, and they need to be addressed separately.
For a broader look at where data residency obligations sit and what they require, the guide on Australian data residency in 2026 covers the current policy landscape in detail.
Private endpoints are one of the most straightforward ways to tighten the network perimeter around managed cloud services. The gap is almost never in the concept. It's in the DNS configuration, the public access settings that stay on after the endpoint goes live, and the on-premises path that nobody tested. Closing those gaps before go-live takes an hour. Finding them after an audit takes considerably longer.