--- title: "CloudWatch Application Signalsとは｜料金の実額・SLO設計・2026年の新機能を公式資料で整理" url: "https://www.issoh.co.jp/tech/details/3413/" published: 2024-08-28 updated: 2026-11-01 categories: ["AWS"] publisher: "株式会社一創" --- # CloudWatch Application Signalsとは｜料金の実額・SLO設計・2026年の新機能を公式資料で整理 Amazon CloudWatch Application Signalsは、OpenTelemetryの自動計装でアプリケーションの遅延と障害をサービス単位に可視化するAWSのAPM機能です。2024年6月10日に一般提供が始まり、2026年6〜7月には稼働中のアプリから変数の値を取り出すDynamic Instrumentationと、例外やデプロイを自動で拾うService Eventsが加わりました。導入判断で詰まりやすいのは料金で、Transaction Searchを有効にするかどうかで課金の単位が「件数」から「バイト数」へ入れ替わります。この記事では東京リージョンの単価での月額計算、2つの課金モードの分岐点、SLOの型の選び方、新機能の使い分けを、AWSの料金データとユーザーガイドで確かめながら整理します。有効化の手順は[Application Signalsの導入手順｜ECS・EKS・EC2・Lambda別の有効化設定と表示されないときの確認](/tech/details/7452/)で扱っています。 ## まとめ：Application Signalsの料金と設計で先に決めること - **課金モードは2つ**。Transaction Searchを使わないなら受信・送信リクエストとSLOのシグナル件数（最初の1億件は100万件あたり1.50 USD）、使うならスパンとメトリクスの取り込み量（最初の10TBは1GBあたり0.35 USD）で課金されます。東京・大阪の単価はバージニア北部と同額です。 - **どちらが安いかは1シグナルあたりのデータ量で決まります**。単価から逆算した分岐点は約4.3KBで、これより小さければ取り込み課金のほうが安くなります（第1階層同士の比較）。 - **SLOそのものは安い**。1分周期のSLOは1本あたり月87,600シグナル＝約0.13 USD、100本でも約13 USDです。請求額を左右するのはリクエスト量で、毎秒10件を受信して監視対象の依存先を1回ずつ呼ぶサービスなら、シグナル料金だけで月78.84 USDです（730時間・無料枠なし・第1階層単価）。 - **送信される標準メトリクスは`Latency`・`Fault`・`Error`の3つ**。Availabilityは計算値で、HTTP 4XXは成功として数えます。 - **Go・PHP・RubyはADOT SDKが無く、Transaction Searchの有効化が前提**です。計装した時点で取り込み課金に乗ります。 - **Dynamic InstrumentationとService Eventsの対応言語はJava・Python・JavaScript**。Dynamic InstrumentationはLambdaで使えず、取得したデータはCloudWatch Logsの料金で課金されます。 ## Application Signalsが自動で可視化する範囲と標準メトリクス Application Signalsを有効にすると、計装したサービスの呼び出し件数・可用性・レイテンシ・障害・エラーが、カスタムコードやダッシュボードを作らずに表示されます。サービス一覧、サービスと依存先の関係を描くアプリケーションマップ、SLOの3つが日常の監視の入口で、CloudWatch RUMやSyntheticsのカナリアとも同じ画面で突き合わせられます（[AWS公式：Application Signals](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Application-Monitoring-Sections.html)）。提供リージョンはカナダ西部（カルガリー）を除く全商用リージョンで、2025年11月にはAWS GovCloud（米国）にも広がりました。同一リージョン内の複数のAWSアカウントにまたがるサービスとSLOは、OAMで共有を設定すると、クロスアカウント監視自体の追加料金なしで1つの監視アカウントから見られます（2025年2月追加）。 ### 標準メトリクスは3つ、Availabilityは計算値 `ApplicationSignals`名前空間に送られる標準メトリクスは次の3つだけです（[Metrics collected by Application Signals](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AppSignals-MetricsCollected.html)）。 | メトリクス | 内容 | 単位 | | --------- | -------------------------------------- | --- | | `Latency` | リクエスト発行からデータ転送開始までの遅延 | ミリ秒 | | `Fault` | HTTP 5XXとOpenTelemetryのspanステータスエラーの件数 | なし | | `Error` | HTTP 4XX（クライアント側エラー）の件数 | なし | ダッシュボードのAvailabilityは送信されているメトリクスではなく、`(1 - Faults/Total)*100`で計算されます。Totalは`SampleCount(Latency)`から導かれます。**4XXはAvailabilityを下げません**。認証エラーが多発していてもAvailabilityが100%のままなのは仕様どおりで、4XXを追うなら`Error`に別のアラームを張ります。指標の役割分担は[Golden Signals（4つのゴールデンシグナル）とは？SREの監視指標と実装・アラート設計を解説](/tech/details/15714/)と合わせて読むと設計しやすくなります。 ### サービスメトリクスと依存関係メトリクスのディメンション サービスAがBを呼ぶとき、リクエストを受けるB側が「サービスメトリクス」を、呼び出すA側が「依存関係メトリクス」を出します。サービスメトリクスのディメンションは`Service`・`Operation`・`Environment`、依存関係メトリクスはそこに`RemoteService`・`RemoteOperation`・`RemoteEnvironment`・`RemoteResourceIdentifier`・`RemoteResourceType`が加わります。 設計で効く制約が1つあります。`Operation`は最大1024文字ですが、**オペレーション単位のSLOを張れるのは名前が194文字以下のときだけ**です。長いURLパスをそのままオペレーション名にしていると、メトリクスは見えるのにSLOだけ作れません。 ## Application Signalsの料金：2つの課金モードと東京リージョンの単価 Transaction Searchは、X-Rayに送られたスパンを100%、構造化ログとして`aws/spans`ロググループに取り込み、その一部をX-Rayのトレースサマリーとして索引付けする機能です（[CloudWatch Transaction Search](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Transaction-Search.html)）。これを有効にするかどうかで、Application Signalsの課金対象が入れ替わります。[CloudWatchの料金ページ](https://aws.amazon.com/cloudwatch/pricing/)が読み込む料金データを2026年11月1日に確認したところ、東京（ap-northeast-1）・大阪（ap-northeast-3）・バージニア北部（us-east-1）の単価はすべて同じでした。 | モード | 課金対象 | 単価（東京・大阪・バージニア北部） | | --------------------- | ------------ | ----------------- | | Transaction Search 無効 | 最初の1億シグナル | 1.50 USD/100万件 | | Transaction Search 無効 | 次の9億シグナル | 0.75 USD/100万件 | | Transaction Search 無効 | 10億シグナル超 | 0.30 USD/100万件 | | Transaction Search 有効 | 取り込み 最初の10TB | 0.35 USD/GB | | Transaction Search 有効 | 取り込み 次の20TB | 0.20 USD/GB | | Transaction Search 有効 | 取り込み 30TB超 | 0.15 USD/GB | | Transaction Search 有効 | 索引付けしたスパン | 0.75 USD/100万スパン | 件数課金のシグナルは、アプリが受けたリクエスト1件、監視対象の依存先へ出したリクエスト1件ごとに1件と数えます。SLOはSLIの計測周期ごとに2件です。取り込み課金側は、取り込んだスパンの1%までの索引付けが無料で、それを超えた分に索引付けの料金がかかります。無料利用枠はどちらのモードもアカウントあたり3か月で、それより先に上限（件数課金は1億シグナル、取り込み課金は取り込み100GB＋索引付け100万スパン）に達したらその時点で終わります。 ### 件数課金と取り込み課金が釣り合う分岐点 第1階層の単価どうしで比べると、1シグナルあたりの課金額は1.50 USD÷100万＝0.0000015 USDです。これを取り込み単価0.35 USD/GBで割ると、同じ金額で取り込めるのは約4,286バイト（1GB＝10億バイトで計算）です。**受信・送信1回あたりのスパンとメトリクスが平均約4.3KBより小さければTransaction Searchを有効にしたほうが安く、大きければ件数課金のほうが安い**という目安になります（第1階層の単価同士・索引付け1%以下の場合）。 ただし、この比較には前提が2つあります。DB呼び出し以外の内部スパンはシグナルに数えられないのに取り込み量には乗ること、そして索引付けを1%より増やせば0.75 USD/100万スパンが加わることです。実際のサイズは、Transaction Searchを有効にした後、`aws/spans`ロググループのスパン取り込み量と課金対象のアプリケーションメトリクスの取り込み量を合算し、同じ期間の受信・送信シグナル件数で割って確かめます。 ### SLOとリクエスト量の月額を計算するコード 月の長さはAWS料金ページの計算例に合わせて43,800分（730時間）とします。次のコードは、AWSの計算例（1分・5分・10分周期のSLOを10本ずつで合計1,138,800シグナル）を再現したうえで、SLOとリクエスト量の月額を出します。Python 3.9で実行し、出力を下に載せています。 ``` # Application Signals の月額を、AWS料金ページの単価（東京・バージニア北部共通）で計算する MINUTES_PER_MONTH = 43_800 # AWSの計算例と同じ730時間 SECONDS_PER_MONTH = MINUTES_PER_MONTH * 60 # Transaction Search 無効：シグナル件数の段階単価（USD / 100万件） TIERS = [(100_000_000, 1.50), (900_000_000, 0.75), (float("inf"), 0.30)] def signal_cost(signals): total, rest = 0.0, signals for size, price in TIERS: used = min(rest, size) total += used / 1_000_000 * price rest -= used if rest <= 0: break return total def slo_signals(period_minutes, count=1): # SLO 1本は SLI の計測周期ごとに2件のシグナルを生成する return count * 2 * MINUTES_PER_MONTH // period_minutes def request_signals(rps, outbound_per_request): # 受信1件と、監視対象の依存先への送信1件ごとに1シグナル return int(rps * SECONDS_PER_MONTH * (1 + outbound_per_request)) aws_example = slo_signals(1, 10) + slo_signals(5, 10) + slo_signals(10, 10) print("AWS計算例の再現:", f"{aws_example:,}", "シグナル") print("SLO 1本(1分周期):", f"{slo_signals(1):,}", "件", round(signal_cost(slo_signals(1)), 2), "USD") print("SLO 100本(1分周期):", round(signal_cost(slo_signals(1, 100)), 2), "USD") for rps in (10, 100): s = request_signals(rps, outbound_per_request=1) print(f"{rps} req/s・依存先1回:", f"{s:,}", "件", round(signal_cost(s), 2), "USD") # 取り込み課金(0.35 USD/GB)と件数課金(1.50 USD/100万件)が釣り合う1シグナルあたりのバイト数 print("分岐点:", round(1.50 / 1_000_000 / 0.35 * 1_000_000_000), "バイト/シグナル") ``` ``` AWS計算例の再現: 1,138,800 シグナル SLO 1本(1分周期): 87,600 件 0.13 USD SLO 100本(1分周期): 13.14 USD 10 req/s・依存先1回: 52,560,000 件 78.84 USD 100 req/s・依存先1回: 525,600,000 件 469.2 USD 分岐点: 4286 バイト/シグナル ``` ここから言えるのは、**この試算条件では、SLOの本数よりリクエスト由来のシグナル料金を先に見直すべき**だということです。100本で月13 USD程度に対し、毎秒100リクエストで依存先を1回呼ぶサービス1つで月469.2 USDになります。抑える対象はリクエスト量に比例する部分で、件数課金ならシグナル数、取り込み課金ならスパンの量です。スパンを減らす手段は[トレースサンプリングのヘッドベースとテールベースの使い分け](/tech/details/15713/)で整理しています。 ### 取り込み課金側でしか使えない機能 料金ページは、取り込み課金のモードに付く機能として、全スパンの可視化、計装していないサービスも含めた自動検出とグルーピング、性能問題の自動監査、直近の変更の表示を挙げています。直近の変更（Change Events）はCloudTrailのイベントからAuto Scalingグループ、EKS、ECS、ロードバランサー、Lambda関数などの設定変更とデプロイを拾ってアプリケーションマップに重ねる機能、自動監査は問題の候補と関連トレースを重大度順にまとめて示す機能です。件数課金には全トランザクションスパンの可視化は含まれませんが、別料金のX-Rayでサンプリングされたトレースを確認できます。**金額だけで件数課金を選ぶと、これらを十分に使えない構成になる**ので、分岐点の計算と機能の要否をあわせて判断します。 ## 対応言語・ランタイム版数とADOT SDK別の計装方式 Application SignalsはAmazon EKS、ネイティブのKubernetes、Amazon ECS、Amazon EC2でサポート・テストされ、Lambdaにも対応しています。ランタイムの対応版は[Supported systems](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Application-Signals-supportmatrix.html)の表のとおりです。 | 言語 | 対応ランタイム版数 | ADOT SDK | | ------- | -------------------------------------------------- | -------- | | Java | JVM 8, 11, 17, 21, 23, 25 | あり | | Python | 3.10, 3.11, 3.12, 3.13, 3.14 | あり | | .NET | .NET 8, 9, 10 / .NET Framework 4.6.2以上 | あり | | Node.js | 18, 20, 22, 24 | あり | | PHP | 8.0以上 | なし | | Ruby | CRuby 3.1以上 / JRuby 9.3.2.0以上 / TruffleRuby 22.1以上 | なし | | Go | 1.18以上 | なし | ### Go・PHP・RubyはTransaction Searchが前提 この3言語には専用のADOT SDKがなく、公式ドキュメントは標準のOpenTelemetry SDKを使い、Transaction Searchを有効にしたうえでゼロコード計装をするよう案内しています。料金表と突き合わせると、**Go・PHP・Rubyを計装した時点で課金は取り込み量ベースに決まります**。1億シグナルの無料枠ではなく、100GBの取り込み枠が先に減っていきます。 Goには固有の手当てもあります。自動計装ライブラリがAWS SDKの計装に対応していないため、`otelaws.AppendMiddlewares(&cfg.APIOptions)`を併用します。SQL呼び出しは`db.system`属性が未対応で依存先が`UnknownRemoteService`と表示され、`Query`や`Exec`のままだとコンテキストが渡らずspanが親から切れるため、`QueryContext`・`ExecContext`に置き換えます。 ### ランタイムメトリクスの対応言語とNode.jsの制約 GC時間・ヒープ使用量・スレッド数などのランタイムメトリクスは、Java・Python・.NETで収集されます。**Node.jsでは収集されません**。Node.jsのメモリリークをApplication Signalsで追う前提は成り立たないので、別の手段を用意します。ランタイムメトリクスもApplication Signalsの料金に含めて課金されます。 ## SLOの設計：期間ベースとリクエストベースの選び方 Application SignalsのSLOは、Application Signalsが集めた`Latency`やAvailabilityだけでなく、任意のCloudWatchメトリクスやメトリクス式もSLIにできます。型は2つで、エラーバジェットの動き方が違います（[Service level objectives (SLOs)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-ServiceLevelObjectives.html)）。用語の整理は[SLOとは？SLA・SLIとの違いと目標値の決め方、エラーバジェットの運用](/tech/details/6080/)を先に読むと早道です。 ### SLOの評価方式・評価区間とエラーバジェットの増減 評価区間は、月などに揃えるカレンダー型と、直近の一定期間を見るローリング型から選びます。期間ベースのSLOは、1分などの期間ごとにしきい値を満たしたかを判定し、満たさなかった期間を数えます。固定されたカレンダー区間では、残りのエラーバジェットは違反期間に応じて減ります。ローリング区間では、過去の違反期間が評価範囲から外れると回復することがあります。たとえば30日間で99.95%の期間を満たす目標なら、総エラーバジェットは43,200分の0.05%＝21.6分です。カレンダー月ではCloudWatchが実際の日数に応じて自動で補正します。 リクエストベースのSLOは「良いリクエスト数÷全リクエスト数」で測り、後から正常なリクエストが積み上がれば残りのバジェットが増えることがあります。**契約が時間割合を定義しているなら期間ベース、リクエストごとの成功率やレイテンシ達成率を追うならリクエストベース**が噛み合います。 ### バーンレートアラームのしきい値の決め方 バーンレートは、エラーバジェットを目標に対して何倍の速さで消費しているかを示す値で、`ルックバック期間のエラー率 ÷ (100% - 達成目標)`で計算します。1なら目標ちょうど、1を超えると期間内に目標を割る可能性があります。 しきい値は「直近のルックバック時間でバジェットのX%を使ったら知らせる」と決めると、`X% × SLOのインターバル長 ÷ ルックバック期間`で出せます。公式の例では、30日（720時間）のバジェットの5%を1時間で使ったときに鳴らすなら、5% × 720 ÷ 1＝36です。勘でしきい値を置くとアラートが鳴りすぎるか鳴らないかのどちらかになりやすいので、まずこの式で決めてから運用で調整します。 ### メンテナンス窓の除外・複合SLO・依存関係SLO 計画メンテナンスは時間帯の除外として登録でき、1回限りにも繰り返しにもできます。除外した時間帯は、期間ベースでは違反なしとして扱われ、リクエストベースではその間のリクエストが計算から外れます。1つのサービスの2〜20個のオペレーションを束ねてAvailabilityを集計する複合SLOも作れます（対象はAvailabilityのみ）。2025年4月2日からは、決済代行のような依存先への送信リクエストにもSLOを張れるようになり、自社サービスの劣化が依存先起因かを切り分けやすくなりました（[AWS What’s New 2025-04-02](https://aws.amazon.com/about-aws/whats-new/2025/04/service-dependencies-amazon-cloudwatch-application-signals-slos/)）。 ### 2026年3月に追加されたSLOの3機能 2026年3月13日には、コンソールから使う3つの機能が加わりました（[AWS What’s New 2026-03-13](https://aws.amazon.com/about-aws/whats-new/2026/03/cloudwatch-application-signals-adds-slo-capabilities/)）。SLO Recommendationsは直近30日のP99レイテンシとエラー率から目標値を提案し、Service-Level SLOはオペレーション単位でなくサービス全体を1本のSLOとして扱い、SLO Performance Reportは日次・週次・月次のカレンダー期間で達成状況を振り返ります。新しくSLOを作るなら、まずRecommendationsの提案値を見てから、上のバーンレートの式で通知条件を決めるのが手戻りの少ない順番です。 ## 2026年に追加された障害調査の機能：Dynamic InstrumentationとService Events 2026年は、SLOで「悪化した」と分かった後の原因調査を短くする機能が続けて入りました。どちらも対応言語はJava・Python・JavaScript（TypeScript）に限られ、.NET・Go・PHP・Rubyでは使えません。 | 機能 | 発表日 | 取れるもの | 課金 | | ----------------------- | ---------- | ---------------------- | --------------- | | Dynamic Instrumentation | 2026-06-30 | 指定した行の変数・引数・戻り値・スタック | CloudWatch Logs | | Service Events | 2026-07-06 | 例外・レイテンシのスナップショット、デプロイ | CloudWatchの標準料金 | ### Dynamic Instrumentationによる変数取得と対応条件 Dynamic Instrumentationは、稼働中のアプリを再起動も再デプロイもせずに、指定したコード位置の変数の値・引数・戻り値・スタックトレースをスナップショットとして取り出す機能です（[AWS What’s New 2026-06-30](https://aws.amazon.com/about-aws/whats-new/2026/06/cloudwatch-dynamic-instrumentation/)）。既定で24時間（5分〜24時間で指定）後に期限切れになるブレークポイントと、削除するまで残るプローブがあります。ただしJavaScript・TypeScriptは行単位のブレークポイントのみで、プローブは使えません。TypeScriptにはソースマップも必要です。スナップショットはCloudWatch Logsに書かれて実行中のトレースと結び付きます。取り込み・保存はCloudWatch Logsの標準料金です。 ADOT SDKでは既定で無効なので、アプリ側で次の環境変数を設定します。EKSではCloudWatch Observabilityアドオンを、その他の環境ではADOT SDKとCloudWatchエージェントの両方を最新版に更新します（[Debug applications with Dynamic Instrumentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Application-Signals-DynamicInstrumentation.html)）。`deployment.environment.name`の値は、Application Signalsのコンソールに出ている環境名と一致させます。 ``` OTEL_AWS_DYNAMIC_INSTRUMENTATION_ENABLED=true OTEL_SERVICE_NAME=checkout-api OTEL_RESOURCE_ATTRIBUTES=deployment.environment.name=production ``` 監視するコード位置は、Application SignalsのMCPサーバーかAWS CLI・SDKで指定します。**Lambdaでは使えません**。 ### Service Eventsによる例外・デプロイの関連付け Service Eventsは、Application Signalsを有効にしたサービスから、例外とレイテンシのイベントスナップショット、デプロイイベントをコードの変更なしに取り込む機能です（[AWS What’s New 2026-07-06](https://aws.amazon.com/about-aws/whats-new/2026/06/cloudwatch-service-events/)）。コンソールのサービス詳細の［Errors］から、デプロイの直後に新しい例外が出始めたかを確かめられます。関数呼び出しのメトリクスは任意で有効にでき、OpenTelemetryメトリクスとして取り込まれます。 ## Application Signalsの導入方式の選び分け アカウントでの有効化は1回だけで、CloudWatchコンソールの［Services］から［Start discovering your Services］を実行すると、サービスリンクロール`AWSServiceRoleForCloudWatchApplicationSignals`が作られます（[Enable Application Signals in your account](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Application-Signals-Enable.html)）。その後のアプリ側の計装は実行基盤で方式が分かれます。 | 実行基盤 | 計装の入れ方 | サービス名の自動検出 | | ---------- | ------------------------------------------------ | ---------- | | Amazon EKS | CloudWatch Observability EKSアドオン（v5.0.0以降は既定で有効） | あり | | Amazon ECS | CloudWatchエージェントをサイドカーかデーモンで配置 | なし（自分で指定） | | Amazon EC2 | CloudWatchエージェント＋ADOT SDK | なし（自分で指定） | | Lambda | ADOTのLambdaレイヤー＋実行ロールのポリシー | 関数名（変更可） | タスク定義・Podの注釈・エージェント設定・Lambdaレイヤーの具体的な書き方と、データが表示されないときの確認順は[Application Signalsの導入手順｜ECS・EKS・EC2・Lambda別の有効化設定と表示されないときの確認](/tech/details/7452/)にまとめています。AWS上の監視基盤ごと設計から任せたい場合は、[AWS・Google Cloud・Azureのインフラ構築支援](/service/system/aws/)で相談を受け付けています。 ## Application Insights・X-Ray・CloudWatch Omniとの違い CloudWatchには名前や役割の近い機能がいくつかあります。起点の違いで見分けます。 | 機能 | 起点 | 主な用途 | | ------------------------------- | ---------- | --------------------------- | | Application Signals | アプリのコード実行 | サービス単位の遅延・障害とSLO | | CloudWatch Application Insights | AWSリソースの構成 | .NET・SQL Serverなどの監視設定と異常検知 | | AWS X-Ray | 個別のリクエスト | トレースの保存と経路の追跡 | | CloudWatch Omni | 既存のテレメトリ | 収集済みデータを横断して読む作業画面 | ### CloudWatch Application Insightsとの違い CloudWatch Application Insightsは、アプリを構成するリソースをスキャンしてメトリクスとログの監視を推奨・設定し、SQL Serverのバックアップ失敗やメモリリークなど.NET・SQL Serverのスタック特有の問題を検知する別サービスです。**リソース構成から入るのがApplication Insights、コードの実行から入るのがApplication Signals**です。なお、AzureにもApplication Insightsという同名のAPMがあり、こちらは[Azure Application Insightsとは？機能・料金・導入手順とLog Analyticsとの違い【2026年10月】](/tech/details/7169/)で扱っています。 ### X-Rayとの関係 X-Rayとは分業です。サービス単位で「遅い・落ちている」を見つけるのがApplication Signals、個別リクエストの経路をたどって原因の区間を特定するのがX-Rayです。境界とOpenTelemetryでの使い方は[AWS X-Rayとは？CloudWatchとの違い・SDKサポート終了の現状とOpenTelemetryでの使い方【2026年10月】](/tech/details/6812/)で扱っています。 ### CloudWatch Omniとの関係 CloudWatch Omniは、Application Signalsのスパンを含む既存のテレメトリを読む作業画面で、計装やSLOの機能を置き換えるものではありません。東京リージョンでは提供されていない点を含め、[CloudWatch Omniとは：料金・東京未対応の制約とAIエージェント計装の手順](/tech/details/18243/)で整理しています。 ## Application Signalsで導入後につまずきやすい仕様 | 対象 | 症状・制約 | 対処 | | ------- | ---------------------------------- | ------------------------------------- | | .NET | AWS SDK for .NET V4に非対応 | AWS SDK for .NET V3を使う | | Node.js | ESMのサポートは実験的 | CJSを使う。ESMは18.19.0以上 | | Python | `PYTHONPATH`未設定で起動に失敗 | 作業ディレクトリを設定 | | Django | 追加設定が必要 | `--noreload`と`DJANGO_SETTINGS_MODULE` | | Java | SDK v1.32.5でWildflyのランタイムメトリクスが出ない | v1.32.6以上へ更新 | | Go | SQLスパンが親スパンから切れる | `QueryContext`等で文脈を渡す | | SLO | オペレーション単位のSLOを作れない | 名前を194文字以下にする | Java SDK v1.32.5の問題はAmazon CloudWatch Observability EKSアドオンの`2.3.0-eksbuild.1`から`2.6.0-eksbuild.1`にも及び、修正はアドオン`v3.0.0-eksbuild.1`です。すぐに更新できなければ、環境変数`OTEL_AWS_APPLICATION_SIGNALS_RUNTIME_ENABLED=false`でランタイムメトリクスの収集を止めて回避できます。 逆に、**Application Signalsを主役にしないほうがよい構成**もはっきりしています。カナダ西部（カルガリー）で動かしている、Go・PHP・Rubyが中心で取り込み量の見積もりが立っていない、Node.jsのメモリやGCを主に監視したい、Lambdaの本番で変数を見ながら調べたい、のいずれかに当てはまるなら、別のAPMやログ設計を組み合わせる前提で検討します。 ## よくある質問 ### Application Signalsの料金はいくらですか？ Transaction Searchを使わない場合は、受信・送信リクエストとSLOのシグナル件数で課金され、最初の1億件は100万件あたり1.50 USDです。使う場合はスパンとメトリクスの取り込みで、最初の10TBは1GBあたり0.35 USDです。東京リージョンもバージニア北部と同じ単価で、アカウントあたり3か月の無料利用枠があります。 ### Application SignalsとApplication Insightsは何が違いますか？ Application Signalsはアプリのコード実行を計装してサービス単位の遅延・障害とSLOを扱い、CloudWatch Application Insightsはリソース構成をスキャンして.NETやSQL Serverなどの監視を設定します。名前は似ていますが別のサービスです。 ### Transaction Searchは有効にしたほうがよいですか？ 無料枠を除く第1階層の単価同士で、索引付け率1%以下・1GB＝10億バイトと仮定すれば、1シグナルあたりの課金対象データ量が約4.3KB未満では取り込み料金がシグナル料金を下回ります。有効にすると全スパンの検索やChange Events、自動監査も使えます。Go・PHP・Rubyを計装するなら有効化が前提です。最終的な費用比較では、月間利用量による段階単価と、索引付け・X-Rayトレースなどの追加料金も含めて計算します。 ### 東京リージョンで使えますか？ 使えます。Application Signalsはカナダ西部（カルガリー）を除く全商用リージョンで提供され、2025年11月にAWS GovCloud（米国）にも広がりました。Dynamic InstrumentationとService Eventsも全商用リージョンで提供されています。 ### Lambdaで有効化するには何が必要ですか？ ADOTのLambdaレイヤーを関数に追加し、実行ロールに`CloudWatchLambdaApplicationSignalsExecutionRolePolicy`を付けます。コンテナイメージの関数やサービス名の束ね方を含む手順は[Application Signalsの導入手順｜ECS・EKS・EC2・Lambda別の有効化設定と表示されないときの確認](/tech/details/7452/)で解説しています。なお、Dynamic InstrumentationはLambdaでは使えません。 ## 関連記事 - [Application Signalsの導入手順｜ECS・EKS・EC2・Lambda別の有効化設定と表示されないときの確認](/tech/details/7452/) - [AWS X-Rayとは？CloudWatchとの違い・SDKサポート終了の現状とOpenTelemetryでの使い方【2026年10月】](/tech/details/6812/) - [SLOとは？SLA・SLIとの違いと目標値の決め方、エラーバジェットの運用](/tech/details/6080/) - [Golden Signals（4つのゴールデンシグナル）とは？SREの監視指標と実装・アラート設計を解説](/tech/details/15714/) - [トレースサンプリングとは？ヘッドベースとテールベースの仕組み・OpenTelemetry/X-Ray実装・サンプリング率の決め方を実装目線で解説【2026年版】](/tech/details/15713/) --- 出典: [CloudWatch Application Signalsとは｜料金の実額・SLO設計・2026年の新機能を公式資料で整理]()（株式会社一創）