SFTP to S3, automatically

The classic way to land partner files in S3 is to stand up an SFTP server, write incoming files to a disk somewhere, then poll that directory with a cron job or Lambda that copies each file into a bucket and deletes the original. That is three moving parts to patch, monitor and secure — and a window where unencrypted files sit on a volume. FTPasHTTPS collapses the whole pipeline into one streaming hop.

How SFTP-to-S3 forwarding works

1. A client connects over SFTP, FTPS or FTP and runs a STOR (upload) command.
2. FTPasHTTPS opens an S3 PutObject request to your bucket and streams the incoming bytes straight into its body.
3. The object key is templated from the filename, username and timestamp, so uploads land in a predictable prefix.
4. When S3 returns 200, the client receives 226 Transfer complete. A 5xx from S3 maps to 451 Action aborted so the client knows to retry.
5. Every transfer is written to the audit log; failures retry with exponential backoff and fall back to a dead-letter queue.

Configuration + example

An S3 forward target on a server is just a small JSON config. You supply the bucket, region and an IAM credential scoped to s3:PutObject on that prefix only:

# S3 forward target for an SFTP server
{
  "protocol": "sftp",
  "auth": { "type": "ssh-key" },
  "forward": {
    "type": "s3",
    "bucket": "acme-partner-dropbox",
    "region": "eu-west-1",
    "keyTemplate": "inbound/{username}/{date}/{filename}",
    "credentials": {
      "accessKeyId": "${AWS_ACCESS_KEY_ID}",
      "secretAccessKey": "${AWS_SECRET_ACCESS_KEY}"
    },
    "storageClass": "STANDARD_IA"
  }
}

A vendor then uploads exactly as they always have — nothing changes on their side:

# Vendor uploads over SFTP; the file lands in S3
sftp -i partner_key [email protected]
sftp> put orders-2026-06-20.csv
Uploading orders-2026-06-20.csv  100%   42KB
226 Transfer complete

# Object now exists at:
# s3://acme-partner-dropbox/inbound/vendor/2026-06-20/orders-2026-06-20.csv

FTPasHTTPS vs. the DIY SFTP + cron pipeline

Concern	DIY SFTP server + cron + script	FTPasHTTPS → S3
Files on disk	Written to a volume, then deleted	Never touch disk — streamed
Moving parts	SFTP daemon + cron/Lambda + copy script	One streaming forward
Latency to S3	Up to the cron interval (minutes)	Streams during the upload
Retries on S3 error	Hand-rolled, often missing	Exponential backoff + dead-letter queue
Audit trail	Scattered across syslog	Full audit log per transfer
Patching & uptime	You own the OS and daemon	Managed for you
Protocols	Usually SFTP only	FTP, FTPS and SFTP

When to use it (and the limits)

Reach for FTPasHTTPS-to-S3 when partners insist on SFTP or FTP but your stack lives in object storage, when you want files in a bucket the moment they arrive, or when you would rather not own an internet-facing SFTP daemon. S3 forwarding (and the transformation features) is available from the Professional plan up; the Free tier is FTP-only and ideal for proving the flow before you wire in production credentials.

A few limits to keep in mind: forwarding is per-file at upload time, so this is not a tool for batch re-syncing an existing bucket. Object keys are derived from the upload, not arbitrary client paths. And throughput is bounded by your plan's monthly transfer and size caps — 10,000 transfers / 50GB on Professional, 50,000 / 250GB on Enterprise.

Object keys, prefixes and downstream triggers

Because the object key is templated, you decide exactly how uploads are organised in the bucket. A template like inbound/{username}/{date}/{filename} partitions every partner into their own prefix and every day into its own folder, which keeps lifecycle rules, IAM policies and downstream consumers simple. Scope the IAM credential to s3:PutObject on that single prefix and a leaked key can do nothing but write where it was already allowed to write.

Once the object lands, the rest of your pipeline behaves exactly as it would for any other S3 write — S3 event notifications, EventBridge rules or a Glue crawler can all fire off the new object. If you prefer not to depend on S3 events at all, attach a webhook to the same forward so your application is notified directly the instant the upload completes, with the object key and partner identity included. Either way, the audit log gives you a single place to answer the only question that matters during an incident: did the file arrive, and when?

Frequently asked questions