S3基础

S3（简单存储服务）是AWS的标准云存储服务，提供从0到5TB的几乎任意大小的任意数量文件的文件（不透明「blob」）存储。（在2011年之前，最大尺寸为5 GB;现在较大的尺寸通过多部分支持得到很好的支持。）
项目或对象被放置在存储名称通常被称为键的命名桶中。主要内容是价值。
对象被创建，删除或更新。大对象可以流式传输，但是不能访问或修改一部分值; 你需要更新整个对象。
每个对象也有元数据，其中包括任意键值对，并以类似于HTTP标头的方式使用。有些元数据是系统定义的，有些元数据在从桶或CloudFront提供HTTP内容时很重要，您还可以定义任意元数据供您自己使用。
S3 URI：虽然通常在API中分别提供了存储区和密钥名称，但通常还是以「s3：// bucket-name / path / to / key」格式编写一个S3位置（这里的关键字是path /到/键）。（您还会在Hadoop系统中看到s3n：//和s3a：//前缀。）
S3与冰河，EBS和EFS： AWS提供了许多存储服务，除S3之外的一些提供文件类型抽象。冰川是更便宜和不常访问的档案存储。与S3不同，EBS允许通过传统文件系统随机访问文件内容，但一次只能附加到一个EC2实例。EFS是许多实例可以连接的网路文件系统，但成本较高。看比较表。

S3提示

对于大多数实际用途，您可以考虑S3容量无限制，无论是在文件的总大小和对象的数量。桶中的对象数量本质上也是无限的。客户通常拥有数百万个对象。
? 许可权：

?如果您在Amazon S3上存储业务数据，则合理管理许可权很重要。在2017年，像道琼斯和Verizon这样的公司看到了数据泄露的原因是由于对敏感数据的S3配置选择不当。如果您拥有大量资产和内部用户，那么稍后解决这个问题可能是一项艰巨的任务。
?有三种不同的方式来授予访问存储桶中Amazon S3内容的许可权。

IAM策略使用熟悉的身份和身份验证管理许可权方案来控制对特定操作的访问。
存储桶策略授予或拒绝整个存储桶的许可权。在S3中托管一个网站时，您可能会使用此方法，以使该存储桶公开可读，或通过IP地址限制对存储桶的访问。亚马逊的样本存储桶策略显示了许多这些策略派上用场的用例。
访问控制列表（ACL）也可以应用于存储在S3中的每个存储桶和对象。ACL授予超出IAM或存储桶策略中指定的额外许可权。可以使用ACL来授予对另一个AWS用户的访问许可权，也可以授予像普通公众一样的预定义组。这是强大的，但可能是危险的，因为你需要检查每个对象，看看谁有权访问。

?AWS的预定义访问控制组使用可能不符合允许访问的名称，这可能不符合您期望的名称：

「所有用户」向公众授予许可权，不仅限于在您自己的AWS账户中定义的用户。如果一个对象对所有用户都可用，那么可以通过表单的一个简单的HTTP请求来检索它http://s3.amazonaws.com/bucket-name/filename。访问这个类别的数据不需要授权或签名。
「经过身份验证的用户」授予使用AWS账户的任何人的许可权，同样不限于您自己的用户。因为任何人都可以注册AWS，所有的意图和目的也向公众开放。

这个ACL的典型用例与S3 的请求者支付功能一起使用。

?2017年8月，AWS添加了AWS Config规则，以确保您的S3存储桶安全。

?这些AWS Config规则仅检查您的存储桶策略和存储区级ACL的安全性。您仍然可以创建对象ACL，授予其他许可权，包括向全世界打开文件。

?如果您有不同类型的数据具有不同的敏感级别，请创建新的存储桶。这比复杂的许可权规则更不容易出错。例如，如果数据仅供管理员使用，如日志数据，则将其放入只有管理员可以访问的新存储区。
有关更多指导，请参阅：

如何保护Amazon S3存储桶
深入了解S3访问控制。
S3许可权如何工作？。

存储区命名：从全局命名空间中选择存储区（跨所有区域，尽管S3本身将数据存储在您选择的任何S3区域中），所以您会发现许多存储区名称已被占用。创建一个存储桶意味著取得该名称的所有权，直到删除它。存储桶名称对它们有一些限制。

在访问存储桶或其内容时，存储桶名称可以用作主机名的一部分<bucket_name>.s3-us-east-1.amazonaws.com，只要名称符合DNS。
通常的做法是使用公司名称的首字母缩写词或缩写词作为前缀（或后缀，如果您更喜欢DNS风格的层次结构）所有存储桶的名称（但请不要使用这个检查作为安全措施 - 这是非常不安全的并容易规避！）。
?包含「。」的存储桶名称（句点）在使用SSL时可能导致证书不匹配。使用 - 代替，因为这符合SSL的期望，并符合DNS。

版本控制： S3具有可选的版本控制支持，所有对象版本都保存在一个存储桶中。如果您想要更改存档或退出错误（注意：它缺少像Git这样的完整版本控制系统的功能集），这个功能最为有用。
耐用性： S3的耐用性非常高，因为它在内部保留了几个副本。如果不意外删除它，可以指望S3不会丢失您的数据。（AWS提供99.999999999％的似乎不可能的持久率，但这是一个基于独立失效率和复制水平的数学计算 - 不是一个真正的概率估计，无论哪种方式，S3都有很好的耐久性记录。是多比EBS耐久性更高！
??S3定价取决于存储，请求和传输。

对于传输，将数据放入AWS是免费的，但是您将付费。从S3转移到EC2在同一地区是免费的。转移到其他地区或一般的互联网并不是免费的。
删除是免费的。

S3减少冗余和不经常访问：大多数人使用S3中的标准存储类，但是其他存储类的成本更低：

??减少冗余存储（RRS）已被有效地弃用，并且具有比标准S3更低的耐久性（99.99％，所以只有四个九）。请注意，它不再参与S3的降价，所以它提供比标准S3更多的资金。因此，没有理由使用它。
不经常访问（IA）可让您获得更便宜的存储，以换取更昂贵的访问许可权。这对于已经处理的日志等档案很有用，但是可能要稍后再看。要了解在使用不频繁访问（IA）时节约成本的想法，可以使用此S3不频繁访问计算器。
冰川是作为独立产品讨论的第三种选择。
看比较表。

?性能：最大化S3性能意味著在带宽和每秒操作数方面提高整体吞吐量。

S3具有高度的可扩展性，因此原则上可以获得任意高的吞吐量。（一个很好的例子是S3DistCp。）
但是通常你被源和S3之间的管道和/或操作的并发级别所约束。
吞吐量当然是从AWS到S3，同一区域的EC2实例和S3存储桶之间最高的。
来自EC2的带宽取决于实例类型。请参阅ec2instances.info上的「网路性能」列。
从许多EC2实例分散式访问数据时，许多对象的吞吐量非常高。一次可以从数百或数千个实例读取或写入来自S3的对象。
但是，从单个实例顺序访问对象时吞吐量非常有限。单独的操作需要很多毫秒，而实例的带宽是有限的。
因此，为了执行大量的操作，有必要在各个实例上使用多个工作者线程和连接，对于较大的作业，也需要多个EC2实例。
多部分上传：对于大型对象，您希望利用多部分上传功能（从最小块大小为5 MB开始）。
大量下载：您也可以通过利用HTTP GET范围标头功能并行下载单个大型对象的块。
??列表分页：列表内容发生在每个请求1000个响应，所以对于具有数百万个对象列表的分区将需要时间。
? 关键字前缀：另外，操作上的延迟高度依赖于键名之间的前缀相似性。如果您需要大量的操作，为了避免「热点」，在密钥名称的前面（前6或8个字元）尽早考虑更多随机性的命名方案是非常重要的。

我们列举这是一个主要的问题，因为做大规模的重命名往往是痛苦的。
?请注意，不幸的是，关于随机密钥名称的建议与使用通用前缀进行一致布局来自动管理数据生命周期不一致。

对于AWS以外的数据，DirectConnect和S3 Transfer Acceleration可以提供帮助。对于S3传输加速，为了使用较近的端点，您需要支付大约相当于1-2个月的传输存储空间。

命令行应用程序：从命令行使用S3有几种方法：

最初，s3cmd是这项工作的最佳工具。它仍然被许多人使用。
常规的aws命令行界面现在支持S3，并且在大多数情况下非常有用。
s4cmd是一个替代品，通过多线程更加强调性能，这对于大文件和大型文件集是有帮助的，并且还提供类似于Unix的通配符支持。

GUI应用程序：您可能更喜欢GUI，或者希望为技术较差的用户支持GUI访问。一些选项：

在AWS控制台确实提供了使用S3图形化的方式。请谨慎告知非技术人员使用它，但是，由于没有严格的许可权，因此可以访问许多其他AWS功能。
在大多数情况下，传输是macOS上的一个很好的选择。
在MacOS和Windows上，Cyberduck是一个很好的选择，支持分段上传，ACL，版本控制，生命周期配置，存储类和伺服器端加密（SSE-S3和SSE-KMS）。

S3和CloudFront： S3与CloudFront CDN紧密集成。有关更多信息以及S3传输加速，请参阅CloudFront部分。
静态网站托管：

S3有一个静态的网站托管选项是简单地使配置HTTP指数和错误页面，并设置HTTP重定向的支持，以公共内容的S3。这是一个简单的方法来托管静态资产或一个完全静态的网站。
考虑在大部分或全部资产之前使用CloudFront：

像任何CDN一样，CloudFront显著提高了性能。
?SSL仅在S3的内置http://amazonaws.com域中受支持。S3支持通过自定义域来提供这些网站，但不支持自定义域上的SSL。但是，CloudFront允许您通过https提供自定义域名。Amazon通过Amazon Certificate Manager提供免费的SNI SSL / TLS证书。SNI不适用于非常过时的浏览器/操作系统。或者，您可以提供您自己的证书，以便在CloudFront上使用，以支付所有浏览器/操作系统的费用。
?如果跨域的资源包括CSS文件中的字体，则可能需要为服务这些资源的存储桶配置CORS。
由于现在几乎所有东西都转移到了SSL上，而且您可能想要控制域，所以您可能希望在S3之前使用自己的证书来设置CloudFront（并忽略AWS上的示例，因为它只是非SSL ）。
也就是说，如果您这样做，则需要考虑CloudFront上的失效或更新。您可能希望在文件名中包含版本或散列，因此无效是不必要的。

数据生命周期：

在管理数据时，理解数据的生命周期与理解数据本身同样重要。当把数据放到一个桶里时，想想它的生命周期 - 它的生命结束，而不仅仅是它的开始。
?通常，具有不同过期策略的数据应该存储在顶层的不同前缀下。例如，一些大量的日志可能需要每月自动删除，而其他数据是关键的，不应该删除。将前者放在单独的存储桶中或至少一个单独的文件夹是明智的。
?想想这个前面会省下你的痛苦。清理由许多工程师创建的大量文件是非常困难的，这些工程师具有不同的生命周期和不一致的组织。
或者，您可以设置生命周期策略以将旧数据归档到Glacier。小心将大量的小物体归档到冰川，因为它实际上可能花费更多。
还有一个称为「 不频繁访问」的存储类别，它具有与标准S3相同的耐用性，但是按GB标准打折。它适用于不常访问的对象。

数据一致性：对于有多个数据生产者和消费者的S3的任何使用来说，了解数据一致性至关重要。

在S3中创建和更新单个对象是原子的，因为你永远不会上传一个新的对象或改变一个对象，而让另一个客户端只看到部分改变的一半。
不确定性在于当你的客户和其他客户看到更新。
新对象：如果你创建一个新的对象，你将能够立即读取它，这就是所谓的写后读一致性。

好吧，另外需要注意的是，如果在对象存在之前先读取一个对象，然后创建它，那么您将得到最终的一致性（不是写后读）。
这不适用于任何列表操作; 新创建的对象不保证立即出现在列表操作中

对对象的更新：如果你覆盖或者删除了一个对象，你只能保证最终的一致性，即改变会发生，但你不能保证什么时候。
?对于很多用例来说，将S3对象视为不可变的（即按照惯例来决定它们将被创建或删除，但不会被更新）可以大大简化使用它们的代码，避免复杂的状态管理。
?请注意，到2015年之前，「美国标准」地区的最终一致性模型较弱，而其他（较新的）地区则是后写。这个问题终于得到纠正 - 但是请注意许多老博客提到这个！
慢速更新：在实践中，「最终一致性」通常意味著在几秒钟内，但预计几分钟或几小时的罕见情况。

S3作为文件系统：

一般来说，S3的API有固有的限制，使得S3很难直接作为POSIX风格的文件系统使用，同时仍然保留S3自己的对象格式。例如，追加到文件需要重写，这削弱了性能，并且对目录进行原子重命名，在打开文件时互斥，以及硬链接是不可能的。
s3fs是一个FUSE文件系统，可以继续尝试，但是由于这些原因，它具有性能限制和意外。
Riofs（C）和Goofys（Go）是最近尝试采用不同的数据存储格式来解决这些问题的努力，s3fs也可能有所改进。
S3QL（讨论）是一个Python实现，提供重复数据删除，快照和加密，但一次只能有一个客户端。
ObjectiveFS（讨论）是一个支持文件系统功能和并发客户端的商业解决方案。

如果您主要使用VPC，请考虑设置适用于S3 的VPC Endpoint，以便让VPC托管的资源轻松访问，无需额外的网路配置或跳跃。
跨区域复制： S3具有在一个区域与另一个区域之间复制存储区的功能。请注意，S3在一个区域内已被高度复制，因此通常这不是持久性所必需的，但对于遵从性（地理上分散的数据存储），较低的延迟或作为减少区域间带宽的策略通过在第二个地区镜像大量使用的数据来降低成本。
IPv4 vs IPv6：很长一段时间，S3仅在默认端点支持IPv4 https://BUCKET.s3.amazonaws.com。但是，截至2016年8月11日，它现在支持IPv4和IPv6！要同时使用，您必须在您首选的API客户端中启用dualstack，或直接使用此url方案https://BUCKET.s3.dualstack.REGION.amazonaws.com。这也延伸到S3传输加速。
S3事件通知：可以将S3配置为在存储桶事件上发送SNS通知，SQS消息或AWS Lambda函数。
?将您的个人用户（或IAM角色）限制在最低要求的S3位置，并对「已批准」位置进行编目。否则，S3往往成为垃圾场，人们把数据放在随机的地方，这些地方多年来没有清理干净，花了你大笔的钱。

S3陷阱和局限性

?多年来，每个账户有一个臭名昭著的100桶限制，不能提高，造成许多公司的痛苦。截至2015年，您可以要求增加。你可以要求增加限制，但是它仍然会被限制（通常在每个账户?1000以下）。
?注意不要对事务或对对象更新的排序作出隐含的假设。永远不要假设，如果你修改一个对象序列，客户端将会以相同的顺序看到相同的修改，或者如果你上传了一大堆文件，它们将全部出现在所有的客户端。
?S3具有一个SLA与99.9％的正常运行时间。如果您大量使用S3，那么随著磁碟或其他基础架构的失败，您将不可避免地看到偶然的错误访问或存储数据。可用性通常在几秒或几分钟内恢复。虽然可用性不是非常高，但如上所述，耐用性非常好。
?上传之后，对对象所做的任何更改都会导致完全重写对象，因此请避免使用常规文件进行附加操作。
?如上所述，最终的数据一致性有时会令人惊讶。如果S3受到内部复制问题的困扰，则可能会从一部分机器中看到一个对象，具体取决于它们所在的S3端点。那些通常在几秒钟内解决; 然而，当问题持续20-30小时时，我们看到了孤立的案例。
??MD5和多部分上传：在S3中，S3中的ETag头是对象的散列。在很多情况下，这是MD5散列。但是，当您使用多部分上传时，通常情况并非如此。一种解决方法是自己计算MD5，并将其放入自定义标题（例如由s4cmd完成）。
??不完整的多部分上传成本：即使上传失败并且没有创建S3对象，不完整的多部分上传也会产生存储费用。亚马逊（和其他）建议使用生命周期策略来清理不完整的上传并节省存储成本。请注意，如果你有很多这样的情况，那么可能有必要调查一下定期失败的事情。
??美国标准地区：以前，美国东部地区（也称为美国标准地区）在海岸线上被复制，导致等待时间变化更大。从2015年6月19日起，这不再是这种情况。所有Amazon S3区域现在都支持写后读一致性。亚马逊S3还将美国标准地区更名为美国东部（弗吉尼亚北部）地区，以符合AWS地区性命名惯例。
??S3认证版本和区域：在较新的地区，S3 只支持最新的认证。如果使用CLI或SDK的S3文件操作在一个区域中不起作用，但在另一个区域中正常工作，请确保使用最新的身份验证签名。