あるチームがCloudWatch Logsのロググループに大量のログが蓄積されており、特定のエラーパターン（"ERROR: connection refused"）が発生したときにSlackに通知したい。既存のアーキテクチャへの変更を最小限にしてこれを実現する方法として最も適切なのはどれか。
- A. CloudWatch Logs Insightsで5分ごとにクエリを実行するLambda関数を作成し、エラーが見つかったらSNSに送信する
- B. CloudWatch Logs メトリクスフィルターを作成してエラーパターンを検知し、メトリクスが1以上になったらCloudWatchアラームでSNSトピックをトリガーしSlack Webhookを呼び出す
- C. Kinesis Data Firehoseにログをストリームして、Lambdaトランスフォームでエラーを検知してSNSに送信する
- D. CloudTrailでLambda関数のエラーログを監視してEventBridge経由でSNS通知する
解答と解説を見る
正解: B
CloudWatch Logsのメトリクスフィルター（選択肢B）はロググループに対してパターンマッチングを定義し、パターンに一致するたびにカスタムメトリクスをインクリメントするサービス機能。このメトリクスに対してCloudWatchアラームを設定し、アラーム状態になったらSNSトピックにメッセージを送信、SNSのHTTPサブスクリプションでSlack Webhookを呼び出すか、Lambda関数経由でSlackに通知する構成が最も標準的でシンプル。既存のアーキテクチャへの変更は最小限（追加リソースの設定のみ）で済む。選択肢Aのポーリング方式はリアルタイム性がなく、Lambdaの定期実行コストが発生する。選択肢DのCloudTrailはAPIコールの監査ログであり、アプリケーションのエラーログ監視には使わない。選択肢CのKinesisは大規模ログ処理には適しているが、シンプルなエラー通知にはオーバーエンジニアリング。
📚 関連サービスの解説: Amazon CloudWatch ・ Amazon SNS