A transit agency evaluates AWS Global Accelerator for a public API already fronted by DNS failover and CloudFront for static content. When is Global Accelerator the cost-aware choice?
Select an answer to reveal the explanation.
Short Explanation
Global Accelerator is a performance sports car—great when the stopwatch says you need it, pricey if DNS and CloudFront already win the race. Buy it when metrics justify the fare.
Full Explanation
AWS Global Accelerator provides static anycast IP addresses and AWS global network routing that can improve performance and regional failover for internet-facing applications. A transit agency that already uses DNS failover and CloudFront for static content should adopt Global Accelerator only when measured performance or regional failover benefits exceed its incremental cost versus those existing controls. Instrument latency from rider-facing clients, compare failover behavior under Region impairment drills, and buy Global Accelerator when the stopwatch and SLA justify it—not by default.
Always enabling Global Accelerator on every static image bucket because it replaces S3 pricing fails by concept: it does not replace S3 storage pricing and is usually the wrong tool for pure static objects already suited to CloudFront. Enabling it automatically for all internal VPC DNS names with no metrics wastes spend on non-internet entry points. Preferring Global Accelerator whenever CloudFront exists, regardless of anycast or failover needs, stacks services without a measured gap.
Exam caveat: CloudFront optimizes HTTP caching at the edge; Global Accelerator operates at the network layer for TCP/UDP acceleration and failover. They solve overlapping but not identical problems—know which symptom you are fixing.
Operational check: baseline API p95 latency and failover RTO with DNS+CloudFront alone, trial Global Accelerator against the public API, compare rider-region latency and cost line items, and retain GA only if improvements exceed its monthly charge for the transit workload.