一家现场活动公司在Auto Scaling组中的EC2实例上运行票务应用程序，并使用PostgreSQL作为数据库。销售活动会导致需求出现一次性的计划性高峰。该公司需要一种扩展方法，以在这些计划性销售活动期间最大限度地提高可用性。哪种解决方案能满足这些需求？

此解决方案通过计划性扩展来应对EC2实例的已知流量高峰，确保在销售活动开始前有足够的计算资源。将数据库托管在Amazon Aurora PostgreSQL Multi-AZ DB集群上，提供了高可用性和可扩展性。在销售前通过EventBridge触发Lambda创建并故障转移到一个更大的Aurora副本，可以应对数据库的读写负载激增，而Aurora的存储是自动扩展的。销售结束后再缩减副本，优化了成本。 其他选项的不足在于： 预测性扩展虽然可以应对周期性负载，但对于“一次性的计划性高峰”不如计划性扩展直接有效。 使用Amazon RDS for PostgreSQL Multi-AZ并创建更大的只读副本，然后故障转移到该副本，虽然可行，但Aurora PostgreSQL在性能和扩展性方面通常优于RDS PostgreSQL，特别是在应对高并发和突发负载时。Aurora的存储层也更具弹性。 预热数据库的Lambda函数可能无法完全解决数据库层面的扩展问题，特别是在写入密集型场景下。