AWS X-Ray SDK と Daemon のサポート終了スケジュール
AWS は 2025 年 10 月から 11 月にかけて、AWS X-Ray SDK および X-Ray Daemon のサポート終了を公式に発表しました。長年にわたって多くの AWS ユーザーに利用されてきたこれらのツールは、段階的に役割を終え、OpenTelemetry（OTel）ベースのソリューションへの移行が強く推奨されています。
スケジュールは以下のとおりです。2026 年 2 月 25 日には X-Ray SDK および X-Ray Daemon がメンテナンスモードへ移行し、以降は重大なセキュリティ修正のみが提供されます。2027 年 2 月 25 日には完全にサポートが終了し、一切のアップデートが提供されなくなります。
重要なのは、X-Ray サービス本体は引き続き完全にサポートされる点です。変更となるのは SDK と Daemon の部分のみであり、CloudWatch コンソールでのトレース確認体験は移行後も変わりません。すでに 2026 年 5 月時点でメンテナンスモードに入っているため、特に新規プロジェクトでは最初から OpenTelemetry ベースのアーキテクチャを採用することをおすすめします。
なぜ OpenTelemetry への移行が推奨されるのか
AWS が OpenTelemetry を移行先として推奨する背景には、オブザーバビリティの世界的な標準化の潮流があります。OpenTelemetry は CNCF（Cloud Native Computing Foundation）が管理するオープンソースフレームワークであり、メトリクス・ログ・トレースを統合的に扱うための標準仕様とツールセットを提供しています。
OpenTelemetry へ移行することで得られる主なメリットは次のとおりです。
- ベンダーロックインの回避：特定クラウドに縛られない標準仕様を採用することで、マルチクラウド・ハイブリッドクラウド環境への対応が容易になります。
- 幅広いシステムへのトレース対応：AWS 外のサービスやオンプレミス環境を含む多様なシステムにまたがるトレーシングが可能になります。
- メトリクス・ログ・トレースの統合収集：3 つのシグナルをひとつのフレームワークで管理でき、オブザーバビリティ基盤の統一が実現します。
- 自動計装（Auto-instrumentation）：Java・.NET・Python・Node.js などの主要言語でコード変更なしに計装できる機能が充実しています。
- 豊富なライブラリ対応：OpenTelemetry Registry では数百を超えるライブラリの計装モジュールが公開されています。
CloudWatch Application Signals や Transaction Search といった AWS の新しいオブザーバビリティ機能は OpenTelemetry ベースの計装を前提として設計されています。OpenTelemetry へ移行することで、AWS の最新機能をフル活用できるようになります。
移行先の選択肢を整理する
X-Ray SDK と Daemon から OpenTelemetry へ移行する際には、「計装（SDK）レイヤー」と「データ収集（コレクション）レイヤー」の 2 つの軸でそれぞれ選択肢を検討する必要があります。
計装レイヤーの選択肢は 2 つあります。OpenTelemetry SDK（ネイティブ）は CNCF が管理する標準的な OTel SDK で、各言語ごとに公式 SDK が提供されています。AWS Distro for OpenTelemetry（ADOT）Instrumentationは AWS がメンテナンスするディストリビューションで、X-Ray のサンプリングルールや AWS 固有の機能に対応しています。
データ収集レイヤーには主に 3 つの選択肢があります。CloudWatch Agent（v1.300025.0 以降）は OTLP に対応しており X-Ray Daemon と統合できます。AWS Distro for OpenTelemetry Collector（ADOT Collector）は AWS がメンテナンスし X-Ray Exporter が組み込まれています。Amazon CloudWatch Observability EKS Add-onは EKS 環境向けのアドオンです。
X-Ray と OpenTelemetry の概念マッピング
X-Ray の概念 | OpenTelemetry の概念 |
|---|---|
X-Ray Recorder | Tracer Provider / Tracers |
Segment | Server Span |
Sub-segment | 非 Server Span |
X-Ray Emitter | Span Exporter |
Annotations / Metadata | Attributes |
X-Ray Daemon | OpenTelemetry Collector |
X-Ray Sampling Rules | OpenTelemetry Sampling（カスタマイズ可） |
OpenTelemetry へ送られたデータは X-Ray 形式に自動変換されるため、CloudWatch コンソール上での表示は従来と変わりません。既存のダッシュボードや分析環境をそのまま活用できます。
環境別の移行アプローチ
Amazon EC2 / オンプレミス環境では、まず X-Ray Daemon を停止してからコレクターを導入します。コレクターには OTLP レシーバーと X-Ray エクスポーターを設定し、アプリケーションからのトレースデータを受け取って X-Ray へ転送します。コレクターには xray:PutTraceSegments 権限を持つ IAM ロールが必要です。
Amazon ECS 環境では、サイドカーパターンの X-Ray Daemon コンテナを CloudWatch Agent コンテナまたは OTel Collector コンテナに差し替えます。X-Ray Daemon を停止してからコレクターを起動し（ポート競合を防ぐため）、アプリケーションコンテナの環境変数にコレクターのエンドポイントを設定します。
AWS Lambda 環境では Lambda Layer を使ったアプローチが推奨されます。AWS が提供する「Lambda Layer for OpenTelemetry」は CloudWatch Application Signals に対応しています。トレースのみを利用する場合は環境変数 OTEL_AWS_APPLICATION_SIGNALS_ENABLED=false を設定します。
AWS Elastic Beanstalk 環境では .ebextensions の設定ファイルで CloudWatch Agent を構成します。OTLP エンドポイント設定を記述してデプロイすることで移行が可能です。
移行時に必ず確認したい注意点
Lambda のコールドスタートレイテンシ増加に注意が必要です。ADOT Lambda Layer を利用する場合、コールドスタートのレイテンシが従来の 5〜6 倍程度増加する可能性があります。パフォーマンスに敏感な関数では、軽量な OTel SDK を直接組み込む、またはトレース対象を絞り込むといったチューニングを検討しましょう。
リモートサンプリングの挙動変化も把握しておく必要があります。標準的な OTel SDK では X-Ray のリモートサンプリングは自動的には機能しません。ADOT Instrumentation を利用するとリモートサンプリング機能を引き継げます。それ以外の場合は Tail Sampling Processor やローカルサンプリングロジックで対応します。
トレースコンテキスト伝播の設定にも注意してください。X-Ray SDK は X-Ray 独自のトレースヘッダーを使用しますが、OpenTelemetry のデフォルトは W3C Trace Context です。段階的に移行する場合は OTel 設定で X-Ray Propagator を有効化することで、両方の SDK が混在する期間のトレース分断を防ぐことができます。
Annotations と Metadata の扱いの変化についても確認しておきましょう。デフォルトでは OTel の Attributes は X-Ray の Metadata に変換されます。Annotations として扱いたい属性キーは aws.xray.annotations リストに明示的に追加する必要があります。
移行を成功させるためのチェックリスト
移行前の確認事項として、現在利用している X-Ray SDK のバージョンと対応言語の確認、X-Ray Daemon の稼働環境のリスト化、リモートサンプリングルールの使用有無の確認と移行後の対応方法の決定、計装レイヤーとデータ収集レイヤーの選択、Annotations として使っている属性キーのリストアップを行いましょう。
移行中の確認事項として、ステージング環境での動作確認、異なる SDK が混在する期間における X-Ray Propagator の有効化、ECS 環境での X-Ray Daemon コンテナの停止タイミングへの注意、Lambda 関数におけるコールドスタートパフォーマンスの測定が重要です。
移行後の確認事項として、CloudWatch コンソールでトレースデータが正しく表示されることの確認、X-Ray Daemon が完全に停止されていることの確認、不要な IAM 権限のレビュー、そして 2027 年 2 月のサポート終了前に全環境での移行が完了していることの確認を行いましょう。
OpenTelemetry への移行は、単なるツール変更にとどまらず、オブザーバビリティ戦略全体を見直す好機でもあります。標準化された計装基盤を整えることで、将来的なマルチクラウド対応や新たな監視ツールへの移行もスムーズになります。2027 年 2 月のサポート終了までに余裕を持って計画し、段階的に移行を進めていきましょう。
