What it is
A private link service is the publishing half of a private connection between two networks. You put a service behind a load balancer in your own cloud network and register it with the provider. Other teams or companies then open a private endpoint in their network, which gives them a private IP address. Their traffic goes to that IP and lands on your load balancer without crossing the public internet. AWS calls this PrivateLink endpoint services, Azure calls it Private Link service, Google Cloud calls it a published service in Private Service Connect. Different names, same model.
Most people meet private links as a consumer, pasting in a service name a vendor gave them. The service side is the part you own: the thing you register, approve and keep healthy. It is not a VPN and not peering. Peering joins two whole networks and both sides route to each other's address ranges. A private link service exposes one service on one port, in one direction, and the consumer sees a private IP and nothing else of your network.
How it works
On your side you need the service running in private subnets behind a load balancer the cloud accepts. AWS requires a Network Load Balancer for an endpoint service. Azure requires a Standard Load Balancer. Google Cloud wants a supported producer behind a service attachment. You create the endpoint service, point it at that load balancer, decide whether connections need manual acceptance, and get a service name or alias to hand out.
The consumer creates an interface endpoint, private endpoint or service attachment connection in subnets they choose, which places network interfaces with private IPs in their VPC. If you require acceptance, the request stays pending until someone approves it. Then DNS: a private hosted zone so the application name resolves to the endpoint IPs. Skip that and the app keeps resolving to the public address while the private path sits idle.
Traffic runs from the consumer's workload to the endpoint interface, across the provider backbone, into your load balancer, then to your targets. Your app usually sees the endpoint's IP as the client address. On AWS you can enable proxy protocol v2 on the load balancer to keep the real client IP. Security groups on the endpoint, network ACLs and your load balancer rules all still apply. Each one can silently block a connection.
On premises works through a consumer VPC, not directly. The data center reaches that VPC over a dedicated circuit or a site to site VPN, and the endpoint lives in the VPC.
Why it matters for a business
The blast radius shrinks. No public IP to scan, no list of customer IPs to maintain, no inbound rule open to the internet. Traffic stays on the provider's network between the two endpoints.
Network boundaries stay clean. You do not swap route tables with a partner or argue about overlapping address space. Onboarding a customer becomes an approval and a DNS record. Offboarding is deleting the endpoint, which is easier to enforce than asking someone to close a firewall rule.
Every connection gets an owner and a record. You can see who is connected, revoke one consumer without touching the rest, and require manual approval so nobody connects by guessing a service name. The trade off is that you now run a service others depend on. Uptime depends on your load balancer, your health checks and how fast you approve requests.
Common mistakes
Registering the wrong load balancer. Only certain types can back a private link service, and it must sit in the right region and account. Publishing an internet facing load balancer does not make the path private. The endpoint service is what does that.
Leaving DNS pointing at the public address. The connection shows as available, the consumer's app still works, and nobody notices it is crossing the internet. Test from inside a consumer subnet with dig or nslookup, and confirm the private hosted zone is attached to the right VPC.
Treating the link as authentication. It controls reachability, not identity. Any workload in an approved account can call the endpoint, so keep TLS, tokens and per tenant authorization. If acceptance is automatic, anyone holding the service name can connect.
Skipping the operational details: health checks that never fire, cross zone load balancing left off, source IP lost because proxy protocol is disabled, subnet IP exhaustion as endpoints pile up, and billing that adds an hourly charge per endpoint plus data processing. None of that is hard. All of it surprises teams after launch.
How to get started
Start with an inventory. List the services you might publish, who needs them, on which port, and who approves a new consumer. One page is enough, and it becomes your approval policy.
Build one pilot end to end. Private subnets, load balancer, endpoint service, manual acceptance, then connect from a second account you control. Add the private DNS record. Check the TCP handshake and the TLS certificate from the consumer side, and read your logs to see which address shows up as the client.
Add guardrails before the second consumer arrives: a naming convention, a change record for approvals, alarms on unhealthy targets, a quarterly review of idle endpoints, and a written revoke procedure. Document what the consumer must do on their side, because that is where support tickets start.
If this is your team's first private link service, a second opinion helps. That could be an internal network architect, a consulting partner, or Cloudverg's Expert architecture session at $450/month, which includes 90 minutes with a senior architect and a written summary. Decide the approval model before you publish anything.
Frequently asked questions
What is the difference between a private link service and VPC peering?
Peering connects two whole networks, so both sides can route to each other's address ranges. A private link service exposes a single service on a single port, and the consumer gets one private IP for it. Use peering for broad access between networks you control, and a private link service when you want to hand out one service with tight limits.
Can I reach a private link service from my own data center?
Yes, but through the consumer VPC. Your data center connects to that VPC over a dedicated circuit or a site to site VPN, and the endpoint sits inside the VPC. The data center does not create the endpoint itself, so that VPC has to exist and be routed correctly.
Is a private link service secure on its own?
It removes the public internet from the path and limits who can reach the service, which is a real gain. It does not encrypt or authenticate anything by itself. Keep TLS, application level authorization and logging, and review approved consumers on a schedule.