New Relic-AWS連携のコスト、見直しませんか？CloudWatchのメトリクスをフィルタリングする一手間で、無駄なコストと監視のノイズを削減できます。その具体的な設定方法を分かりやすく解説します。
はじめに
New Relic の AWS 統合は、クラウド環境の可観測性を高める強力な機能です。特に CloudWatch Metric Stream を利用した連携は、リアルタイムに近いデータ収集を可能にします。
しかし、デフォルト設定のままでは、AWS アカウントで利用可能な「すべて」のメトリクスが New Relic に送信されてしまいます。これにより、データを連携している Amazon Data Firehose の転送量の増加、 New Relic のデータ取り込み（Ingest）量の増加よって、コスト増につながるケースや、不要なメトリクスがノイズとなり、本当に重要な情報を見つけにくくなるという課題があります。
本記事では、CloudWatch Metric Stream のフィルタリング機能を活用し、監視に必要なメトリクスだけを賢く選択して New Relic に送信する方法を、具体的な手順を交えて解説します。これにより、コスト最適化と監視の効率化を両立させましょう。
最新のアップデートの詳細はこちら
New Relic アップデート一覧
無料のアカウントで試してみよう！
New Relic フリープランで始めるオブザーバビリティ！
なぜメトリクスのフィルタリングが必要なのか？
コストの観点 - "塵も積もれば山となる"
AWS 側のコスト: CloudWatch Metric Stream は、Amazon Data Firehose を使用しているため転送するデータ量に基づいて課金されます。対象を絞ることで、このコストを抑制できます。
New Relic 側のコスト: New Relicの料金体系は、取り込んだデータ量（GB）に基づきます。不要なメトリクスの送信を止めることは、Ingestコストの削減に直結します。
例えば、あまり重要視していないサービスの大量のメトリクスまで送信すると、コストが想定以上に膨れ上がる可能性があります。
監視効率の観点 - ノイズの海から重要な"シグナル"を救い出す
インシデント対応の遅延: 障害発生時、ノイズの中から原因（シグナル）を探す作業に時間を取られ、問題解決が遅れます。
分析と思考の中断: クエリ作成時、無関係な選択肢が多すぎると、目的のメトリクスを探すだけで消耗し、分析の思考が中断されます。
監視の形骸化: ノイズに埋もれて重要指標が不明確になり、形だけのダッシュボードや機能しないアラートを生む原因となります。
Metric Stream のフィルターの設定変更手順
前提条件
既に CloudWatch Metric Stream の設定が完了している状態を想定しています。
まだ設定していない方はこちらの記事を参考に設定してみてください。
ステップ1: 既存のメトリクスストリームの特定
AWSマネジメントコンソールにログインし、CloudWatchのサービスページへ移動。
左側のナビゲーションメニューから「ストリーム」を選択。
現在New Relicへの送信用に稼働しているメトリクスストリーム（例: NewRelic-Metric-Streamなど）を探し、その名前をクリックします。
ステップ2: 編集画面への移動とフィルタリング設定
メトリクスストリームの詳細画面で、「編集」ボタンをクリックします。
画面をスクロールし、「ストリーミングするメトリクス」セクションを見つけます。おそらく現在は「すべてのメトリック」が選択されています。
ここが最重要ポイントです。「メトリクスを選択」を選ぶと名前空間とメトリクスを選択することができます。
設定の方法は簡単です。
ドロップダウンリストから、EC2 (AWS/EC2)、RDS (AWS/RDS)、Lambda (AWS/Lambda)など、対象のサービスだけを選択します。
メトリクスのドロップダウンリストから、対象のメトリクスを選択します。
選択すると下記のように設定が追加されていきます。複数設定する場合は名前空間の選択から再度設定すると追加されます。
「含む（Include）」で必要なものだけを選ぶ
「含む」にチェックを変更して対象のメトリクスを選択すると選択したメトリクスのみが New Relic へ連携されます。
メリット: 必要なものが明確な場合に最適。意図しないサービスのメトリクスが追加されるのを防ぎます。
「除外（Exclude）」で不要なものを除外する
「除外」にチェックを変更して対象のメトリクスを選択すると選択したメトリクス以外が New Relic へ連携されます。
メリット: 基本は全体を把握しつつ、特定のノイズ源だけを排除したい場合に有効です。
ステップ3: 変更の保存
フィルタリングルールを設定したら、ページ下部の「変更を保存」をクリックします。これで設定変更は完了です。
発展編：Terraform/CloudFormationによるフィルタリング設定のコード化
監視設定もコードで管理したいと考えるエンジニアは多いでしょう。
CloudWatch Metric Streamのフィルタリング設定は、TerraformやAWS CloudFormationなどのIaCツールで管理が可能です。これにより、設定の再現性を担保し、レビュー可能な状態に保つことができます。
Terraformでの設定例
Terraformを使用する場合、aws_cloudwatch_metric_streamリソース内でフィルタリング条件を指定します。include_filter（含める）とexclude_filter（除外する）は併用できないため、どちらかを選択します。
✅ "含む (Include)" 場合の例
監視対象のサービス（EC2, RDS, Lambda）が明確に決まっている場合のコード例です。
Terraform
resource "aws_cloudwatch_metric_stream" "main" {
# ... (他の設定は省略) ...
# 転送したいサービスの名前空間とメトリクスだけを指定
include_filter {
namespace = "AWS/EC2"
metric_names = ["CPUUtilization", "NetworkOut"]
}
include_filter {
namespace = "AWS/EBS"
metric_names = []
}
}
CloudFormationでの設定例
CloudFormation では、AWS::CloudWatch::MetricStream リソースの IncludeFilters または ExcludeFilters プロパティで設定します。
✅ "除外 (Exclude)" する場合の例
コストに関するメトリクスなど、特定のサービスを除外したい場合のコード例です。
YAML
Resources:
# ... (他の設定は省略) ...
CloudWatchMetricStream:
Type: AWS::CloudWatch::MetricStream
Properties:
Name: !Ref CloudWatchMetricStreamName
FirehoseArn: !GetAtt FirehoseStreamToNewRelic.Arn
RoleArn: !GetAtt MetricStreamRole.Arn
OutputFormat: 'opentelemetry0.7'
# 特定のメトリクスのみをストリームから除外する設定
ExcludeFilters:
- Namespace: AWS/EC2
MetricNames:
- NetworkPacketsIn
- NetworkPacketsOut
# 他にも、AWS/Billing名前空間のメトリクスを全て除外することも可能
- Namespace: AWS/Billing
IaCを導入することで、監視設定の一貫性が保たれ、チームでの運用がよりスムーズになります。ぜひ導入を検討してみてください。
運用上の注意点：設定変更前に確認したいこと
フィルタリング設定はコストとノイズの削減に非常に効果的ですが、いくつか注意すべき点があります。設定を変更する前に、以下のポイントを確認しておくことをお勧めします。
1. 絞り込みすぎのリスク
「必要なメトリクス」まで消さないために
コスト削減を意識するあまり、障害調査やパフォーマンス分析に将来必要となる可能性のあるメトリクスまで除外してしまうリスクがあります。
特に最初の設定では、「少し広めにフィルタリングし、後から不要なものをさらに削っていく」という段階的なアプローチが安全です。
✅ おすすめのアプローチ:
現状のダッシュボードとアラートを確認する: チームが現在監視しているダッシュボードや、設定されているアラートで使われているメトリクスをリストアップし、それらが必ず含まれるようにしましょう。
「もし障害が起きたら？」と想像する: 担当サービスの障害対応をシミュレーションし、「原因調査にどのメトリクスを見るか？」を考えてみてください。そのメトリクスは除外対象から外すべきです。
2. 設定反映のタイムラグ
Metric Stream のフィルター設定を保存しても、すぐに New Relic へのデータ転送量に反映されるわけではありません。AWS 内部の処理やデータのパイプラインには、数分程度のタイムラグが生じることがあります。
「設定したのにデータ量が減らない」と焦らず、少し時間をおいてから New Relic のデータ取り込み量（Ingest）や、AWS の Firehose のメトリクスを確認してください。
3. 定期的なフィルタリング内容の見直し
「一度設定したら終わり」 ではありません。アプリケーションに新しい機能が追加されたり、新しいAWSサービスを導入したりすると、監視すべきメトリクスも変化します。
「四半期に一度」のように、定期的にフィルタリング内容が現状の監視要件に合っているかを見直す運用をチームで取り決めておくと、いざという時の「監視漏れ」を防ぐことができます。
まとめ
CloudWatchメトリクスストリームの「全件送信」はセットアップこそ簡単ですが、運用フェーズでは見直しの絶好のポイントです。今回紹介したフィルタリング設定を適用することで、無駄なコストを削減し、監視の精度を高めることができます。ほんの数クリックの変更で、よりスマートなオブザーバビリティ環境を実現しましょう。
New Relicでは、新しい機能やその活用方法について、QiitaやXで発信しています！
無料でアカウント作成も可能なのでぜひお試しください！
New Relic株式会社のX(旧Twitter) や Qiita Organizationでは、
新機能を含む活用方法を公開していますので、ぜひフォローをお願いします。
無料のアカウントで試してみよう！
New Relic フリープランで始めるオブザーバビリティ！
