A tourism bureau serves static park maps globally and also exposes a latency-sensitive API that benefits from static anycast entry IPs. How should edge and global performance services be applied?
Select an answer to reveal the explanation.
Short Explanation
Maps love CloudFront’s edge cache; APIs that want a stable anycast front door love Global Accelerator. Use each tool for the job it actually does.
Full Explanation
A tourism bureau that serves static park maps globally and also exposes a latency-sensitive API with static anycast entry IPs needs two complementary edge services. Amazon CloudFront caches static park maps at the edge, while AWS Global Accelerator provides static-IP anycast entry to the regional API—matching each workload's access pattern. Serving park maps only from a single Region origin with no CDN ignores global static performance. Using Global Accelerator to cache static map files at the edge misunderstands Accelerator versus CDN roles. Replacing both needs with one public EC2 Elastic IP in a single metro fails global performance and static anycast requirements. Exam caveat: CloudFront origins and Accelerator endpoint groups still need health checks and TLS design. Operational check: fetch maps from distant clients via CloudFront with cache hits, connect API clients to Accelerator static IPs, fail one Region endpoint, and confirm API entry remains reachable through healthy endpoints. In municipal cloud governance, record the owners, success metrics, and rollback or restore contacts beside this technical choice so the next incident, budget review, or audit does not rediscover the decision from scratch under time pressure.