2026.07.17 インフラ

AWSオブザーバビリティの実装｜ADOT・CloudWatch・Container Insightsで計装する構成【2026年時点】

AWS上で動くシステムの「なぜ遅いのか」「どこで落ちたのか」を追えるようにするのが、オブザーバビリティの実装です。本記事は、メトリクス・ログ・トレースの三本柱をAWSのどのサービスで担うのか、ADOT（AWS Distro for OpenTelemetry）でどう計装するのか、CloudWatch agentとどう併用するのかを、実装者の目線で整理します。CloudWatch・Application Signals・X-Ray・Container Insightsの役割分担を押さえたうえで、自前で作り込むべき範囲とマネージドに寄せるべき範囲の損益分岐まで、条件を示して言い切る構成です。オブザーバビリティそのものの定義はオブザーバビリティとは何かを整理した記事に譲り、本記事はAWSでの組み方に絞ります。

目次

まとめ：AWSオブザーバビリティ実装の全体像と選定の勘所

AWSのオブザーバビリティは、収集する信号ごとに担当サービスを分けて考えると設計がぶれません。インフラのメトリクスとログはCloudWatch agent、アプリのトレースとアプリメトリクスはADOTで集め、可視化と相関はCloudWatchのApplication SignalsやContainer Insightsに集約する、という三層の役割分担が基本形です。

選定の勘所は三つあります。第一に、計装レイヤーはOpenTelemetry準拠のADOTに寄せること。AWSはX-Ray SDKをメンテナンスモードに移し、計装の入口をADOTへ集約する方向にあります（2026年時点）。第二に、コンテナ環境ならContainer Insightsの拡張オブザーバビリティを有効化し、Pod単位のメトリクスを先に押さえること。第三に、SLOやサービスマップの作り込みは規模に見合うぶんだけにし、小規模なら標準メトリクスとアラームで止めることです。OpenTelemetryの仕様そのものはOpenTelemetry（OTel）とは何かを解説した記事で扱っています。

オブザーバビリティの三本柱とAWS監視サービスにおける位置づけ

実装に入る前に、AWSのどのサービスが何を担うのかを一枚に整理します。ここを曖昧にすると、同じ信号を二重に集めて課金だけがかさむ構成になりがちです。

メトリクス・ログ・トレースの三本柱とAWSサービスの担当範囲

オブザーバビリティは、メトリクス・ログ・トレースという三種類の信号（テレメトリ）で成り立ちます。メトリクスは時系列の数値、ログは出来事の記録、トレースはリクエストがサービスをまたいで流れた経路です。AWSでは、メトリクスとログの土台をCloudWatch、分散トレースをX-Ray、それらを相関させる上位レイヤーをApplication SignalsとContainer Insightsが担います。三本柱を別々のツールに分散させず、CloudWatchを収束先に置くのがAWSネイティブ構成の骨格になります。

従来型のしきい値監視とオブザーバビリティによる後追い調査の違い

従来の監視は「あらかじめ決めた指標がしきい値を超えたか」を見る発想でした。オブザーバビリティは「起きてから、なぜ起きたかを後追いで問える」状態を指します。マイクロサービスやサーバーレスで処理経路が動的に変わる構成では、事前に全ての障害パターンを想定しきれません。だからトレースで実際の経路を残し、高カーディナリティな属性で後から絞り込める設計が要ります。この違いを踏まえると、AWSでもX-Rayやトレース属性の設計を後回しにしない判断につながります。

AWSオブザーバビリティを構成する主要サービスと役割分担の全体像

AWSは2026年1〜5月だけでCloudWatch・X-Ray・Managed Grafana・Managed Service for Prometheusにまたがり40を超える更新を出しています。全てを追う必要はなく、実装の起点になるサービスを役割で押さえます。

CloudWatchとApplication Signalsが担うアプリ計装の範囲

CloudWatchはメトリクス・ログ・アラームの土台で、その上に立つApplication Signalsがアプリケーション性能管理（APM）の面を担います。CloudWatch Application Signalsの概要を解説した記事のとおり、これはサービスの応答時間やエラー率、SLO達成状況をコード変更なしで可視化する仕組みです。2026年7月にはService Eventsが加わり、ADOT SDKやCloudWatch ObservabilityのEKSアドオンで計装しておくだけで、例外やレイテンシー、デプロイイベントを自動で捕捉できるようになりました。まずApplication Signalsを入口に据えると、サービスマップとSLOから障害箇所を辿れます。

X-RayとContainer Insightsが埋めるトレースと基盤の可視化

X-Rayは分散トレースを担い、リクエストがサービス間をどう流れたかを追跡します。AWSはX-Ray SDKをメンテナンスモードに移しており、新規実装のトレース計装はADOT側へ寄せる流れです（2026年時点）。基盤側では、Container Insightsの拡張オブザーバビリティがECSとEKSで使え、クラスタやPod単位のCPU・メモリ・ネットワークを詳細に可視化します。アプリの遅延をX-Rayで、その下のコンテナ資源をContainer Insightsで見る、という縦の切り分けが実装の指針になります。

Managed PrometheusとGrafanaを選ぶ判断の分かれ目

PrometheusのメトリクスやPromQLの資産が既にあるなら、Amazon Managed Service for PrometheusとManaged Grafanaを組み合わせる選択肢が現実的です。CloudWatch側もネイティブのOpenTelemetryメトリクスやPromQL Query Studioを備え、PromQLで問い合わせられる範囲が広がっています。判断の分かれ目は、既存のPrometheus運用資産の有無です。ゼロから始めるならCloudWatchに寄せた方が構成要素が減り、Kubernetesで既にPrometheusを回しているならManaged Prometheusへ載せ替える方が学習コストを抑えられます。

ADOTによるOpenTelemetry計装とCloudWatch agentの併用

信号をどう集めるかの実体が計装（インストルメンテーション）です。AWSではADOTがその中心で、用途に応じて二つの構成を使い分けます。

ADOT CollectorとコレクターレスSDKの使い分け

ADOTは、OpenTelemetryの上流Collectorに、X-Ray・CloudWatch・Managed Service for Prometheus向けのエクスポーターとOTLPエクスポーターを足したディストリビューションです。構成は二通りあります。ひとつはADOT Collectorをサイドカーやデーモンとして立て、複数のアプリからテレメトリを集約して送る形。もうひとつはコレクターを立てず、ADOT SDKから直接送るコレクターレス構成です。後者はCloudWatchのOTLPエンドポイントへメトリクス・トレース・ログを直送でき、Lambdaのような短命な実行環境と相性が良い設計です。集約や加工が要るならCollector、構成を軽くしたいならSDK直送、と切り分けます。

CloudWatch agentとADOTの守備範囲の切り分け

CloudWatch agentとADOTは競合ではなく併存します。CloudWatch agentはホストのインフラメトリクスとログ収集を担い、ADOTはアプリのトレースとアプリメトリクスを担う、という守備範囲の分担です。EKSでは、CloudWatch ObservabilityのアドオンがCloudWatch agentとADOTをまとめて導入し、Container InsightsとApplication Signalsの両方に必要な計装を一括で整えます。ここを理解しないまま両者を重ねると、同じログを二重に送って取り込み料金を膨らませる事故が起きます。役割で線を引くのが第一歩です。

AWSオブザーバビリティ実装の進め方と初期構成の具体的な作り方

役割分担が決まったら、最小構成から段階的に広げます。全部を一度に有効化せず、投資対効果の高い順に積みます。

最小構成から段階的に広げるAWSオブザーバビリティ導入ステップ

実装は次の順序で積むと、各段階で得られる情報が明確になります。

  1. CloudWatch agentでインフラのメトリクスとログを収集し、基本的なアラームを敷く
  2. コンテナ環境ならContainer Insightsの拡張オブザーバビリティを有効化し、Pod単位の資源を可視化する
  3. ADOTでアプリを計装し、トレースをX-RayまたはOTLPエンドポイントへ送る
  4. Application Signalsを有効化し、サービスマップとSLOで性能を面として捉える
  5. 外形監視やダッシュボードを整え、通知先とエスカレーションを固める

この順序なら、上位のAPMを組む前に土台のメトリクスが揃い、障害時に見る場所が段階ごとに増えます。設計や導入を外部に相談する場合の窓口はAWSを含むインフラ構築の支援で受け付けています。

取り込みデータ量と保持期間から逆算するログとメトリクスの設計

オブザーバビリティのコストは、ほぼ取り込みデータ量と保持期間で決まります。全ログをそのままCloudWatch Logsへ流すと、開発環境の冗長ログまで課金対象です。実務では、収集する属性を先に決め、デバッグ用の詳細ログはサンプリングか短い保持期間に寄せるのが効きます。トレースも全リクエストを100%残す必要はなく、エラーや遅延リクエストを優先的にサンプリングする設計が有効です。「まず全部集める」ではなく「見る指標から逆算して集める」を初期設計の原則に置くと、後からの削減より手戻りが減ります。

オブザーバビリティを内製で作り込むかマネージドに寄せるかの損益分岐

ここは投資判断です。オブザーバビリティは作り込むほど見えるものが増えますが、運用の手間とコストも比例して増えます。規模で割り切ります。

サービスが少数のときSLOとダッシュボード作り込みを見送る場面

結論から言えば、動かしているサービスが一つか二つの小規模なら、Application SignalsのSLO設計やカスタムダッシュボードの作り込みは過剰です。この段階では、CloudWatchの標準メトリクスと少数のアラーム、加えてエラーログの通知があれば運用は回ります。SLOを精緻に定義しても、対象サービスが少なければ改善アクションに結びつく頻度が低く、定義と保守の手間だけが残ります。作り込みが効いてくるのは、サービス数が増えて障害の切り分けに時間がかかり始めてからです。「サービスがまだ数個」の段階でSLOを作り込むのは見送るという判断を、ここで明確に置きます。

サービス数が増えた段階でマネージドに寄せて総コストを抑える条件

逆に、マイクロサービスが十数個を超え、チームをまたいで障害調査が発生する規模になると、計装とSLOへの投資が回収局面に入ります。この段階では、自前でPrometheusとGrafanaのクラスタを組んで運用するより、Managed Service for PrometheusとApplication Signalsに寄せた方が、可用性の担保やスケーリングの手間を基盤側へ預けられるのが利点です。自前運用が有利になるのは、既存のPrometheus資産が大きく、独自の集計や長期保持の要件が明確なときに限られます。要件が「標準的なAPMとメトリクスで足りる」なら、マネージドに寄せた方が総保有コストは下がります。

よくある質問

AWSでオブザーバビリティを実装する前に、判断でよく詰まる点に答えます。

CloudWatchとX-Rayはどう使い分けますか？

CloudWatchはメトリクス・ログ・アラームの土台とダッシュボードを担い、X-Rayはリクエストがサービス間を流れた経路を追う分散トレースを担います。両者は上下の関係で、資源やログの異常をCloudWatchで捉え、その原因となった処理経路をX-Rayで辿る、という組み合わせで使います。新規のトレース計装はADOT経由へ寄せるのが2026年時点の流れです。

ADOTとCloudWatch agentのどちらを入れるべきですか？

どちらか一方ではなく、役割で併用します。ホストやコンテナのインフラメトリクスとログはCloudWatch agent、アプリのトレースとアプリメトリクスはADOTの担当です。EKSではCloudWatch Observabilityのアドオンが両方をまとめて導入するため、個別に入れる手間を省けます。役割の線引きをせずに重ねると、データの二重送信で料金が膨らむ点に注意してください。

Container Insightsの拡張オブザーバビリティとは何ですか？

Container Insightsが集めるコンテナ基盤のメトリクスを、より詳細な粒度で可視化する機能です。ECSとEKSで使え、クラスタやサービス、Pod単位でCPU・メモリ・ネットワークの状態を細かく追えます。従来より深い粒度で資源のボトルネックを特定できるため、コンテナ環境では初期段階で有効化しておく価値があります。

OpenTelemetryは必ず使う必要がありますか？

必須ではありませんが、計装をOpenTelemetry準拠にしておくと、後からベンダーを変えても計装コードを書き直さずに済みます。AWSはX-Ray SDKをメンテナンスモードに移し、ADOTを計装の中心に据える方向です。長期の保守を見据えるなら、AWS固有のSDKよりADOT経由でOpenTelemetryに寄せておく判断が無難です。

小規模なシステムでもオブザーバビリティは必要ですか？

必要ですが、規模に見合う範囲に絞ります。サービスが一つか二つなら、CloudWatchの標準メトリクスとログ、少数のアラームで十分です。SLOやサービスマップの作り込みは、サービス数が増えて障害の切り分けが難しくなってから段階的に足せば間に合います。最初から全機能を有効化する必要はありません。

関連記事

資料請求

RELATED POSTS 関連記事

一覧へ戻る