Minimize network latency with your AWS Transfer for SFTP servers

Do you have clients spread across the globe accessing your SFTP server? Are your globally distributed end users experiencing performance issues due to geographical distance from your server endpoints? Wouldn’t it be great if you could provide similar performance to all your clients irrespective of their location? In this post, I provide you with best practices so you can achieve low latency for such users by setting up AWS Transfer for SFTP (SFTP) servers globally. I also walk through using latency-based routing in Amazon Route 53 (Route 53) to direct your users to the lowest latency SFTP server endpoint.

Route 53: Latency-based routing

Consider the setup in the following screenshot, described afterward:

My SFTP server endpoint is hosted in the London Region, and I have clients accessing the endpoint from London and Sydney. As expected, the client in London benefits from quick response times, since both the endpoint and bucket are in the same geographical region as the user. However, my client in Sydney is experiencing high latency and poor connectivity.

To provide a consistent experience for your users across all geographic regions, we set up SFTP servers in AWS Regions closer to where users are located. We then use Route 53’s latency-based routing to route traffic to the nearest server based on latency from the client machine. We enhance this setup further by having a dedicated regional Amazon S3 bucket mapped to the SFTP server. Data from regional Amazon S3 buckets is then replicated to a master Amazon S3 bucket via Cross-Region Replication, which serves as a common data store for all your SFTP servers.

Globally distributed architecture:

In the above scenario, Users P, R, and S are connecting from London, Sydney, and N. Virginia respectively. When they attempt to connect to sftp.example.com, the request reaches Route 53 for DNS resolution. Route 53 provides them with an IP address of the SFTP server in their corresponding Regions as they would observe minimal latency from these SFTP servers.

Now, let’s understand the setup for User Q, who is attempting to connect. When the user’s client initiates the connection, the request reaches Route 53, which determines and compares the latencies from the client across all three servers. Once the SFTP endpoint with the lowest latency for User Q is determined, the IP address of the SFTP server endpoint (London in the diagram above) is returned. At this point, the user is connected to use that endpoint.

Building your setup

To complete the setup, create S3 Buckets, SFTP servers, SFTP User configuration, and Route 53 records.

S3 buckets:

You need S3 buckets in all Regions where your servers reside. You can either use pre-existing buckets or create new buckets.

Once you have S3 buckets available in all Regions that you have your SFTP servers in, create one more bucket that would be a master bucket. You can create this in your Region of choice. Therefore, if you have five Regions where your servers are present, you need six S3 buckets.

S3 Cross-Region Replication:

Set up S3 Cross-Region Replication such that the master bucket has data from all the regional buckets. Configure S3 Cross-Region Replication on all of your regional buckets so they then replicate data to your master bucket. We recommend using S3 Event Notifications on the Master S3 bucket for post upload processing for data management.

SFTP server:

You need SFTP servers for all your Regions where you want an SFTP presence. If you have existing servers, you can use them or create new servers.

When you specify DNS hostnames, either choose None or Other DNS and specify the DNS Hostname. Choosing the Route 53 DNS Alias option doesn’t allow us to configure latency-based routing ahead in Route 53 setup.

SFTP user configuration:

While setting up User Configuration, there are a few pointers to keep in mind:

• You can either have a single credential store for your users across all servers or have multiple individual credential stores for each of your servers. We recommend a single credential store for ease of management, with individual records for each Region determining authorization to the S3 buckets in the Region. Optionally, you may want to have a read-only copy of the credential store in each Region to minimize your users’ login latencies.
• When the individual buckets are replicated to the master bucket, you want to ensure the objects written by different users do not overlap.
• We recommend using a specific naming mechanism to map a user’s HomeDirectory to a prefix in S3 such that it doesn’t overlap with other users. This can be used with Logical Directories so that your end users are presented with the same directory structure. This is independent of the endpoint they connect to and the S3 bucket they access because of it.

Route 53:

Following are the steps you must follow to set up latency-based routing in Route 53.

1. Open up the Route 53 Console and navigate to your Hosted Zone.
2. Select Create Record Set.
   • Name: Type in the DNS hostname that you would like to use with your SFTP server.
   • Type: Select CNAME
   • Alias: No
   • Value: Copy the default DNS hostname of your SFTP server. You obtain this value from the Endpoint field your SFTP server details in the AWS Transfer for SFTP Console.
   • Routing Policy: Select Latency
   • Region: Select the Region where your server resides.
   • Set ID: This field uniquely identifies the record set in the group of latency sets. You can enter any string that helps you identify this record set. Example: Global SFTP <Region>
   • Associate with Health Check: No
3. Save Record Set.
4. Similarly, you create Record Sets for all your SFTP servers.
5. Ensure the following:
   • The DNS hostname stays the same for all your Record Sets specified in Step 2-A.
   • The Region you selected for your latency-based routing is the same as the Region of your SFTP server.
   • The Set ID in Step 2-G is unique for all Record Sets.
6. Once done, you should have a CNAME DNS record for your hostname pointing to all your regional SFTP servers.

This concludes your setup. Once DNS records have propagated, you can test DNS resolution for your hostname to check which SFTP server you’ll be connected to. You can use the following commands:

• MAC or Linux: dig sftp.example.com
• Windows: nslookup sftp.example.com

Testing the Setup

Setup:

Here’s how I tested the setup to compare latencies:

Data transfer performance:

I measured data upload and used the same 2-GB file in all my tests. The same test can be applied for measuring download performance as well.

Command: sftp> put file.txt

Results format – transfer speed | time elapsed

When using a single-server setup, one without latency-based routing, performance from Client 1 is better compared to that of Client 2. There is a huge margin of almost 5 minutes, as the client is geographically distant from the server and S3 setup. However, after implementing latency-based routing, we see similar performance for Client 1 and 2, as they are connected to a server and S3 setup in their respective Regions.

Connectivity performance:

I used netcat command along with time to check for connectivity timings.

Command: time nc -vz sftp.example.com 22

Without latency-based routing, the differences in connectivity times vary by about 200 ms. This improves to a difference of about 10 ms when connecting to a SFTP server within the same Region.

Summary

In this blog post, we went over steps on how to set up and route your globally distributed end users to SFTP endpoints nearest to their location to reduce latencies. With AWS Transfer for SFTP, you can provide a consistent user experience on a global scale. To learn more about AWS Transfer for SFTP, visit the SFTP product page or get started building this architecture in the AWS Management Console. Thank you for reading, and please leave any comments or questions in the comment section below.