The city's open-data portal is a static site of CSVs, maps, and HTML with a few dynamic query APIs still on the permitting backend. The current design serves everything from a pair of always-on EC2 web servers. Which storage-and-delivery modernization should architects select?
Select an answer to reveal the explanation.
Short Explanation
A pile of CSVs and HTML is a brochure rack, not an application server. Park the static files on S3, let CloudFront hand them out, and keep the living queries on APIs. Don't freeze the whole portal into Glacier.
Full Explanation
The city's open-data portal—a static site of CSVs, maps, and HTML with a few dynamic query APIs still on the permitting backend—currently served from a pair of always-on EC2 web servers should host the static open-data site on Amazon S3 with Amazon CloudFront and keep dynamic queries on APIs. That storage-and-delivery modernization scales citizen download days without pairing EC2 for static bytes. Keeping the static files on EC2 local disks and scaling the instances for download day fails cost and operational simplicity. Putting the entire portal, including APIs, into Amazon S3 Glacier Deep Archive fails interactive retrieval and API hosting. Requiring residents to download a desktop client that ships every CSV on a USB stick fails open-data accessibility goals. Exam caveat: S3+CloudFront for static open data; APIs remain separate. Operational check: sync static assets to S3, front with CloudFront/OAC, leave query APIs on managed API endpoints, load-test download day, and retire EC2 static hosting. Document the decision in the municipal architecture decision record and re-verify controls after the first production wave so auditors see continuous improvement, not one-time tribal knowledge.