Een financiële onderneming host een data lake in Amazon S3. Elke nacht uploaden verschillende derde partijen financiële gegevens via SFTP. Het bedrijf draait momenteel zijn eigen SFTP-server op een EC2-instance in een publiek subnet; een cron-taak op die instance verplaatst geüploade bestanden naar het data lake. De SFTP-server is bereikbaar op sftp.example.com via Amazon Route 53. Hoe kan een solutions architect de betrouwbaarheid en schaalbaarheid van deze SFTP-oplossing verbeteren?

De juiste oplossing is het migreren naar AWS Transfer for SFTP. Dit is een volledig beheerde AWS-service die SFTP-functionaliteit biedt en automatisch schaalt, waardoor de betrouwbaarheid en schaalbaarheid aanzienlijk toenemen zonder dat u servers hoeft te beheren. De Route 53 DNS-record moet worden bijgewerkt om naar het endpoint van de Transfer server te verwijzen, zodat de bestaande URL blijft werken. Het verplaatsen van de EC2-instance naar een Auto Scaling group achter een ALB is ongeschikt omdat ALB's HTTP/HTTPS-verkeer verwerken, niet SFTP. Een NLB zou wel SFTP-verkeer kunnen doorsturen, maar lost de operationele overhead van het beheer van de SFTP-server op EC2 niet op en biedt geen automatische schaalbaarheid voor de SFTP-functionaliteit zelf. AWS Storage Gateway (file gateway) is bedoeld voor het verbinden van on-premises applicaties met S3 via standaard file protocols, niet als een externe SFTP-server voor derden.