Here’s the same article with an HA angle woven in — especially contrasting ALB/VPCE toil with CloudFront as a global managed edge.
From Private VPC Endpoints to the Edge: mTLS for Mobile APIs on AWS
TL;DR — You used to terminate mobile mTLS at API Gateway or ALB, and the ALB path forced Private API Gateway + VPC Endpoints + IP target groups. CloudFront now speaks mTLS at the edge — so you can keep API Gateway Regional, add WAF/Shield/custom headers, and stop plumbing private IPs into load balancers. Bonus: you also stop designing HA for the front door — CloudFront is already a global service.
The problem nobody enjoys explaining in a design review
Mobile apps talking to backends often need more than “Bearer token in a header.”
You want cryptographic client identity before the request even looks like an HTTP call:
- Only devices with a valid client certificate connect
- Stolen tokens alone are not enough
- Certificate lifecycle becomes part of your trust model
That’s mutual TLS (mTLS): the server proves who it is and the client proves who it is.
On AWS, the question has always been: where do you terminate that handshake?
Option 1 — mTLS at API Gateway (simple, but limited)
Mobile ──mTLS──▶ API Gateway ──▶ Backend
What works well
- Direct path
- Fewer moving parts
- Certificate validation close to your API surface
What starts to hurt
- Less natural fit for edge controls (global PoPs, Shield Advanced patterns, rich WAF at the CDN layer)
- Harder to centralize “edge policy” (headers, geo, bot signals, caching rules) in one place
- You still need a clean story for public exposure, rate limits, and DDoS
- Availability is mostly “API Gateway is managed,” but you still think regionally about the entry point
This is a solid baseline. Many teams start here.
Option 2 — ALB in front (secure… and operationally spicy)
Some teams put an Application Load Balancer in front so mTLS (or TLS policy) lives on the ALB:
Mobile ──mTLS──▶ ALB ──▶ API Gateway ──▶ Backend
On paper: great. In practice: the network plumbing gets loud.
Because ALB needs a private path into API Gateway, you often end up here:
| Piece | Why it exists | Pain point |
|---|---|---|
| Private API Gateway | Not publicly reachable | Can’t use a simple public Regional endpoint |
| VPC Endpoint (VPCE) | ALB reaches private API | Extra networking + IAM/interface endpoint design |
| IP target group | ALB targets VPCE ENI IPs | IPs can change; registration/health checks get awkward |
| Private DNS / routing | Glue it together | More failure modes in prod |
| HA design | ALB is regional | Multi-AZ is table stakes; multi-region means another design |
Why this feels like a tax
You’re not just “adding a load balancer.” You’re adopting a private connectivity mini-platform:
- Make API Gateway private
- Stand up Interface VPC Endpoints
- Discover / track VPCE private IPs
- Register those IPs as ALB targets
- Keep health checks and IP churn under control
- Decide AZ placement, failover, and (if you’re serious) multi-region entry
- Debug “is it certs, ALB, VPCE, or API GW?” at 2 a.m.
It works. It’s also a lot of undifferentiated heavy lifting for what you really wanted: authenticate the device, then call the API.
HA tax: With ALB you’re still thinking in regions and AZs. Multi-AZ is expected. Cross-region active/active or failover is a project. Your mobile clients need a resilient DNS/routing story on top of mTLS.
Option 3 — CloudFront viewer mTLS (the plot twist)
CloudFront can now perform the viewer mTLS handshake at the edge.
That flips the architecture:
Mobile ──mTLS──▶ CloudFront ──▶ Regional API Gateway ──▶ Backend
│
├── AWS WAF
├── AWS Shield
└── Custom headers / edge policy
Why this is a big deal
Because CloudFront is public by design, you no longer need the Private API Gateway + VPCE + IP target group dance just to put a smart front door in front of your API.
You can:
- Expose Regional API Gateway
- Point CloudFront origin at the API Gateway domain name
- Terminate / validate client certificates at CloudFront
- Layer WAF and Shield on the same distribution
- Inject custom headers from CloudFront → origin
Mental model: CloudFront becomes your global mTLS gate. API Gateway goes back to being an API — not a networking science project.
The HA win you stop overthinking
Here’s the underrated part of the CloudFront path:
You don’t design HA for the front door the way you do for ALB.
| Concern | ALB + Private API | CloudFront viewer mTLS |
|---|---|---|
| Scope | Regional construct | Global edge network |
| Multi-AZ | You plan it | Inherited from the service |
| Multi-region entry | Extra architecture | Clients hit nearest PoP by default |
| Failover story | DNS, dual stacks, runbooks | Largely AWS-operated edge capacity |
| What you still own | Everything behind the ALB | Origin health + Regional API / backend HA |
CloudFront is a global managed service. Mobile clients resolve to the edge; certificate handshake and request acceptance happen at PoPs worldwide. You’re not standing up “an HA pair of mTLS terminators” in each region.
That doesn’t mean your origin is magically multi-region — Regional API Gateway and backends still need their own resilience story. But the client-facing mTLS plane stops being an HA design exercise.
Punchline: With ALB you buy availability with architecture diagrams. With CloudFront you inherit a global front door — and spend your HA budget where it still matters: the origin and the data plane.
Side-by-side: pick your pain
| API Gateway only | ALB → Private API GW | CloudFront viewer mTLS → Regional API GW | |
|---|---|---|---|
| mTLS termination | API Gateway | ALB | CloudFront edge |
| API Gateway type | Regional / as designed | Often Private | Regional |
| Extra networking | Low | VPCE + IP targets | Origin config |
| Front-door HA | Managed, regional entry | You design AZ / region strategy | Global service — largely out of scope |
| Edge WAF / Shield | Separate story | Possible but awkward | Native with distribution |
| Custom edge headers | Limited | App/ALB rules | CloudFront native |
| Ops complexity | Low–medium | High | Medium (edge-focused) |
| Best for | Simple APIs | Existing ALB-centric estates | Mobile fleets + edge security |
What “good” looks like with CloudFront
A practical pattern for mobile backends:
- Provision device certificates from your private CA (or managed PKI)
- Build a CloudFront trust store with the CA(s) you trust
-
Enable viewer mTLS on the distribution
- Required — every client must present a valid cert (typical for private mobile APIs)
- Optional — mixed traffic during migration
- Passthrough — edge doesn’t fully validate; origin does (migration/legacy)
- Origin = Regional API Gateway custom domain / execute-api hostname
- Lock down the origin so it only accepts traffic from CloudFront (custom secret header, Resource Policy, or both)
- Attach WAF for L7 rules; lean on Shield for DDoS posture at the edge
- Invest HA behind the origin (API / compute / data) — not in reinventing a global TLS edge
The hidden win: security and availability move to the edge
With ALB + Private API Gateway, a lot of your energy goes into reachability and keeping the front door up.
With CloudFront mTLS, more of that energy goes into policy:
- Who is allowed to connect? → certificates / trust store
- What traffic shapes are abusive? → WAF
- Who absorbs volumetric attacks? → Shield + edge capacity
- How does the origin trust CloudFront? → origin access controls + headers
- Do we need multi-AZ mTLS terminators? → No — CloudFront is already global
That’s a healthier split for mobile APIs: authenticate early, authorize narrowly, keep the origin boring, and don’t DIY global HA for TLS.
When you might still choose ALB
CloudFront isn’t magic for every estate.
Keep ALB (or ALB + Private API) if you need:
- Sticky ALB-centric features as the primary entry
- Patterns that already assume VPC-native targets end-to-end
- Strict internal-only topologies where a CDN edge is the wrong trust boundary
For public mobile clients + API Gateway, CloudFront viewer mTLS is usually the cleaner story — on security and on how little HA you have to invent at the perimeter.
Closing thought
mTLS for mobile isn’t hard because TLS is hard.
It’s hard because teams accidentally buy a networking + HA architecture when they only needed a client authentication control point.
- API Gateway alone: simple
- ALB + Private API + VPCE IPs: powerful, expensive in toil (and you still own regional HA)
- CloudFront viewer mTLS + Regional API Gateway: authenticate at the edge, keep the API public-but-protected, bring WAF/Shield/custom headers along — and skip front-door HA design because CloudFront is already a global service
If you’re writing the next version of your mobile API edge: start with certificates and trust stores — not private ENI IP target groups or multi-region ALB runbooks.
Suggested subtitle / social blurb
Stop wiring ALB target groups to VPC Endpoint IPs just to do mTLS. Terminate client certificates at CloudFront, keep API Gateway Regional, get WAF + Shield for free — and stop designing HA for the front door. CloudFront is already global.
One nuance worth keeping in the article (so reviewers don’t nitpick): CloudFront removes most front-door HA work; you still design HA for Regional API Gateway + backends. The win is that mTLS entry is no longer part of that problem.
Top comments (0)