亚马逊AWS官方博客
S3 成本优化 – Part 2 常见问题以及解决方案
背景
在我们的第一篇博客文章中，我们讲述了一下如何使用Amazon Simple Storage Service（以下简称S3）生命周期，S3批量处理，Athena，CUR等功能对S3存储桶进行成本优化的过程。在接下来的这篇文章中我们会继续讲述一下对S3优化过程中会遇到的常见问题/注意事项以及如何解决这些问题。
实际例子
首先我们先看一个S3成本优化的案例（以下所有费用以美东1 佛吉尼亚为例）：
比如目前一个S3存储桶现状是
标准存储 ： 文件大小3000TB 大约存储成本 65000$/每月， 一共30亿文件数
Glacier ： 文件大小2000TB 大约存储成本 8200$/每月，一共50亿文件数
现有生命周期： 超过6个月的数据自动转换为Glacier，超过3年的数据自动删除
每个月新增4亿文件数，这部分新增文件大小为200TB，每个月新增文件数相同，所以同样会有200TB的文件自动转换为Glacier。
现有每月成本为 9.4万$： “标准存储费65000$”+“Glacier存储费8200$”+“每月新增Glacier存储费200X1024X0.004=820$”+“生命周期转换费400,000,000X0.05X0.001=20,000$”
如果考虑到Glacier Deep Archive比Glacier便宜很多的情况，直接选择方案将现有生命周期修改为 – “超过6个月数据自动转换为Glacier Deep Archive“, 保留“超过3年的数据自动删除”
优化后第一个月成本为 31.7万$：“标准存储费65000$”+“Deep Archive存储费2000X1024X0.00099 =2028$”+“每月新增Deep Archive存储费200X1024X0.00099=203$”+“一次性生命周期转换费5000,000,000X0.05X0.001=250,000$”
之后每个月成本为 8.7万：“标准存储费65000$”+“Deep Archive存储费2000X1024X0.00099 =2028$”+“每月新增Deep Archive存储费200X1024X0.00099=203$”X2+“每月生命周期转换费400,000,000X0.05X0.001=20,000$”
综合比较，第一个月多付出22.3万$，第二个月开始每个月节省7000$，长期来看需要31个月才能开始收回这一次“优化”的成本，而且由于已有的Glacier文件本身会在3年后删除，对他们进行再次转换损失的成本远远高于不转换的成本。 由此，可以基本定义此方案为优化失败。
可以从例子中总结出 – 注意优化中的各种费用和特定问题是成功优化成本的关键。
常见问题列表和对应解决方式
1.不同存储类型的互相转换方式
其他类型转换都比较明确，但是有一点可能需要注意到的是，Glacier虽然正常情况下需要解冻才可以读取里面的文件，但是可以不经过解冻直接转换为Glacier Deep Archive，而且因为Glacier Deep Archive是2019年才推出的新服务，很多客户可能目前的S3桶上都有Glacier。 如果没有意识到这一点，新增生命周期或者修改已有的生命周期为转换到Glacier Deep Archive，不仅仅其他类型会转换为Deep Archive，Glacier本身也会转换为Deep Archive。对于已经使用Glacier很久的客户这可能会导致一份很高的单月转换费用，需要特别注意。（比如本文开始提到的案例）
解决方式：
a.使用第一篇博客中提到的方法，用Athena查询出来非Glacier文件列表，然后使用S3批量处理做一次性转换为Glacier Deep Archive。 优点是没有其他额外费用生成，但是无法做到长期自动化，需要每个月手动操作。
b.可以使用S3批量处理单独给所有非Glacier文件打标签，然后之后上传的文件也使用应用打好标签，之后用生命周期根据标签转换为Glacier Deep Archive，从而排除已有的Glacier。优点是可以实现长期自动化，但是标签本身也有费用，1亿个S3标签的费用为100$/每月,需要考虑这部分额外费用。
2.避免使用大致的文件数量和文件大小做预估
默认在不开启任何特殊功能的情况下，大家可以在S3控制台中看到全桶统计的所有文件大小（BucketSizeBytes）和所有文件数量（numberofobjects）。
通过S3控制台–存储桶界面–管理–指标–存储 可以找到 。 如下所示：
但是这并不能给我们太多指引，因为平均文件个数，平均文件大小在实际生产中根据前缀（prefix）和应用不同可能会有很大差别，所以并不一定每个存储类型中的平均文件大小都是一致的。比如按照本文开始提到的例子使用平均算法来看的话，标准存储为30/50* 80 亿=48亿文件数，Glacier为20/50* 80亿=32亿文件数，跟实际值误差超过60%，如果使用不准确的数据进行优化方案推测，优化结果也可能会差别非常大，无法达到预期效果。
解决方式：使用我们在前一篇博客中提到的开启S3清单功能，然后使用Athena功能对实际数据进行详细的统计。
3.使用S3批量处理的时候作业失败，报错Task Target Couldn’t be URL decoded
使用S3批量处理的时候，大家可能会遇到类似这样的报错: Failed to parse task from Manifest XXXXX.csv at bytes offset XXXXXXXX. ErrorMessage: Task target couldn’t be URL decoded.这是由于提供的清单文件csv文件中有一些前缀含有非Unicode字符，原理是由于S3批量处理需要文件夹目录和文件名对于特殊字符已经经过转码处理（比如空格，百分号等）。
解决方式：开启清单模式的时候不要选择ORC或者Parquet，仅选择csv格式开启清单，这样生成的清单文件就会已经经过自动转码处理。
4.正常情况下删除文件是不收费的，但是优化之后在下月账单或者CUR中发现了DeleteObject收费
这是由于IA/智能分层/Glacier/Glacier Deep Archive这几个存储类别都有最少存储天数的要求，如果优化过程中删除了某些文件，但是这些文件没有达到相应存储类型的最少存储天数的要求，那么就会产生一次性的删除费用，补齐这些文件如果继续存满最小天数之后需要缴纳的费用。对于这几个存储类型， 最少存储天数要求分别是 ， IA和智能分层最少30天，Glacier最少存储90天，Glacier Deep Archive最少存储180天。
解决方式：没有解决方式，因为这是正常的使用费用。
5.使用S3批量处理或者生命周期转换文件的时候有部分文件并没有被转换
这是因为这部分文件大小小于128KB，小于128KB的文件无法被转换为IA或者智能分层存储。
解决方式：使用S3清单，查询Athena排除小于128KB的文件，再使用S3批量处理进行转换到IA或者智能分层。使用生命周期的话无法排除，会直接不处理这些小文件，也不会收取额外费用。
6.小文件转换为Glacier和Glacier Deep Archive可能会造成成本上升而不是下降
由于S3在将文件转换为Glacier或者Deep Archive的时候会自动增加40KB的元数据，其中8KB会继续存在标准存储上,32KB存在对应的Glacier或者Deep Archive。所以8KB以下的文件转换到Glacier或Deep Archive可能会让这部分数据存储费反而增加。
解决方式：使用S3清单，查询Athena看小于8KB的文件有多少（具体命令参考上一篇博客文章），如果数量巨大，那么需要查询Athena排除小于8KB的文件，然后使用S3批量处理来做类型转换。如果数量很少可以接受，还是可以使用生命周期做自动转换（但是无法排除小文件）。
7.生命周期建立之后很久没有运行，导致成本优化没有进行
生命周期规则每天只会在通用协调时间 (UTC) 的午夜（00:00）运行一次，并且最多需要48小时才能开始运行参考官方文档
8.S3批量处理作业建立好之后，运行时间很长一直显示运行中。
S3 批量处理转换所需的时间不是数据大小决定的，而是根据您对象的数量决定的。经过测试1天时间大概能够处理2亿文件量。
解决方式：S3批量处理作业会显示完成百分比，失败百分比等等。所以可以根据已经进行的时间预计完成时间。
总结
至此我们详细讲述了S3成本优化过程以及可能遇到的各种问题和解决方法，但是长期来看还会有进一步优化方案，比如改进应用将不需要频繁访问的文件直接上传为IA以节省后期转换费成本，应用上传文件的时候就打好业务标签以便于以后优化分析等等，但是由于不属于对已有的成本优化而是未来架构方面的优化，本文就不再一一探讨。最后希望大家在使用AWS的时候能更有效率的使用S3服务。