Amazon CloudWatch Application Signalsとは｜料金・SLO設計・対応言語を実装目線で解説【2026年版】

Amazon CloudWatch Application Signalsは、OpenTelemetryベースの自動計装でアプリケーションの遅延と障害を可視化するAPM機能です。2024年6月10日に一般提供が始まりました。導入判断でいちばん詰まるのは「結局いくらかかるのか」で、公式の料金ページには課金モードが2つ並んでいて単価の桁も単位も違います。ここでは料金の計算方法を実額まで落とし、収集されるメトリクスの正体、SLOの2つの型、対応言語ごとの手当ての差、そして有効化後に実際につまずく仕様までを、AWS公式ドキュメントと料金ページで確認しながら整理します。

まとめ

• 課金モードは2つ。Transaction Searchを有効にしないなら「Application Signals件数」課金（バージニア北部で最初の1億件が100万件あたり1.50 USD）、有効にするならスパンの取り込み量課金（0〜10TBで1GBあたり0.35 USD）＋インデックス課金（100万スパンあたり0.75 USD）に変わります。
• SLOそのものは安い。1つのSLOはSLIの計測周期ごとに2件のシグナルを生成するため、1分周期なら1本あたり月87,600件＝約0.13 USD。100本並べても月13 USD程度で、コストの主因はSLOではなくスパンの取り込み側です。
• 収集される標準メトリクスはLatency・Fault・Errorの3つだけ。ダッシュボードのAvailabilityは送信されているメトリクスではなく(1 - Faults/Total)*100で計算された値で、HTTP 4XXは成功扱いです。
• 言語によって手当てが違う。Java・.NET・Python・Node.jsはADOT SDKでゼロコード計装できますが、Go・PHP・Rubyは専用のADOT SDKが無く、標準のOpenTelemetry計装＋Transaction Searchの有効化が前提になります。
• ランタイムメトリクス（GC・メモリ・スレッド）はNode.jsでは収集されません。Java・Python・.NETのみです。
• 短縮名での検索意図やECS・Lambdaでの導入手順はApplication Signalsとは何か？概要と基本機能をやさしく解説で扱っています。

CloudWatch Application Signalsが自動で可視化する範囲

Application Signalsは、アプリケーションにOpenTelemetryの自動計装を仕込み、サービス単位・オペレーション単位の性能を標準化されたダッシュボードに出します。AWSはGA発表で「no manual effort, no custom code, and no custom dashboards」でvolume・availability・latency・faults・errorsが見えるようになる、と説明しています。計装コードを書かずに済むのが従来のX-Ray単体運用との最大の差です。

収集される標準メトリクスは3つ、Availabilityは計算値

ここは誤解が多いところです。Application SignalsがApplicationSignals名前空間に送るメトリクスは次の3つに限られます。

ダッシュボードに出るAvailabilityはこのリストに入っていません。公式ドキュメントは(1 - Faults/Total)*100で算出すると明記しており、TotalはSampleCount(Latency)から導出されます。つまり4XXはAvailabilityを下げません。「認証エラーが多発しているのにAvailabilityが100%のまま」という状況は仕様どおりで、4XXを追うならErrorメトリクスに別途アラームを張る必要があります。この4つの観点の整理はGolden Signals（4つのゴールデンシグナル）とは？SREの監視指標と実装・アラート設計を解説と合わせて読むと設計しやすくなります。

サービスメトリクスと依存関係メトリクスは別物

マイクロサービスAがBを呼ぶとき、リクエストを処理するB側が「サービスメトリクス」を、呼び出す側のAが「依存関係メトリクス」を出します。ディメンションもそれぞれ違い、サービスメトリクスはService・Operation・Environmentの3つ、依存関係メトリクスはこれにRemoteService・RemoteOperation・RemoteEnvironment・RemoteResourceIdentifier・RemoteResourceTypeが加わります。

設計時に効く制約が1つあります。Operationの最大長は1024文字ですが、オペレーション単位でSLOを設定できるのは名前が194文字以下のときだけです。長いパスをそのままオペレーション名にしていると、メトリクスは見えるのにSLOだけ張れないという状態になります。

料金｜2つの課金モードと実額での試算

Application Signalsの料金がわかりにくいのは、Transaction Search（トランザクション検索）を有効にするかどうかで課金対象そのものが入れ替わるからです。Transaction Searchは、サンプリングに左右されずスパンを全件取り込み、X-Ray Trace Summariesとして検索できるようにする機能で、CloudWatchコンソールのApplication Signals設定から有効化します。有効にすると「件数で買う」課金から「バイト数で買う」課金へ切り替わる、と考えると整理できます。以下はAWSのCloudWatch料金ページに掲載されているバージニア北部（us-east-1）の単価です。

無料利用枠はどちらのモードも「アカウントあたり3か月間、または下記の上限に達するまで」の早い方です。上限はTransaction Searchを使わない場合が1億シグナル（この枠ではトランザクションのspanは見えません）、使う場合が100GBの取り込み＋100万スパンのインデックスです。加えて、取り込んだスパンの1%相当までのインデックスは取り込み料金に含まれ、追加のインデックス料金はかかりません。単価はリージョンで異なるため、東京リージョン（ap-northeast-1）の実額はAWS Pricing Calculatorで確認してください。

SLO 1本あたりの月額は計算できる

AWSは「各SLOはSLIの計測周期ごとに2件のApplication Signalsを生成する」と定義しています。式が明示されているので、SLOの費用は見積もりではなく計算で出せます。以下はTransaction Searchを有効にしていない場合の単価で、月の長さはAWS料金ページの計算例に合わせて43,800分（730時間）としています。

1分周期なら月43,800周期、これに2を掛けて87,600件、第1階層の単価1.50 USD/100万件を適用して約0.13 USDという計算です。この式はAWS料金ページの計算例（1分・5分・10分の周期のSLOを10本ずつで合計1,138,800シグナル）を再現でき、同じ前提であることを確認できます。第1階層の1億件を使い切るには1分周期のSLOが1,141本必要なので、現実的な規模ではSLOが階層を跨ぐことはまず起きません。

この試算からの判断ははっきりしています。SLOの本数を絞ってコストを削るのは筋が悪い。100本並べても月13 USD程度で、削っても効果は誤差にしかなりません。Application Signalsで請求額が膨らむのは、Transaction Searchを有効にして全リクエストのspanを取り込んだときです。1,000GB取り込めば350 USDになり、SLO 100本の約27倍に達します。コストを制御する対象はSLOではなくspanの量で、その手前で効くのがトレースサンプリングのヘッドベースとテールベースの使い分けです。

対応プラットフォームと言語｜ADOT SDKの有無で手当てが変わる

Application SignalsはAmazon EKS、ネイティブKubernetes、Amazon ECS、Amazon EC2でサポート・テストされており、Lambdaにも対応しています。EC2向けの手順は、CloudWatchエージェントとAWS Distro for OpenTelemetry（ADOT）が動くプラットフォームであれば同様に機能するとされています。

対応ランタイム版数｜Java 8〜25・Python 3.10〜3.14・Node.js 18〜24

Go・PHP・RubyはTransaction Searchが前提になる

この3言語には専用のADOT SDKが用意されていません。公式ドキュメントは標準のOpenTelemetry Instrumentation SDKを使い、Transaction Searchを有効にしたうえでゼロコード計装を行うよう案内しています。前節の料金表と突き合わせると意味がはっきりします。Go・PHP・Rubyを計装する時点で、課金は件数ベースではなくスパンの取り込み量ベースに乗ることが確定する。JavaやPythonと同じ感覚で「まず無料枠で試す」と考えていると、想定していた1億シグナルの枠ではなく100GBの取り込み枠のほうが先に減っていく。

Goにはさらに固有の制約があります。自動計装ライブラリがAWS SDKの計装に対応していないため、otelaws.AppendMiddlewares(&cfg.APIOptions) の併用が必須です。加えてSQL呼び出しのdb.system属性が現時点で未対応で、依存関係の表示がDBクライアント名ではなくUnknownRemoteServiceになります。QueryやExecをそのまま使うとコンテキストが渡らずspanが親から切れるため、QueryContext・ExecContextへの置き換えが前提になります。

ランタイムメトリクスはNode.jsでは収集されない

GC時間・ヒープ使用量・スレッド数といったランタイムメトリクスは、Java（JVMGCDurationやJVMMemoryHeapUsedなど）、Python（PythonProcessRSSMemoryUsedなど）、.NET（DotNetGCGen0Countなど）で収集されます。Node.jsアプリケーションでは収集されません。Node.jsのメモリリークをApplication Signalsのランタイムメトリクスで追う想定を立てていると成立しないので、設計段階で切り分けておく必要があります。

収集にはバージョン条件もあります。CloudWatchエージェントは1.300049.1以降、Amazon CloudWatch Observability EKSアドオンを使う場合は2.30-eksbuild.1以降で、公式ドキュメントはアドオンを更新した場合にアプリケーションの再起動が必要だと明記しています。ADOT SDKはJavaが1.32.5以降、Pythonが0.7.0以降、.NETが1.6.0以降です。

SLOの設計｜リクエストベースとピリオドベースで挙動が変わる

Application SignalsのSLOには2つの型があり、エラーバジェットの振る舞いが根本的に違います。SLOとは？SLA・SLIとの違いと設定方法をわかりやすく解説で用語を押さえたうえで、型の選択に進むのが早道です。

エラーバジェットが減るだけか、戻るか

ピリオドベースのSLOは、あらかじめ決めた期間を単位に「しきい値を満たさなかった期間」を数えます。エラーバジェットは目標を満たしたまま失敗できる最大期間数から始まり、失敗した期間が記録されるたびに減ります。公式ドキュメントは1つのインターバル内でエラーバジェットが増えることは決してないと明記しています。「毎月99.95%のリクエストが2000ms未満で完了する」というSLOは、月あたり21.9分のダウンタイムに相当するエラーバジェットになります（43,800分の0.05%）。

リクエストベースのSLOは期間を使わず、インターバル中の「良いリクエスト数÷全リクエスト数」で測ります。こちらは残りエラーバジェットが動的で、比率次第で増えることもあります。短時間のスパイクで一度バジェットを失うと月末まで戻らないのがピリオドベース、後続の正常リクエストで比率が回復すればバジェットも戻るのがリクエストベースです。可用性の契約をそのまま反映したいならピリオドベース、レイテンシ改善の進捗を追いながら運用したいならリクエストベースが噛み合います。

バーンレートと2026年に追加された3つのSLO機能

バーンレートは、SLOの達成目標に対してサービスがどれだけ速くエラーバジェットを消費しているかを示します。残量そのものではなく速度を見るため、「このペースなら期間内に使い切る」という判断が先に立てられます。バーンレートはアプリケーション性能目標向けに2024年11月に追加されました。

2026年3月には、コンソールから使えるSLO機能が3つ追加されています。SLO Recommendationsは直近30日のP99レイテンシとエラー率を分析して目標値を提案し、設定前に妥当性を検証できます。しきい値を勘で決めてアラート疲れを招く問題への回答です。Service-Level SLOsは、従来のオペレーション単位に加えてサービス全体を1つのSLOとして見る型で、技術指標とビジネス目標の対応づけがしやすくなります。SLO Performance Reportは日次・週次・月次のカレンダー期間に沿った履歴分析を出します。いずれもApplication Signalsが利用できる全リージョンで提供されています。

有効化の最小構成｜Lambdaを例に

プラットフォームごとに手順は違いますが、共通しているのは「自動計装のしくみを注入する」「IAM権限を与える」の2点です。ECSやEKSでの導入手順はApplication Signalsとは何か？概要と基本機能をやさしく解説で扱っているので、ここではLambdaの最小構成を挙げます。手動で有効化する場合は次の3つです。

• AWS Lambda Layer for OpenTelemetryを関数のランタイムに追加する（レイヤーARNはリージョン・ランタイムごとに異なる）
• 環境変数 AWS_LAMBDA_EXEC_WRAPPER=/opt/otel-instrument を設定する
• AWS管理ポリシー CloudWatchLambdaApplicationSignalsExecutionRolePolicy を実行ロールにアタッチする

設定でつまずきやすい点が2つあります。1つ目は計装の既定範囲です。コールドスタートを抑えるため、Python・Node.js・Javaでは既定でAWS SDKとHTTPの計装しか有効になっていません。他のライブラリを計装するには明示的に指定します。

# Python: 無効化されている計装をすべて有効にする
OTEL_PYTHON_DISABLED_INSTRUMENTATIONS=none

# Node.js
OTEL_NODE_DISABLED_INSTRUMENTATIONS=none

# Java
OTEL_INSTRUMENTATION_COMMON_DEFAULT_ENABLED=true

2つ目はコンテナイメージでデプロイしたLambdaです。コンテナイメージの関数には通常の方法でレイヤーをアタッチできないため、ビルド時にレイヤーの中身をイメージへ取り込む必要があります。以下はAWS公式ドキュメント「Enable your applications on Lambda」のコンテナイメージ手順に基づく構成で、layer.zipを取得して/opt/へ展開し、otel-instrumentに実行権限を与えています。

FROM public.ecr.aws/lambda/python:3.13

# AL2023ベースのイメージには wget と unzip が含まれないため導入する
RUN dnf install -y unzip wget

# Application Signals対応のOpenTelemetryレイヤーを取得
RUN wget https://github.com/aws-observability/aws-otel-python-instrumentation/releases/latest/download/layer.zip -O /tmp/layer.zip

RUN mkdir -p /opt && \
    unzip /tmp/layer.zip -d /opt/ && \
    chmod -R 755 /opt/ && \
    rm /tmp/layer.zip

複数のLambda関数を1つのサービスとして束ねたいときは、環境変数OTEL_SERVICE_NAMEに同じ値を設定します。未設定なら関数名がそのままサービス名になります。

Application Insightsとの違い｜リソース構成起点かコード実行起点か

名前が似ているため取り違えやすいのがAmazon CloudWatch Application Insightsです。こちらは別サービスで、目的も対象も違います。

Application Insightsは、アプリケーションに含まれるリソースをスキャンしてCloudWatchのメトリクスとログを推奨・設定し、履歴データからメトリクスのパターン異常を検出するサービスです。SageMakerなどの技術で動作し、SQL Serverのバックアップ失敗やメモリリーク、大きなHTTPリクエストといった.NET／SQLスタック特有の問題について根本原因の手がかりを提示します。AWS SSM OpsCenterと統合されており、Systems Manager Automationドキュメントで対処まで進められます。リソース構成から入るのがApplication Insights、コードの実行から入るのがApplication Signalsという違いです。

X-Rayとの関係｜競合ではなくトレース実体の担当

X-Rayとの関係は分業です。Application Signalsはメトリクス・トレース・ログ・リアルユーザーモニタリング・シンセティックモニタリングを横断して相関を取り、その中でトレースの実体はX-Rayが担います。Transaction Searchを有効にしたときにスパンがX-Ray Trace Summariesとして検索できるようになるのも、この分担によるものです。

言い換えると、サービス単位で「遅い・落ちている」を見つけるのがApplication Signals、個別リクエストの経路を追って原因の区間を特定するのがX-Rayです。両者の境界とOpenTelemetry移行後の使い方はAWS X-Rayとは｜CloudWatchとの違いとOpenTelemetry移行後の使い方【2026年版】で詳しく扱っています。

導入後につまずきやすい仕様

公式ドキュメントに散在している既知の制約のうち、実際に手が止まりやすいものをまとめます。事前に知っていれば設計で回避できるものばかりです。

Java SDK v1.32.5の問題は、影響範囲がAmazon CloudWatch Observability EKSアドオンの2.3.0-eksbuild.1から2.6.0-eksbuild.1まで及びます。すぐに更新できない場合は環境変数OTEL_AWS_APPLICATION_SIGNALS_RUNTIME_ENABLED=falseでランタイムメトリクスの収集を止めれば回避できます。

機能追加も続いています。2024年10月にAmazon ECS上のアプリケーション向けの監視が強化され、2024年11月にはJavaとPythonのランタイムメトリクスとバーンレートが追加されました。2025年2月には.NETのランタイムメトリクスとLambdaのJava／.NETマネージドランタイムのAPM対応が加わり、2025年10月にはアプリケーションマップが一般提供になっています。2026年6月にはService Eventsとして、例外・レイテンシのイベントスナップショットや関数レベルの性能データ、デプロイイベントをコード変更なしで取得する機能が全商用リージョンで提供されました（対応言語はJava・Python・JavaScript）。導入時点の制約が解消されている可能性があるので、対応表は都度確認してください。

よくある質問

Application Signalsの料金はいくらですか

Transaction Searchを有効にしていなければApplication Signalsの件数課金で、バージニア北部では最初の1億件が100万件あたり1.50 USD、次の9億件が0.75 USD、それ以降が0.30 USDです。有効にしている場合はスパンの取り込み量課金（0〜10TBで1GBあたり0.35 USD）とインデックス課金（100万スパンあたり0.75 USD）に変わります。単価はリージョンで異なります。

Application SignalsとApplication Insightsは何が違いますか

別サービスです。Application Signalsはアプリケーションのコード実行を自動計装してサービス単位の遅延・障害とSLOを扱います。Application InsightsはAWSリソースの構成をスキャンして監視設定を推奨・構成し、.NETやSQL Server、SAPといったスタックの問題を自動検知します。名前が似ているだけで用途が重なりません。

Lambdaで有効化するには何が必要ですか

AWS Lambda Layer for OpenTelemetryの追加、環境変数AWS_LAMBDA_EXEC_WRAPPER=/opt/otel-instrumentの設定、AWS管理ポリシーCloudWatchLambdaApplicationSignalsExecutionRolePolicyのアタッチの3点です。CloudWatchコンソールやLambdaコンソール、AWS CDKからも有効化できます。コンテナイメージの関数はレイヤーを使えないため、ビルド時にlayer.zipの中身をイメージへ取り込みます。

公式ドキュメントはどこを見ればよいですか

対応言語とランタイム版数はCloudWatchユーザーガイドの「Supported systems」（サポートされるシステム）、収集メトリクスとディメンションは「Metrics collected by Application Signals」、料金はAmazon CloudWatchの料金ページのApplication Signalsセクションが該当します。既知の問題は「Supported systems」末尾のKnown issuesに集約されています。

東京リージョンで使えますか

使えます。アジアパシフィック（東京、ap-northeast-1）は一般提供開始時点の対応リージョンに含まれます。2024年6月10日のGA時点で28の商用リージョンに対応し、対象外はCA West（カルガリー）、AWS GovCloud（米国）、中国リージョンとされていましたが、GovCloud（米国東部・西部）は2025年11月6日に提供が始まりました。2026年6月に追加されたService Eventsは全商用リージョンで提供されています。

関連記事

• Application Signalsとは何か？概要と基本機能をやさしく解説
• AWS X-Rayとは｜CloudWatchとの違いとOpenTelemetry移行後の使い方【2026年版】
• SLOとは？SLA・SLIとの違いと設定方法をわかりやすく解説
• Golden Signals（4つのゴールデンシグナル）とは？SREの監視指標と実装・アラート設計を解説
• トレースサンプリングとは？ヘッドベースとテールベースの仕組み・OpenTelemetry/X-Ray実装・サンプリング率の決め方を実装目線で解説【2026年版】