Hermes Wiki
TechResearch/PrivateLink_vs_GTM/privatelink-vs-gtm-traffic-routing

Why these get confused

Both concepts change what a DNS name resolves to. That's the entire reason they get mixed up — but they operate at completely different layers and solve unrelated problems.

  • Interface Endpoint (AWS PrivateLink) — private, in-VPC access from your workload into one specific AWS service.
  • GTM / Route 53 — public-facing DNS routing that decides which site/region a client's request should land on.

One is about reaching into a service privately. The other is about choosing between multiple live sites. They never substitute for each other.


Problem it solves: your workload inside a VPC needs to call an AWS service (S3, Secrets Manager, KMS, etc.) without that traffic ever touching the public internet.

Mechanism:

  • Creates an ENI with a private IP inside your own subnet.
  • Backed by a security group (not IAM/routing policies).
  • AWS gives you a DNS name (e.g. secretsmanager.us-east-1.amazonaws.com) that, inside the VPC, now resolves to that private IP instead of the public endpoint.
  • Your application code doesn't change — same hostname, private path underneath.

Real-world example: an OCP pod needs to pull a DB password from Secrets Manager. Normally that call would route out via a NAT Gateway to a public AWS endpoint and back. With an Interface Endpoint, the call resolves to a private IP in the same subnet and never leaves the private network — lower latency, smaller attack surface, no NAT Gateway cost for that traffic.


GTM / Route 53 (Global Traffic Management)

Problem it solves: multiple live copies of the same application exist in different locations. Which one should a given user's request go to?

Mechanism:

  • Sits at the public DNS layer, in front of multiple sites/regions.
  • Runs health checks against each site's endpoint (load balancer / ingress VIP).
  • Applies a routing policy — latency-based, failover, weighted, geo — to decide which site's IP to hand back in the DNS response.
  • If a site's health check fails, DNS stops resolving to it; traffic shifts automatically, with zero application-level involvement.

Real-world example (yours): an app runs across 2 OCP locations, 2 replicas each (4 pods total). GTM decides whether app.company.com resolves to Site A's or Site B's ingress VIP, based on health and routing policy. If Site A's pods start failing, GTM stops handing out Site A's IP.

AWS equivalent: the same app running in EKS in us-east-1 and eu-west-1, each behind its own ALB. A Route 53 record with a latency-based or failover routing policy, backed by health checks against both ALBs, does exactly what GTM does across the two OCP sites.


Side-by-side

Interface Endpoint (PrivateLink) GTM / Route 53
Question it answers "How does my workload reach one AWS service privately?" "Which site/region should this user's traffic land on?"
Layer Private networking — ENI + security group, inside one VPC DNS-based global routing — public-facing, multi-site
Access control Security groups Health checks + routing policy (latency / failover / weighted / geo)
Scope Single service, single VPC Multiple sites/regions serving the same app
Your infra analogy Private route to a specific backend service Your existing GTM setup across 2 OCP locations

Key takeaways

  • Interface Endpoints are about private connectivity into a specific AWS service — think "give me a private in-network address for this one thing."
  • GTM / Route 53 are about choosing between multiple live sites for incoming traffic — health-check-driven DNS routing.
  • The AWS analogue of an on-prem GTM setup is Route 53 (latency/failover routing + health checks), optionally paired with Global Accelerator for anycast-based routing at the network layer instead of DNS.
  • These two concepts sit next to each other in the AWS networking story but never replace one another.

Publishing checklist

  • Fill in real date in frontmatter when ready to publish
  • Expand with a diagram (Interface Endpoint ENI-in-subnet vs. GTM/Route 53 multi-site DNS resolution)
  • Copy into BlogPosts/ upstream repo (fullstackfusions/fullstackfusions/_posts) using TEMPLATE.md conventions — this vault's BlogPosts/ folder is a read-only nightly mirror, not the source
Hermes Wiki