AWS CloudTrail Lake 実践ガイド（2026年版）：Trino SQLでイベントを分析し、Athena+S3とどう使い分けるか——新規受付終了後の現実解

「90日を超える監査ログを、属性を横断して SQL で集計したい」「インシデント発生時に、誰が・いつ・どの IP から・どのリソースに何をしたのかを、複数の条件で一気に絞り込みたい」——監査・セキュリティの現場で必ずぶつかる壁です。

ところが CloudTrail のイベント履歴（証跡なしで見られるあれ）は、90日・管理イベントのみ・単一リージョン・単一属性検索という制約があり、こうした横断分析にはまったく歯が立ちません。だからこそ AWS は CloudTrail Lake と Athena という、SQL で監査ログを分析する仕組みを別に用意しているわけです。

私はサーバーレス決済基盤の信頼性レイヤーを主導し、本番での二重課金を 0 件に保ってきました。そこで痛感したのは、監査ログは「貯めるだけ」では資産にならないということです。インシデントの一次切り分けも、コンプライアンス監査への回答も、結局は「ログを SQL で横断的に問い合わせられる構造になっているか」で決まる。本記事は、CloudTrail Lake をその「分析できる資産」に変える実践ガイドです。

ただし、2026年の今、この記事には最初に伝えるべき不都合な真実があります。

**CloudTrail Lake は 2026年5月31日をもって新規顧客の受付を終了しました。**既存顧客はこれまでどおり利用を継続できます（CloudTrail Lake availability change）。つまりこの記事は、(a) すでに Lake を使っている人が使いこなすためと、(b) これから監査ログ分析基盤を作る人が「Lake は選べない」前提で最適解を選ぶための、二つの読み方ができるように書いています。最初にこの現実を置くのが、いちばん誠実で、いちばん役に立つと考えました。

0. メンタルモデル：Lake は「SQLで横断分析できる不変の監査データレイク」

細かい機能に入る前に、1枚で本質を固めます。CloudTrail Lake とは何か。公式の言葉を借りれば、**「コンプライアンススタックを補完し、ニアリアルタイムのトラブルシューティングを支援する監査ソリューション」**です。実態としては次の3点に集約されます。

1. 不変（immutable）のイベントデータストア（EDS） に、AWS／非AWS のアクティビティイベントを貯める。
2. 貯めたイベントは内部で行ベースの JSON から Apache ORC（列指向）に変換され、高速に取り出せる。
3. その上で すべての有効な Trino の SELECT 文・関数を使って、フィールドを横断する SQL 分析ができる。

[AWS / 非AWS のイベント]
        │  高度なイベントセレクタで取捨選択
        ▼
┌─────────────────────────────┐
│  Event Data Store (EDS)     │  ← 不変・ORC列指向・KMS暗号化・保持階層
│  1カテゴリ/EDS・組織EDS対応  │
└─────────────────────────────┘
        │  全Trino SELECT・複数EDSのJOIN
        ▼
[Trino SQL クエリ] → 結果(最大7日保持/S3保存可)
        │
        ├─→ 14のマネージドダッシュボード / カスタム / Highlights
        ├─→ 自然言語→SQL（生成AIクエリ生成：GA）
        └─→ Glueデータカタログへフェデレーション → Athena で照会

この記事は CloudTrail クラスタの「Lake・SQL分析」担当（スポーク）です。証跡の作成手順・イベント種別の全体像・基本のセキュリティ設計、そして Athena 用テーブルの DDL（パーティション射影）は CloudTrail 監査ログ・ガバナンス・セキュリティ完全ガイド（ピラー記事）に集約しています。本記事では DDL を全文再掲せず、Lake そのものと「Lake vs Athena の使い分け」を深掘りします。

1. 新規受付終了の現実と、最初の意思決定

まず立ち位置を確定させましょう。あなたは今、どちら側にいますか。

1-1. 既存顧客が「継続できること／できないこと」（公式）

公式の availability change は、既存顧客のサポート範囲を EDS の種類で明確に分けています。ここは誤解が多いので正確に引用します。

• 組織イベントデータストア（organization EDS） がある場合：Lake は従来どおり機能する。組織に新しく追加されるメンバーアカウントのサポートも、追加リージョンへの拡張も継続される。
• アカウントイベントデータストア（account EDS）のみの場合：既存アカウント分は継続サポートされ、新リージョンへの拡張もできる。ただし 組織に新規追加されたアカウントの取り込みはサポートされない。新規アカウントもカバーしたいなら、組織EDSを作るか CloudWatch へ移行する必要がある。
• なお Lake は重大なバグ修正とセキュリティアップデートのみを受ける状態になります。新機能は期待できません。

重要：これは「Lake が止まる」話ではありません。公式は「AWS CloudTrail は引き続き完全にサポートされる。新規受付を終了したのは CloudTrail Lake のみ。証跡（Trails）・Insights・集約イベントには影響しない」と明記しています。慌てて証跡まで作り直す必要はありません。

1-2. AWS が推奨する移行先は CloudWatch（Athena+S3 だけではない）

ここは正確さが命なので、私見と公式を分けて書きます。公式が第一に推奨する移行先は Amazon CloudWatch です。CloudTrail Lake の EDS を CloudWatch に直接インポートできる仕組み（コンソールの Export to CloudWatch、または CLI の aws logs create-import-task）が用意されており、OCSF/OTel 対応・OpenSearch ネイティブ分析・サードパーティコネクタといった、Lake 顧客の要望が強かった機能が乗っています。

# 既存EDSをCloudWatchへインポート（CLI例：公式の create-import-task）
aws logs create-import-task \
  --import-source-arn "arn:aws:cloudtrail:ap-northeast-1:123456789012:eventdatastore/EXAMPLE-eds-id" \
  --import-role-arn "arn:aws:iam::123456789012:role/CloudTrailLakeExportRole" \
  --import-filter '{"startEventTime": 1704067200, "endEventTime": 1706745600}'

# 非同期処理なので進捗を確認
aws logs describe-import-tasks --import-id "EXAMPLE-import-id"

移行の落とし穴（公式注記）：**2023年より前のデータは CloudTrail Lake から CloudWatch へは移行されません。**2023年より前のイベントが必要なら、Lake で直接クエリし続けるか、S3 バケットへ退避させてください。だからこそ、いきなり全量を流すのではなく、まず24時間など狭い範囲でパイロット移行し、スキーマ・クエリ・ダッシュボード・IAM ロールが期待どおり動くか検証してから本番移行する——というのが公式のベストプラクティスです。

ではなぜ本記事は Athena+S3 も主役に据えるのか。理由は3つです。

1. 多くのチームは Lake/CloudWatch とは別に、証跡の配信先 S3 をすでに持っている。そこに Athena テーブルを定義するだけで、追加の取り込みコストなしに SQL 分析が始められる。
2. スキャン単価が安く（Lake は $0.005/GB スキャン、Athena は $5/TB ≒ $0.005/GB だが、Athena はパーティション射影で読む範囲を物理的に削れる）、コストを構造で殴れる。
3. Lake と Athena は フェデレーションで橋渡しできる（6章）。二者択一ではなく、併用も移行のグラデーションも取れる。

結論として、新規構築なら「証跡→S3→Athena」を土台に置き、マネージド志向・OCSF/OpenSearch が欲しいなら CloudWatch を選ぶ——というのが2026年の現実解です。それぞれの向き不向きは5章で表にします。

2. Lake の仕組み：イベントデータストア（EDS）を正しく理解する

Lake を使いこなす鍵は、土台である EDS の性質を正確に押さえることです。ここを曖昧にしたまま使うと、後から「保持期間を間違えた」「KMSキーを外せない」といった取り返しのつかない事故になります。

2-1. EDSの5つの本質

2-2. 保持階層は「拡張可能な1年」か「7年」の二択

EDS を作るときの最重要パラメータが保持期間（retention）です。公式は2つの課金体系に対応した保持タイプを持ちます。

直感として：「まず分析したいだけなら One-year-extendable、7年保管が法令・契約で確定しているなら Seven-year」。保持を長くするほどストレージ料金（1年拡張分は $0.023/GB/月）が効いてきます。料金の深掘りは CloudTrail 料金・コスト最適化ガイド に任せ、ここでは「保持＝コスト」という一点だけ刻んでおきます。

2-3. 既存の証跡イベントを「コピー取り込み」できる

EDS は将来のイベントを貯めるだけでなく、既存の証跡（trail）に溜まったイベントを EDS にコピーして、過去のある時点までのスナップショットを作れます。「Lake を後から導入したが、過去ログも SQL で分析したい」という現場で効きます。新規取り込みではなく既存ログの取り込みなので、過去のインシデント調査を Lake の SQL に載せ替えられるわけです。

2-4. 組織EDS：全社監査を1つのSQL面に

複数アカウントを AWS Organizations で束ねているなら、組織EDSを作ることで全メンバーアカウントのイベントを1つの EDS に集約できます。1-1で見たとおり、新規受付終了後も組織EDSは新規メンバーアカウントを自動カバーします。マルチアカウント監査の設計そのものは 組織トレイル・マルチアカウント監査ガイド に詳しいので、Lake と組み合わせる前提でそちらも参照してください。

3. Trino SQL クックブック：コピペで使える実用クエリ集

ここが本記事の主役です。CloudTrail Lake は すべての有効な Trino SELECT 文・関数をサポートします（SQL constraints）。SELECT のみで、データを変更・改ざんするクエリは一切通りません。以下のクエリは公式のサンプルクエリ集・クエリ生成例のフィールドパスに忠実です。

使い方の前提（3つ）

1. FROM には EDS の ID（ARN の末尾）を書きます。本記事では $EDS_ID と表記します。実行時にあなたのIDへ置換してください。
2. 必ず eventTime の範囲を入れる。 クエリ課金はスキャンしたデータ量（$0.005/GB）に対して発生します。期間を絞ることがそのままコスト削減です。
3. ネストフィールドはドット記法（userIdentity.arn）、マップ型は element_at(map, 'key') でアクセスします。

3-1. トップAPIコール元（誰がどのAPIを叩いているか）

「IAM を最も呼んでいるプリンシパルは誰か」をあぶり出す、運用の基本クエリです。サービスを変えれば汎用的に使えます。

SELECT
    COUNT(*) AS apiCount,
    eventName,
    recipientAccountId,
    userIdentity.principalId
FROM $EDS_ID
WHERE userIdentity.principalId IS NOT NULL
    AND eventSource = 'iam.amazonaws.com'
    AND eventTime >= '2026-06-01 00:00:00'
    AND eventTime <  '2026-06-27 00:00:00'
GROUP BY eventName, recipientAccountId, userIdentity.principalId
ORDER BY apiCount DESC
LIMIT 50;

3-2. AccessDenied スパイクをプリンシパル別に検出

認可エラーの急増は、設定ミスか、あるいは攻撃者の権限探索の兆候です。誰が・どのアクションで弾かれているかを集計します。

SELECT
    userIdentity.arn AS principal,
    eventName,
    eventSource,
    COUNT(*) AS deniedCount
FROM $EDS_ID
WHERE (errorCode = 'AccessDenied' OR errorMessage = 'Access Denied')
    AND eventTime >= '2026-06-20 00:00:00'
    AND eventTime <  '2026-06-27 00:00:00'
GROUP BY userIdentity.arn, eventName, eventSource
ORDER BY deniedCount DESC
LIMIT 100;

なぜ errorCode と errorMessage の両方を見るのか：サービスによって AccessDenied（errorCode）として記録される場合と、Access Denied（errorMessage）として記録される場合があるためです。公式のクエリ生成例も両方を OR で拾っています。フォレンジック観点でのインシデント対応フレームは 脅威検知・インシデント対応ガイド に委ねます。本記事のクエリはあくまで「分析・集計」に寄せています。

3-3. ルートユーザーの利用を洗い出す

ルートユーザーの操作はそれ自体が監査の最重要シグナルです。userIdentity.type = 'Root' で抽出します。

SELECT
    eventTime,
    eventName,
    eventSource,
    sourceIPAddress,
    awsRegion,
    userIdentity.arn
FROM $EDS_ID
WHERE userIdentity.type = 'Root'
    AND eventTime >= '2026-06-01 00:00:00'
    AND eventTime <  '2026-06-27 00:00:00'
ORDER BY eventTime DESC;

3-4. MFAなしのコンソールログイン

公式サンプルそのままの、最も重要なセキュリティクエリの1つです。サインインイベントで MFAUsed が No のものを拾います。

SELECT
    eventTime,
    userIdentity.arn,
    sourceIPAddress,
    awsRegion,
    element_at(additionalEventData, 'MFAUsed') AS mfaUsed
FROM $EDS_ID
WHERE eventSource = 'signin.amazonaws.com'
    AND eventName = 'ConsoleLogin'
    AND element_at(additionalEventData, 'MFAUsed') = 'No'
    AND eventTime >= '2026-06-01 00:00:00'
    AND eventTime <  '2026-06-27 00:00:00'
ORDER BY eventTime DESC;

additionalEventData はマップ型なので、element_at(additionalEventData, 'MFAUsed') でキー値を取り出します。これは公式サンプル console-login-with-no-mfa.sql のフィールドパスに忠実です。

3-5. クロスアカウントアクセス（別アカウントから自分のリソースへ）

「呼び出し元のアカウントID（userIdentity.accountId）と、受け側のアカウントID（recipientAccountId）が一致しない」イベントは、クロスアカウントアクセスです。意図しない外部アクセスの検出に使います。

SELECT
    eventTime,
    userIdentity.principalId,
    eventName,
    eventSource,
    userIdentity.accountId   AS callerAccount,
    recipientAccountId       AS resourceAccount
FROM $EDS_ID
WHERE userIdentity.accountId != recipientAccountId
    AND eventTime >= '2026-06-01 00:00:00'
    AND eventTime <  '2026-06-27 00:00:00'
ORDER BY eventTime DESC;

3-6. IAMポリシー変更のタイムライン

権限変更は監査の核心です。PutRolePolicy などの変更系イベントを、対象ロール名・ポリシードキュメントとともに時系列で並べます。マップ型 requestParameters から element_at で値を抜くのがポイントです。

SELECT
    eventTime,
    recipientAccountId,
    eventName,
    userIdentity.arn,
    element_at(requestParameters, 'roleName')       AS roleName,
    element_at(requestParameters, 'policyDocument')  AS policyDocument
FROM $EDS_ID
WHERE eventName IN ('PutRolePolicy', 'AttachRolePolicy', 'PutUserPolicy', 'CreatePolicyVersion')
    AND eventTime >= '2026-06-01 00:00:00'
    AND eventTime <  '2026-06-27 00:00:00'
ORDER BY eventTime DESC;

3-7. 読み取り/書き込みの日次トレンド

readOnly フラグで読み取り系・書き込み系を分け、日次で集計します。アクティビティの異常な山を見つける起点になります。公式のクエリ生成例に忠実な CASE 集計です。

SELECT
    date(eventTime) AS eventDate,
    SUM(CASE WHEN readOnly = true  THEN 1 ELSE 0 END) AS readEvents,
    SUM(CASE WHEN readOnly = false THEN 1 ELSE 0 END) AS writeEvents
FROM $EDS_ID
WHERE eventTime >= '2026-06-01 00:00:00'
    AND eventTime <  '2026-06-27 00:00:00'
GROUP BY date(eventTime)
ORDER BY eventDate ASC;

3-8. ソースIP別のアクティビティ

不審な単一IPからの集中アクセスを見つけます。sourceIPAddress 別に件数とユニークなプリンシパル数を出します。

SELECT
    sourceIPAddress,
    COUNT(*) AS eventCount,
    COUNT(DISTINCT userIdentity.arn) AS distinctPrincipals
FROM $EDS_ID
WHERE eventTime >= '2026-06-20 00:00:00'
    AND eventTime <  '2026-06-27 00:00:00'
GROUP BY sourceIPAddress
ORDER BY eventCount DESC
LIMIT 50;

3-9. 複数EDSをまたぐJOIN（例：本番EDSと監査EDSの突き合わせ）

Lake は 複数の EDS をまたぐ高度なクエリをサポートします（multi-table query support）。サポートされる JOIN 系演算子は UNION / UNION ALL / EXCEPT / INTERSECT / LEFT JOIN / RIGHT JOIN / INNER JOIN です。

-- 2つのEDS（本番=edsA, 監査=edsB）を eventId で突き合わせる
SELECT
    edsA.eventName  AS prodEvent,
    edsB.eventName  AS auditEvent,
    edsA.eventTime
FROM eds1_id AS edsA
LEFT JOIN eds2_id AS edsB
    ON edsA.eventId = edsB.eventId
WHERE edsA.eventTime >= '2026-06-01 00:00:00'
    AND edsA.eventTime <  '2026-06-27 00:00:00'
ORDER BY edsA.eventTime DESC;

-- 3つのEDSのイベントを縦に連結して横断的に並べる
SELECT eventId, eventName FROM eds1_id
UNION
SELECT eventId, eventName FROM eds2_id
UNION ALL
SELECT eventId, eventName FROM eds3_id
ORDER BY eventId
LIMIT 100;

クエリ結果は 最大7日間 保持され、必要なら S3 バケットに保存できます（CLI の start-query --delivery-s3uri）。長時間（1時間超）走るクエリはタイムアウトする可能性がありますが、その場合も処理済みの部分結果は取得できます。だからこそ eventTime で範囲を絞ることが、コストと完走率の両面で効くのです。

4. ダッシュボードと生成AI：見える化と「SQLを書かない分析」

SQL を書ける人だけが分析できるのでは、組織の監査は回りません。Lake にはダッシュボードと生成AIによる補助があります。

4-1. 3種類のダッシュボード

ポイントは、各ウィジェットの実体が1つの SQL クエリだということです。つまり3章のクックブックは、そのままカスタムダッシュボードのウィジェットに転用できます。「MFAなしログイン」「ルート利用」「AccessDeniedスパイク」を並べた監査ダッシュボードを1枚作っておけば、日々の点検が SQL を都度書かずに済みます。

4-2. 自然言語クエリ生成は「GA」、結果要約は「preview」

ここは混同しやすいので、成熟度を明確に分けます。

クエリ生成（GA）は、SQL や CloudTrail のフィールドに詳しくなくても「先月のトップエラーは？」のような英語の問いから SQL を作ってくれます。CLI ではこう使います。

# 英語プロンプトからSQLを生成（生成は無料。実行時のみスキャン課金）
aws cloudtrail generate-query \
  --event-data-stores "arn:aws:cloudtrail:ap-northeast-1:123456789012:eventdatastore/EXAMPLE-eds-id" \
  --prompt "Show me all console login events for the past week"

# 返ってきた QueryAlias でそのまま実行
aws cloudtrail start-query --query-alias AWSCloudTrail-EXAMPLE-UUID

生成例（公式）はこんな具合です。プロンプト "Show any events with access denied errors for the past three weeks" に対して、errorCode = 'AccessDenied' と eventTime の範囲を含む SQL が返ります。

注意点（公式）：プロンプトに個人情報・機密情報を含めないこと。これは生成AI（LLM）であり、返ってきたSQLは必ず人が確認してから実行することが推奨されています。AIはあくまで「下書きを速くする」道具で、最終確認は人がやる——私が決済基盤で守ってきた「AIで速く、検証は人が」の原則と同じです。cloudtrail:GenerateQuery を IAM ポリシーから外せば、機能を明示的にオプトアウトできます。

5. Lake vs Athena 徹底比較：新規構築は結局どう選ぶか

ここがこれから作る人の本丸です。Lake は新規で選べない以上、現実の選択肢は 「S3 + Athena（自前管理）」 と 「CloudWatch（Lake後継のマネージド）」 の二択になります。判断軸を表で固定します。

5-1. 決定マトリクス

5-2. シナリオ別の推奨

• 「証跡の S3 配信は既にある。コストを最小化したい。SQL は自分で書ける」 → S3 + Athena。追加の取り込み料金なしで分析でき、パーティション射影でスキャン量を物理的に削れるのが最大の武器です。中小〜中規模の監査分析はこれで十分まかなえます。
• 「セキュリティ・運用・コンプライアンスのログを一元化したい。OCSF 正規化や OpenSearch ネイティブ分析、サードパーティコネクタが欲しい」 → CloudWatch。Lake の後継として公式が第一に推す道です。
• 「既存の Lake EDS があり、2023年以降のデータを使い続けたい」 → 当面は Lake を継続しつつ、必要に応じて CloudWatch へパイロット移行。2023年より前のデータは Lake に残すか S3 へ退避します。

5-3. S3 + Athena を選ぶときの実装指針（要点のみ）

新規で Athena を選ぶ場合の勘所は3つです。

1. パーティション射影（partition projection） を使い、region/year/month/day の階層で読む範囲を絞る。これがスキャン量＝コストを最も効かせるレバーです。
2. Glue データカタログにテーブル定義を置き、スキーマを一元管理する。
3. ライフサイクルで古いパーティションを Glacier に送り、ストレージ代と分析対象を分離する。

Athena 用テーブルの DDL（CloudTrail ログ向けのパーティション射影付き CREATE EXTERNAL TABLE）の完全版は、CloudTrail 監査ログ・ガバナンス・セキュリティ完全ガイド に掲載しています。本記事で全文を重複させると保守が二重になるため、DDL はピラーに一本化します。Lake と Athena のコスト計算の詳細（$/TB スキャンの実額、ライフサイクルの効き）は 料金・コスト最適化ガイド に委ねます。本章の役割は「どちらを選ぶか」の意思決定までです。

6. 外部ソースとフェデレーション：Lake の境界を広げる

Lake は AWS の中だけのものではありません。そして Lake と Athena は橋渡しできます。

6-1. AWS の外のアクティビティを取り込む（PutAuditEvents）

オンプレミス・SaaS・ハイブリッド環境のアクティビティイベントを、PutAuditEvents API と「チャネル（channel）」を通じて Lake に取り込めます。さらに、十数以上のパートナー統合（直接統合／ソリューション統合）が用意されており、AWS の監査ログと AWS 外のログを同じ EDS・同じ Trino SQLで横断分析できます。「AWS の操作」と「外部 SaaS の操作」を1つのタイムラインで追えるのは、インシデント調査で非常に強力です。

6-2. EDS を Glue データカタログにフェデレーション → Athena で照会

ここが Lake と Athena をつなぐ機能です。EDS を AWS Glue データカタログにフェデレーションすると、メタデータが Glue に登録され、Lake Formation 経由でAmazon Athena から同じイベントデータを SQL で照会できるようになります。

公式の挙動（federation）を正確に押さえます。

• フェデレーションを有効化すると、CloudTrail が aws:cloudtrail という名前のマネージドデータベース（無ければ作成）と、EDS の ID をテーブル名にしたマネージドフェデレーションテーブルを Glue データカタログに作る。
• Lake Formation が、フェデレーションされたリソースのきめ細かいアクセス制御を担う。フェデレーションロールを消したり Lake Formation で権限を剥奪すると、Athena から照会できなくなる。
• Athena でこのデータを照会するユーザーは、IAM で lakeformation:GetDataAccess を許可されている必要がある（AmazonAthenaFullAccess マネージドポリシーに含まれる）。
• フェデレーション自体に CloudTrail の課金は発生しない。発生するのは Athena のクエリ料金のみ。
• フェデレーションを無効化しても Lake のデータは一切削除されない。Athena から照会できなくなるだけで、Lake では引き続きクエリできる。
• 注意：フェデレーションが有効な EDS は削除できない。削除するには先にフェデレーション（と、有効なら削除保護）を無効化する必要がある。

フェデレーションロールに必要な最小権限の核は、EDS データへの読み取りアクセス（KMS暗号化していれば復号権限も）です。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "LakeFederationEDSDataAccess",
      "Effect": "Allow",
      "Action": "cloudtrail:GetEventDataStoreData",
      "Resource": "arn:aws:cloudtrail:ap-northeast-1:123456789012:eventdatastore/EXAMPLE-eds-id"
    },
    {
      "Sid": "LakeFederationKMSDecryptAccess",
      "Effect": "Allow",
      "Action": ["kms:Decrypt", "kms:GenerateDataKey"],
      "Resource": "arn:aws:kms:ap-northeast-1:123456789012:key/EXAMPLE-key-id"
    }
  ]
}

使い分けの示唆：**Lake のネイティブ Trino クエリは「即時・組み込みダッシュボード込み」、フェデレーション経由の Athena は「他の Athena テーブル（VPC Flow Logs、ALB ログ等）と JOIN したいとき」**に効きます。フェデレーションは、Lake から Athena への「移行のグラデーション」としても使えます——まず両方で同じデータを照会できる状態を作り、徐々に分析を Athena 側へ寄せていく、という移行設計が取れるわけです。

7. まとめ：Lake / Athena / CloudWatch 使い分けチートシート

最後に、明日からの意思決定に使える早見表で締めます。

CloudTrail Lake の新規受付終了は「終わり」ではなく、監査ログ分析の設計を見直す好機です。本質はずっと変わりません——監査ログを「貯めるだけのデータ」から「SQL で横断的に問い合わせられる資産」へ構造を変えること。Lake でも、Athena でも、CloudWatch でも、その一点を外さなければ、インシデントの一次切り分けも、監査への回答も、勘ではなく構造で速く正確にこなせます。

私はサーバーレス決済基盤で、信頼性とコストの「正しさ」をコードの構造で担保し、本番二重課金 0 件を維持してきました。監査ログ基盤も同じ思想で設計できます——「分析できる構造」を最初から組み込むことで、有事に強く、平時に安いログ基盤になる。

監査ログを「分析できる資産」に設計し直したい方へ。 既存 Lake の使いこなし、Athena/CloudWatch への移行設計、マルチアカウント監査の集約、コストを構造で抑える設計まで、現場の実装に踏み込んで伴走します。お気軽に お問い合わせ ください。

一次情報（公式ドキュメント）

• CloudTrail Lake availability change（新規受付終了・移行）
• Working with AWS CloudTrail Lake
• CloudTrail Lake SQL constraints（Trino・JOIN・制約）
• Create queries from natural language prompts（クエリ生成：GA）
• Federate an event data store（Glue/Athena連携）
• CloudTrail Lake sample queries（GitHub: aws-samples）
• AWS CloudTrail Pricing