Amazon CloudWatch が OpenTelemetry トレースへの API キー（ベアラートークン）認証をサポート

Amazon CloudWatch は、AWS X-Ray の OpenTelemetry Protocol (OTLP) トレースエンドポイントに対して、API キー（ベアラートークン）を使用した認証オプションを追加しました。これにより、AWS Signature Version 4 (SigV4) を使用できない環境や、静的な Authorization ヘッダーのみをサポートする OTLP/HTTP クライアントからでも、CloudWatch へトレースを送信することが可能になります。

💡 今回のアップデートのポイント

これまで、オンプレミス環境やマルチクラウド、あるいは CI/CD パイプラインなど、「AWS SDK が直接使えない」「短期間の認証情報（IAM Role 等）を渡すのが難しい」といった環境から OpenTelemetry トレースを送るには、SigV4 署名が大きな壁となっていました。

今回の ベアラートークン認証 の導入により、標準的な Authorization ヘッダーが設定できるクライアント（OpenTelemetry Collector や SDK エクスポーターなど）であれば、比較的容易に CloudWatch へデータを統合できるようになります。オブザーバビリティの境界線を広げる、非常に実用的な改善です。

🇯🇵 日本国内での利用状況

最新のリージョン状況を確認したところ、東京リージョン (ap-northeast-1) および 大阪リージョン (ap-northeast-3) の両方で、本機能を利用可能です。AWS X-Ray の OTLP エンドポイントが提供されている商用リージョンであれば、問題なく利用できる見込みです。

🛠 運用上のアドバイス

• セキュリティ: API キー（ベアラートークン）は静的な認証情報となるため、SigV4 に比べて管理に注意が必要です。キーの漏洩を防ぐため、シークレット管理サービスとの併用を強く推奨します。
• 推奨事項: AWS 公式では引き続き SigV4 が推奨 されています。AWS 環境内で完結するワークロードであれば、既存の ADOT (AWS Distro for OpenTelemetry) をそのまま使い続けるのがベストプラクティスです。
• 機能差分: 認証方式の違いによって CloudWatch 上の機能（Transaction Search や Application Signals など）が制限されることはありません。

✅ 次のアクション

まずは、現在 AWS 外で動いているワークロードや、認証情報の受け渡しが困難なツールから、このベアラートークン方式でトレースが正しく CloudWatch に届くか、PoC を実施してみるのが良いでしょう。

参照ドキュメント: Setting up bearer token authentication for traces (AWS X-Ray Developer Guide)