4 of the 7 questions we have for this objective, shown with the answer and the reasoning.
Determine high-performing and/or scalable network architectures
Ironvale Interactive runs a multiplayer game whose clients communicate with game servers over UDP. The servers sit behind Network Load Balancers in us-east-1 and eu-west-1. Players worldwide need the lowest possible latency, the game client ships with hard-coded static IP addresses, and if one Region fails, traffic must shift to the other within seconds without relying on clients re-resolving DNS.
Which solution will meet these requirements?
- ADeploy AWS Global Accelerator with the two Network Load Balancers as endpoints and distribute the accelerator's static anycast IP addresses in the clientGlobal Accelerator provides two static anycast IPs, routes UDP and TCP traffic onto the AWS global network at the nearest edge, sends each player to the lowest-latency healthy Region, and fails over in seconds without DNS changes.
- BDeploy an Amazon CloudFront distribution with the two Network Load Balancers as originsCloudFront accelerates HTTP and HTTPS; it does not proxy arbitrary UDP game traffic and does not offer fixed IP addresses for clients.
- CUse Amazon Route 53 latency-based routing with health checks across the two Network Load BalancersLatency routing picks the closest Region, but the addresses change per Region and failover depends on DNS TTL expiry and client re-resolution, which the scenario rules out.
- DConnect the two Regions with a Transit Gateway peering attachment and route players through the nearest RegionTransit Gateway peering connects VPCs privately across Regions; it does not provide client-facing entry points, static IPs, or traffic steering for internet users.
Why: Global Accelerator is the answer when a scenario combines non-HTTP protocols such as UDP, a need for static IP addresses, and fast Regional failover that must not depend on DNS caching. Its anycast IPs bring traffic onto the AWS backbone at the nearest edge and continuously steer each user to the best healthy endpoint. CloudFront is the trap for anyone who equates global performance with CDN; it only handles HTTP(S). Route 53 latency routing is a good multi-Region tool but fails the static-IP and DNS-independent failover requirements.
Determine high-performing and/or scalable network architectures
Mossvale Learning hosts a web application in us-east-1: static course content (images, video, JavaScript) in an S3 bucket named mossvale-static and a REST API on an Application Load Balancer. Students in Europe, India, and Brazil report slow page loads. Mossvale wants to reduce latency for all users worldwide without deploying its application stack in additional Regions.
What should a solutions architect recommend?
- AEnable S3 Cross-Region Replication of mossvale-static to buckets in Europe, India, and BrazilReplicating the bucket creates copies but does not route users to the nearest copy and does nothing for the API traffic that goes to the ALB.
- BUse Route 53 latency-based routing to direct users to the closest RegionLatency-based routing only helps when the application runs in multiple Regions, which the company has ruled out.
- CDeploy AWS Global Accelerator with the S3 bucket and the ALB as endpointsGlobal Accelerator improves the network path to ALB, NLB, EC2, and Elastic IP endpoints but does not cache content and does not support S3 buckets as endpoints.
- DCreate an Amazon CloudFront distribution with mossvale-static as one origin and the ALB as a second origin, using cache behaviors to route static and API pathsCloudFront caches the static content at hundreds of edge locations close to the students and accelerates the dynamic API calls over the AWS backbone, all from the single existing Region.
Why: A global audience and a single-Region deployment point to CloudFront: edge caching eliminates the long trip for static assets, and even uncacheable API requests benefit from edge TLS termination and the optimized AWS network path to the origin. Multiple origins with path-based cache behaviors let one distribution front both S3 and the ALB. Global Accelerator is the trap: it also improves global performance, but it works at the network layer for TCP and UDP endpoints and cannot cache or front S3, so it is the answer for non-HTTP or static-IP scenarios, not for web content delivery.
Determine high-performing and/or scalable network architectures
Pembrook Financial must pass all inbound and outbound traffic for 12 application VPCs through a fleet of third-party next-generation firewall appliances that its security team manages on EC2 instances in a central inspection VPC. The firewalls must scale horizontally, be health-checked, and receive the original packets transparently so that the application teams do not change their application code or IP addressing.
Which solution should a solutions architect recommend?
- APlace the firewall instances behind a Network Load Balancer and route each VPC's traffic to the NLB's IP addressesAn NLB can balance TCP and UDP to the appliances, but it is not transparent: packets are proxied and routed to the NLB rather than passed through inline, and it does not provide the bump-in-the-wire insertion the appliances expect.
- BPlace the firewall instances behind an Application Load Balancer and use path-based routing rulesAn ALB terminates HTTP connections and routes requests; it cannot forward raw packets of every protocol to inline inspection appliances.
- CReplace the appliances with AWS Network Firewall in each application VPCNetwork Firewall is a managed option, but the requirement is to keep the security team's existing third-party appliances, which it would replace rather than scale.
- DDeploy a Gateway Load Balancer in the inspection VPC with the firewall instances as targets, and route each application VPC's traffic through Gateway Load Balancer endpointsA Gateway Load Balancer sits inline, encapsulates the original packets with GENEVE, health-checks and scales the appliance fleet, and Gateway Load Balancer endpoints in each VPC insert it transparently into the routing path.
Why: The Gateway Load Balancer exists for exactly one job: transparently inserting and scaling a fleet of third-party virtual appliances such as firewalls, intrusion detection systems, and deep packet inspection tools. It combines a transparent network gateway with a load balancer and uses GENEVE encapsulation so appliances see the original packets. NLB is the trap because it also handles Layer 4 traffic, but it is a proxying load balancer, not an inline gateway. When a scenario names third-party appliances and transparent inspection, pick Gateway Load Balancer.
Determine high-performing and/or scalable network architectures
Redcliffe Exchange operates a market-data feed that trading firms consume over a proprietary TCP protocol on port 9000. The feed must handle millions of connections per second with ultra-low latency, preserve the client source IP address, and present one static IP address per Availability Zone so that the firms can allowlist it in their firewalls. The feed servers run on an Auto Scaling group across three Availability Zones.
Which load balancer should a solutions architect recommend?
- AAn Application Load Balancer with a TCP listenerAn ALB works at Layer 7 for HTTP, HTTPS, and gRPC; it cannot listen for an arbitrary TCP protocol and does not offer static IP addresses.
- BA Network Load Balancer with a TCP listener on port 9000 and an Elastic IP address in each Availability ZoneThe NLB operates at Layer 4, handles millions of requests per second with very low latency, preserves the client source IP for TCP targets, and supports one static or Elastic IP address per Availability Zone.
- CA Gateway Load Balancer with GENEVE encapsulationA Gateway Load Balancer distributes traffic to inline virtual appliances such as firewalls for inspection; it is not a front door for application clients.
- DA Classic Load Balancer with a TCP listenerThe Classic Load Balancer is a previous-generation option without static IP support or the extreme throughput and latency characteristics of the NLB.
Why: Load balancer selection follows the layer and the features: ALB for HTTP-aware routing, NLB for TCP, UDP, and TLS at very high throughput with static IPs and source-IP preservation, and Gateway Load Balancer for transparent insertion of third-party appliances. Non-HTTP protocol, extreme connection rate, and the need for allowlistable static addresses each independently point to the NLB. The trap is the ALB, which is the default mental choice for web workloads but cannot carry a proprietary TCP protocol.