Archive Zoom Cloud Recordings to Amazon S3 (or Any S3-Compatible Bucket)

Your Zoom account is closing in on its storage cap again, and you already know a bucket costs a fraction of what Zoom's add-on tiers charge per gigabyte — the question left is how recordings actually get there, and whether "S3" means Amazon specifically or the bucket you already run somewhere else. Search "zoom recordings to s3" and page one is API reference docs and generic Zapier templates, not an answer for either kind of bucket.

What's actually happening

Zoom does ship a feature called Bring Your Own Storage, but it doesn't cover what most people mean by "my Zoom recordings." Zoom's own BYOS documentation states plainly that it "saves Video SDK cloud recordings directly to your Amazon S3 bucket instead of the Zoom cloud" — that's the embeddable video SDK used inside custom apps, not the Zoom Meetings client everyone actually records with. For a standard Meetings cloud recording, Zoom's own developer guidance is the same as for any other third-party destination: build the connection yourself against Zoom's API — webhooks and REST calls, not a setting you flip on.

That leaves recordings sitting in Zoom's cloud storage, billed at Zoom's own per-gigabyte add-on rate, until the account's quota fills or a retention policy clears them out — with no first-party path to the bucket you're already paying for and already administer.

What you need

1. A paid Zoom plan (Pro, Business, Education, or Enterprise) — cloud recording is disabled on free plans.
2. Cloud recording turned on in your Zoom account settings.
3. A bucket on an S3-compatible endpoint: Amazon S3, Cloudflare R2, Backblaze B2, Wasabi, MinIO, or another provider that speaks the S3 API — reachable on a public hostname with valid TLS, per the NAS note above.
4. An automation that authenticates with a scoped key rather than your root credentials, and handles large and password-protected recordings reliably — RecordFlow is built for exactly this.

The permission shape

The credential you hand over matters as much as the bucket you point at. RecordFlow asks for an IAM user with an access key — no roles, no STS, nothing that needs a trust policy — scoped to one prefix inside one bucket, able to:

• Write and overwrite objects under that prefix.
• Read objects back, to verify what it just uploaded actually landed.
• Delete an object, so a copy that fails verification doesn't get mistaken for a finished archive on the next pass.
• Abort an incomplete multipart upload. This is the one permission it's easy to forget and expensive to skip: the parts of a failed large-file upload are billed by your provider until something explicitly aborts them, and a large recording that RecordFlow uploads in chunks is exactly the shape that leaves orphaned parts behind if the connection drops mid-transfer.

For Amazon S3 or Wasabi, RecordFlow generates the exact least-privilege IAM policy document for you to paste in, with your bucket and prefix already substituted — copy it, attach it, done. Backblaze B2 and Cloudflare R2 scope keys through their own console instead of a JSON policy, and RecordFlow shows the equivalent steps for whichever one you pick. Either way, deleting the key in your provider's console stops RecordFlow immediately — you don't need to ask us to disconnect anything.

How to archive Zoom recordings to S3

1. Verify cloud recording is on. In Zoom Settings → Recording, Cloud recording should be toggled on — without it, nothing RecordFlow can see ever gets created.
2. Install RecordFlow's Zoom App from the Zoom App Marketplace, a one-click OAuth install that only ever asks for read access to cloud recordings.
3. Choose your bucket on the connect screen. Pick your provider — for Amazon S3, Cloudflare R2, Backblaze B2, or Wasabi, RecordFlow fills in the correct endpoint once you name your region (or Cloudflare account ID for R2); for MinIO or anything else, you type the endpoint yourself. Name the bucket and, optionally, a folder prefix — leave it blank to archive at the bucket root.
4. Create the scoped key, following the exact recipe the screen shows for your provider, and paste the access key ID and secret. RecordFlow writes a test object to the bucket and reads it back before saving anything, so a typo in the key or a bucket you don't actually have write access to fails immediately instead of silently on your first real recording. Recording bytes never touch RecordFlow's own infrastructure in between — this key just lets files stream straight from Zoom into your bucket.
5. Record your next meeting to the cloud. Once Zoom finishes processing it, RecordFlow copies the video, the audio-only file, any transcript, and the chat log into your bucket under one prefix per year and one folder per meeting — object keys laid out the same way as RecordFlow's file-based destinations, so the bucket stays browsable in your provider's own console. If Zoom generated a transcript, RecordFlow also renders it as a formatted Word document alongside the raw .vtt.

Already sitting on months or years of recordings from before you connected anything? RecordFlow's archive-history setting reaches back into that backlog too — it starts at the past month, included free, and reaching further is a one-time paid unlock that streams even a multi-year backlog into your bucket in chunks.

What to check if a recording doesn't arrive

How RecordFlow fits

RecordFlow treats an S3-compatible bucket the same way it treats Google Drive, OneDrive, or Dropbox: one connection, and every new cloud recording lands there automatically from then on, files streamed directly from Zoom to your bucket rather than held anywhere in between. The difference is who owns the storage — a bucket you provisioned, under a key you scoped and can revoke in one click, with no vendor lock-in to a drive plan. That one connection works the same whether you're archiving your own recordings or, as an account admin, every opted-in member's recordings into a single bucket you control. If a transfer fails it retries automatically, and an hourly safety sweep catches anything a webhook notification missed, so the archive doesn't quietly depend on a script someone wrote once and forgot about. Full setup reference, including what each provider's connect screen looks like: S3-compatible storage documentation.