我正在使用S3来备份对我的业务至关重要的大型文件。我是否可以确信，一旦上传，这些文件将被验证完整性并且完好无损？
有很多关于可伸缩性和可用性的文档，但我找不到任何关于完整性和/或校验和的信息。
答案 0 :(得分：2)
上传到S3时，会出现一个可选的请求标头（在我看来， 不是可选，但我离题了）Content-MD5。如果将此值设置为请求正文的MD5哈希的base64编码，则S3将在不匹配时直接拒绝您的上载，从而阻止上载损坏的数据。
ETag标题将设置为对象的十六进制编码的MD5哈希，用于单个部分上传（某些类型的服务器端加密除外）。
对于分段上传，Content-MD5标题设置为相同的值，但是对于每个部分。
当S3将多部分上传的部分组合到最终对象中时，ETag标头设置为每个部分的级联二进制编码（原始字节）MD5哈希的十六进制编码的MD5哈希值，加上-加上零件数量。
当你要求S3完成组合分段上传部分的最后一步时，你必须将它在原始部件上传过程中给你的ETag给它，这应该是为了确保S3结合了什么是你认为它结合的。不幸的是，您可以向S3询问有关您上传的部分的API请求，而一些懒惰的开发人员只会向S3询问此列表，然后将其发送回来，文档会警告，但是，嘿，它似乎有效，＆＃34;正确？
超过5GB的对象需要分段上传，超过5MB的对象需要分段上传。
正确使用，这些功能可确保完整上传。
如果您使用的签名版本4（旧版区域也是可选的）有一个额外的完整性机制，而且这个机制不是可选的（如果您实际使用的是V4）：上传必须具有请求标头x-amz-content-sha256，设置为有效负载的十六进制编码的SHA-256哈希值，如果此处存在不匹配，请求将被拒绝。
我的观点：由于其中一些功能是可选的，因此除非您审核其代码，否则您无法相信任何工具都能正确执行此操作。
我不信任任何人使用我的数据，所以为了我自己的目的，我编写了我自己的实用程序，内部称为＆＃34;迂腐上传者，＆＃34;它不使用SDK并直接与REST API对话。它计算文件的sha256并将其添加为x-amz-meta-...元数据，以便可以将其与对象一起提取以进行比较。当我上传压缩文件（gzip / bzip2 / xz）时，我将压缩和未压缩的sha存储在元数据中，并将压缩和未压缩的大小以八位字节存储在元数据中。
请注意，Content-MD5和x-amz-content-sha256是请求标头。他们不会返回下载。如果您要将此信息保存在对象元数据中，如此处所述。
在EC2中，您可以轻松下载对象而无需将其实际保存到磁盘，只是为了验证其完整性。如果EC2实例与存储桶位于同一区域，则如果使用具有公共IPv4或IPv6地址，NAT实例，S3 VPC端点或IPv6的实例，则不会为数据传输付费出口网关。 （如果通过NAT网关访问S3 over IPv4，则需要为NAT网关数据吞吐量付费）。显然有一些方法可以自动执行此操作，但是手动，如果您在控制台中选择对象，请选择“下载”，右键单击并复制生成的URL，然后执行以下操作：
$ curl -v '<url from console>' | md5sum # or sha256sum etc.
只需使用单'引号将控制台中的网址包装起来，因为它会预先签名，并且会在查询字符串中包含&，您不希望shell解释
答案 1 :(得分：0)
您可以在本地执行MD5校验和，然后根据S3上对象的MD5校验和进行验证，以确保数据完整性。 Here is a guide