企業の DevOps チームが Lambda 関数で CloudWatch の GetMetricData API を1分ごとにポーリングし、メトリクスを Datadog へ転送しています。監視対象メトリクスが増加するにつれ API レート制限エラーが頻発し、データの遅延が最大5分に達しています。ポーリング方式を廃止し、2〜3分以内のほぼリアルタイムでメトリクスをプッシュベースで Datadog へ転送するアーキテクチャとして最も適切なものはどれですか？
CloudWatch Metric Streams は継続的なプッシュ型で Amazon Data Firehose にメトリクスを送信し、2〜3分以内にサードパーティへ転送します。ポーリングと異なり API レート制限の影響を受けず、Datadog・Splunk・New Relic 等の HTTP エンドポイントへ直接配信できます。名前空間・メトリクス単位でのフィルタリングによりコスト最適化も可能で、プロフェッショナルレベルの大規模監視基盤に適しています。 選択肢AのEventBridge スケジュールルールで Lambda を30秒ごとに起動する方式は、ポーリングベースであり API レート制限の根本的な解決にはなりません。 選択肢CのCloudWatch エージェントを EC2 上にメトリクスプロキシとしてデプロイする方式は、collectd プラグインでの転送は複雑で、スケーラビリティに欠けます。 選択肢DのAmazon Managed Grafana に CloudWatch と Datadog の両方をデータソースとして設定する方式は、メトリクスの統合表示に向いており、プッシュベースのリアルタイム転送には適しません。