A city open-data site serves mostly static PDFs and images from an ALB/EC2 origin, and egress bills keep climbing. Which architecture change best reduces origin and data-transfer cost?
Select an answer to reveal the explanation.
Short Explanation
Put the popular park maps at the edge of town so every visitor doesn't drive downtown. CloudFront caches static assets and trims origin plus egress cost.
Full Explanation
A city open-data site serving mostly static PDFs and images from an ALB/EC2 origin pays repeatedly for origin compute and typically higher data-transfer patterns when every citizen download hits the regional origin. Placing Amazon CloudFront in front of those static assets caches objects at edge locations, reducing requests and bytes served from ALB/EC2 and usually lowering egress cost for popular open-data files such as zoning maps, council agendas, and park guides. Origin shield or appropriate cache TTLs further stabilize hit ratios for municipal catalogs that change infrequently.
Disabling caching and proxying every download through a single NAT Gateway fails by concept: it increases NAT processing and removes cache savings. Storing public PDFs only on RDS Multi-AZ for "cheaper downloads" abuses a relational database as a CDN and raises HA database cost. Requiring citizens to VPN into the VPC before each PDF GET adds friction and operational cost contrary to open-data goals.
Exam caveat: CloudFront still incurs request and data-transfer-out pricing—savings come from edge efficiency and reduced origin load, not from "free bandwidth." Dynamic personalized content may need different cache behaviors than static PDFs.
Operational check: put CloudFront distributions in front of the open-data origin or S3, set TTLs and compression for PDF/image types, compare origin request counts and data-transfer line items before versus after, and sample cache hit ratio while validating that updated municipal documents invalidate or version correctly.