A public-works GIS team keeps nightly-updated project files on an on-premises NFS share and wants an efficient, scheduled replication into Amazon S3 for analytics without rewriting applications as custom rsync fleets. Which service best fits?
Select an answer to reveal the explanation.
Short Explanation
DataSync is the scheduled moving truck for file shares—point it at NFS, aim it at S3, and stop babysitting homemade rsync fleets. USB couriers, SNS-as-file-transfer, and hand-pasted API calls aren’t serious ingest for GIS analytics.
Full Explanation
AWS DataSync is the service purpose-built to replicate an on-premises NFS share to Amazon S3 on a schedule without rewriting public-works GIS applications into homemade rsync fleets. DataSync agents read the NFS source, handle parallel transfer, integrity verification, and scheduling so nightly-updated project files land in S3 for analytics with far less operational glue. Manual USB drives couriered between the yard and a Region each Monday are slow, untracked, and error-prone for municipal GIS continuity. Amazon SNS emailing each file as a Base64 attachment to a shared inbox is not a file-replication protocol and will hit size, reliability, and security limits quickly. Amazon API Gateway REST APIs that GIS technicians paste file contents into by hand do not scale for nightly project trees and invite human error. Exam caveat: plan bandwidth windows, verify NFS permissions for the DataSync agent, and choose transfer options (overwrite/delete behavior) carefully so S3 mirrors match GIS retention expectations. Operational check: run an initial inventory/sync on a sample project share, compare file counts and checksums in S3, schedule the nightly job, and alert on DataSync task failures before decommissioning any interim copy process.