翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

スケジュールされたクエリの概念を理解する

スケジュールされたクエリを作成する前に、クエリの実行方法と結果の配信先に影響するこれらの主要な概念を理解してください。

IAM ロールの分離

スケジュールされたクエリには 2 つの異なる IAM ロールが必要です。1 つはクエリを実行するためのロールで、もう 1 つは Amazon S3 または Amazon EventBridge イベントバスに結果を配信するためのロールです。この分離が存在する理由を理解することで、アクセス許可を正しく設定し、セキュリティと運用上の利点を活用できます。

2 ロールアーキテクチャは、データアクセスとデータ配信の責任を分けます。クエリ実行ロールはログデータにアクセスしてクエリを実行し、送信先配信ロールは選択した送信先に結果を書き込みます。この分離は最小特権の原則に従います。各ロールには、特定の関数に必要なアクセス許可のみがあります。

この分離は、オペレーションに実用的な利点をもたらします。セキュリティの観点から、結果の配信先を変更する必要がある場合は、クエリ実行のアクセス許可を変更せずに送信先配信ロールのみを変更します。コンプライアンスと監査のために、機密ログデータにアクセスするロールと外部システムに書き込むロールを明確に追跡できます。これにより、ログ分析インフラストラクチャがセキュリティのベストプラクティスに従っていることを簡単に実証できます。

クロスリージョンおよびクロスアカウントの使用

スケジュールされたクエリは特定のリージョンに作成され、そのリージョンで実行されます。ただし、ロググループをクエリし、リージョンとアカウント間で結果を配信できます。1 つ以上の AWS アカウントをモニタリングアカウントとして設定し、複数のソースアカウントにリンクする必要があります。モニタリングアカウントは、ソース AWS アカウントから生成されたオブザーバビリティデータを表示して操作できる中央アカウントです。ソースアカウントは、そのアカウントに存在するリソースのオブザーバビリティデータを生成する個々の AWS アカウントです。ソースアカウントは、オブザーバビリティデータをモニターリングアカウントと共有します。そのため、すべてのリンクされたアカウントのロググループを使用して、モニタリングアカウントからスケジュールされたクエリを設定できます。

代替方法: CloudWatch Logs の一元管理を使用して、複数のアカウントとリージョンのログデータを一元的なモニタリングアカウントにレプリケートします。これにより、すべての一元化されたログにアクセスするスケジュールされたクエリを 1 つのリージョンに作成できるため、リージョン間のクエリを回避し、IAM アクセス許可の管理を簡素化できます。

スケジュール式とタイムゾーン処理

定義したスケジュールによって、クエリの実行日時と実行頻度が決まります。適切なスケジュール式を選択すると、結果を受け取るタイミングとクエリするデータの量に影響します。式タイプを理解すると、シンプルさと精度のどちらかを選択できます。

Cron 式はタイミングを正確に制御するため、正確な時間、曜日、または曜日を指定できます。特定の営業時間にクエリを実行したり、運用スケジュールに合わせる必要がある場合は、cron 式を使用します。コンソールでは、簡単なカレンダーオプションを使用してクエリをスケジュールすることもできます。

スケジュールされたクエリはすべて、ローカルのタイムゾーンや AWS リソースの場所に関係なく、UTC で実行されます。これは、営業時間や時間的制約のある分析のためにクエリをスケジュールする場合に特に重要です。たとえば、米国東部標準時で事業を運営していて、米国東部標準時午前 9 時に日次レポートが必要な場合は、UTC オフセット (夏時間中は 14:00 UTC、それ以外の場合は 13:00 UTC) を考慮する必要があります。クエリが意図した時間に実行されるように、UTC を念頭に置いてスケジュール式を計画します。

クエリ言語の選択

スケジュールされたクエリは 3 つの異なるクエリ言語をサポートしており、クエリの作成方法とチームがクエリを簡単に維持できるかどうかの両方に影響します。適切な言語は、分析要件とチームの既存のスキルによって異なります。

主にログデータをフィルタリングおよび集約する場合、CloudWatch Logs Insights クエリ言語は最も単純な構文を提供します。複数のステップでデータを再形成または強化する必要がある複雑なデータ変換の場合、PPL のパイプラインアプローチにより、ロジックに従うのが容易になります。データベースオペレーションに似た結合や複雑な集計を実行する必要がある場合、SQL はデータベース経験豊富なチームがすばやく採用できる使い慣れた構文を提供します。

送信先の選択とユースケース

クエリ結果を送信する場所によって、クエリ結果で何ができるかが決まります。この選択により、長期分析の構築、自動応答のトリガー、またはその両方を行うかどうかにかかわらず、ダウンストリームワークフロー全体が形成されます。各送信先タイプの長所を理解することは、ユースケースに適したアーキテクチャを設計するのに役立ちます。

Amazon S3 の送信先は、ストレージとバッチ処理用に最適化されています。クエリ結果を数か月または数年間保持したり、経時的な傾向を分析したり、分析プラットフォームにデータをフィードしたりする必要がある場合、Amazon S3 は無制限の保持で費用対効果の高いストレージを提供します。EventBridge の送信先は、リアルタイムオートメーション用に最適化されています。クエリ結果がアラートの送信、ワークフローの開始、システムの更新などの即時アクションをトリガーする場合、EventBridge はアプリケーションが即座に応答できるイベントとして結果を提供します。デフォルトでは、すべてのクエリ完了イベントはイベントとしてデフォルトのイベントバスに自動的に送信され、ダウンストリーム処理システム、Lambda 関数、またはその他のイベント駆動型アーキテクチャとの統合が可能になります。結果は、クエリが正常に実行された場合にのみ送信先に発行されます。

クエリ結果の形式と構造

Amazon S3 送信先の場合 - クエリ結果はGetQueryResults API レスポンスと同じ構造で JSON 形式で配信されます。Amazon EventBridge がスケジュールされたクエリ結果の形式を理解すると、ダウンストリームの処理および統合ワークフローを設計するのに役立ちます。

クエリ結果は、次の構造で JSON 形式で配信されます。

{
    "version": "0",
    "id": "be72061b-eca2-e068-a7e1-83e01d6fe807",
    "detail-type": "Scheduled Query Completed",
    "source": "aws.logs",
    "account": "123456789012",
    "time": "2025-11-18T11:31:48Z",
    "region": "us-east-1",
    "resources": [
        "arn:aws:logs:us-east-1:123456789012:scheduled-query:477b4380-b098-474e-9c5e-e10a8cc2e6e7"
    ],
    "detail": {
        "queryId": "2038fd57-ab4f-4018-bb2f-61d363f4a004",
        "queryString": "fields @timestamp, @message, @logStream, @log\n| sort @timestamp desc\n| limit 10000",
        "logGroupIdentifiers": [
            "/aws/lambda/my-function"
        ],
        "status": "Complete",
        "startTime": 1763465460,
        "statistics": {
            "recordsMatched": 0,
            "recordsScanned": 0,
            "estimatedRecordsSkipped": 0,
            "bytesScanned": 0,
            "estimatedBytesSkipped": 0,
            "logGroupsScanned": 1
        }
    }
}

主な要素は次のとおりです。