EコマースサービスがAWS Lambdaを使用したサーバーレスAPIをAurora MySQL クラスターに接続して運用しています。セール期間中にLambdaが数千の同時実行まで急増すると「Too many connections」エラーが多発し、Auroraの最大接続数（db.r5.large では約1,000）に達してサービス障害が発生します。コールドスタート時に大量の短命な接続が同時確立されることも問題です。アプリケーションコードの大規模な変更なしにこの問題を最も効果的に解決するアーキテクチャはどれですか？
Amazon RDS ProxyはLambdaとRDS/Auroraの間で接続をプールし、数千のLambda同時実行が少数の永続的DB接続を共有できるようにします。Lambda側の接続先をRDS ProxyエンドポイントのDNS名に変更するだけで動作し、大規模なコード変更は不要です。RDS ProxyはIAM認証やSecrets Managerとも統合でき、セキュリティも向上します。 選択肢AのAuroraインスタンスのスケールアップはmax_connectionsを増加させますが、Lambda同時実行が継続的に増加すれば接続上限に再度到達するため根本解決にはなりません。Aurora Serverless v2への移行もコネクション数の根本的な解決にはつながりません。 選択肢CのLambda予約済み同時実行数の制限は接続数を抑制できますが、セール期間中の高負荷時にスループットが低下してサービス品質が劣化します。SQSキューによる平準化も有効な場面はありますが、追加のアーキテクチャ変更を伴います。 選択肢DのElastiCache for Redisは読み取りクエリのキャッシュには有効ですが、書き込みクエリや強い一貫性が必要なクエリでは依然としてAurora接続が必要となり、「Too many connections」問題の根本解決にはなりません。