Advanced Cloud Networking: PrivateLink, Hybrid & DNS

The wall you hit after the VPC works

You built a VPC. Subnets are carved up, route tables are clean, the NAT gateway works, and your app reaches the internet. Then a real requirement lands: "Reach the managed database, but never over the public internet." "Connect this VPC to four others without a tangle of peerings." "Let the on-prem payroll system call our internal API." "Make db.internal.acme.com resolve the same from a Lambda, an EC2 box, and a server in the data center." Suddenly the basic VPC mental model runs out of road.

This is the layer where cloud networking stops being about one VPC and starts being about connectivity between things, services, VPCs, and your own data center, plus the DNS that ties them together. Get it right and traffic stays private, predictable, and cheap. Get it wrong and you either expose internal systems to the internet or spend a day staring at a name that won't resolve.

One idea: connectivity is plumbing, not magic

Advanced cloud networking is just deciding which pipes connect which buildings, and making sure every building uses the same phone book.

Every option below is a different shape of pipe, and DNS is the shared phone book. Before the cloud-specific names overwhelm you, anchor on the physical picture:

The picture: services, VPCs, and on-prem

Here is the topology most senior cloud engineers end up building. An application VPC reaches a managed service privately through PrivateLink, connects to other VPCs through a Transit Gateway, and reaches the on-prem data center over Direct Connect or a VPN, while a private DNS resolver makes internal names resolve from every side.

1. 1

   App makes a request to db.internal.acme.com

   The app does not know or care whether the target is a managed service, another VPC, or on-prem. It just resolves a name.

2. 2

   The private resolver answers

   A private hosted zone returns a private IP, the PrivateLink endpoint's ENI, a peer VPC address, or (via a forwarding rule) an on-prem record.

3. 3

   Traffic takes a private pipe

   PrivateLink for a single service, the Transit Gateway for VPC-to-VPC, or Direct Connect/VPN for on-prem. Nothing crosses the public internet.

4. 4

   Return path mirrors it

   Route tables on both ends must point back the right way. Asymmetric routing, out one pipe, back another, is the silent killer here.

Private connectivity to services (PrivateLink / PSC)

PrivateLink (AWS) and Private Service Connect (GCP) solve one precise problem: reach a *single service* over private IP space without peering whole networks together. The provider exposes the service behind a load balancer; you create an endpoint in your VPC that materializes as a network interface (an ENI) with a private IP in your own subnet. Your traffic to that IP is tunneled to the service, no internet gateway, no public IP, no route changes between networks.

The win over peering is isolation and scale. Peering joins entire address spaces and forces you to manage overlapping CIDRs and bidirectional trust. PrivateLink exposes *only the one service* and is one-directional, the consumer reaches the provider, never the reverse. It is how you consume a SaaS vendor, another team's internal API, or an AWS service (S3, Secrets Manager) without your packets ever touching public routes. The trade-off: it is per-service, so it does not replace VPC-to-VPC routing for general traffic.

VPC peering vs Transit Gateway

VPC peering is a direct, point-to-point link between two VPCs. It is cheap and low-latency, but it is non-transitive: if A peers with B and B peers with C, A still cannot reach C. With N VPCs that all need to talk, you face N·(N-1)/2 peerings, a full mesh that becomes unmanageable past a handful.

Transit Gateway (AWS) / Cloud Router + VPC peering hubs (GCP) is a hub-and-spoke router. Each VPC attaches once to the hub, and the hub routes between all of them, and to on-prem over the same attachment model. It costs more (per-attachment and per-GB) and adds a hop, but it turns an O(N²) mesh into O(N) attachments and gives you one place to apply route tables and segmentation. Rule of thumb: 2–3 VPCs that rarely change, use peering; a growing fleet or anything hybrid, use a Transit Gateway.

Hybrid connectivity (VPN / Direct Connect / ExpressRoute)

Hybrid means joining your cloud network to your physical data center. Two grades exist. A site-to-site VPN runs an encrypted IPsec tunnel over the public internet, fast to stand up, cheap, but latency and throughput ride on the open internet, so it varies. Direct Connect (AWS) / ExpressRoute (Azure) / Cloud Interconnect (GCP) is a *dedicated private circuit* from a carrier into the cloud provider, consistent latency, higher bandwidth, lower per-GB cost at scale, but weeks of lead time and a monthly port fee.

The common production pattern is both: Direct Connect as the primary path for predictable performance, with a VPN as automatic failover if the circuit drops. Routes are usually exchanged via BGP, so each side learns the other's prefixes dynamically, which is exactly why your CIDR planning has to be disjoint from day one (more on that in mistakes).

Build it: a PrivateLink endpoint + private DNS zone

Here is a minimal Terraform setup: an interface endpoint (PrivateLink) for a service, plus a private hosted zone so a friendly internal name resolves to it. Scope this to your VPC and private subnets.

# Interface VPC endpoint (PrivateLink) into the provider's service
resource "aws_vpc_endpoint" "svc" {
  vpc_id              = aws_vpc.app.id
  service_name        = "com.amazonaws.vpce.eu-west-1.vpce-svc-0abc123"
  vpc_endpoint_type   = "Interface"
  subnet_ids          = aws_subnet.private[*].id
  security_group_ids  = [aws_security_group.endpoint.id]
  private_dns_enabled = true # service's own DNS name now resolves to the ENI

  tags = { Name = "svc-privatelink" }
}

# Lock the endpoint down: only the app tier may reach it on 443
resource "aws_security_group" "endpoint" {
  name   = "privatelink-endpoint"
  vpc_id = aws_vpc.app.id

  ingress {
    from_port       = 443
    to_port         = 443
    protocol        = "tcp"
    security_groups = [aws_security_group.app.id]
  }
}

# Private hosted zone, internal names that never leak to public DNS
resource "aws_route53_zone" "internal" {
  name = "internal.acme.com"

  vpc {
    vpc_id = aws_vpc.app.id # zone is only visible inside this VPC
  }
}

# Friendly alias pointing at the PrivateLink endpoint
resource "aws_route53_record" "db" {
  zone_id = aws_route53_zone.internal.zone_id
  name    = "db.internal.acme.com"
  type    = "A"

  alias {
    name                   = aws_vpc_endpoint.svc.dns_entry[0]["dns_name"]
    zone_id                = aws_vpc_endpoint.svc.dns_entry[0]["hosted_zone_id"]
    evaluate_target_health = true
  }
}

How DNS actually resolves across the boundary

DNS is where hybrid setups quietly fall apart, because there are *three* name spaces, cloud private zones, on-prem internal zones, and the public internet, and every resolver has to know which one to ask for a given name.

Private hosted zones

A private zone (Route 53 private hosted zone / Cloud DNS private zone) is a DNS zone visible only inside the VPCs you associate with it. db.internal.acme.com resolves to a private IP for anything in the VPC and does not exist on the public internet. This is how you give services stable internal names without ever exposing them.

Split-horizon (split-brain) DNS

Split-horizon means the *same name* returns *different answers* depending on who asks. api.acme.com resolves to a private endpoint when queried from inside the VPC, and to a public load balancer when queried from the internet. You achieve it by running a public zone and a private zone for the same domain; the private zone wins for in-VPC queries. It is powerful, one hostname everywhere, but it is the single most confusing failure mode when someone debugs from the wrong network and gets the "other" answer.

Resolution across hybrid

For cloud and on-prem to resolve each other's names you need a resolver with forwarding rules: an inbound endpoint so on-prem can query cloud names, and an outbound endpoint with a conditional forwarder that says "send *.corp.local queries to the on-prem DNS server at 10.10.0.53." Without these, an instance in AWS asking for an on-prem hostname gets NXDOMAIN even though the network path is wide open.

Common mistakes that cost hours

1. Overlapping CIDRs. Two VPCs (or a VPC and on-prem) using 10.0.0.0/16 *cannot* be peered or routed together, routing is ambiguous. Plan a disjoint IP address scheme across every VPC and data center *before* you build anything. This is the #1 retrofit nightmare.
2. Exposing internal services publicly. Reaching for a public load balancer or a 0.0.0.0/0 security-group rule because "it was faster than PrivateLink." Internal APIs and databases should only ever be reachable over private paths, PrivateLink, peering, or the Transit Gateway.
3. DNS works in cloud, fails to on-prem (or vice versa). Network path is open but names won't resolve, because there is no conditional forwarder / resolver endpoint bridging the two name spaces. Always test resolution *from both sides*.
4. Split-horizon confusion. Debugging api.acme.com from your laptop (public answer) while the app inside the VPC gets the private answer, and concluding the app is broken. Always check which network the failing query came from.
5. Asymmetric routing. Traffic leaves over the Transit Gateway and tries to return over a VPN, or the return route table never got the peer's CIDR. Stateful firewalls drop the reply. Confirm route tables point back symmetrically on both ends.
6. Peering mesh sprawl. Adding the fifth, sixth, seventh peering by hand until nobody can reason about the topology. Move to a Transit Gateway hub the moment you outgrow a handful of VPCs.

Takeaways

Where to go next

Build the muscle memory hands-on, then zoom out to how this fits a real multi-account organization.

• Practice routing, endpoints, and resolution in the Networking lab and the DNS lab.
• Solidify the basics first if any of this felt shaky: Cloud Networking Fundamentals: How a VPC Actually Works.
• See where these VPCs and connectivity live in a real org: Multi-Account / Landing Zone Strategy & Governance.
• Map the full journey on the Cloud Engineer career path.