问题是解决方案无法提供复制过程状态的可见性，例如无法轻松地监视目标位置上丢失的对象或任何可能干扰过程并可能导致复制不起作用的权限问题，以及缺少复制滞后的反馈。
我们发现了几种工具类似于CRR Monitor https://aws.amazon.com/answers/infrastructure-management/crr-monitor/
，但是我们没有很好的经验，因为我们管理着数以千计的对象，这些对象可能花费数个每月需要数千美元用于CloudWatch事件，以及解决方案所需的服务的其他管理（DinamoDB，Kinesis等），还需要另一层“监视监视器”。
现在我们每天都在使用源和设计之间的S3对象清单比较使用AWS Athena查询进行排序，这也感觉像是一种破解，并且由于每天产生的库存量也不是最优的问题检测方法。
我希望看到一些替代方案的反馈，建议，想法或经验。理想的解决方案将是托管解决方案或“无服务器”解决方案，这将提高过程的可见性并提供对错误的快速检测。
#1 楼
我的解决方案基于@rombob之一。我使用S3并创建了源存储桶的每日S3库存文件（已复制）。然后，我使用Glue（在CloudFormation中）创建了一个Athena数据库和表。
然后我实现了一个触发lambda的S3事件。每次上载新的manifest.checksum文件（=新清单已完成）。
lambda在Athena表上执行查询，并检查是否存在复制状态为FAILED的对象。如果存在，则lambda发布到SNS主题以发送电子邮件。
#2 楼
仍然没有答案，并且在AWS上仍然没有CRR监控，这是简约的解决方案，欢迎任何反馈和建议。此监视器将仅显示目标中缺少哪些S3对象，不会提供已复制对象版本的可见性。 br />启用src（来源）和dst（目标）存储桶上的库存报告基于每个存储桶的库存报告创建Athena表（
src_inventory，dst_inventory）监控器
在生成两个清单报告之后运行Athena查询，例如每天，都可以从Lambda，Step Function，构建服务器或任何类型的cron作业中执行。
Athena查询示例，应在生成时显示目标存储桶中缺少对象的数量清单报告：
FROM src_inventory src
LEFT JOIN dst_inventory dst
ON src.key = dst.key
WHERE dst.key is NULL
AND src.dt = '2018-11-11-08-00';
结果可以报告为CloudWatch指标并通过CloudWatch警报进行监视。
#3 楼
此时，使用S3清单来监视复制是大型存储桶的最佳解决方案，而AWS自己也提出了该解决方案。由于AWS不会直接报告状态，因此涉及到许多对象时，任何其他解决方案都可能既昂贵又耗时。看来您走在正确的（也是唯一的？）轨道上。一个明显的想法是与AWS Support讨论此问题，请他们添加这样的功能。但这很明显。