Self-Hosted SFTP with S3, Azure, SharePoint or Google Cloud Storage Backend

Q: Can I use S3 as the storage for my own SFTP server?

Yes. You do not have to use a managed cloud SFTP service to get files into a bucket. A self-hosted server can mount a bucket as a folder in its own virtual file system, so a user who connects over SFTP sees an ordinary directory while the bytes are written to and read from the bucket. CompleteFTP Enterprise MFT does this with its Amazon S3 folder type, which also supports non-AWS S3-compatible services such as Wasabi and MinIO.

Q: How do I mount Azure storage as an SFTP folder?

In CompleteFTP Enterprise MFT, the Azure Share folder type mounts a share from the File service of an Azure storage account. On the Folders tab, choose New root folder or New sub-folder, select Azure Share folder, then enter the storage account name, an access key and the share name, with an optional directory inside the share. A raw Azure File connection string containing AccountName and AccountKey can be supplied instead.

Q: Is s3fs production-ready for an SFTP server?

It works, and plenty of people run it, but it presents an object store through a POSIX filesystem interface that the object store does not natively provide. Renames, directory listings, partial writes and metadata operations behave differently from local disk, and failures surface as filesystem errors that the SFTP server reports without context. A server that talks to the storage API directly can report and log the underlying condition instead.

Q: What is the latency of cloud-backed SFTP?

It depends on the distance and bandwidth between your server and the storage region, and it is always higher than local disk. The effect is largest on directory listings and small-file operations, where each action becomes a separate request over the network. Bulk transfers of large files are affected less, because throughput between the server and the storage service tends to dominate rather than per-request overhead.

AWS Transfer Family, the managed SFTP endpoint AWS runs in front of your buckets, is the usual answer to the question of how to put SFTP and S3 together. It solves a different problem from the one many people are asking about. They already run an SFTP server, with users, keys, folder permissions, event triggers and an audit trail that partners and auditors depend on. What they want to change is the storage underneath, not the endpoint their partners connect to.

The same mismatch appears when the storage is not AWS at all. If your files belong in an Azure storage account, a SharePoint document library or a Google Cloud Storage bucket, an AWS-hosted SFTP endpoint is not a candidate. The question underneath is architectural: how do you keep the SFTP experience your partners already have while the bytes live in cloud storage that somebody else operates?

Managed endpoint or your own server

The case for keeping your own SFTP server

Two situations sit behind this question and pull in opposite directions: an organisation that already runs an SFTP server with partners connected to it, and one starting from nothing.

Whether keeping your own SFTP server is worth the effort depends mostly on how much history it already carries. A server that has been running for a few years is rarely just an SFTP server: it holds the accumulated shape of how an organisation exchanges files, which partner lands in which directory, which upload fires which downstream process, and what the log looks like when someone asks who took a file on the fourteenth. Moving that to a managed endpoint means rebuilding it in a different system and re-issuing connection details to every partner, and the partner-side change is the expensive part.

A greenfield deployment has none of that to preserve. Inside a single cloud, with no partners already connecting and no downstream processes wired to particular folders, a managed endpoint is a reasonable answer, and most of the arguments in this article carry little weight. The case for running your own server grows with the amount of working arrangement already built around it.

There is also the question of where the server is allowed to run. Many file transfer servers sit inside a corporate network on a machine subject to a specific set of controls, and pushing only the storage out to a cloud provider is a smaller change to justify than moving the whole endpoint.

The case for cloud storage as the backend

The pull in the other direction is usually capacity and durability. Local disk fills up, and expanding it is a scheduled outage on a machine that partners connect to at all hours. Object storage grows without anyone touching the server, and the provider handles replication.

The other common driver is that the data is already going somewhere else. If the files a partner uploads are read by an analytics job that expects them in a bucket, or by a team that works in a SharePoint library, then landing them there directly removes a copy step and the failure modes that come with it.

Cloud-backed folders are in routine production use rather than being a theoretical option:

"We have been connecting Azure shares as home folders for users."

an Australian B2B software organization (EnterpriseDT support archive)

When the managed service is the better answer

For a greenfield deployment entirely inside one cloud, with no existing server and no partner base to migrate, the managed option removes work. The picture changes as soon as more than one provider is involved, or the server has to live somewhere specific, or the platform is doing work beyond moving bytes. Scheduled transfers, PGP handling, protocol translation and per-partner folder structures are the reasons people keep a full file transfer server. Our MFT versus SFTP guide works through where that line usually falls.

Four ways to put cloud storage behind an SFTP server

Cloud storage mounted per folder

The server keeps its own virtual file system, and individual folders within it are backed by cloud storage rather than local disk. A partner's upload directory can point at a bucket while the neighbouring directory points at a local path, and the user connecting over SFTP cannot tell the difference from the listing. Credentials, region, bucket and path become properties of the folder, and because the server talks to the storage service's own API, failures arrive as storage-service errors it can log with context.

Cloud storage as an archive tier behind local disk

Active transfers land on local disk, where reads and writes are fast and directory listings are instant, and a scheduled job moves files older than some threshold into cloud storage. Partners get local-disk responsiveness for recent files, and long-term retention costs whatever the object store costs.

The mechanism is a scheduled job that moves files from the local folder into the mounted cloud folder once they pass an age threshold. Where the server's own automation can see both folders as part of one file system, that move is a single file operation rather than an external tool juggling two sets of credentials.

Mounting the bucket on the operating system with s3fs or blobfuse

A FUSE driver such as s3fs or blobfuse mounts the bucket or container as a drive on the server's operating system, and the SFTP server is pointed at that mount as if it were an ordinary local directory. No support from the file transfer software is required, which is why the approach is so widely suggested.

The cost is that a FUSE layer presents an object store through a POSIX interface the object store does not actually implement. Renames become copy-then-delete, directory listings become key enumerations, and when something fails the SFTP server sees a filesystem error carrying no information about what the storage service said.

A gateway folder to the provider's own SFTP endpoint

A gateway folder mounts a directory from another FTP, FTPS or SFTP server, so a user logged in over one protocol reaches files held on a server speaking another. It is an Enterprise MFT feature, and the gateway folders documentation describes both the shared-connection and fixed-credential modes.

Several providers now put an SFTP endpoint in front of their own object storage, and a gateway folder can be pointed straight at it. Customers use it that way. Pointing a gateway folder at the provider's endpoint reaches the data without the server needing native support for that storage service:

"I have setup a gateway folder to an SFTP destination (that is an Azure Blob with SFTP). When trying to connect (from Filezilla or similar) I receive the error attached."

a UK financial services organization (EnterpriseDT support archive)

One design consequence is worth planning for: the provider's network rules then apply to your server's address rather than the end user's, so a storage-account allowlist covering an administrator's own machine will not cover the file transfer server. Where a native folder type exists for the storage in question, it talks to the storage API directly and avoids the second hop entirely.

Choosing between them

If the file transfer server supports the storage backend natively, use that. Reach for the FUSE mount when it does not, or when the deployment is small enough that the operational overhead never surfaces. Use the archive tier when interactive performance on recent files matters more than uniformity, and a gateway folder when the provider offers an SFTP endpoint and no native folder type exists for it.

How cloud folders work in CompleteFTP Enterprise MFT

The cloud backends are additional folder types in CompleteFTP's virtual file system, alongside Windows folders, network folders and virtual folders. All of them require the Enterprise MFT edition. Every one is added the same way: on the Folders tab, choose New root folder or New sub-folder, pick the folder type from the menu, and fill in the configuration dialog for that backend.

Amazon S3 and S3-compatible storage

The Amazon S3 Folder type mounts a bucket, or a directory within a bucket, into the virtual file system. A radio button at the top of the configuration dialog chooses between Amazon S3 and Non-AWS S3-compatible storage.

For Amazon S3 you supply the region, an access key ID, a secret access key, the bucket name, and optionally a directory inside the bucket; leaving the directory blank mounts the root. Access can also be granted without any key material, because an IAM role attached to the EC2 instance CompleteFTP runs on can be granted access to the bucket, in which case both key fields are left blank. For non-AWS services implementing the S3 API, the documentation names Wasabi and MinIO as examples, you supply the service URL instead of a region.

Two things are worth knowing before you commit to the design. The first is that object storage does not supply directory timestamps, so folder dates arrive wrong unless the server is asked to calculate them, which is covered under "Object stores do not have directories" below. The second is that a server with no route to the public internet needs a network endpoint configured before it can reach the bucket at all. Both are settings rather than obstacles, and the Amazon S3 folders documentation has the screenshots.

Azure Files shares

The Azure folder type mounts a share from the File service of an Azure storage account, not a Blob container. Configuration asks for the storage account name, one of the account's access keys, and the share name, with an optional directory inside the share. A raw Azure File connection string containing AccountName and AccountKey attributes can be entered instead.

The distinction matters to your design, because Azure Files and Azure Blob are different services and data in one is not reachable as though it were in the other. If your files already sit in Blob containers, you either move them to a file share, reach the container another way, or check the current position with support before committing. The Azure folders documentation covers what is supported.

SharePoint and OneDrive

SharePoint document libraries and OneDrive for Business storage can be mounted as virtual folders through the Microsoft Graph API, so users reach Microsoft 365 content over FTP, FTPS, SFTP or HTTP like any other folder.

The prerequisite is an application registered in Azure Active Directory, granted the relevant Microsoft Graph permissions with administrator consent. That registration is the part worth planning, because it usually needs somebody with tenant-level rights rather than the file transfer administrator, and it is where this integration stalls when it stalls.

You then choose the target. A SharePoint Site target needs the full site URL and the name of the document library, which defaults to Documents, while a User's OneDrive target needs the user principal name. Either accepts an optional root path so that only a subdirectory is mounted. Certificate-based authentication, Teams channel access and direct drive ID configuration are supported but not exposed in the user interface, and are available through support.

Google Cloud Storage

GCS buckets mount in the same manner, given a Google Cloud project with Cloud Storage enabled, an existing bucket, and a service account with a JSON key file. Configuration is short: paste the entire contents of the key file into the Service Account JSON field, and enter the bucket name. On the Google side the service account is typically granted Storage Object Admin for read/write access or Storage Object Viewer for read-only. The bucket has to exist first, because CompleteFTP does not create buckets.

What the end user sees

Nothing. A partner connecting with WinSCP, FileZilla or a scripted client gets a directory listing, changes directory, uploads and downloads. Permissions, quotas, IP restrictions and event triggers apply to a cloud-backed folder as they do to a local one, and a folder backed by a SharePoint library is equally reachable over FTP, FTPS, SFTP, SCP and the web file manager, which is often the point of the exercise.

Performance and cost

Latency and the mismatch between two connections

A cloud-backed folder puts a network hop between the SFTP server and the bytes, and that hop is slower and more variable than a local disk read. Both the S3 and SharePoint documentation flag the same failure mode: clients may experience timeouts when the connection between the client and CompleteFTP is faster than the connection between CompleteFTP and the storage service. Look at the server-to-storage path as carefully as the client-to-server path, and place the server in the same region as the storage where you have the choice.

Object stores do not have directories

Object storage does not have folders at all. It stores objects under keys, and the directory tree an SFTP client appears to browse is inferred from the slashes in those key names. By default nothing in the store holds a record of a folder, which means nothing holds a date for one either, and that is why folder timestamps come back as an obviously wrong placeholder rather than a real date. Some tools do create special marker objects that store directory information such as timestamps, but that is a convention rather than part of the storage model, and it is not always present. Asking the server to calculate accurate folder dates fixes the display but costs time on every listing, because the answer has to be assembled from the objects underneath.

One customer reported both halves of that trade-off at once:

"We configured one of our Amazon S3 Folders to enable Accurate folder timestamps and it doesn't appear to be working. It slows down the listing of folders at the main level, but the timestamps are all incorrect. In Filezilla they show up as 1/18/2038 and with WinSCP they show up as 1/1/1900."

a US media and publishing organization (EnterpriseDT support archive)

The same absence explains the rest of the behaviour. Operations that are trivial on a filesystem, such as listing a directory, renaming a folder, or checking metadata across many files, become sequences of API requests whose cost scales with the number of objects involved. Workloads with tens of thousands of small files in one directory feel that immediately.

Egress and request costs

Cloud storage billing has two components that matter to a file transfer workload: charges for data leaving the provider's network, and charges for API requests. An SFTP server outside the provider's network pays the first on every download, because each file a partner retrieves is read out of the storage service and across to the server. A server inside the same cloud and region as the bucket usually avoids most of it.

Request-level charges scale with operations rather than bytes, which is what catches people out: a monitoring script that lists a directory every minute generates requests all day regardless of whether any data moves. Rates differ by provider and change over time, so price the pattern you expect against your provider's current schedule.

Where a local tier helps

If the latency characteristics do not suit a partner-facing directory, the archive-tier pattern gives a middle position. Recent files sit on local disk, older files move to the bucket on a schedule, and both are visible in the same virtual file system under different paths.

Operational concerns

Credentials for the cloud account

Each backend has its own credential, and each is a standing grant of access to storage that may hold more than the file transfer server needs. Scope them accordingly: an IAM policy limited to one bucket and prefix, a GCS service account with a storage role on one bucket rather than project-wide rights, an Azure AD app registration whose Graph permissions match the libraries actually being mounted.

The two to treat most carefully are the GCS service account JSON, a complete key in one file, and the Azure storage account access key, which grants access to the whole storage account rather than the single share. Where a role-based option exists, as it does for S3 on an EC2 instance, prefer it. Rotation belongs in the runbook, since changing a key on the provider side without updating the folder configuration takes the folder offline for every user mounted on it.

Encryption at rest does not follow the file into the bucket

CompleteFTP's encryption-at-rest feature encrypts files with AES as they are written onto the server's file system, transparently to the user. The documentation states plainly, for every cloud backend, that files stored in those folders are not automatically encrypted by that feature.

Encryption of data sitting in the bucket is therefore the storage provider's server-side encryption, managed with the provider's keys. If your requirement is that the storage operator cannot read the content, the answer is to encrypt before the file reaches the bucket. CompleteFTP's PGP support can do that from a JSS trigger on upload, using a public key whose private half never goes near the storage account. Our article on encryption at rest for SFTP works through the distinction.

What happens during a provider outage

A cloud-backed folder is unavailable when the storage service is unavailable, and there is no local copy to fall back on. The SFTP server itself stays up, other folders keep working, and users mounted on the affected folder get errors. For a partner-facing directory this needs a decision made in advance rather than during the incident: does the partner retry, does the upload divert to a local folder, or does the transfer fail and get chased?

Audit trail across the gap

Server-side logging records what happened at the SFTP layer, and that record does not change because the folder is cloud-backed. What it does not cover is access to the same data through the storage provider's own interfaces, because anyone with credentials on the bucket, the file share or the SharePoint library can read and write objects without touching your server. A complete audit position therefore has two halves, and the compliance question is usually whether anyone has arranged to keep and review the second one. Our SFTP audit log guide covers the server side.

Configuring one

Each backend is a folder type with its own configuration dialog, and the steps are short enough that the documentation is the better place for them: Amazon S3, Azure Files and gateway folders. What is worth deciding before you open the dialog is how the server will authenticate: a role attached to the instance where the provider supports it, otherwise a key scoped to the one bucket or share rather than the whole account.

Frequently asked questions

Can I use S3 as the storage for my own SFTP server?

Yes. A self-hosted server can mount a bucket as a folder in its own virtual file system, so a user connecting over SFTP sees an ordinary directory while the bytes live in the bucket. CompleteFTP Enterprise MFT does this with its Amazon S3 folder type, which also covers non-AWS S3-compatible services such as Wasabi and MinIO.

What is the difference between AWS Transfer Family and my own SFTP server with an S3 backend?

The managed service runs the SFTP endpoint for you inside AWS and is billed by AWS. A self-hosted server runs on a machine you control, on any network, and can mount storage from more than one provider at once. The self-hosted route keeps your existing users, keys, permissions, triggers and audit configuration in place.

How do I mount Azure storage as an SFTP folder?

Use the Azure Share folder type, which mounts a share from the File service of an Azure storage account. On the Folders tab choose New root folder or New sub-folder, select Azure Share folder, and enter the storage account name, an access key and the share name.

Can SharePoint be used as SFTP storage?

Yes. CompleteFTP Enterprise MFT mounts SharePoint document libraries and OneDrive for Business storage through the Microsoft Graph API. You register an application in Azure Active Directory, grant it Files.ReadWrite.All or Sites.ReadWrite.All as application permissions with admin consent, then configure the folder with the tenant ID, client ID and client secret.

Is s3fs production-ready?

It works and it is widely used, with the caveat that it presents an object store through a POSIX filesystem interface the object store does not natively provide. Renames, listings and metadata operations behave differently from local disk, and failures reach the SFTP server as filesystem errors stripped of the storage service's own explanation.

What is the latency of cloud-backed SFTP?

Higher than local disk, by an amount that depends on the distance and bandwidth between your server and the storage region. Directory listings and small-file operations feel it most, because each becomes a separate request across the network. Large-file transfers are affected less.

Which CompleteFTP edition do I need?

Enterprise MFT. The Amazon S3, Azure Share, SharePoint/OneDrive, Google Cloud Storage and gateway folder types are all Enterprise MFT features. Standard and Professional editions mount Windows folders, Windows special folders, network folders and virtual folders.

Trying it against your own storage

The configuration for a cloud-backed folder is short enough that the useful test is an empirical one. Install the trial, which runs as Enterprise MFT, mount a bucket or share you already have, and connect with the same client one of your partners uses. Twenty minutes of that shows how the listing behaves from where your users sit, and how a large upload behaves across your particular path to the storage region.

CompleteFTP Enterprise MFT includes all four cloud backends, gateway folders for protocol translation, scheduled and event-driven triggers for the archive-tier pattern, and the audit logging that sits alongside all of it. The CompleteFTP MFT page covers the edition, and the SFTP server guide covers the server itself.