Architecture Design and Implementation Built for the Cloud · Topic 5 of 11
Ingress, Edge Compute and Global Traffic Routing
Choose ALB, NLB, API Gateway or the Load Balancer Controller for ingress, CloudFront Functions or Lambda@Edge, and Route 53 or Global Accelerator routing.
- 5 min
- ALB is layer 7 routing and authentication; NLB is layer 4 with static IPs and PrivateLink support.
- REST APIs carry the management features; HTTP APIs are the cheaper, simpler option.
- CloudFront Functions run only on viewer events, with no network access; Lambda@Edge handles origin events and external calls.
What it is
Ingress is the front door of an application: the component that accepts client traffic and passes it to the right backend. Edge compute runs small pieces of logic in CloudFront locations close to the user.
Global routing decides which Region serves each user, and how traffic moves when a Region fails. Together these choices set latency, availability and the cost of every request.
How it works
Choosing the ingress
| Option | Layer | Choose it for |
|---|---|---|
| Application Load Balancer | 7 (HTTP, HTTPS, gRPC) | Path and host routing, OIDC or Cognito authentication, AWS WAF, Lambda targets |
| Network Load Balancer | 4 (TCP, UDP, TLS) | Very high throughput at low latency, static IP per AZ, source IP preservation, PrivateLink endpoint services |
| API Gateway REST API | API management | Usage plans and API keys, request validation, caching, private APIs, AWS WAF |
| API Gateway HTTP API | Lightweight API proxy | Lower cost and latency for simple Lambda or HTTP backends with JWT authorizers |
| AWS Load Balancer Controller | Kubernetes integration | Provisions an ALB for an Ingress resource and an NLB for a Service of type LoadBalancer on EKS |
With the Load Balancer Controller, IP target mode sends traffic straight to pod IPs, which is required for pods on Fargate. One ALB can serve several Ingress resources through an ingress group, which cuts the number of load balancers.
Optimize by usage pattern. Spiky, low-volume APIs fit API Gateway with Lambda; steady high-volume traffic usually costs less on an ALB in front of containers.
Edge compute: CloudFront Functions or Lambda@Edge
| Feature | CloudFront Functions | Lambda@Edge |
|---|---|---|
| Runtime | JavaScript | Node.js and Python |
| Events | Viewer request and viewer response | Viewer and origin, request and response |
| Duration | Submillisecond | Up to 5 seconds on viewer events, 30 seconds on origin events |
| Network and file system access | No | Yes |
| Request body access | No | Yes |
| Scale | Millions of requests per second | Lower, per Region limits |
CloudFront Functions fit header rewrites, URL redirects, cache key normalization and simple token checks. Lambda@Edge fits work that calls external services, reads the body, or changes the origin based on a lookup.
CloudFront KeyValueStore gives CloudFront Functions a low-latency key value lookup, such as redirect maps or feature flags, without a network call.
Global routing: Route 53 and Global Accelerator
| Route 53 policy | Use |
|---|---|
| Latency | Send users to the Region with the lowest latency |
| Failover | Active-passive with health checks |
| Weighted | Split traffic, blue/green, gradual Region shift |
| Geolocation | Route by user country or continent, for content or compliance rules |
| Geoproximity | Route by distance with a bias to grow or shrink a Region's share |
| IP-based | Route by client CIDR ranges |
| Multivalue answer | Return several healthy records |
AWS Global Accelerator gives two static anycast IP addresses. Traffic enters the AWS network at the nearest edge location and goes to the healthiest endpoint group, and failover does not wait for DNS caches to expire.
| Need | Choose |
|---|---|
| HTTP content caching and edge logic | CloudFront |
| Static IPs, TCP or UDP, fast Regional failover | Global Accelerator |
| DNS-level Regional routing with policies | Route 53 |
Global Accelerator traffic dials shift a percentage of traffic away from an endpoint group, and endpoint weights split traffic inside a group.
How the exam asks about this
- "Clients allowlist fixed IP addresses and need failover between two Regions in seconds" -> Global Accelerator with endpoint groups in both Regions.
- "Every request must have a header normalized at the edge at the lowest cost and latency" -> CloudFront Functions on viewer request.
- "An EKS application on Fargate needs path-based HTTP routing" -> AWS Load Balancer Controller with an Ingress resource using IP target mode.
What to remember for the exam
- ALB is layer 7 routing and authentication; NLB is layer 4 with static IPs and PrivateLink support.
- REST APIs carry the management features; HTTP APIs are the cheaper, simpler option.
- CloudFront Functions run only on viewer events, with no network access; Lambda@Edge handles origin events and external calls.
- Route 53 latency, failover, weighted and geolocation policies solve most multi-Region routing scenarios.
- Global Accelerator gives static anycast IPs and fast failover without relying on DNS TTLs.
- Combine Route 53 health checks with failover records for active-passive Regional designs.
Geolocation routing is not latency routing. A user near a Region border may be sent to a farther Region by geolocation; use it for content or legal rules, and latency routing for speed.
Common mistakes
Using Lambda@Edge for simple header changes. It works, but costs more and adds latency. CloudFront Functions is built for lightweight viewer-side changes.
Choosing CloudFront when the requirement is static IPs for a TCP service. CloudFront caches HTTP content; Global Accelerator provides static anycast IPs for any TCP or UDP application.
Creating one ALB per Kubernetes Ingress. Each load balancer adds cost. An ingress group lets several Ingress resources share one ALB.
Check yourself
Which edge option can call an external service before forwarding a request to the origin?
Lambda@Edge, because CloudFront Functions have no network access.
Why does Global Accelerator fail over faster than DNS-based routing?
Clients keep the same static anycast IPs, and Global Accelerator moves traffic to a healthy endpoint without waiting for cached DNS records to expire.
When do you choose an NLB over an ALB?
When the workload needs layer 4 TCP or UDP handling, static IP addresses, very high throughput, or a PrivateLink endpoint service.
Topic 5 of 11 in Architecture Design and Implementation Built for the Cloud
Test yourself on Architecture Design and Implementation Built for the Cloud
The full AWS SAP-C03 question bank has 850 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by AWS. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.