【待望】CloudWatch Logs InsightsにJOINとサブクエリがついに降臨！「手動でのログ突合」という苦行が終了する。

Amazon CloudWatch Logs Insights のクエリ言語に、新機能として JOIN および sub-query コマンドが追加されました。これにより、単一のクエリで複数のロググループにまたがる相関分析が可能になります。本機能は、東京リージョンおよび大阪リージョンを含むすべての商用AWSリージョンで、本日より利用可能です。

🛠️ これまでの「地獄のログ集計」がついに解禁！

今まで、分散システムのエラー調査で「Lambdaのログ」と「ECSのログ」を紐付けたくて、複数のクエリを叩いて結果をCSVで書き出し、PythonやExcelで必死にJOINしていたエンジニアの皆さん、お疲れ様でした。その苦行、今日で終わりです。

💡 何が変わるのか？

今回のアップデートは、単なる機能追加ではありません。「ログの相関分析」がCloudWatchコンソール内で完結するというパラダイムシフトです。

• JOIN: リクエストIDやトランザクションIDをキーにして、異なるロググループ間でデータを結合（INNER JOIN, LEFT JOIN 対応）。
• サブクエリ: クエリ内に別のクエリをネストさせ、中間結果を抽出して次の処理に渡す。

🇯🇵 日本のエンジニアへの朗報

調査の結果、東京リージョン (ap-northeast-1) および 大阪リージョン (ap-northeast-3) で既に提供開始されています。すぐに検証を開始できます。

⚠️ 運用上の「ハマりポイント」とアドバイス

強力な武器ですが、使い方を間違えるとコストやパフォーマンスに直面します。

1. コスト管理: Logs Insightsはスキャン量課金です。JOINの前に必ず filter でスキャン範囲を極限まで絞り込んでください。広範囲をいきなりJOINすると、請求額を見て青ざめることになります。
2. 制約の把握: JOINの右側（結合先）のキー値は最大50,000件、サブクエリの実行時間は最大30秒、さらにサブクエリの入れ子は不可といった制約があります。これらは「あらかじめ設計されたクエリ」に使うべき機能です。
3. 権限: 結合対象のすべてのロググループに対し logs:FilterLogEvents 権限が必要です。

🚀 次のアクション

まずは、エラー頻出サービスを抽出したサブクエリを作り、それをパフォーマンスログとJOINさせてみる「相関分析のプロトタイプ」を作ってみるのがおすすめです。

Reference: Amazon CloudWatch Logs documentation (https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_AnalyzeLogData_LogsInsights.html)