Networking
Part 5 of 6 · Sidecar & Service MeshCloud Equivalents — App Mesh, ALB/NLB, VPC Lattice & When Not to Mesh
On AWS and peers you can buy pieces of the mesh story without running your own control plane. App Mesh is managed Envoy sidecars; ALB/NLB cover north-south; VPC Lattice is a service network. Interviews want honest tradeoffs and a clear when-not-to-mesh.
- 1Gist
- 2Maps
- 3Q&A
- 4Sandbox
Voice readout needs Web Speech Synthesis in this browser.
Buying pieces of a mesh
Prefer
Match the AWS (or peer) primitive to the pain
Ingress HTTP → ALB. Raw TCP or passthrough → NLB. Uniform east-west retries/mTLS with a managed control plane → App Mesh. Multi-account connectivity and authz without sidecars everywhere → Lattice. Discovery registry → Cloud Map.
- You still operate sidecars if you chose App Mesh.
- DIY Istio/Linkerd wins when AWS coupling is the risk.
- Start with ALB/NLB plus health checks; mesh last.
Alternative
Mesh by default, or call Lattice a sidecar
A 12-service Python fleet does not need Envoy next to every task. Lattice is a service network plus policy, not a per-pod proxy. Mixing the words fails the follow-up.
- Sidecar CPU at scale surprises more than mesh control-plane SKUs.
- Canaries at ALB are ingress-only; east-west canaries need mesh or app logic.
- SGs are not mTLS.
Honest migration on a cloud account
Each step should earn the next with golden signals.
- 1
ALB/NLB plus health checks
Target groups, drain, SG. Depth: LB cluster. - 2
Timeouts in one library or gateway
Hottest clients first. Avoid duplicate retry layers later. - 3
Lattice or mesh if polyglot east-west hurts
Multi-account vs deep L7 is the fork. - 4
Sidecars everywhere only after measuring
CPU, mem, p99 hop. Skip CronJobs.
Overview
On AWS (and peers) you can buy pieces of the mesh story without running istiod. App Mesh runs Envoy sidecars with a managed control plane. ALB/NLB cover north-south (and some east-west) load balancing. VPC Lattice offers service-network connectivity and authz without classic sidecars. Interviews want honest tradeoffs — not a product brochure — and a clear when not to mesh.
Peers elsewhere: GCP Traffic Director + Envoy; Azure Application Gateway / Front Door / Istio add-ons. Same tradeoff space.
Pattern map
| Primitive | Abstraction | You still operate |
|---|---|---|
| App Mesh | Envoy-based mesh; virtual nodes/routers; mTLS and retries via API | Sidecars in tasks/pods |
| ALB (L7) | Path/host routing, TLS terminate, WAF, target health | Ingress (some service routing) |
| NLB (L4) | TCP/UDP, source IP, passthrough or terminate | No HTTP retries/canaries |
| VPC Lattice | Service network across VPCs/accounts; auth policies | Targets, not classic every-pod Envoy |
| Cloud Map | Discovery registry (DNS or API) | Not a proxy |
| DIY mesh | Istio/Linkerd; portable CRDs | Control plane and dataplane |
ALB vs NLB protocol choice is the L4 vs L7 lesson. Health on target groups is health checks.
Decision: which primitive?
Decisions
- ?
1 Non-HTTP only?
- yes2 NLB
- no3 East-west mTLS?
- 2
2 NLB
- ?
3 East-west mTLS?
- no4 ALB ingress
- yes4 Multi-account?
- 4
4 ALB ingress
- ?
4 Multi-account?
- yes5 VPC Lattice
- no5 Team can own sidecars?
- 6
5 VPC Lattice
- ?
5 Team can own sidecars?
- yes6 App Mesh or OSS
- no5 VPC Lattice
- 8
6 App Mesh or OSS
- 9
5 VPC Lattice
Lesson map
Cloud Equivalents — App Mesh, ALB/NLB, VPC Lattice & When Not to Mesh
On AWS and peers you can buy pieces of the mesh story without running your own control plane. App Mesh is managed Envoy sidecars; ALB/NLB cover north-south; VPC Lattice is a service network. Interviews want honest tradeoffs and a clear when-not-to-mesh.
Architecture. Architecture
Select a node to see why it exists, or an edge to see the protocol, direction, effect, and consequence.
Mermaid export
flowchart TB nh["1 Non-HTTP only?"] nlb["2 NLB"] ew["3 East-west mTLS?"] alb["4 ALB ingress"] nh -->|yes| nlb nh -->|no| ew ew -->|no| alb
When each wins
- ALB — public or internal HTTP APIs, host/path routing, integrated certs/WAF, classic target health.
- NLB — extreme performance, non-HTTP protocols, TLS passthrough to pods, static IPs / PrivateLink front doors.
- App Mesh — polyglot ECS/EKS fleets needing uniform east-west retries/mTLS/obs with an AWS-managed control plane.
- VPC Lattice — multi-account service connectivity and policy without deploying a full mesh control plane everywhere.
- DIY mesh — portability, multi-cloud, richer custom resources, when AWS coupling is a risk.
When NOT to introduce a mesh
- Fleet is small (roughly under 20–40 services), one language, and ALB/NLB plus good timeouts suffice.
- Latency budget cannot absorb a sidecar hop — prefer library or L4.
- Team cannot own proxy upgrades, cert rotation, and capture debugging.
- You only needed ingress authz/rate limits — that is a gateway / ALB problem.
- A regulated path is already solved by VPC design + security groups + mTLS in a few critical clients.
Edge vs east-west
Keep these as two stacked single-column flows so desktop labels stay readable.
North-south
Decisions
- 1
1 DNS
- next2 HTTP API?
- ?
2 HTTP API?
- yes3 ALB L7
- no3 NLB L4
- 3
3 ALB L7
- next4 Target group
- 4
3 NLB L4
- next4 Target group
- 5
4 Target group
- next5 Tasks or pods
- 6
5 Tasks or pods
East-west options
Decisions
- 1
1 Tasks or pods
- next2 Need uniform policy?
- ?
2 Need uniform policy?
- no3 In-process library
- yes3 Multi-account?
- 3
3 In-process library
- ?
3 Multi-account?
- yes4 VPC Lattice
- no4 App Mesh sidecars
- 5
4 VPC Lattice
- 6
4 App Mesh sidecars
Sandbox: pick an AWS pattern (Python)
Press Run. Snippets must be self-contained — no network, files, or native modules.
Same idea: cost axes (TypeScript)
Press Run. Snippets must be self-contained — no network, files, or native modules.
Security groups vs mTLS
Security groups are network allow. mTLS is workload identity. Complementary, not substitutes. Depth: s2s mTLS / SPIFFE.
Pitfalls
Public HTTP API, 8 Python services, no east-west mTLS mandate. What do you buy on day one? Now add a second account and a payments service that must prove identity. Do you jump to App Mesh, Lattice, or a library?
Interview Q&A
App Mesh vs Istio?
Answer
Similar Envoy dataplane idea. App Mesh is an AWS-managed control plane with an AWS resource model. Istio is portable and Kubernetes-centric.
ALB vs mesh for canaries?
Answer
ALB weighted target groups work for ingress. Mesh does east-west canaries between services.
NLB plus TLS?
Answer
Terminate or passthrough. No HTTP retry semantics — pair with the app or a mesh for L7. See L4 vs L7.
Does Lattice need sidecars?
Answer
Not the classic every-pod Envoy model. Agents/targets differ — check the current AWS model in interviews carefully. Do not equate Lattice with a sidecar mesh.
Cloud Map role?
Answer
Discovery backend, often with ECS/App Mesh. Not a full proxy. Related: control plane discovery.
When not to mesh on AWS?
Answer
Small services, ALB enough, no east-west mTLS mandate, team bandwidth low.
Security groups vs mTLS?
Answer
SGs = network allow. mTLS = workload identity. Complementary. See s2s mTLS.
Cost surprise?
Answer
Sidecar vCPU and memory at scale often dwarf control-plane fees. Measure before you inject the fleet.
GCP / Azure analogue?
Answer
Traffic Director plus Envoy, Azure gateways and mesh add-ons. Same placement question: edge LB vs service network vs sidecar.
Health checks?
Answer
Target-group health and drain stay in the health-check lesson. Do not recap thresholds here.
What is next after picking a primitive?
Answer
Placement of retries, blast radius, and migration — mesh vs library vs gateway.
Is App Mesh just Envoy?
Answer
App Mesh is managed control plane plus Envoy dataplane. Envoy remains one dataplane example, including when AWS runs it for you.