A city’s open-data portal serves popular CSV and GeoJSON files from an S3 origin to thousands of citizens. Origin egress cost is rising. Which design improves performance and reduces transfer cost?
Select an answer to reveal the explanation.
Short Explanation
Popular open-data files should hitch a ride at the edge—CloudFront caches the hits so S3 isn’t paying taxi fare on every download. Turning off cache or shipping the whole bucket to every laptop is the opposite of thrifty.
Full Explanation
Popular open-data CSV and GeoJSON files served from an S3 origin to thousands of citizens create repeated origin egress when every identical download hits the bucket. Placing Amazon CloudFront in front of the S3 origin lets edge caches absorb repeat downloads, improving latency for residents while reducing origin transfer cost for the municipality. The design works because hot, cacheable civic files are read-mostly; edge TTLs convert one origin fetch into many citizen hits. Forcing every download through a cross-Region S3 Replication hop before serving fails by adding transfer and complexity without helping hot-object caching at the edge. Disabling caching so every request refetches unchanged files fails conceptually—it maximizes origin egress precisely when popular datasets are stable. Exposing the bucket via frequent full-bucket Sync to each citizen laptop overnight fails operationally and economically: wholesale client sync does not scale and multiplies transfer for files users may never open. Exam caveat: set appropriate TTLs and invalidation processes for datasets that do update; CloudFront helps most when objects are cacheable—signed or highly personalized responses need careful cache-key design. Operational check: enable CloudFront on the open-data distribution, compare S3 BytesDownloaded and CloudFront cache-hit ratio for top prefixes over two weeks, and document TTL and invalidation ownership for the data stewards.