Aws Transfer Family FAQs | Amazon Web Services Flashcards
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: What is the difference between SFTP and FTPS? Which should I use when?
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 use SCP, HTTPS or AS2, to transfer files using this service?
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 my users continue to use their existing file transfer clients and applications?
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.
Q: Can I use CloudFormation to automate deployment of my servers and users?
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 use my corporate domain name (sftp.mycompanyname.com) to access my endpoint?
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 still use the service if I don’t have a domain name?
A: Yes, you will need to CNAME the domain to the service supplied endpoint hostname.
Q: Can I use my domain that already has a public zone?
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: Can I use FTP with an internet facing endpoint?
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: What if I need to use FTP for transfers over the public internet?
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 I use FTP without a VPC?
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 my end users use fixed IP addresses to whitelist access to my server’s endpoint in their firewalls?
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 I restrict incoming traffic by end users’ source IP addresses?
A: No. Fixed IP addresses that are usually used for firewall whitelisting purposes are currently not supported on the PUBLIC Endpoint type.
Q: Can my end users use fixed IP addresses to access my server whose endpoint type 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: What IP ranges would my end users need to whitelist to access my SFTP server’s endpoint type that is PUBLIC?
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: Q: Will my AWS Transfer for SFTP server's host key ever change after I create the server?
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: Can I import keys from my current SFTP server so my users do not have to reverify the session information?
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: How do my end users’ FTPS clients verify the identity of my FTPS server?
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 active and passive modes of FTPS and FTP?
A: We only support explicit FTPS mode.
Q: Do you support Explicit and Implicit FTPS modes?
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: Can I enable multiple protocols on the same endpoint?
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: When should I create separate server endpoints for each protocol vs enable the same endpoint for 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: Can I set up the same end user to access the endpoint over multiple protocols?
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.
Q: Why should I maintain separate credentials for FTP 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 does the service authenticate users?
A: You can use Service Managed authentication to authenticate your SFTP users using SSH keys.
Q: How can I authenticate my users using Service Managed authentication?
A: You can upload up to 10 SSH keys per user.
Q: How many SSH keys can I upload per SFTP user?
A: Yes. Refer to the documentation for details on how to set up key rotation for your SFTP users.
Q. Is SSH key rotation supported for service managed 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. Can I use the service managed authentication for password 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. How can I get started with integrating my existing identity provider for Custom authentication?
A: No, anonymous users are currently not supported for any of the protocols.
Q. Are anonymous users supported?
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.
Q: When setting up my users via a custom identity provider, what information is used to enable access to my users?
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 an AWS IAM Role 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: Why do I need to provide home directory information and how is it used?
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: 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?
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 files stored in my Amazon S3 bucket transferred using AWS Transfer?
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: How are Amazon S3 objects stored in my bucket presented to my users?
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.
Q: What file operations are supported? What operations are not supported?
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 control which operations my users are allowed to perform?
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 provide my end users access to more than one Amazon S3 bucket?
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 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 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 automate processing of a file once it has been uploaded to Amazon S3?
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.
Q: Can I customize rules for processing based on the user uploading the file?
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: Which protocols should I use for securing data while in-transit over a public network?
A: You can choose to encrypt files stored your bucket using Amazon S3 Server-Side Encryption (SSE-S3) or Amazon KMS (SSE-KMS).
Q: What are my options to encrypt data at rest?
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: Which compliance programs does AWS Transfer Family support?
A: Files uploaded through services are verified by comparing the file’s pre- and post-upload MD5 checksum.
Q: How does the service ensure integrity of uploaded files?
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 monitor my end users’ activity?
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.
Q: How can I track amount of data uploaded and downloaded over the protocols?
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: How am I billed for use of the service?
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: Will my billing be different if I use the same server endpoint for multiple protocols or use different endpoints for each protocol?
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.
Q: I have stopped my server. Will I be billed while it is stopped?