S3 to SFTP and SFTP to S3: Three Ways to Connect a Bucket and an SFTP Server

S3 to SFTP sounds like one step and turns out to be a small system. Your data lives in a bucket. A partner, a bank, or a vendor can only take it over SFTP, or can only deliver it over SFTP, and now something has to sit between the two and move files on a schedule without losing any.

For a one-off transfer, download and upload is enough. In production the job also needs scheduling, retries, credential management, monitoring, an audit trail, and protection against half-written files, and if the partner's nightly file never arrives, someone has to know before the downstream process runs on stale data.

Here are the three ways teams actually build it, in both directions: a script on a relay machine, an SFTP endpoint in front of the bucket, and Files.com connecting the bucket and the partner's SFTP server directly so nothing runs in the middle at all.

Which one fits depends mostly on who operates the SFTP endpoint and how much transfer infrastructure you want to own.

A script through a relay machine

Most S3-to-SFTP workflows begin as a script that downloads from S3 to a machine and uploads from that machine over SFTP. With the AWS CLI and the OpenSSH client, the basic flow is two commands and a batch file:

aws s3 cp s3://brightway-exports/orders/2026-08-03.csv /tmp/orders.csv

cat > /tmp/upload.sftp <<'SFTP'
put /tmp/orders.csv /inbound/orders-2026-08-03.csv.tmp
rename /inbound/orders-2026-08-03.csv.tmp /inbound/orders-2026-08-03.csv
bye
SFTP

sftp -b /tmp/upload.sftp -i /etc/sftp/keys/brightway_ed25519 \
     -o BatchMode=yes -o StrictHostKeyChecking=yes alice@sftp.example.com

The other direction reverses the sequence: get in the batch file, then aws s3 cp up to the bucket. In Python the same job is boto3 on one side and paramiko on the other, and the Python SFTP walkthrough covers the paramiko half.

Scripts are quick to build, easy to read, and cheap when a suitable machine already exists. For one partner, one file, and one direction, this may be all you need.

The cost shows up when the script has to become a reliable service. The relay machine needs disk for the largest file you will ever move, plus a cleanup step you will forget once. It holds two sets of credentials, an AWS key or role for the bucket and an SSH key for the partner.

S3 failures and SFTP failures need separate retries. A half-uploaded file looks complete to the partner unless you upload under a temporary name and rename, which the batch file above does. The host key needs verifying rather than auto-accepting.

Someone has to be told when the job fails, and separately when the source file never showed up. And the machine itself is now infrastructure: patched, monitored, and owned by a team.

None of that is hard on its own. Together it turns two commands into a transfer system.

An SFTP endpoint in front of the bucket

When the partner is willing to connect to an SFTP server you provide, the cleaner shape is an SFTP folder whose storage is the bucket. The partner uploads over SFTP, and the object appears in S3 with nothing in the middle. In the other direction, the partner browses the SFTP folder and downloads files that live in S3.

The self-managed version is an SFTP server on an EC2 instance connected to the bucket through a sync process, a gateway, or a FUSE-style mount. That gives you control, and it leaves you responsible for patching and availability, SFTP users and keys, sync reliability, logging and alerts, and capacity.

Files.com provides the same pattern as a service. A Remote Server Mount connects a folder on your Files.com site to your S3 bucket in real time: every upload, download, rename, and delete in that folder passes through to the bucket as it happens, and Files.com keeps no copy.

Create an SFTP user scoped to that folder and the partner sees a conventional SFTP server while the files land as objects in your bucket.

Files.com authenticates to AWS with an access key and secret, or with AWS STS role assumption for temporary credentials, and in either case the IAM policy is scoped to the bucket and prefix the exchange needs.

This shape works when partners connect to you. It does not help when the partner insists that you connect to a server they operate.

Connect the bucket and the partner's SFTP server directly

Banks, payment processors, healthcare providers, and large vendors often run their own SFTP servers. They hand you credentials and expect you to deliver files to them or collect files from them. That requirement is what usually brings the relay machine back. It does not have to.

Mount both ends

Files.com can mount the partner's SFTP server the same way it mounts your bucket. You give it the partner's hostname, port, and credentials, and the partner's server becomes a second folder, say /partners/brightway, next to the bucket mount at /cloud-storage/orders.

Files.com authenticates to the partner with a password, a private key, or both, and it can generate the key pair itself (RSA, 4096-bit) so you hand the partner a public key and the private half never leaves Files.com.

It detects and stores the partner's host key on the first connection and disables the connection if that key ever changes, which is the man-in-the-middle protection a hand-written script skips when it auto-accepts host keys. The partner's only job is to allowlist the Files.com IP addresses.

Move files with a scheduled Sync

With both ends as folders on one site, a Files.com Sync moves files between them on a schedule. A Sync's source and destination can each be any supported location, including two remote servers, so bucket-to-partner and partner-to-bucket are each one Sync with its own schedule and include and exclude filters, and a dry run shows what a Sync would do before it moves anything.

Files.com retries failures, logs every run and every file, emails administrators when a run fails, and keeps one audit trail for both directions.

On object-storage sources, a Sync also checks whether a file changed while the run was in progress and skips it until the next run, recording the skip in the log, so an object still being written never goes out half-finished.

The practical gain is not that the transfer works. The script worked too. It is that there is no relay host, no staging disk, no second set of credentials on a machine, no hand-written retry loop, and no separate monitoring process to keep alive.

React when a file arrives

A scheduled Sync fits files that move at predictable times. When the partner drops files on their own server and you want to react rather than wait for the next run, turn on the Remote Metadata Index for the mount.

Files.com scans the mount on the interval you set, as often as every few minutes on the higher plans, records new and removed files as actions, and Automations trigger on those actions.

When a file arrives from the partner, an automation copies it into the bucket mount, renames it to your convention, and notifies the pipeline that consumes it. Discovery is still interval-based, and everything after it is automatic.

Alert when a file does not arrive

A failed transfer produces an error. A missing source file produces nothing, because no transfer was ever attempted. Suppose a partner owes you a settlement file by 6:00 a.m. and it never comes.

Files.com Expectations let you declare when a file is due in a folder, and when the deadline passes without it, Files.com raises an alert. The missing file becomes a notification at 6:05, not a discovery when the downstream import runs on stale data hours later.

Add code only where you need it

Managed transfers do not shut out your own logic. The Files.com CLI and SDKs talk to Files.com over HTTPS with an API key, and an upload into either mount does what the Sync does:

files-cli upload /data/exports/report.csv /partners/brightway/inbound/report.csv

Your code still validates records, transforms filenames, or makes routing decisions. It no longer implements SFTP connection handling, retries, and transfer logging. For the bucket mount, Files.com Direct Routing sends the file data straight between the CLI or SDK and S3 rather than through the Files.com network, and that traffic is not billed as transfer usage.

Which way

The script is fine for one or two simple workflows at low volume, on a machine you already operate, when a local staging copy is acceptable and the team is comfortable owning retries, monitoring, and credentials.

An SFTP endpoint in front of the bucket is the answer when partners connect to you and you want their uploads to land in S3, each partner confined to its own folder or prefix.

Two mounts and a Sync is the answer when the partner runs the SFTP server, when files move in both directions, when several partners are involved, or when you want the relay machine and its staging disk gone, because adding a partner becomes adding a mount, not provisioning a server.

The SFTP automation guide covers the scripted version in depth for the cases where it is the right call.

When the relay machine stops being the right answer

Relay machines appear gradually. A team writes one script, then adds another partner, another schedule, another credential, another alert, and the "temporary" server becomes critical infrastructure. The question is not whether the script can move a file. It can. The question is whether your team wants to keep operating the system around it.

Files.com is the cloud-native File Orchestration Platform: one platform that replaces the stack of legacy tools IT teams run to move files, including the SFTP servers, the sync scripts, and the relay machines holding it all together. It speaks every protocol, connects 50+ cloud and on-prem systems, automates every transfer, and keeps a complete audit trail.

For the transfer in this post, that means the bucket and the partner's SFTP server are two folders on one site, a Sync moves files between them with retries and a record, Automations react to arrivals, and Expectations watch for the file that does not come.

If the SFTP side has to stay in your own data center, the ExaVault appliance is a free SFTP server for up to 50 users, and Files.com mounts it like any other remote server.

Start a free Files.com trial, mount your bucket, and connect the partner. No credit card required, and both mounts are live in minutes.

Frequently asked questions

How do I transfer files from S3 to an SFTP server?

Three ways. Script it with the AWS CLI and the OpenSSH sftp client through a relay machine. Or, on Files.com, mount the S3 bucket and the partner's SFTP server as two folders on one site and let a scheduled Sync move files between them, with no code, no staging disk, retries, and one audit trail.

How do I get SFTP uploads into S3?

Put an SFTP endpoint in front of the bucket. On Files.com, a Remote Server Mount connects a folder to your bucket in real time. Give the partner an SFTP login scoped to that folder and their uploads become objects in S3 as they arrive.

Can Files.com connect to a partner's existing SFTP server?

Yes. A Remote Server Mount connects to any SFTP server with a password, a private key Files.com can generate for you, or both. Files.com pins the server's host key, disables the connection if that key changes, and passes every operation in the mounted folder through in real time. The partner allowlists the Files.com IP addresses once.

How does Files.com authenticate to Amazon S3?

With an AWS access key and secret, or by assuming an IAM role through AWS STS for temporary credentials. Either way, scope the IAM permissions to the bucket and prefix the exchange needs.

What happens if a file changes while a Sync is running?

On S3, Azure Blob, and Google Cloud Storage sources, the Sync checks whether a file changed during the run and skips it until the next run, so a partially written object never goes out. The skip is recorded in the Sync log.

How do I know when a partner's file does not arrive?

Set a Files.com Expectation on the folder with the time the file is due. When the deadline passes without it, Files.com raises an alert, so the miss surfaces before the downstream import runs on stale data.