A digitization team uploads many large scanned permit packets to Amazon S3 daily. Leadership asks how to reduce PUT request overhead and stored bytes without changing durability goals. Which upload strategy best helps?
Select an answer to reveal the explanation.
Short Explanation
Big scanned packets love two thrifty habits: squeeze the air out (compress) and use multipart so large files transfer efficiently. Tiny one-byte PUT storms, fragile single-shot multi-GB uploads, and five-Region duplicates before compression burn money for no durability win.
Full Explanation
Compressing scanned permit packets where appropriate and using efficient multipart uploads for large transfers reduces both PUT request overhead and stored bytes without weakening Amazon S3 durability goals. Compression shrinks object size (and often transfer time), while multipart upload improves reliability and parallelism for multi-GB digitization batches compared with fragile single-PUT transfers. Uploading millions of tiny one-byte objects with individual PUT calls and no compression maximizes request charges and operational noise for no analytic benefit. Disabling multipart upload for multi-GB files and using a single failing connection each night increases failure risk and operational rework during nightly municipal digitization windows. Storing duplicates of every packet in S3 Standard across five Regions before compression multiplies storage and transfer cost and is unrelated to efficient upload technique. Exam caveat: multipart has part-size and completion semantics to handle correctly; also weigh compression CPU cost and whether content is already compressed (for example some image formats). Operational check: benchmark compressed versus uncompressed packet sizes, configure multipart part sizes for typical permit PDFs, monitor PutRequest and storage metrics after a week of uploads, and confirm application retrieval still decompresses correctly for clerks.