FTP followup

A few years ago I wrote up an article about some of the issues we had migrating our FTP server to AWS. Luckily for us the world continued to move forward. CDK Global decided to spin our division off as Sincro LLC. As part of that we needed to also support SFTP in AWS rather than depending on a custom server CDK was hosting in their datacenter. We weren't interested in managing a one off server for this, and we didn't have any tooling or process for dealing with ssh keys and account creation/deletion for customers on the engineering side of things.

AWS just happened to have a solution for us with https://aws.amazon.com/aws-transfer-family/ We stood up a solution via terraform which worked pretty well. Originally we backed it with S3 but we ran into some performance and behavioral issues with our batch processes that were all written expecting on an NFS mounted filesystem. After a short period of time of experiencing problems we ended up switching to EFS as the backing datastore rather than revisiting the code in literally hundreds of batch processes written in Java and Perl. Since no one on the teams owning these processes knew Perl, that was the final decision point.

This article is primarily a followup to let folks know that our semi-hand-built FTP system doesn't exist anymore and doesn't need to. We instead leverage a managed service and have full automation via terraform for managing it. Additionally we don't have to pay for a certificate anymore and leverage an Amazon issued cert. User management is via a lambda that talks to our existing identity management service which means our support people can manage SFTP users the same as they would manage customer access to GUI tools.

要查看或添加评论,请登录

Douglas Leonard的更多文章

  • FTP in AWS challenges

    FTP in AWS challenges

    My company recently moved to have our primary datacenter hosted in AWS. As part of that we had to build a large amount…

社区洞察

其他会员也浏览了