Guide

How to give a client SFTP access to your S3 bucket (without IAM users)

Four ways to let a client or vendor upload files to your Amazon S3 bucket over SFTP, AWS Transfer Family, a self-hosted server, s3fs, and a managed gateway, with the real trade-offs of each.

A partner needs to drop files with you. They have an SFTP client and expect a hostname, a username, and a path. You want those files to land in your own Amazon S3 bucket, not on some third party’s servers, and not in an inbox you have to babysit. And you’d rather not hand out AWS credentials or stand up a server to do it.

This is one of the most common “last mile” problems in cloud file transfer, and there are four realistic ways to solve it. Here’s each, with the catch.

What you’re actually trying to avoid

Two things make this harder than it looks:

  1. You can’t give the client AWS credentials. SFTP users aren’t IAM users. Your partner has an SFTP client, not the AWS CLI, and you don’t want long-lived access keys floating around in someone else’s automation.
  2. S3 isn’t a filesystem. It’s a flat object store with no real directories, no rename, and eventual consistency on listings. SFTP clients expect a POSIX-like filesystem. Something has to translate between the two.

Every option below is really just a different answer to “who runs the translation layer.”

Option 1: AWS Transfer Family

AWS’s own managed SFTP service. It puts a fully-managed SFTP/FTPS/FTP endpoint in front of S3, with users mapped to bucket prefixes via IAM roles.

  • Good: first-party, integrates with IAM and CloudWatch, scales without you running anything.
  • The catch: you pay an hourly charge for each protocol you enable, whether or not anyone connects, plus a per-GB data charge, so a low-volume “one partner, a few files a day” use case still carries a meaningful fixed monthly cost. You also author the IAM policies, set up the VPC/endpoint, and wire CloudWatch yourself to get an audit trail.

If you’re already deep in AWS and need first-party everything, it’s a reasonable pick. See AWS Transfer Family pricing, explained for the actual numbers, and our AWS Transfer Family alternative page for the side-by-side.

Option 2: self-host an SFTP server (sftpgo, OpenSSH + s3fs)

Run your own SFTP server on an EC2 instance and point it at S3, either with a tool like SFTPGo that has a native S3 backend, or OpenSSH with s3fs/rclone mount.

  • Good: full control, no per-endpoint vendor fee, open-source.
  • The catch: now you own a server. Patching, key rotation, monitoring, backups, high-availability, and the fun edge cases where a FUSE mount disagrees with S3 about what a “directory rename” means. It’s cheap until it pages you at 2am. Fine if you enjoy running infrastructure; a tax if you don’t.

Option 3: a managed bring-your-own-bucket gateway

A hosted SFTP gateway that connects to a bucket you own and runs the SFTP-to-S3 translation for you. This is the category Firepipe is in.

The distinguishing idea is bring-your-own-bucket: you grant a scoped, cross-account IAM role (for S3) and the gateway streams files straight into your bucket. Your data never lives on the vendor’s infrastructure: there’s nothing to migrate and nothing to get locked into.

  • Good: no server to run, no IAM policy to hand-write, per-user credentials and a full audit trail out of the box, live in minutes.
  • The catch: it’s a managed service, so you’re trusting a third party to operate the gateway (the files still land in your bucket, but the connection passes through them). Pick one whose security model you’re comfortable with.

With Firepipe specifically you get per-user SFTP credentials (SSH keys or password), each jailed to a path prefix, instant revoke that also tears down live sessions, and the ability to pin a credential to specific source IPs. Pricing starts free, then $19/mo, with no per-operation or per-listing fees. See SFTP to S3 for the walkthrough.

A security checklist, whichever option you pick

  • Never share one credential across partners. One set of SSH keys per client, so you can revoke one without breaking the rest.
  • Path-jail every user to their own prefix so a partner can’t list or read anyone else’s files.
  • Use a scoped role, not root credentials. The gateway (or server) should only be able to touch the prefix it needs.
  • Keep an audit trail of connections and transfers: you will eventually need to answer “did file X arrive, and when?”
  • Have a revoke story. When an engagement ends, can you cut access in seconds?

Which should you choose?

  • One or two partners, low volume, you don’t want to run anything: a managed bring-your-own-bucket gateway is usually the least-effort, lowest-fixed-cost option.
  • Heavy AWS shop that needs first-party tooling and IAM integration: AWS Transfer Family.
  • You enjoy running infrastructure and want zero vendor in the path: self-host.

The thing they all share: your files should end up in your S3 bucket, under access you can revoke at will. That’s the bar, everything else is a question of who runs the plumbing.

Try it on your own bucket

Connect a bucket you already own, Amazon S3, Azure Blob, Google Cloud Storage, or an S3-compatible store, and hand out a clean SFTP endpoint in minutes. Your files stay in your cloud.

Start free

← All guides