Most teams think they’re choosing between VPC Lattice and PrivateLink. In reality, they’re choosing how their architecture behaves under failure. The difference becomes obvious when your backend stops being static.

Introduction

AWS networking has evolved from VPC peering → Transit Gateway → PrivateLink → VPC Lattice. Each step adds abstraction and capability.

But I consistently see teams make the same mistake:

They design connectivity assuming their backends are static.

That assumption holds—until it doesn’t.

The question isn’t just:

Should I use VPC Lattice or PrivateLink?

The real question is:

How will my connectivity layer behave when my backend changes under me?

That’s where most architectures fail.

Understanding the Architectures

PrivateLink Endpoint Services

PrivateLink is the traditional pattern:

Consumer VPC
    ↓
VPC Endpoint
    ↓
NLB (Provider)
    ↓
Backend Resources

Strengths:

• Mature
• Cost-effective
• Excellent for static infrastructure

Constraint:

• Relies on NLB target behavior → assumes relatively stable endpoints

VPC Lattice

VPC Lattice introduces a service-oriented model:

Consumer VPC
    ↓
Service Network
    ↓
Managed routing + policy
    ↓
Backend Targets

Strengths:

• Service abstraction
• Built-in observability
• More flexible targeting models

Tradeoff:

• Higher cost
• Newer operational model

The Real Problem: Dynamic Backends

Let’s look at the scenario that exposes the difference:

Aurora failover

When Aurora promotes a replica:

• The endpoint DNS stays the same
• The underlying IP changes

This breaks any architecture that assumes:

“backend = stable IP”

Where PrivateLink Breaks Down

With PrivateLink, you rely on an NLB:

• NLB requires IP-based targets
• NLB does not support DNS resolution

That creates a fundamental constraint:

• Target by IP → breaks on failover
• Target by DNS → not supported

You end up building automation just to maintain correctness:

Detect Aurora failover and update NLB targets

(Operational complexity introduced purely by architecture choice)

This works—but introduces:

• Lambda
• Monitoring
• State reconciliation
• Failure modes you now own

Why VPC Lattice Changes the Equation

VPC Lattice allows you to move up a layer of abstraction:

• You can route through ALBs
• ALBs support DNS-based targets
• DNS abstracts underlying IP changes

Now your architecture aligns with the backend’s behavior:

Dynamic backend → dynamic resolution → stable connectivity

The Broader Pattern (This Is the Important Part)

This is not an Aurora-specific issue.

This is a class of architectural problems:

Static connectivity layers + dynamic backends = eventual failure

You’ll see this pattern with:

• Database failovers (Aurora, RDS)
• Autoscaling compute
• Service mesh integrations
• Managed services with internal mobility

The Principle

Any architecture that couples connectivity to static endpoints will eventually fail under real-world conditions.

What You’re Actually Choosing

This is not just a service decision.

You’re choosing between:

Control:

• PrivateLink: High
• VPC Lattice: Lower

Abstraction:

• PrivateLink: Low
• VPC Lattice: High

Cost:

• PrivateLink: Lower
• VPC Lattice: Higher

Operational burden:

• PrivateLink: Higher (for dynamic systems)
• VPC Lattice: Lower

Resilience alignment:

• PrivateLink: Weak (dynamic backends)
• VPC Lattice: Strong

Decision Framework

Use PrivateLink when:

• Backends are static
• Cost sensitivity is high
• You want tight control over networking primitives
• You’re integrating with existing PrivateLink ecosystems

Use VPC Lattice when:

• Backends are dynamic (databases, managed services)
• You want service-level abstraction
• You care about resilience under failure conditions
• You want built-in observability and policy control

Special Case: Aurora

• PrivateLink → requires abstraction layer (ALB + automation)
• Lattice → aligns more naturally with DNS-based resolution

Regardless of approach:

If you don’t test failover, your architecture is theoretical.

What Most Teams Get Wrong

Most teams optimize for:

• initial simplicity
• cost
• familiarity

They don’t optimize for:

• failure behavior
• backend dynamism
• operational burden over time

That’s why these issues show up months later during incidents.

Wrapping Things Up...

VPC Lattice vs PrivateLink isn’t really about networking.

It’s about whether your architecture:

• assumes stability
  or
• embraces change

The teams that handle failures gracefully are not the ones with the simplest architectures.

They’re the ones whose systems are aligned with how their dependencies actually behave.

If you found this article useful, let me know on BlueSky or on LinkedIn!