拦截AWS S3请求

Question

嗨，我正在寻求实现这样的工作流程

Input-files => S3 (regular/multipart) uploader => My-processing-server => Output-files => S3 (regular/multipart) uploader => AWS-S3-server

换句话说，预期Input-files将根据S3请求上载到My-processing-server，以便My-processing-server可以处理Input-files来生成Output-files，然后上传到AWS-S3-server。

我想知道如何设置内部My-processing-server，它可以通过S3 API接受Input-files。

注意：我注意到client configuration允许配置proxy*字段。但是，如果我理解正确，它只是允许通过代理服务器传递流量，而无需在代理服务器上引入任何处理步骤或更改文件大小等。

Answer 1

您不能真正拦截对S3的API调用（如果我理解您的要求），而让自己的API接收调用-这样做的能力将破坏S3的API调用的信任链。 / p>

在这里，您有两种选择可用于执行与您要的操作类似的操作：

1. 创建您自己的API，并让用户上传到您的API来处理文件。这具有使用户更同步的优势（即，在S3上的文件可用之前，您的处理在上载时立即进行），但是它的缺点是迫使您处理正在执行转换的服务的所有扩展。如果您破坏了缩放比例，那么在繁重的工作时间内用户文件上传将失败。这看起来像是普通的旧版ec2服务器，ECS容器，lambda + api网关等。有多种托管Web服务器的方法。
2. 创建一个SQS队列，以侦听上载到S3的S3文件。然后，您的用户会将文件直接上传到S3（如果它是不受信任的用户，请确保您为此查找签名的URL），并且您将收听SQS队列以了解何时处理消息（创建输出文件） ）。在这种情况下，您可能希望将输出文件存储到单独的S3存储桶中，以避免处理循环。这样的好处是允许您依靠S3的内置缩放来处理大负载的时间，但是它的缺点是您的处理与用户是异步的。如果他们上传文件，他们将不会立即将其视为输出。

还有其他可能影响设计的软性因素（例如，是否允许上传非常大的文件，这将使您进入解决方案2），但这是您所要使用的两种常见设计模式。要求。