让我从一些背景开始，我们正在为数百万的用户提供免费的电子邮件服务，并且我们目前正在使用AWS托管我们的服务。 我们当前的后端架构如下：
邮件mime和附件被推送到AWS S3进行存储
AWS S3是就存储而言最便宜的选择，但还包括针对服务请求的额外定价（https://aws.amazon.com/s3/pricing/）。 它还包含一个称为“生命周期策略”的内容，它定义了S3中每个对象的规则，在我们的体系结构上，生命周期策略的定义是将30天后每个对象都移至S3 IA（不经常访问-S3 IA与标准S3相似，只是存储价格比标准S3便宜50％，但要求价格更高）。
在我可以描述我的问题之前，还有另外一件事要提及：如果S3标准存储中的对象的大小大于128K（S3 IA上的最小文件大小为128K），则该对象只会转移到S3 IA。
所以我的问题如下：
平均电子邮件哑剧大小约为30-40-50K，压缩后将缩小为3-4-5K（90％压缩-文本！）。 因此，如果我们在压缩后将电子邮件mime推送到S3，则生命周期策略将不适用于它，它将永远保留在S3标准中。 我要解决此问题的想法是为传入的电子邮件创建另一个Q，并等待足够数量的电子邮件，然后压缩每个电子邮件并将它们捆绑在一起，最小大小为10MB。 S3支持Content-Range标头，因此我可以检索单个电子邮件而无需检索整个捆绑对象。 当我需要删除一封要求我获取完整对象的电子邮件，删除特定电子邮件并将其重新放入S3时，会发生问题。 快速计算后，此过程效率很低。
有什么聪明的建议吗？更好的算法？