A city publishes a global static open-data portal (HTML, JS, CSV, GeoJSON) and needs low time-to-first-byte for citizens worldwide. Which AWS design best improves performance?

A global static open-data portal of HTML, JS, CSV, and GeoJSON files serves citizens worldwide who expect low time-to-first-byte. Amazon CloudFront places the content at edge locations, caching static objects close to users and reducing latency compared with every request traveling to a single Regional origin. For municipal open data, that pattern improves performance for residents and researchers far from the origin Region without rewriting files into a dynamic application tier.

Serving files from a single EC2 instance in one Region with no edge caching concentrates load and latency on one place and scales poorly for global citizens. Requiring every citizen to VPN into a private subnet before downloading public CSVs destroys the “open” in open data and adds friction and cost. Storing the portal only on Amazon EBS volumes attached to stopped instances makes the content unavailable and is not a web distribution design.

Exam caveat: CloudFront needs a valid origin (often S3 or a load balancer), correct cache behaviors for CSV/GeoJSON, and appropriate TLS certificates for the civic hostname. Cache TTLs must balance freshness of frequently updated datasets against edge hit ratios. CloudFront is not a substitute for authorization controls when some datasets are sensitive—signed URLs/cookies or origin auth may still apply.

Operational check: measure TTFB from multiple geographies before and after CloudFront; verify cache hit ratio for static assets; confirm invalidation or versioned object keys when open-data files update; and ensure the distribution’s default root and error pages match the portal’s UX.