民间， 我在EC2实例上设置了SFTP服务器，以接收远程客户的文件，这些客户需要每天发送3个文件，全天多次（每个客户每天连接多次，每次都传输3个文件，保留他们的名字，但改变他们的内容）。如果同时连接的客户数量受到控制，这样可以正常工作，但是我无法准确控制每个客户何时连接（他们已经自动完成了连接过程）。我预计，如果有太多人试图同时上传文件，我可能会遇到瓶颈，并且一直在寻找整个过程的替代方案（＆＃34;分布式文件传输＆＃34;某种形式）。当我偶然发现根据定义分发的AWS S3时，我想知道我是否可以执行以下操作：
最后一点在SFTP上很容易，因为你可以设置一个＆＃34; root＆＃34;每个用户的文件夹，以便当用户连接到服务器时，它会自动登陆其相应的文件夹。不确定是否可以在S3上解决这类问题。此外，文件传输机制不仅必须提供访问存储桶的凭据，还必须提供＆＃34;子凭证＆＃34;访问该文件夹。
我一直在深入研究S3，但无法弄清楚这一整个想法是否可行（a）是否可行，（b）是否切合实际。我原来的SFTP解决方案的另一个限制是，根据定义，SFTP服务器是单点故障，我很乐意避免。如果有人能对此有所了解，我会感到激动（顺便说一句，其他解决方案也受到欢迎）。
请注意，我正在尝试完全取消SFTP服务器，而不是将S3存储桶作为＆＃34;根文件夹＆＃34;对于SFTP服务器。
谢谢
答案 0 :(得分：1)
您可以创建一个S3策略，该策略仅授予对特定前缀（＆＃34;文件夹＆＃34;在您的计划中）的访问权限。您的客户唯一需要的是获得PUT请求的权限。对于每个客户，您还需要创建一组访问密钥。
看来你过度复杂了。如果SFTP是瓶颈并且不是冗余，您始终可以创建一个比例组（在其前面使用ELB或DNS循环）并使用sshfs或goofys将S3安装到EC2实例。如果此处的成本不是问题，您甚至可以将EFS挂载为NFS共享。
答案 1 :(得分：1)
AWS有一个示例配置here，似乎可以很好地满足您的需求。
我认为你在传统的SFTP设置中考虑s3是绝对正确的。如果您采用基于服务器的方法，我同意谢格尔的答案 - 由共享EFS存储支持的自动扩展服务器组。当然，您必须拥有这些服务器的维护，这可能是也可能不是问题，具体取决于您的专业知识和愿望。
然而，纯粹的s3解决方案几乎肯定会更便宜，并且从长远来看需要更少的维护。答案 2 :(得分：0)
AWS Transfer 系列中现在有一项 AWS 托管 SFTP 服务。
https://aws.amazon.com/blogs/aws/new-aws-transfer-for-sftp-fully-managed-sftp-service-for-amazon-s3/
<块引用>今天，我们推出了适用于 SFTP 的 AWS Transfer，这是一项完全托管、高度可用的 SFTP 服务。您只需创建一台服务器、设置用户帐户并将该服务器与一个或多个 Amazon Simple Storage Service (S3) 存储桶相关联。您可以精细地控制用户身份、权限和密钥。您可以在 Transfer for SFTP 中创建用户，也可以使用现有的身份提供者。您还可以使用 IAM 策略来控制授予每个用户的访问权限级别。您还可以利用现有的 DNS 名称和 SSH 公钥，轻松迁移到 Transfer for SFTP。您的客户和合作伙伴将继续保持联系并照常进行转移，而不会改变他们现有的工作流程。