Selecting AWS Traffic, Security, and Load-Balancing Components for Performance and Availability

Welcome back. In the previous lesson, you designed the regional network foundation: multi-AZ subnet tiers, AZ-local egress, private AWS service access through VPC endpoints, and security-group-based segmentation. That gives the platform safe places to run. This lesson addresses the next question: which managed AWS component should receive each kind of traffic, and why?

For a senior interview, do not answer this as a product list. Start with the request profile: Is it HTTP or raw TCP? Is the payload cacheable? Do clients need a stable IP? Do you need API-level authorization and throttling? Is the principal risk application-layer abuse, volumetric DDoS, or a regional outage? The component follows from those constraints.

---

Think in traffic planes, not in one “front door”

Assume an exchange platform has four externally visible traffic types:

1. Public web and mobile assets: JavaScript bundles, documentation, market-data pages, images, and cacheable public GET requests.
2. Transactional HTTP APIs: login, balances, order placement, cancellation, and account operations.
3. Partner connectivity: long-lived TCP sessions, perhaps a FIX-style protocol, with partner IP allowlists and strict latency expectations.
4. Administrative or integration APIs: lower-volume APIs that need explicit authentication, quotas, versioning, and controlled consumption.

These do not belong behind one universal component. A better principle is:

Use the highest-level managed service that supplies a required control without violating protocol, latency, or operational requirements.

For example, an API Gateway may be valuable for partner onboarding and per-client throttling, but it is not automatically the right ingress layer for a latency-sensitive, high-throughput transactional path. Conversely, an NLB offers transport-level performance and static IP options, but it cannot make HTTP path-routing, payload validation, or WAF inspection decisions.

A useful selection summary is below.

Component	Primary decision it makes	Best fit	Key limitation
Route 53	Which public endpoint a domain name resolves to	DNS, regional routing, failover, weighted migration	DNS is not an in-request proxy or instant failover mechanism
CloudFront	Whether content can be served from an edge cache or forwarded to an origin	Static content, public cacheable reads, global user reach	Not a substitute for API authorization or transactional consistency
AWS WAF	Whether an HTTP request is allowed before it reaches the application	HTTP flood protection, exploit filtering, rate-based rules	Does not inspect arbitrary TCP or UDP flows
API Gateway	Whether an API request is authenticated, authorized, throttled, validated, and routed to an integration	Managed public or partner APIs	Adds another managed hop and has API-specific limits
ALB	Which HTTP, HTTPS, gRPC, or WebSocket target group receives a request	ECS/EKS microservices, host/path/header routing	No native per-consumer API product controls such as usage plans
NLB	Which target receives a TCP, TLS, or UDP flow	Low-latency L4 protocols, TCP partners, static IP needs	No HTTP-aware routing or direct WAF attachment

---

Route 53 is DNS control, not the data path

Amazon Route 53 is usually the first public component in the architecture, but it is important to describe its role precisely. It answers DNS queries for domains such as:

• www.exchange.example
• api.exchange.example
• fix.exchange.example
• admin-api.exchange.example

It can use alias records to direct those names to AWS-managed endpoints such as CloudFront distributions, Application Load Balancers, and API Gateway custom domains.

Within a single Region, an ALB or NLB distributes traffic across healthy targets and Availability Zones. Route 53 is not needed to balance traffic between ECS tasks or between AZs behind that load balancer. Its higher-value availability role is selecting between endpoints, especially across Regions.

For example, Route 53 can support:

• Failover routing for active-passive regional recovery.
• Latency-based routing when active-active regional endpoints can safely serve the same users.
• Weighted routing for a controlled migration, canary release, or progressive regional expansion.
• Health checks that test a meaningful endpoint, such as a synthetic /ready or dependency-aware status API.

The important limitation is DNS caching. If a resolver has cached a response, Route 53 cannot move an already-resolved client immediately. Therefore, DNS failover is excellent for regional resilience but should not be described as sub-second protection for an individual failed request.

For write operations such as order placement, do not casually choose latency-based multi-Region routing. The routing choice must align with data ownership and consistency. A user routed to the nearest Region is not useful if that Region cannot safely validate balance, risk, position, or order state.

The AWS Well-Architected guidance is a concise review of these availability distinctions.

---

CloudFront and WAF: edge controls for HTTP traffic

CloudFront: use it where caching changes the economics and resilience

CloudFront is a content delivery network. Its core value is serving cached content close to users from edge locations, lowering origin load and improving perceived latency for geographically distributed clients.

For an exchange platform, CloudFront is a strong default for:

• Static web application assets.
• Public documentation.
• Images and downloadable client software.
• Public market-data pages where brief caching is acceptable.
• Cacheable GET APIs with an explicit cache policy and safe cache key.

It is not automatically appropriate to cache transactional or personalized APIs. For order placement, cancellation, balances, account information, and authenticated portfolio state, the default posture should be no caching unless the endpoint has deliberately defined semantics for it.

CloudFront can still forward dynamic HTTP traffic to an origin, but that is a different decision from caching. For a globally distributed public API, CloudFront can provide edge termination and WAF placement, while forwarding requests without caching. For a strict latency-sensitive order path, however, adding another hop must be justified with measured end-to-end latency and availability benefits.

A senior answer makes this distinction:

“I would use CloudFront aggressively for static assets and explicitly cacheable public reads. I would not treat CloudFront caching as a solution for transactional exchange APIs. If CloudFront fronts dynamic APIs for edge protection, I would configure API behaviors to prevent caching of authenticated and mutation requests, and benchmark the tail latency rather than assuming the edge improves every request.”

AWS WAF: protect HTTP semantics, not every protocol

AWS WAF evaluates HTTP(S) requests. It can be associated with CloudFront, an ALB, or API Gateway. It is appropriate for controls such as:

• AWS Managed Rules for common exploit patterns.
• SQL injection and cross-site scripting detection.
• URI, header, query string, request-body, and IP-based rules.
• Rate-based rules to reduce abusive request volumes.
• Geographic restrictions where legally or commercially required.
• Bot-control strategies where the threat model justifies them.
• Explicit allowlists for administrative endpoints.

For a public web application, the preferred attachment point is often CloudFront, so malicious HTTP traffic is filtered before it consumes regional origin capacity. If traffic does not use CloudFront, attach WAF directly to the internet-facing ALB or API Gateway.

Avoid blindly attaching separate WAF policies everywhere. Multiple layers may be justified for independent public entry points, but duplicate policies can complicate rule ownership, incident debugging, and false-positive handling. Define one policy owner, a change process, logging destination, and a monitored count-mode rollout for rules with uncertain impact.

Also distinguish AWS WAF from AWS Shield:

• AWS Shield Standard is enabled by default and helps protect supported AWS services against common Layer 3 and Layer 4 DDoS attacks.
• AWS WAF protects HTTP application behavior, including malicious request patterns and HTTP floods.
• AWS Shield Advanced is a risk and cost decision for high-value public endpoints facing elevated DDoS exposure; it is not a replacement for sound application capacity, rate limits, or WAF rules.

An NLB accepting raw TCP partner traffic cannot have AWS WAF attached directly. Its protection model instead relies on network controls, Shield protections, careful source restrictions, protocol-level validation, and, where required, dedicated inspection architecture.

---

ALB versus NLB: decide at Layer 7 or Layer 4

The most common interview mistake is to say “NLB is faster, so I would use NLB.” That is incomplete. NLB is the right choice when the required protocol and connection characteristics are Layer 4. ALB is the right choice when routing and protection decisions depend on HTTP semantics.

The following short comparison is useful before going deeper.

Application Load Balancer

An ALB operates at Layer 7. It understands HTTP and HTTPS requests, and supports routing based on information such as:

• Host name, such as orders.exchange.example versus accounts.exchange.example.
• Path, such as /v1/orders/* versus /v1/market-data/*.
• HTTP header and request method.
• Query string conditions.
• Target health and target-group membership.

For an ECS service, ALB is usually the natural ingress choice. A target group can register ECS tasks by IP address, and ALB health checks remove unhealthy tasks before they receive production traffic. A single ALB can route traffic to multiple independently scaled services without exposing each task publicly.

Typical selection:

Requirement	ALB justification
ECS microservices behind a shared public API hostname	Host and path routing can direct requests to distinct target groups
HTTP APIs, gRPC services, or WebSocket connections	ALB understands Layer 7 protocols and can terminate TLS
WAF protection needed at the regional ingress point	AWS WAF can be associated directly with the ALB
Health-based routing across multiple AZs	ALB directs requests only to healthy registered targets
Blue-green ECS deployment	Separate target groups support controlled traffic shifting

An ALB does not replace an API-management product. It can route /orders and /accounts, but it does not intrinsically provide consumer-facing API keys, per-client quotas, API lifecycle semantics, or rich request transformation.

Network Load Balancer

An NLB operates at Layer 4. It distributes TCP, TLS, and UDP traffic based on connection and flow characteristics rather than HTTP request content. One TCP connection or UDP flow remains associated with its selected target for the lifetime of that flow.

NLB is a better fit when you need:

• Long-lived TCP sessions.
• A non-HTTP protocol such as FIX.
• UDP traffic.
• Very high connection rates.
• Static, zonal IP addresses or Elastic IPs for partner allowlisting.
• Source-IP preservation where the target protocol or audit model requires it.

For a partner trading gateway, a defensible choice may be:

“I would use an internet-facing NLB for a FIX-over-TCP endpoint because routing occurs at Layer 4, partners may need stable IP allowlisting, and session duration can be long. The NLB would span at least two AZs, target healthy gateway tasks or instances in each AZ, and use tightly constrained security groups and partner source ranges. I would not select an NLB merely to make an HTTP microservice faster, because I would lose useful Layer 7 routing and direct WAF integration.”

“Low latency” must be interpreted carefully. NLB avoids some Layer 7 processing, but a system’s meaningful latency is end-to-end: TLS handling, application queues, database calls, risk checks, and downstream contention often dominate. Select NLB for protocol and connection requirements, then validate latency with load tests.

The AWS comparison below is useful for explaining the protocol and routing distinction under interview pressure.

---

API Gateway: choose API management when you need API management

API Gateway is a managed API front door. It is not simply “another load balancer.” It is valuable when the public contract itself needs controls that are awkward or unsafe to reproduce across every backend service.

Choose API Gateway when requirements include several of the following:

• JWT, IAM, Lambda-authorizer, or Cognito-based authorization at the API edge.
• Per-client throttling, burst limits, usage plans, or quotas.
• API versioning and OpenAPI-oriented lifecycle management.
• Request validation and limited request or response transformation.
• Direct integrations with AWS services or Lambda.
• A managed public API surface consumed by partners or third-party developers.
• A low-to-moderate traffic API whose managed, request-based model fits its traffic pattern.

For the exchange scenario, API Gateway often fits:

• Partner onboarding APIs.
• Customer profile and configuration APIs.
• Administrative APIs.
• Webhook intake with strict request validation and throttling.
• Public developer APIs where quotas and keys are part of the commercial or security model.

It may be less appropriate for the core matching or order-ingestion path when the path has tight tail-latency requirements, sustained high volume, custom connection behavior, or a protocol that is not HTTPS. That does not mean “never use it for orders.” It means the decision must be measured against concrete API Gateway quotas, timeout behavior, integration type, API payload size, p99 latency, and per-request cost.

A common internal architecture can combine components without making every public request traverse unnecessary layers:

Public interface	Suggested edge	Regional service ingress	Reasoning
Web UI and static assets	Route 53, CloudFront, WAF	S3 or an ALB origin	Edge caching and early HTTP filtering
Public REST API with API consumer controls	Route 53, WAF, API Gateway	Private integration to application services	Authentication, throttling, validation, governed API contract
Core HTTP microservices	Route 53, WAF, ALB	ECS or EKS target groups	Layer 7 routing, health checks, and container integration
FIX-like partner TCP endpoint	Route 53, NLB	TCP gateway targets across AZs	Long-lived L4 connections and stable entry addresses

Where API Gateway connects to private ECS or EKS services, use an appropriate private integration, such as VPC Link, rather than exposing backend tasks or an internal service directly to the internet.

Do not place API Gateway in front of an ALB merely because both are available. That design is justified only if API Gateway is supplying a needed public API control plane while the ALB is still needed for internal Layer 7 distribution to multiple services. Otherwise, the extra hop adds cost, latency, operational dependencies, and incident surface area.

---

Read the reference architecture as patterns, not one mandatory chain

The DDoS-resilient reference architecture is useful because it shows how edge services, regional ingress, and multi-AZ compute complement one another. However, it should not be interpreted as “put Route 53, Global Accelerator, WAF, CloudFront, API Gateway, ALB, and NLB in front of every service.”

In particular:

• Route 53 is normally present for public DNS.
• CloudFront is selected for caching and edge delivery, not by default for every API.
• WAF is selected for public HTTP endpoints, at a deliberate enforcement point.
• API Gateway and ALB can coexist, but only when API management and downstream HTTP routing are both required.
• NLB is normally an alternative ingress choice for Layer 4 traffic, not a companion to ALB for the same simple service.
• Global Accelerator, shown in the diagram, is outside this lesson’s required component set. It can be relevant when globally distributed users need static anycast IPs and improved routing to regional endpoints; it is not a replacement for CloudFront caching or API Gateway controls.

---

A practical selection for the exchange scenario

A clear initial architecture might separate endpoints as follows:

Domain	Selected components	Primary rationale
www.exchange.example	Route 53, CloudFront, WAF	Fast global delivery of static assets; reduce origin exposure and absorb high read traffic
api.exchange.example for account and public developer APIs	Route 53, WAF, API Gateway	API authentication, controlled consumer access, validation, throttling, version governance
trade.exchange.example for core HTTPS trading APIs	Route 53, WAF, ALB	ECS/EKS service routing, target health checks, container-friendly traffic distribution
fix.exchange.example for institutional TCP sessions	Route 53, NLB	Layer 4 traffic, stable IP requirements, long-lived TCP behavior
Internal service endpoints	Private DNS, internal ALB or NLB where justified	No internet exposure; service protocol determines ALB versus NLB

This is not the only valid answer. If the core trading API requires strict client-level quotas, API Gateway may be justified. If partner traffic is HTTPS and needs Layer 7 authorization, an ALB or API Gateway could be a better fit than NLB. The senior-level skill is showing which stated requirement changes the decision.

---

Defend the design through trade-offs

When asked why you selected a component, use a compact structure:

1. State the traffic and nonfunctional requirement.
   “This is a public HTTPS API with untrusted clients, per-client rate limits, and a stable versioned contract.”

2. Name the selected component.
   “I would put API Gateway behind a Route 53 custom domain and associate WAF.”

3. Explain what it supplies.
   “It centralizes authentication, request throttling, validation, and API lifecycle controls, reducing duplicated implementation across services.”

4. State what you deliberately did not choose and why.
   “An ALB could route this API, but it would not supply consumer-level API controls natively. I would use ALB directly for high-throughput internal-facing HTTP service routing.”

5. Name the operational verification.
   “Before production approval, I would load-test p99 latency and throttling behavior, validate WAF false-positive handling, test unhealthy backend behavior, and monitor 4xx, 5xx, target health, and rejected requests.”

For cost, avoid blanket claims such as “API Gateway is always cheaper” or “CloudFront always saves money.” Compare the actual profile:

• CloudFront can reduce regional data transfer and origin capacity for cacheable content, but has request and transfer costs.
• API Gateway is usage-based and can suit intermittent managed APIs, while sustained high volume needs explicit cost modelling.
• ALB pricing depends on hours and Load Balancer Capacity Units, including connections, processed bytes, and rule evaluations.
• NLB pricing depends on hours and capacity units shaped by connections and traffic.
• WAF cost grows with Web ACLs, rules, and request volume, but may be economically justified by preventing abusive traffic from reaching more expensive layers.

---

Key takeaways

A strong component choice begins with the request profile, not with an AWS service preference:

• Route 53 provides highly available DNS and regional routing decisions; it does not balance requests inside an ALB or provide instant client failover.
• CloudFront is for global edge delivery and caching. Use it aggressively for static and safely cacheable content; be deliberate with transactional APIs.
• AWS WAF filters HTTP application-layer abuse. It complements, rather than replaces, Shield protections, security groups, authentication, and rate limits.
• ALB is the normal Layer 7 choice for HTTP microservices on ECS or EKS, especially when path, host, header, gRPC, WebSocket, and target-group routing matter.
• NLB is the Layer 4 choice for TCP, TLS, UDP, long-lived connections, and stable-address partner requirements. It is not inherently the correct answer for every low-latency workload.
• API Gateway is appropriate when the API contract needs managed authorization, validation, throttling, quotas, and lifecycle control.
• Combining services is valid only when each layer supplies a specific requirement. Extra layers without a stated purpose create latency, cost, and failure modes.

Next, you will move from ingress selection to the compute platform behind it: designing and defending a highly available ECS service, including capacity model, placement, target health, autoscaling, task IAM, secrets, and the conditions that would justify EKS instead.