ある小売企業がAmazon Aurora MySQL互換エディションをECサイトのバックエンドデータベースとして使用しています。以下の課題があります。 ・セールイベント時に突発的なトラフィックが発生し、通常時の20倍のDBクエリが発生する ・セール期間以外はインスタンスがほぼアイドル状態になる ・開発・テスト環境でも同じデータベースサービスを使用したい ・運用コストを抑えつつ、ピーク時の性能を自動的に確保したい 既存のAurora MySQLクラスター（プロビジョニングインスタンス）をこれらの課題を解決するために移行すべき最適な構成はどれですか？
Aurora Serverless v2はACU（Aurora Capacity Units）を秒単位でシームレスにスケールアップ・ダウンします。最小ACUを小さく設定することでアイドル時のコストを削減し、最大ACUを高く設定することでセールピーク時の急激な負荷に対応できます。プロビジョニング型からのオンライン移行も可能で、開発・テスト環境でも同じサービスを利用でき、使用した分のコンピューティングのみ課金されます。 選択肢AのAurora MySQL Multi-AZ + Readレプリカは読み取りスケールには有効ですが、固定構成のため常時コストが発生し、急激なピーク時に自動スケールできません。 選択肢CのRDS for MySQLへの変更はAuroraの高可用性・パフォーマンス上の優位性を失い、根本的なコスト・スケーラビリティ課題は解決されません。 選択肢DのElastiCache for Memcachedはキャッシュ層として有効な場合もありますが、データベース自体の自動スケーリング機能を提供するものではなく、セールピーク時のDB書き込み負荷には対応できません。