AWS Transfer Family FAQs

Yes. You can configure your Transfer Family server to display customized banners such as organization policies or terms and conditions to your users. You can also display customized Message of The Day (MOTD) to users who have successfully authenticated. To learn more, visit the documentation .

Yes. The service supplies a domain name by default to access your endpoint. 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 AWS Transfer Family uses Amazon Route 53 for custom domain names (applicable to internet facing endpoints only).

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 Security Groups. Refer to the documentation on creating your server endpoint inside your VPC using AWS PrivateLink for details.

No, when you enable FTP, you will only be able to use VPC hosted endpoint’s internal access option due to the fact that FTP transmits data in clear text. If traffic needs to traverse the public network, secure protocols such as SFTP or FTPS should be used.

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.

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 .

Yes. You have three options to restrict incoming traffic by users’ source IP address. If you are hosting your server endpoint within VPC, refer to this blog post on using Security Groups to allow list source IP address or use AWS Network Firewall service. If you are a public EndpointType Transfer server and API Gateway to integrate your identity management system, you can also use AWS WAF to allow, block, or rate limit access by your end users’ Source IP address.

Yes. You can deploy your server endpoint with shared VPC environments typically used when segmenting your AWS environment using tools such as AWS Landing Zone for security, cost monitoring, and scalability. Refer to this blog post on using VPC hosted endpoints in shared VPC environments with AWS Transfer Family .

You can use AWS Global Accelerator with your Transfer server endpoint to improve file transfer throughput and round-trip time. Visit this blog post for more information.

Yes. Based on your security and compliance requirements, you can select one of our available service managed security policies to control the cryptographic algorithms that will be advertised by your server endpoints. When your end users’ file transfer clients attempt to connect to your server, only the algorithms specified in the policy can be used to negotiate the connection. Refer to the documentation on pre-defined security policies .

Yes. AWS Transfer Family supports quantum-safe public-key exchange for SFTP file transfers. You can associate one of the pre-defined hybrid PQ security policies with your SFTP server enabling quantum-safe key exchange with clients that support PQ encryption algorithms.

No. Fixed IP addresses that are usually used for firewall whitelisting purposes are currently not supported on the PUBLIC Endpoint type. Use VPC hosted endpoints to assign static IP addresses for your endpoint.

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

No. The server’s host key that is assigned when you create the server remains the same, unless you add a new host key and manually delete the original.

RSA, ED25519, and ECDSA key types are supported for SFTP server host keys.

Yes. You can import a host key when creating a server or import multiple host keys when updating a server. Refer to the documentation on managing host keys for your SFTP-enabled server .

Yes. The oldest host key of each key type can be used to verify the authenticity of an SFTP server. By adding RSA, ED25519, and ECDSA host keys, 3 separate host keys can be used to identify your SFTP server.

The oldest host key of each key type is used to verify authenticity of your SFTP server.

Yes. You can rotate your SFTP server host keys at any time by adding and removing host keys. Refer to the documentation on managing host keys for your SFTP-enabled server .

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 .

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.

We only support explicit FTPS mode.

Yes. File transfers traversing a firewall or a router are supported by default using extended passive connection mode (EPSV). If you are using an FTPS/FTP client that does not support EPSV mode, visit this blog post to configure your server in PASV mode to expand your server’s compatibility to a broad range of clients.

Yes. In addition to standard port 22, AWS Transfer Family also supports alternate ports 2222 and 22000. By default, port 22 is configured by default for your SFTP servers. To enhance the security of your server, you can configure SSH traffic to use port 22, 2222, or both. Refer to our documentation here.

You can authenticate connections to remote servers using either SSH key-pairs or password, or both, depending on the remote server requirements. To learn more about storing and managing your connector’s authentication credentials in your AWS Secrets Manager account, visit the documentation. 

You can transfer files to or from Amazon S3 to remote SFTP servers using SFTP connectors.

We support RSA and ECDSA host key algorithms. For more details on the supported key types, please visit the documentation here .  

The connector uses the host fingerprint to validate the identify of the remote server. If the fingerprint provided by the remote server does not match that uploaded to the connector’s configuration, the connection will fail and error details will be logged in CloudWatch. To learn more on how to upload the public portion of a remote server’s SSH key for identification, visit the SFTP connectors documentation here.

Yes. Based on your security and compatibility requirements, you can select one of our available service managed security policies to control the cryptographic algorithms that will be advertised by your SFTP connector. When your connector attempts to connect to remote server, only the algorithms specified in the policy attached to your connector will be used to negotiate the connection. Refer to the documentation on pre-defined security policies.

Yes. You can create a SFTP connector in one AWS account, and use it to transfer files from another account by providing the appropriate access permissions in the IAM role attached to your connector.

You can test connectivity to the remote server using the AWS Management Console or TestConnection API/CLI/CDK command. We recommend you test the connectivity to the remote server as soon as you create your connector to ensure that it is configured correctly. Make sure that the static IP addresses associated with your connectors are allow-listed by the remote server if needed. To learn more, visit SFTP connectors documentation.

SFTP connectors can be used to send files from Amazon S3 to a remote SFTP server, retrieve files from a remote SFTP server to Amazon S3, and list files stored in a directory on remote SFTP server. To learn more about using SFTP connectors, visit SFTP connectors documentation.

You can list the files stored in a directory on remote SFTP servers by using SFTP connectors’ StartDirectoryListing API operation. You will then be able to retrieve target files from the remote server by passing file names from the list when using StartFileTransfer API operation to transfer files. For more information, Refer to the sample solution for synchronising new files from remote SFTP servers, or take the self-paced MFT workshop.

You can list all files from a directory on remote SFTP server using SFTP connectors, and build custom logic to filter the file list based on your wildcard criteria for filename patterns. You can then use the StartFileTransfer API operation to transfer those files using SFTP connectors.

You can monitor the current status of your file transfer operations using the ListFileTransferResults API command. In addition, SFTP connectors emit detailed logs in Amazon CloudWatch, including status of your file transfers, operation type (send or retrieve), timestamp, file path, and error description (if any) to help you maintain data lineage. 

Yes. You can schedule file transfers using Amazon EventBridge Scheduler. Create a schedule that meets your business’s needs using EventBridge’s Scheduler and specify AWS Transfer Family’s StartFileTransfer API, or StartDirectoryListing API, as the universal target for your schedule.

Yes. AWS Step Functions integrates with various AWS services, including AWS Transfer Family, enabling you to invoke SFTP connector’s StartFileTransfer action directly from your state machine. Once you have created your SFTP connector with AWS Transfer Family, leverage Step Functions’ AWS SDK integrations to call the StartFileTransfer API. To learn more about orchestrating your file transfer and file processing workflows using AWS Step Functions and SFTP connectors, take the self-paced event-driven MFT workshop.

Yes. Every file transfer operation using SFTP connectors publishes an event notification in your default event-bus in Amazon EventBridge. You can subscribe to SFTP connector events, and use them to orchestrate event-driven processing of your transferred files using Amazon EventBridge or any other workflow orchestration service of your choice that integrates with these events.

Yes. Static IP addresses are associated with your connectors by default that can be used to allow-list connections on your business partner’s firewall. You can identify the static IP addresses associated with your connectors by navigating to the connector details page in the AWS Transfer Family Console, or by using the DescribeConnector API/CLI/CDK command.

Yes. All SFTP connectors in an AWS account region will share a set of static IP addresses. Sharing IP addresses between connectors of a given type reduces the amount of allow-list documentation as well as the onboarding communications needed with your external partners.

No. Currently, SFTP connectors can only be used to connect with servers that offer an internet accessible endpoint. If you need to connect to servers that are only accessible via a private network, please let us know via AWS Support or through your AWS account team.

Yes. During setup, you can select the protocol(s) you want to enable for clients to connect to your endpoint. The server hostname, IP address, and identity provider are shared across the selected protocols. Similarly, you can also enable additional protocol support to existing AWS Transfer Family endpoints, as long as the endpoint configuration meets the requirements for all the protocols you intend to use.

When you need to use FTP (only supported for access within VPC), and also need to support over the internet for SFTP, AS2, 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.

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.

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.

The service supports three identity provider options: Service Managed, where you store user identities within the service, Microsoft Active Directory, and, Custom Identity Providers, which enable you to integrate an identity provider of your choice. Service Managed authentication is supported for server endpoints that are enabled for SFTP only.

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

You can upload up to 10 SSH keys per user. RSA, ED25519, and ECDSA keys are supported.

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

When you create your server, you select a directory in AWS Managed Microsoft AD, your on-premises environment, or self-managed AD in Amazon EC2 as your identity provider. You will then need to specify the AD Groups you want to enable for access using a Security Identifier (SID). Once you associate your AD group with access control information such as IAM Role, scope down policy (S3 only), POSIX Profile (EFS only), home directory location, and logical directory mappings, members of the group can use their AD credentials to authenticate and transfer files over the enabled protocols (SFTP, FTPS, FTP). 

When you set up your users, you supply a scope down policy that is evaluated in run time based on your users’ information such as their username. You can use the same scope down policy for all your users to provide access to unique prefixes in your bucket based on their username. Additionally, a username can also be used to evaluate logical directory mappings by providing a standardized template on how your S3 bucket or EFS file system contents are made visible to your user. For more information, visit the documentation on granting access to AD groups .

Yes. You can use Microsoft AD to authenticate users for access over SFTP, FTPS, and FTP.

Yes. You can revoke file transfer access for individual AD Groups. Once revoked, members of the AD groups will not be able to transfer files using their AD credentials.

The Custom 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 Okta , Microsoft AzureAD, or any custom-built identity provider you may be using as a part of an overall provisioning portal.

To integrate your identity provider with an AWS Transfer Family server, you can use an AWS Lambda function, or an Amazon API Gateway endpoint. Use Amazon API Gateway if you need a RESTful API to connect to an identity provider or want to leverage AWS WAF for its geo-blocking and rate limiting capabilities. Visit the documentation to learn more about integrating common identity providers such as AWS Cognito, Okta, and AWS Secrets Manager.

Yes. The client source IP is passed to your identity provider when you use AWS Lambda or API Gateway to connect a custom identity provider. This enables you to allow, deny, or limit access based on the IP addresses of clients to ensure that your data is accessed only from IP addresses that you have specified as trusted.

Yes. You can enforce multiple methods of authentication to provide an additional layer of security when your data is accessed over SFTP. Your SFTP server can be configured to require both password and SSH key, password or SSH key, just password, or just SSH key. Refer to the documentation for details on how to enable multiple methods of authentication using your customer identity provider.

No. Storing passwords within the service for authentication is currently not supported. If you need password authentication, use Active Directory by selecting a directory in AWS Directory Service, or follow the architecture described in this blog on Enabling Password Authentication using Secrets Manager .

No. Anonymous users are currently not supported for any of the protocols.

No. We only support setting access by AD Groups.

No. AWS Transfer Family support for Microsoft AD can only be used for password-based authentication. To use a mix of authentication modes, use the Custom authorizer option.

Yes. AWS Transfer Family support for AS2 has received the official  Drummond Group AS2 Cloud Certification Seal. AWS Transfer Family AS2 capabilities have been thoroughly vetted for security and message exchange compatibility with fourteen other third-party AS2 solutions. Visit our announcement to learn more.

Your trading partner is uniquely identified using their AS2 Identifier (AS2 ID). Similarly, your trading partners identify your messages using your AS2 ID.

You can use AWS Transfer Family’s existing support for Amazon S3, networking features (VPC endpoints, Security Groups, and Elastic IPs), and access controls (AWS IAM) for AS2, as you could for SFTP, FTPS, and FTP. User authentication, logical directories, custom banners, and Amazon EFS as a storage backend are not supported for AS2.

Non-repudiation, unique to AS2, validates that message are successfully exchanged between two parties. Non-repudiation in AS2 is achieved using Message Disposition Notifications (MDN). When an MDN is requested in a transaction, it ensures that the sender sent the message, the receiver successfully received it, and the message sent by the sender was the same message received by the receiver.

There are two aspects to messages transmission – one from the sender and from the receiver. Once the sender has determined what message to send, the message is signed (using the sender’s private key), encrypted (using the receiver’s certificate), and the message integrity is calculated using a hash. This signed and encrypted message is transmitted over the wire to the receiver. Once the message is received, it is decrypted (using the receiver’s private key), validated (using the sender’s public key), processed and a signed Message Disposition Notifications (MDN), if requested, is sent back to the sender to acknowledge successful delivery of the message. Refer to the documentation on how AS2 handles message transmission.

The combination of options possible are driven from a sender’s standpoint. The sender can choose to either only encrypt or only sign the data (or both), and choose to request an Message Disposition Notifications (MDN). If the sender chooses to request an MDN, they can request a signed or unsigned MDN. The receiver is expected to honor these options.

Yes. The sender can choose to request an MDN, choose to request a signed or unsigned MDN, as well as select the signing algorithms that should be used to sign the MDN.

Currently we support both synchronous and asynchronous MDN responses. This enables you to respond to your trading partners with either a synchronous or asynchronous MDN after receiving an AS2 message. Since synchronous MDNs are sent over the same connection channel as the message, it is much simpler and hence the recommended option. If you need more time to process the message before sending an MDN, asynchronous MDNs are preferred. If you have a need to request and receive asynchronous MDNs when sending messages to your trading partners, contact us through AWS Support or your account manager.

AWS Transfer Family extracts key AS2 information from payloads and MDNs exchanged and stores them as JSON files in your Amazon S3 bucket. You can query these JSON files using S3 Select or Amazon Athena, or index the files using Amazon OpenSearch or Amazon DocumentDB for analytics.

Yes. Once you receive an MDN from your trading partner, the service validates the MDN using your certificate and stores the message in your Amazon S3 bucket. You can choose to archive the message by leveraging S3 Lifecycle policies.

Once your data is ready for delivery, you will need to invoke a service provided API, associate a connector to notify us that it is ready to be delivered, and provide us the recipient’s information. This will notify the service to send the message to your trading partner’s endpoint. Refer to the documentation on connectors to send messages to your trading partner over AS2.

Yes. When you set up your trading partner’s profile you can use different folders for each of them.

Yes. You can import your partner’s existing keys and certificates and manage renewals and rotations. Refer to the documentation on importing certificates.

Using the AWS Transfer Family console, you can view a dashboard of certificates sorted by their expiry dates. Additionally, you can opt in to receive notifications ahead of certificate expiry, giving you sufficient time to rotate them to prevent discontinuity in operations.

Yes. We support the ability to connect to your trading partner’s AS2 server using Basic authentication. Refer to the documentation on configuring Basic authentication on AS2 connectors.

Yes. Static IP addresses are associated with your connectors by default that can be used to allow-list connections on your trading partner’s AS2 server. You can identify the static IP addresses associated with your connectors by navigating to the connector details page in the AWS Transfer Family Console, or by using the DescribeConnector API/CLI/CDK command.

Yes. Your AS2 connectors use static IP addresses when sending messages to remote AS2 servers and when returning asynchronous message disposition notification (MDN) responses. You can identify the static IP addresses associated with your connectors by navigating to the connector or server details page in the AWS Transfer Family Management Console, or by using the DescribeConnector or DescribeServer API/CLI/CDK commands.

Yes. Your AS2 server endpoints support configuring IP allow-list controls by using security groups with internet-facing, VPC-hosted endpoints.

Every AS2 message received publishes an event to your default event-bus in Amazon EventBridge. You can subscribe to these events and use them to orchestrate event-driven processing of the received messages using Amazon EventBridge or any other workflow orchestration service. For example, you can use these events to copy incoming messages to other locations in S3, malware scan the contents of messages using a custom Lambda, or tag messages based on their contents so they can be indexed and searched by services like Amazon CloudSearch.

Yes. Your AS2 asynchronous MDN responses will use static IP addresses. You can identify the static IP addresses used for sending your asynchronous MDN responses by navigating to the server details page in the AWS Transfer Family Management Console, or by using the DescribeServer API/CLI/CDK command.

Yes. You can automatically transform the X12 EDI contents of your inbound AS2 messages into common data representations such as JSON and XML using AWS B2B Data Interchange. To do so, create an Amazon EventBridge rule that matches the event pattern of AWS Transfer Family’s AS2 Payload Receive Completed event and specifies AWS B2B Data Interchange’s StartTransformerJob API as the universal target for the rule. By transforming the X12 EDI contents of your inbound AS2 messages with AWS B2B Data Interchange, you can automate and accelerate the integration of your EDI data into downstream business applications and systems.

You can automate the sending of AS2 messages by scheduling them with the Amazon EventBridge Scheduler or by triggering them using Amazon EventBridge rules. To create automated, time-based workflows for sending AS2 messages, create a schedule that meets your business’s needs using the EventBridge Scheduler and specify AWS Transfer Family’s StartFileTransfer API as the universal target for your schedule. To create automated, event-driven workflows for sending AS2 messages, create an Amazon EventBridge rule that matches events published to EventBridge and specify AWS Transfer Family’s StartFileTransfer API as the universal target for your rule.

Yes. Every AS2 message and MDN sent publishes an event to your default event-bus in Amazon EventBridge. You can subscribe to these events and use them to delete or archive AS2 messages and MDN successfully sent to your trading partner.

Yes. AWS Transfer Family publishes events to Amazon EventBridge for every successful or failed AS2 message or MDN sent and received. These events are published to your default event-bus in Amazon EventBridge where they can be used to trigger email notifications to you or your partners using services like Amazon SNS.

No. Currently, managed workflows are not supported for your AS2 endpoints. We recommend using Transfer Family’s event notifications that are published in Amazon EventBridge to orchestrate processing of your AS2 messages. For more details, refer to the File Processing Automation section.

No. AWS Transfer Family does not offer support for AS3 or AS4 at this time.

You have two options: 1) AWS Transfer Family publishes file transfer event notifications in Amazon EventBridge for files transferred over SFTP, AS2, FTPS and FTP, and you can use these events to trigger processing of your files using any service that can integrate with EventBridge events, and 2) AWS Transfer family provides managed workflows to make it easier for you to automatically execute post upload processing of files uploaded over SFTP, FTPS and FTP server endpoints using pre-built file processing steps. When you associate a managed workflow with your server endpoint, all the files uploaded over that endpoint are processed using the same workflow steps.

AWS Transfer Family publishes event notifications in Amazon EventBridge upon successful or failed completion of each file transfer operation, for both server and connector resources. For more information on Transfer Family events published to Amazon EventBridge, refer to the documentation. 

AWS Transfer Family managed workflows provide a pre-built framework for you to create, run, and monitor a linear sequence of steps for processing files uploaded over SFTP, FTPS, and FTP server endpoints. Using this feature, you can save time with pre-built steps to execute common file-processing tasks such as copying, tagging, and decrypting of files. You can also customize file-processing using a lambda function for tasks such as scanning files for PII, virus/malware, or other errors such as incorrect file format or type, enabling you to quickly detect anomalies and meet your compliance requirements. When you associate a managed workflow with your server endpoint, all the files uploaded over that endpoint are processed using the same workflow steps.

If you need to process files that you exchange with your business partners, you need to set up an infrastructure to run custom code, continuously monitor for run time errors and anomalies, and make sure all changes and transformations to the data are audited and logged. Additionally, you need to account for error scenarios, both technical and business, while ensuring failsafe modes are properly triggered. If you have requirements for traceability, you need to track lineage of the data as it passes along different components of your system. Maintaining separate components of a file-processing workflow takes time away from focusing on differentiating work you could be doing for your business. Managed workflows remove the complexities of managing multiple tasks, and provides a standardized file-processing solution that can be replicated across your organization, with built-in exception handing and file traceability for each step to help you meet your business and legal requirements.

Managed workflows allow you to easily preprocess data before it is consumed by your downstream applications by executing a linear sequence of file-processing tasks for all files uploaded to your server endpoints, such as moving uploaded files to user-specific folders, decrypting files using PGP keys, malware scanning, and tagging. You can deploy workflows using Infrastructure as Code (IaC), enabling you to quickly replicate and standardize common post-upload file processing tasks spanning multiple business units in your organization. You can have granular control by associating a managed workflow to your server endpoint that is triggered only on fully uploaded files, and by associating a separate managed workflow that is triggered only for partially uploaded files to process incomplete uploads. Workflows also provide built-in exception handling to allow you to easily react to file-processing outcomes in case of errors or exceptions in the workflow execution, helping you maintain your business and technical SLAs. Each file processing step in your workflow also produces detailed logs, which can be audited to trace data lineage.

AWS Transfer Family server endpoints and connectors automatically publish event notifications in Amazon EventBridge when a file transfer operation completes, along with operational information such as file location, username of the sender, server-id or connector-id, transfer status etc. You can use these events when you need granular control in defining file processing, such as using conditional logic based on the source of the file, or when you need to build event-driven architectures to integrate with other AWS services, third-party applications, and your own applications. On the other hand, AWS Transfer Family managed workflows provide a pre-built framework to define a linear sequence of common file processing steps that are applied to all files uploaded over your SFTP, FTPS, and FTP server endpoints. You can associate a managed workflow to your endpoint when all uploaded files need to be processed using the same common file-processing steps without requiring to apply any granular or conditional logic.

First, set up your workflow to contain actions such as copying, tagging, and a series of actions that can include your own custom step in a sequence of steps based on your requirements. Next, map the workflow to a server, so on file arrival, actions specified in this workflow are evaluated and triggered in real time. To learn more, visit the documentation , watch this demo on getting started with managed workflows, or deploy a cloud-native file-transfer platform using this blog post .

Yes. The same workflow can be associated with multiple servers so it is easier for you to maintain and standardize configurations.

The following common actions are available once a transfer server has received a file from the client:

Decrypting file using PGP keys. Refer to this blog post on encrypting and decrypting files using PGP.

Move or copy data from where it arrives to where it needs to be consumed.

Delete the original file post archiving or copying to a new location.

Tag the file based on its contents so it can be indexed and searched by downstream services (S3 only)

Any custom file processing logic by supplying your own Lambda function as a custom step to your workflow. For example, checking compatibility of the file type, scanning files for malware, detecting Personally Identifiable Information (PII), and metadata extraction before ingesting files to your data analytics.

Yes. You can configure a workflow step to process either the originally uploaded file or the output file from the previous workflow step. This allows you to easily automate moving and renaming of your files after they are uploaded to Amazon S3. For example, to move a file to a different location for file archival or retention, configure two steps in your workflow. The first step is to copy a file to a different Amazon S3 location, and the second step to delete the originally uploaded file. Read the documentation for more details on selecting a file location for workflow steps.

Yes. You can use a pre-built, fully managed workflow step for PGP decryption of files uploaded over your SFTP, FTPS and FTP server endpoints. For more information, refer to managed workflows documentation and this blog post on encrypting and decrypting files using PGP.

Yes. Using managed workflows, you can create multiple copies of the original file while preserving the original file for records retention.

Yes. You can utilize username as a variable in workflows copy steps, enabling you to dynamically route files to user-specific folders in Amazon S3. This removes the need to hardcode destination folder location when copying files and automates creation of user-specific folders in Amazon S3, allowing you to scale your file automation workflows. Read the documentation to learn more.

Refer to the Monitoring section for details on the supported features for logging your managed workflows activity.

AWS Step Functions is a serverless orchestration service that lets you combine AWS Lambda with other services to define the execution of business application in simple steps. To perform file-processing steps using AWS Step Functions, you use AWS Lambda functions with Amazon S3’s event triggers to assemble your own workflows. Managed workflows provide a framework to easily orchestrate a linear sequence of processing and differentiates from existing solutions in the following ways: 1) You can granularly define workflows to be executed only on full file uploads, as well as workflows to be executed only on partial file uploads, 2) workflows can be triggered automatically for S3 as well as EFS (which doesn’t offer post upload events), and 3) workflows provide no code and pre-built options for common file processing like PGP decryption, and 4) customers can get end to end visibility into their file transfers and processing in CloudWatch logs.

Yes. Refer to this blog post on using managed workflows for file delivery notifications.

Yes. You can define separate workflows to be triggered on complete file uploads and on partial file uploads.

Currently, managed workflows can only be triggered for files uploaded over your SFTP, FTPS and FTP server endpoints and process one file per execution. Managed Workflows are not supported for messages exchanged over AS2, for file downloads over your server endpoints and for files transferred using SFTP connectors.

No. Processing can be invoked only on file arrival using the inbound endpoint.

No. Workflows currently process one file per execution.

No. Managed workflows cannot be invoked on a granular, per-user basis. You can define conditional file processing logic based on which user uploaded the file using the file transfer event notifications published in Amazon EventBridge.

The data transfer between AWS Transfer Family servers and Amazon S3 happens over internal AWS networks and doesn’t traverse the public internet. Because of this, you do not need to use AWS PrivateLink for data transfered from the AWS Transfer Family server to Amazon S3. The Transfer Family service doesn’t require AWS PrivateLink endpoints for Amazon S3 to keep traffic from going over the internet, and therefore cannot use those to communicate with storage services. This all assumes that the AWS storage service and the Transfer Family server are in the same region.

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.

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.

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 .

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.

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.

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.

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

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.

Yes. You can use S3 Access Point aliases with AWS Transfer Family to provide granular access to a large set of data without having to manage a single bucket policy. S3 Access Point aliases combined with AWS Transfer Family logical directories enable you to create a fine-grained access control for different applications, teams, and departments, while reducing the overhead of managing bucket policies. To learn more and get started, visit the blog post on enhancing data access control with AWS Transfer Family and Amazon S3 Access Points .

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.

Yes. AWS Transfer Family publishes event notifications in Amazon EventBridge upon completion of a file transfer operation, and you can use these events to automate post upload processing of your files. Alternatively, when all your uploaded files need to be processed using the same file processing steps without any conditional logic, you can use AWS Transfer Family managed workflows to define a linear sequence of common file processing steps which are auto-invoked for each file that your users upload over your SFTP, FTPS or FTP server endpoints.

Amazon S3 can publish event notifications for any new object created in your bucket. On the other hand, AWS Transfer Family publishes event notifications upon successful or failed completion of each file transfer operation. It differentiates from Amazon S3 event notifications in the following ways: 1) You can have granular control in defining post-upload processing for full file uploads vs partial file uploads when using event notifications from Transfer Family, 2) Transfer Family events are published for file uploads in both S3 as well as EFS, and 3) Events generated by Transfer Family contain operational information such as username of the sender, server-id, transfer status, etc., and allows you to define file processing granularly, based on conditional logic over these attributes.

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. Refer to the documentation on information you use for post upload processing. The end-user information is also available in the automatic file upload event notification published by AWS Transfer Family in Amazon EventBridge. You can use this information to orchestrate granular post upload processing of your files based on the user. 

Yes. You can optimize your S3 directory listing so your end users can enjoy accelerated listing of their directory – from minutes to seconds. If you are creating a new server through the console after 11/17/2023, your server will have optimized S3 directory listing enabled by default if you are using Amazon S3 as your storage. This can be toggled on or off at any time. Turning this feature off restores your S3 directory listing to default performance. If you are using CloudFormation, CLI, or API to create a server, optimized S3 directory listing is disabled by default, but can be enabled at any time. Refer to the documentation on how to enable optimized S3 directory listing.

Prior to setting up AWS Transfer Family to work with an Amazon EFS file system, you will need to set up ownership of files and folders using the same POSIX identities (user id/group id) you plan to assign to your AWS Transfer Family users. Additionally, if you are accessing file systems in a different account, resource policies must also be configured on your file system to enable cross account access. Refer to this blog post for step-by-step instructions on using AWS Transfer Family with EFS.

The data transfer between AWS Transfer Family servers and Amazon EFS happens over internal AWS networks and doesn’t traverse the public internet. Because of this, you do not need to use AWS PrivateLink for data transfered from the AWS Transfer Family server to Amazon EFS. The Transfer Family service doesn’t require AWS PrivateLink endpoints for Amazon EFS to keep traffic from going over the internet, and therefore cannot use those to communicate with storage services. This all assumes that the AWS storage service and the Transfer Family server are in the same region.

Amazon EFS uses POSIX IDs which consist of an operating system user id, group id, and secondary group id to control access to a file system. When setting up your user in the AWS Transfer Family console/CLI/API, you will need to specify the username, user’s POSIX configuration, and an IAM role to access the EFS file system. You will also need to specify an EFS file system id and optionally a directory within that file system as your user’s landing directory. When your AWS Transfer Family user authenticates successfully using their file transfer client, they will be placed directly within the specified home directory, or root of the specified EFS file system. Their operating system POSIX id will be applied to all requests made through their file transfer clients. As an EFS administrator, you will need to make sure the file and directories you want your AWS Transfer Family users to access are owned by their corresponding POSIX ids in your EFS file system. Refer to the documentation to learn more on configuring ownership of sub-directories in EFS . Note that Transfer Family does not support access points if you are using Amazon EFS for storage.  

Files transferred over the enabled protocols are directly stored in your Amazon EFS file Systems and will be accessible via a standard file system interface or from AWS services that can access Amazon EFS file systems.

A: SFTP/FTPS/FTP commands to create, read, update, and delete files, directories, and symbolic links are supported. Refer to the table below on supported commands for EFS as well as S3.

1. Only file renames are supported. Directory renames and rename of files to overwrite existing files are not supported.

2. Only root i.e. users with uid=0 can change ownership and permissions of files and directories.

3. Supported either for root e.g. uid=0 or for the file’s owner who can only change a file’s group to be one of their secondary groups.

4. Supported for non-empty folders only.

The IAM policy you supply for your AWS Transfer Family user determines if they have read-only, read-write, and root access to your file system. Additionally, as a file system administrator, you can set up ownership and grant to access files and directories within your file system using their user id and group id. This applies to users whether they are stored within the service (service managed) or within your identity management system (“BYO Auth”).

Yes. When you set up your user, you can specify different file systems and directories for each of your users. On successful authentication, EFS will enforce a directory for every file system request made using the enabled protocols.

Yes. Using AWS Transfer Family logical directory mappings, you can restrict your end users’ view of directories in your file systems by mapping absolute paths to end user visible path names. This also includes being able to “chroot” your user to their designated home directory.

Yes. If symbolic links are present in directories accessible to your user and your user tries to access them, the links will be resolved to its target. Symbolic links are not supported when you use logical directory mappings to set up your users' access.

Yes. When you set up an AWS Transfer Family user, you can specify one or more file systems in the IAM policy you supply as part of your user set up in order to grant access to multiple file systems.

You can use clients and applications built for Microsoft Windows, Linux, macOS, or any operating system that supports SFTP/FTPS/FTP to upload and access files stored in your EFS file systems. Simply configure the server and user with the appropriate permissions to the EFS file system to access the file system across all operating systems.

You have two options: 1) AWS Transfer Family publishes event notifications in Amazon EventBridge upon completion of a file transfer operation, and you can use these events to automate post upload processing of your files, and 2) When all your uploaded files need to be processed using the same file processing steps without any conditional logic, you can use AWS Transfer Family managed workflows to define a linear sequence of common file processing steps that are applied for each file uploaded over your SFTP, FTPS or FTP server endpoints.

For new files, the POSIX user id associated with the user uploading the file will be set as the owner of the file in your EFS file system. Additionally, you can use Amazon CloudWatch to track your users’ activity for file creation, update, delete, and read operations. Visit the documentation  to learn more on how to enable Amazon CloudWatch logging.

Yes. You can use the CLI and API to set up cross account access between your AWS Transfer Family resources and EFS file systems. The AWS Transfer Family console will only list file systems in the same account. Additionally, you’d need to make sure the IAM role assigned to the user to access the file system belongs to Account A.

If you set up an AWS Transfer Family server to access a cross account EFS file system not enabled for cross account access, your SFTP/FTP/FTPS users will be denied access to the file system. If you have CloudWatch logging enabled on your server, cross account access errors will be logged to your CloudWatch Logs.

No. You can use AWS Transfer Family to access EFS file systems in the same AWS Region only.

Yes. You can use AWS Transfer to write files into EFS and configure EFS Lifecycle Management to migrate files that have not been accessed for a set period of time to the Infrequent Access (IA) storage class.

Yes. Amazon EFS provides a file system interface, file system access semantics (such as strong consistency and file locking), and concurrently-accessible storage for up to thousands of NFS/SFTP/FTPS/FTP clients.

Yes. Accessing your EFS file systems using your AWS Transfer Family servers will consume your EFS burst credits regardless of the throughput mode. Refer to the documentation on available performance and throughput modes and view some useful performance tips .

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.

You can choose to encrypt files stored your bucket using Amazon S3 Server-Side Encryption (SSE-S3) or Amazon KMS (SSE-KMS). For files stored in EFS, you can choose AWS or customer managed CMK for encryption of files at rest. Refer to the documentation for more details on options for at rest encryption of file data and metadata using Amazon EFS .

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

AWS East/West and GovCloud (US) Regions are FISMA compliant. When AWS Transfer Family is authorized for FedRAMP, it will be FISMA compliant within the respective regions. 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 or 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 .

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

You can use AWS Transfer Family managed workflows to automatically decrypt files using PGP keys when they are uploaded to your AWS Transfer Family SFTP, FTPS or FTP server endpoints. For more information, refer to managed workflows documentation. Alternatively, you can subscribe to AWS Transfer Family event notifications published in Amazon Eventbridge to orchestrate granular and event-driven processing of transferred files using your own encryption/ decryption logic.

You can monitor your end users’ and their file transfer activities using JSON formatted logs that are delivered to Amazon CloudWatch. Within CloudWatch, you can parse and query your logs using CloudWatch Log Insights, which automatically discovers JSON formatted fields. You can also track top users, total number of unique users, and their ongoing usage with CloudWatch Contributor Insights. We also provide pre-built CloudWatch metrics and graphs that are accessible within the AWS Transfer Family Management Console. Visit the documentation  to learn more.

Yes. You can combine log streams from multiple AWS Transfer Family servers into a single CloudWatch log group. This allows you to create consolidated log metrics and visualizations, which can be added to CloudWatch dashboards for tracking server usage and performance.

Workflow executions can be monitored using AWS CloudWatch metrics such as the total number of workflows executions, successful executions, and failed executions. Using the AWS Management Console, you can also search and view real-time status of in progress Workflow executions. Use CloudWatch logs to get detailed logging of workflows executions.

AWS Transfer Family delivers logs in JSON format across all resources – including servers, connectors, and workflows – and all protocols – including SFTP, FTPS, FTP, and AS2.

You can use the Transfer Family’s managed workflows to receive notifications for files uploaded over your SFTP, FTPS and FTP server endpoints. Refer to this blog post. Alternatively, you can subscribe to AWS Transfer Family events in Amazon EventBridge to receive notifications using Amazon Simple Notification Service (SNS).

Yes. If a file validation check fails against preconfigured workflow validation steps, you can use the exception handler to invoke your monitoring system or alert team members via Amazon SNS topic.

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 your SFTP, FTPS, or FTP servers, number of messages exchanged over AS2, and the amount of data processed using Decrypt workflow step. When using SFTP connectors, you are billed for the amount of data transferred and the number of connector calls. Refer to the pricing page for more details.

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.

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.

You are billed for Decrypt workflow step based on the amount of data you decrypt using PGP keys. There is no other additional charge for using managed workflows. Depending on your workflow configuration, you are also billed for use of Amazon S3, Amazon EFS, AWS Secrets Manager and AWS Lambda.

No. There is no hourly billing for SFTP connectors. For more information on SFTP connector pricing, refer to the pricing page.