General

Q: What is AWS Transfer Family?

A: The AWS Transfer Family is the aggregated name of AWS Transfer for SFTP, AWS Transfer for FTPS, and AWS Transfer for FTP. The AWS Transfer Family offers fully managed support for the transfer of files over SFTP, FTPS, and FTP directly into and out of Amazon S3. You can seamlessly migrate your file transfer workflows by maintaining existing client-side configurations for authentication, access, and firewalls — so nothing changes for your customers, partners, and internal teams, or their applications.

Q: What is SFTP?

A: SFTP stands for Secure Shell (SSH) File Transfer Protocol, a network protocol used for secure transfer of data over the internet. The protocol supports the full security and authentication functionality of SSH, and is widely used to exchange data between business partners in a variety of industries including financial services, healthcare, media and entertainment, retail, advertising, and more.

Q: What is FTP?

A: FTP stands for File Transfer Protocol, a network protocol used for the transfer of data. FTP uses a separate channel for control and data transfers. The control channel is open until terminated or inactivity timeout, the data channel is active for the duration of the transfer. FTP uses cleartext and does not support encryption of traffic.

Q: What is FTPS?

A: FTPS stands for File Transfer Protocol over SSL, and is an extension to FTP. It uses Transport Layer Security (TLS) and Secure Sockets Layer (SSL) cryptographic protocols to encrypt traffic. FTPS allows encryption of both the control and data channel connections either concurrently or independently.

Q: Why should I use the AWS Transfer Family?

A: Today, if you are using file transfer protocols such as SFTP, FTPS or FTP to exchange data with third parties such as vendors, business partners, or customers, and want to manage that data in AWS for processing, analytics, and archival, you have to host and manage your own file transfer service. This requires you to invest in operating and managing infrastructure, patching servers, monitoring for uptime and availability, and building one-off mechanisms to provision users and audit their activity. The AWS Transfer Family solves these challenges by providing fully managed support for SFTP, FTPS, and FTP that can reduce your operational burden, while preserving your existing transfer workflows for your end users. The service stores transferred files as objects in your Amazon S3 bucket, so you can extract value from them in your data lake, or for your Customer Relationship Management (CRM) or Enterprise Resource Planning (ERP) workflows, or for archiving in AWS.

Q: What are the benefits of using the AWS Transfer Family?

A: The AWS Transfer Family provides you with a fully managed, highly available file transfer service with auto-scaling capabilities, eliminating the need for you to manage file transfer related infrastructure. Your end users’ workflows remain unchanged, while data uploaded and downloaded over the chosen protocols is stored in your Amazon S3 bucket. With the data in Amazon S3, you can now easily use it with the broad array of AWS services for data processing, analytics, machine learning, and archival, in an environment that can meet your compliance requirements.

Q: How do I use the AWS Transfer Family?

A: In 3 simple steps, you get an always-on server endpoint enabled for SFTP, FTPS, and/or FTP. First, you select the protocol(s) you want to enable your end users to connect to your endpoint. Next, you set up your users by integrating an existing identity provider like Microsoft Active Directory or LDAP for authentication (“BYO” authentication). Finally, you assign IAM Roles to provide access to your S3 buckets. Once the protocol(s), identity provider, and S3 bucket access policies are enabled, your users can continue to use their existing clients and configurations, while the data accessed is stored in your S3 bucket.

Q: What is the difference between SFTP and FTPS? Which should I use when?

A: FTPS and SFTP can both be used for secure transfers. Since they are different protocols, they use different clients and technologies to offer a secure tunnel for transmission of commands and data. SFTP is a newer protocol and uses a single channel for commands and data, requiring fewer port openings than FTPS.

Q: Can my users use SCP, HTTPS or AS2, to transfer files using this service?

A: No, your users will need to use SFTP, FTPS, or FTP to transfer files. Most file transfer clients offer either of these protocols as an option that will need to be selected during authentication.

Q: Can my users continue to use their existing file transfer clients and applications?

A: Yes, any existing file transfer client application will continue to work as long as you have enabled your endpoint for the chosen protocols. Examples of commonly used clients include WinSCP, FileZilla, CyberDuck, lftp, and OpenSSH clients. 

Q: Can I use CloudFormation to automate deployment of my servers and users?

A: Yes, you can deploy CloudFormation templates to automate creation of your servers and users or for integrating an identity provider. Refer to the usage guide for using AWS Transfer resources in CloudFormation templates.

Server endpoint options

Q: Can I use my corporate domain name (sftp.mycompanyname.com) to access my endpoint?

A: Yes. If you already have a domain name, you can use Amazon Route 53 or any DNS service to route your users’ traffic from your registered domain to the server endpoint in AWS. Refer to the documentation on how the AWS Transfer Family uses Amazon Route 53 for custom domain names (applicable to internet facing endpoints only).

Q: Can I still use the service if I don’t have a domain name?

A: Yes, if you don’t have a domain name, your users can access your endpoint using the hostname provided by the service. Alternatively, you can register a new domain using the Amazon Route 53 console or API, and route traffic from this domain to the service supplied endpoint hostname.

Q: Can I use my domain that already has a public zone?

A: Yes, you will need to CNAME the domain to the service supplied endpoint hostname.

Q: Can I set up my server to be accessible to resources only within my VPC?

A: Yes. When you create a server or update an existing one, you have the option to specify whether you want the endpoint to be accessible over the public internet or hosted within your VPC. By using a VPC hosted endpoint for your server, you can restrict it to be accessible only to clients within the same VPC, other VPCs you specify, or in on-premises environments using networking technologies that extend your VPC such as AWS Direct Connect, AWS VPN, or VPC peering. You can further restrict access to resources in specific subnets within your VPC using subnet Network Access Control Lists (NACLs) or endpoint Security Groups. Refer to the documentation on creating your server endpoint inside your VPC using AWS PrivateLink for details.

Q: Can I use FTP with an internet facing endpoint?

No, when you enable FTP, you will only be able to use VPC hosted endpoint‘s internal access option. If traffic needs to traverse the public network, secure protocols such as SFTP or FTPS should be used.

Q: What if I need to use FTP for transfers over the public internet?

The service doesn’t allow you to use FTP over public networks because, when you create a server enabled for FTP, the server endpoint is only accessible to resources within your VPC . If you need to use FTP for exchanging data over the public internet, you can front your server’s VPC endpoint with an internet-facing Network Load Balancer (NLB).

Q: Can I use FTP without a VPC?

No. VPC is required to host FTP server endpoints. Please refer to the documentation for CloudFormation templates to automate creation of VPC resources to host the endpoint during server creation.

Q: Can my end users use fixed IP addresses to whitelist access to my server’s endpoint in their firewalls?

A: Yes. You can enable fixed IPs for your server endpoint by selecting the VPC hosted endpoint for your server and choosing the internet-facing option. This will allow you to attach Elastic IPs (including BYO IPs) directly to the endpoint, which is assigned as the endpoint’s IP address. Refer to the section on creating an internet facing endpoint in the documentation: Creating your server endpoint inside your VPC.

Q: Can I restrict incoming traffic by end users’ source IP addresses?

A: Yes. You can attach Security Groups to your server’s VPC endpoint which will control inbound traffic to your server. Refer to the section on Creating an internet facing endpoint in the documentation: Creating your server endpoint inside your VPC.

Q: Can my end users use fixed IP addresses to access my server whose endpoint type is PUBLIC?

A: No. Fixed IP addresses that are usually used for firewall whitelisting purposes are currently not supported on the PUBLIC Endpoint type.

Q: What IP ranges would my end users need to whitelist to access my SFTP server’s endpoint type that is PUBLIC?

A: If you are using the PUBLIC endpoint type, your users will need to whitelist the AWS IP address ranges published here. Refer to the documentation for details on staying up to date with AWS IP Address Ranges.

Q: Q: Will my AWS Transfer for SFTP server's host key ever change after I create the server?

A: No. The server’s host key that is assigned when you create the server remains the same, until you delete and create a new one.

Q: Can I import keys from my current SFTP server so my users do not have to reverify the session information?

A: Yes. You can provide a RSA host key when you create a new server, or update an existing one. This key will be used by your end users’ clients to identify your server. Refer to the documentation on using the AWS CLI/SDKs for uploading a Host Key for your server.

Q: How do my end users’ FTPS clients verify the identity of my FTPS server?

A: When you enable FTPS access, you will need to supply a certificate from Amazon Certificate Manager (ACM). This certificate is used by your end user clients to verify the identity of your FTPS server. Refer to the ACM documentation on Requesting New certificates or importing existing certificates into ACM.

Q: Do you support active and passive modes of FTPS and FTP?

A: We only support passive mode, which allows your end users’ clients to initiate connections with your server. Passive mode requires fewer port openings on the client side, making your server endpoint more compatible with end users behind protected firewalls.

Q: Do you support Explicit and Implicit FTPS modes?

A: We only support explicit FTPS mode.

Multi-protocol access

Q: Can I enable multiple protocols on the same endpoint?

A: Yes. During setup, you can select the protocol(s) you want to enable for clients to connect to your endpoint. The server hostname and identity provider are shared across the selected protocols. Similarly, you can also add FTP/FTPS support to an existing AWS Transfer for SFTP server endpoint, as long as the endpoint is hosted within your VPC and you are using a Custom Identity Provider.

Q: When should I create separate server endpoints for each protocol vs enable the same endpoint for multiple protocols?

A: When you need to use FTP (only supported for access within VPC), and also need to support over the internet for SFTP or FTPS, you will need a separate server endpoint for FTP. You can use the same endpoint for multiple protocols, when you want to use the same endpoint hostname and IP address for clients connecting over multiple protocols. Additionally, if you want to share the same credentials for SFTP and FTPS, you can set up and use a single identity provider for authenticating clients connecting over either protocol.

Q: Can I set up the same end user to access the endpoint over multiple protocols?

Yes, you can provide the same user access over multiple protocols, as long as the credentials specific to the protocol have been set up in your identity provider. If you have enabled FTP, we recommend maintaining separate credentials for FTP. Refer to the documentation for setting up separate credentials for FTP.

Q: Why should I maintain separate credentials for FTP users?

Unlike SFTP and FTPS, FTP transmits credentials in cleartext. We recommend isolating FTP credentials from SFTP or FTPS because, if, inadvertently FTP credentials are shared or exposed, your workloads using SFTP or FTPS remain secure.

Authentication modes

Q: How does the service authenticate users?

A: The service supports two modes of authentication: Service Managed, where you store user identities within the service, and, Custom (BYO), which enables you to integrate an identity provider of your choice. Service Managed authentication is supported for server endpoints that are enabled for SFTP only.

Q: How can I authenticate my users using Service Managed authentication?

A: You can use Service Managed authentication to authenticate your SFTP users using SSH keys.

Q: How many SSH keys can I upload per SFTP user?

A: You can upload up to 10 SSH keys per user.

Q. Is SSH key rotation supported for service managed authentication?

A: Yes. Refer to the documentation for details on how to set up key rotation for your SFTP users.

Q. Can I use the service managed authentication for password authentication?

A: No, storing passwords within the service for authentication is currently not supported. If you need password authentication, use the architecture described in this post on Enabling Password Authentication using Secrets Manager.

Q. Why should I use the Custom authentication mode?

A: The Custom authentication mode (“BYO” authentication) enables you to leverage an existing identity provider to manage your end users for all protocol types (SFTP, FTPS, and FTP), enabling easy and seamless migration of your users. Credentials can be stored in your corporate directory or an in-house identity datastore, and you can integrate it for end user authentication purposes. Examples of identity providers include Microsoft Active Directory (AD), Lightweight Directory Access Protocol (LDAP), or any custom identity provider that you may be using as a part of an overall provisioning portal.

Q. How can I get started with integrating my existing identity provider for Custom authentication?

A: To get started, you can use the AWS CloudFormation template in the usage guide and supply the necessary information for user authentication and access. Visit the website on custom identity providers to learn more.

Q. Are anonymous users supported?

A: No, anonymous users are currently not supported for any of the protocols.

Q: When setting up my users via a custom identity provider, what information is used to enable access to my users?

A: Your user will need to provide a username and password (or SSH key) which will be used to authenticate, and access to your bucket is determined by the AWS IAM Role supplied by the API Gateway and Lambda used to query your identity provider. You will also need to provide home directory information, and it is recommended that you lock them down to the designated home folder for an additional layer of security and usability. Refer to this blog post on how to simplify your end users’ experience when using a custom identity provider with AWS SFTP.

User Access Privileges

Q: Why do I need to provide an AWS IAM Role and how is it used?

A: AWS IAM is used to determine the level of access you want to provide your users. This includes the operations you want to enable on their client and which Amazon S3 buckets they have access to – whether it’s the entire bucket or portions of it.

Q: Why do I need to provide home directory information and how is it used?

The home directory you set up for your user determines their login directory. This would be the directory path that your user’s client will place them in as soon as they are successfully authenticated into the server. You will need to ensure that the IAM Role supplied provides user access to the home directory.

Q: I have 100s of users who have similar access settings but to different portions of my bucket. Can I set them up using the same IAM Role and policy to enable their access?

Yes. You can assign a single IAM Role for all your users and use logical directory mappings that specify which absolute Amazon S3 bucket paths you want to make visible to your end users and how you these paths presented to them by their clients. Visit this blog on how to 'Simplify Your AWS SFTP/FTPS/FTP Structure with Chroot and Logical Directories'.

Q: How are files stored in my Amazon S3 bucket transferred using AWS Transfer?

Files transferred over the supported protocols are stored as objects in your Amazon S3 bucket, and there is a one-to-one mapping between files and objects enabling native access to these objects using AWS services for processing or analytics.

Q: How are Amazon S3 objects stored in my bucket presented to my users?

After successful authentication, based on your users’ credentials, the service presents Amazon S3 objects and folders as files and directories to your users’ transfer applications.

Q: What file operations are supported? What operations are not supported?

A: Common commands to create, read, update, and delete, files and directories are supported. Files are stored as individual objects in your Amazon S3 bucket. Directories are managed as folder objects in S3, using the same syntax as the S3 console.

Directory rename operations, append operations, changing ownerships, permissions and timestamps, and use of symbolic and hard links are currently not supported.

Q: Can I control which operations my users are allowed to perform?

A: Yes, you can enable/disable file operations using the AWS IAM role you have mapped to their username. Refer to the documentation on 'Creating IAM Policies and Roles to control your end users’ access

Q: Can I provide my end users access to more than one Amazon S3 bucket?

A: Yes. The bucket(s) your user can access is determined by the AWS IAM Role, and the optional scope-down policy you assign for that user. You can only use a single bucket as the home directory for the user.

Q: Can I create a server using AWS Account A and map my users to Amazon S3 buckets owned by AWS Account B?

A: Yes. You can use the CLI and API to set up cross account access between your server and the buckets you want to use for storing files transferred over the supported protocols. The Console drop down will only list buckets in Account A. Additionally, you’d need to make sure the role being assigned to the user belongs to Account A.

Q: Can I automate processing of a file once it has been uploaded to Amazon S3?

A: Yes, you can use Amazon S3 events to automate post upload processing using a broad array of AWS services for querying, analysis, machine learning and more. Visit the documentation to learn more on common examples for post upload processing using Lambda with Amazon S3.

Q: Can I customize rules for processing based on the user uploading the file?

A: Yes. When your user uploads a file, the username and the server id of the server used for the upload is stored as part of the associated S3 object’s metadata. You can use this information for post upload processing.

Security and compliance

Q: Which protocols should I use for securing data while in-transit over a public network?

Either SFTP or FTPS should be used for secure transfers over public networks. Due to the underlying security of the protocols based on SSH and TLS cryptographic algorithms, data and commands are transferred through a secure, encrypted channel.

Q: What are my options to encrypt data at rest?

A: You can choose to encrypt files stored your bucket using Amazon S3 Server-Side Encryption (SSE-S3) or Amazon KMS (SSE-KMS).

Q: Which compliance programs does AWS Transfer Family support?

A: AWS Transfer Family is PCI-DSS and GDPR compliant, and HIPAA eligible. The service is also SOC 1, 2, and 3 compliant. Learn more about services in scope by compliance programs.

Q: Is AWS Transfer Family FISMA compliant?

A: AWS East/West and GovCloud (US) Regions are compliant. This compliance is demonstrated through FedRAMP Authorization of these two regions to FedRAMP Moderate and FedRAMP High. We demonstrate compliance through annual assessments and documenting compliance with in-scope NIST SP 800-53 controls within our System Security Plans. Templates are available on Artifact along with our customer responsibility matrix (CRM) which demonstrates, at a detailed level, our responsibility to meet these NIST controls as required by FedRAMP. Artifact is available through the management console accessible by an AWS account for both East/West and GovCloud. If you have any further questions on this topic, please consult the Console.

Q: How does the service ensure integrity of uploaded files?

A: Files uploaded through services are verified by comparing the file’s pre- and post-upload MD5 checksum.

Q: How can I monitor my end users’ activity?

A: You can use Amazon CloudWatch to monitor your end users’ activity and use AWS CloudTrail to access a record of all S3 API operations invoked by your server to service your end users’ data requests. Visit the documentation on how to enable Amazon CloudWatch and AWS CloudTrail logging.

Q: How can I track amount of data uploaded and downloaded over the protocols?

A: You can use Amazon CloudWatch Metrics to monitor and track data uploaded and downloaded by your users over the chosen protocols. Visit the documentation to learn more on using Amazon CloudWatch metrics.

Billing

Q: How am I billed for use of the service?

You are billed on an hourly basis for each of the protocols enabled, from the time you create and configure your server endpoint, until the time you delete it. You are also billed based on the amount of data uploaded and downloaded over SFTP, FTPS, or FTP. Refer to the pricing page for more details

Q: Will my billing be different if I use the same server endpoint for multiple protocols or use different endpoints for each protocol?

A: No, you are billed on an hourly basis for each of the protocols you have enabled and for the amount of data transferred through each of the protocols, regardless of whether same endpoint is enabled for multiple protocols or you are using different endpoints for each of the protocols.

Q: I have stopped my server. Will I be billed while it is stopped?

A: Yes, stopping the server, by using the console, or by running the “stop-server” CLI command or the “StopServer” API command, does not impact billing. You are billed on an hourly basis from the time you create your server endpoint and configure access to it over one or more protocols until the time you delete it.

Learn more about SFTP pricing
Learn more about pricing

AWS Transfer Family provides a fully managed service, reducing your operational costs to run file transfer services.

Learn more 
Sign up for a free AWS account
Sign up for a free account

Instantly get access to the AWS Free Tier. 

Sign up 
Start building with SFTP
Start building in the console

Get started building your SFTP, FTPS, and FTP services in the AWS Management Console.

Sign in