3.3 - Improving performance, cost and resilience of existing workloads

1. A dynamic API behind an ALB has global users complaining of latency and the origin is overwhelmed by repeated identical requests. Which change improves latency and offloads the origin?

• Put Amazon CloudFront in front of the ALB with caching and TLS termination at the edge (correct answer)
• Move the ALB to a Network Load Balancer to lower per-request latency globally
• Enable cross-zone load balancing on the ALB across all Availability Zones
• Increase the ALB idle timeout and raise its per-node connection limits

CloudFront terminates TLS and serves cacheable responses from edge locations close to users, cutting latency and shielding the origin from repeated requests. NLB, cross-zone balancing, and timeout tuning do not cache or bring content closer to global users.

2. A global website serves static images and CSS directly from an Application Load Balancer, and users far from the Region complain of slow page loads. What is the simplest improvement?

• Put Amazon CloudFront in front, caching static assets at edge locations (correct answer)
• Deploy identical ALB stacks in ten Regions and let users pick one manually
• Enlarge the ALB and its target instances to serve more requests per second
• Store the assets on an EBS volume with the highest provisioned IOPS tier

CloudFront caches static content at edge locations near users, cutting latency and offloading the origin with minimal change. Manual multi-Region selection burdens users, scaling the ALB does not fix the distance-driven latency, and higher EBS IOPS addresses disk throughput, not geographic delay.

3. A read-heavy product-catalog service hits its RDS database with the same expensive queries thousands of times per second, saturating the database CPU. The team wants to cut repeated reads with minimal code change. What fits best?

• Move the entire product catalog table wholesale into a DynamoDB global table replicated across several Regions
• Raise the RDS instance to the largest class and add more provisioned IOPS
• Add an ElastiCache cache in front of the database for hot query results (correct answer)
• Turn on RDS automated backups more frequently to reduce query pressure

ElastiCache stores hot query results in memory so repeated reads are served from cache, slashing database CPU with a small caching layer added to the app. A full DynamoDB migration is a large redesign, scaling RDS just delays saturation at higher cost, and more frequent backups add load rather than remove it.

4. A latency-sensitive TCP gaming backend runs in two Regions behind Network Load Balancers, but players are routed by DNS and often land on a distant Region with poor performance. What improves routing to the nearest healthy endpoint?

• Lower the TTL on the Route 53 records so clients refresh their DNS more often
• Place a CloudFront distribution in front of both Network Load Balancers
• Use AWS Global Accelerator with the two NLBs as endpoints behind anycast IPs (correct answer)
• Add more NLB nodes in each Region to increase the total connection capacity

Global Accelerator gives static anycast IPs and routes each connection over the AWS backbone to the nearest healthy endpoint, ideal for latency-sensitive TCP/UDP traffic with fast failover. Lower TTL only speeds DNS refresh, CloudFront targets HTTP caching not raw TCP gaming, and more NLB nodes do not fix geographic routing.

5. A reporting feature runs heavy read-only analytical queries against the primary RDS MySQL instance, slowing down transactional writes for regular users. The team wants to offload reports without changing the write path. What should they add?

• A second primary instance so writes can be split evenly across the two databases
• An RDS read replica and point the reporting queries at its endpoint (correct answer)
• A larger storage volume with higher IOPS attached to the primary instance
• A cross-Region snapshot restored each morning for the reporting workload

An RDS read replica takes an asynchronous copy of the primary; pointing reporting queries at its endpoint offloads heavy reads so the primary serves writes unimpeded. RDS has a single writer so a second primary is not how it works, more IOPS does not isolate the read load, and a daily snapshot restore gives stale data.

6. A CPU-bound stateless Java service on x86 On-Demand instances is both costly and only moderately fast. The team can rebuild the container image and wants better price-performance without rewriting the app. What should they evaluate first?

• Move the whole service over to the very largest available x86 memory-optimized instance family currently on offer
• Rebuild for Graviton (arm64) instances to improve price-performance on CPU work (correct answer)
• Run the service on Spot exclusively to cut the hourly compute cost to the minimum
• Attach GPU accelerators to the instances to speed up the CPU-bound processing

Graviton (arm64) instances typically deliver better price-performance for CPU-bound, stateless workloads, and since the container can be rebuilt for arm64 the app itself is unchanged. Memory-optimized families do not help CPU-bound work, Spot addresses price but not performance or stability, and GPUs do not accelerate general CPU code.