An elections office expects election-night media spikes and wants storage that can absorb unpredictable growth without mid-event volume resizing. Which design best scales ahead of that spike?

Election-night media spikes create unpredictable object growth while cameras and press workflows are live. Amazon S3 scales capacity elastically with the number and size of objects, so the elections office does not need to resize block volumes mid-event to absorb uploads. That “scale for future needs without resize drama” property is why object storage is the correct high-performing design for spike media under Task 3.1, especially when civic events produce bursty, hard-to-forecast volume. Pre-creating one maximum-size EBS volume and hoping election night stays under that ceiling fails because block volumes still require capacity planning and modification; underestimating the spike forces mid-event resizing or write failures when the office can least afford them. Keeping all media on a single EC2 instance store and rebooting if space runs out fails conceptually because instance store is ephemeral, size-bound to the host, and unsuitable as the durable or elastic home for election evidence. Using EFS One Zone only in the AZ hosting the press room Wi-Fi fails because tying storage availability to one AZ and a local network assumption does not provide S3-like elastic object capacity or a sound availability design for citywide election media. Exam caveat: S3 removes volume-resize toil but you still design prefixes, multipart uploads, lifecycle, and permissions for election media; elasticity of capacity is not the same as unconstrained request-rate design without partitioning and client best practices. Operational check: direct spike media to S3 before the event, load-test multipart ingest at expected peak, monitor 4xx/5xx and incomplete multiparts, and confirm press and canvass workflows read from the bucket rather than local disks.