Your bucket, your bill.
SyncShot doesn't resell cloud storage. The bucket is yours — at AWS, Backblaze, Cloudflare, Wasabi, anywhere S3-compatible. Pricing is the provider's pricing. What SyncShot adds is multipart writes paced sensibly, resume-on-disconnect, and the same BLAKE3 verification applied to local destinations.
- A bucket and a region
- Pick the region geographically closest to where the work happens — upload throughput is roughly inverse to latency. EU shoots → eu-* region. US west coast → us-west-*. Asia-Pacific shoots → ap-* region.
- Scoped credentials
- An IAM user (or equivalent) restricted to this bucket, with PutObject, CreateMultipartUpload, CompleteMultipartUpload, AbortMultipartUpload. SyncShot doesn't read, doesn't list, doesn't delete — write-only is enough.
- Endpoint, for non-AWS providers
- B2 / R2 / Wasabi / MinIO all expose an S3 endpoint URL. Paste it where SyncShot asks. AWS is the default and doesn't need one.
- Headroom in the bucket
- S3 buckets are effectively unlimited but cost compounds. Set a budget alert in the provider's console; SyncShot writes what it's told to write.
Step by step.
- 01
Create or pick the target bucket
In the AWS console — or any S3-compatible provider (Backblaze B2, Cloudflare R2, Wasabi, MinIO, DigitalOcean Spaces) — pick the bucket the shoot lands in. Region matters for upload latency; pick the one closest to the studio.
- 02
Generate an access key with write access
IAM → Users → SyncShot user (or a dedicated key) → permissions scoped to the bucket. SyncShot needs PutObject, CreateMultipartUpload, CompleteMultipartUpload, AbortMultipartUpload — that's it. Generate the access key ID and secret.
- 03
Add S3 as a destination in SyncShot
Destinations → Add → S3. Paste the bucket name, region, access key ID and secret. For non-AWS providers, set the endpoint (e.g. https://s3.us-west-002.backblazeb2.com for B2). SyncShot tests the connection on save.
- 04
Pick a prefix and the organize-by layout
Bucket root or a prefix (raw-shoots/, archive/, etc.). Same organize-by options as everywhere else — None / Date / Month / Device / Type. The prefix is appended to the chosen layout.
- 05
Add S3 to the job alongside everything else
One read, every write. The source is read once, S3 gets its copy in parallel with the working SSD, the NAS, anything else on the job. Multipart upload for large files; small files go in single PUTs.
- 06
Start the job
Local destinations finish first. S3 keeps uploading in the background — multipart parts written in parallel up to the connection ceiling. If the connection drops, the multipart upload resumes from the last completed part on retry.
- 07
Verify against the server-side hash
S3 returns an ETag (per-part MD5 for multipart, full MD5 for single-part) — SyncShot stores the matching BLAKE3 locally and confirms the round-trip. Green report = the bucket holds the bytes the source had.
After it's done.
The job report names every key SyncShot wrote — the object key, the size, the ETag returned, the BLAKE3 it matched against. If a multipart upload was interrupted, the next run picks it up at the part boundary, not the file start.
- Open the job report
- Every file, every destination including S3, every hash result, every object key. Local destinations finish first; S3 follows when the upload completes.
- Rotate credentials when you need to
- Provider console issues a new access key, paste the new pair into SyncShot, save. The old key can be deactivated immediately — SyncShot uses the new one on the next job.
- Save S3 on the workflow
- Once configured, S3 stays on the workflow until removed. Every future job using that workflow writes to the same bucket and prefix.
Prefer Drive over a bucket? See out to Google Drive. Want the source-and-destinations saved as a one-click run? Saved workflows. More guides at the user guide hub.