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

> CloudTrail Lakeを実践で使う/見極めるガイド。不変のイベントデータストアとTrino SQLによる横断分析、14のマネージドダッシュボードと自然言語クエリ生成、そして2026年5月31日の新規受付終了を踏まえたAthena+S3・CloudWatchとの使い分け・移行までを公式に忠実な実クエリで解説します。

- 公開日: 2026-06-27
- 著者: 友田 陽大
- タグ: AWS, CloudTrail, CloudTrail Lake, Athena, SQL, アーキテクチャ設計
- URL: https://tomodahinata.com/blog/aws-cloudtrail-lake-trino-sql-athena-migration-guide
- カテゴリ: AWS CloudTrail 監査・ガバナンス
- 総合ガイド: https://tomodahinata.com/blog/aws-cloudtrail-audit-logging-governance-security-guide

## 要点

- CloudTrail Lakeは2026/5/31以降 新規受付終了。既存顧客は通常どおり継続でき、新規はAthena+S3またはCloudWatchが現実解。
- Lakeの本質は『不変・ORC列指向のイベントデータストア＋全Trino SELECT文』。90日・単一属性しか検索できないイベント履歴の限界を越える横断SQL分析の資産になる。
- コピペで使える実用Trinoクエリ集（トップAPIコール・AccessDeniedスパイク・MFAなしログイン・クロスアカウント・IAM変更追跡・複数EDSのJOIN）を公式サンプルに忠実に掲載。
- 新規構築の意思決定は『マネージド/不変/即SQL=Lake後継のCloudWatch』vs『安いスキャン単価/パーティション射影/自前管理=S3+Athena』。シナリオ別に推奨を提示。
- EDS→Glue Data Catalog→AthenaフェデレーションでLakeとAthenaは橋渡しできる。自然言語クエリ生成はGA、結果要約はpreview。

---

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

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

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

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

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

---

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

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

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

```text
[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 監査ログ・ガバナンス・セキュリティ完全ガイド](/blog/aws-cloudtrail-audit-logging-governance-security-guide)（ピラー記事）に集約しています。本記事では DDL を全文再掲せず、**Lake そのものと「Lake vs Athena の使い分け」を深掘り**します。

---

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

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

| あなたの状況 | 結論 | 取るべき道 |
| --- | --- | --- |
| すでに Lake の EDS を運用中 | **継続利用可。この記事の2〜4章をそのまま使う** | 既存EDSを使い倒す。必要なら移行も検討（後述） |
| これから監査ログ分析基盤を新規構築 | **Lake は選べない。Athena+S3 か CloudWatch が現実解** | 5章の決定マトリクスで選ぶ |
| 組織にメンバーアカウントを追加予定の既存顧客 | **組織EDSがあるかを今すぐ確認** | 組織EDSなら新アカウントも自動カバー。アカウントEDSのみだと新規アカウントは取り込めない |

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

公式の [availability change](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-lake-service-availability-change.html) は、既存顧客のサポート範囲を 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 顧客の要望が強かった機能が乗っています。

```bash
# 既存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つの本質

| 性質 | 内容 | 設計上の含意 |
| --- | --- | --- |
| **不変（immutable）** | EDSはイベントの不変なコレクション。後から書き換え・改ざんできない | 監査証跡として信頼できる。フォレンジックの基盤になる |
| **1カテゴリ/EDS** | 1つのEDSには1つのイベントカテゴリ（管理／データ／ネットワーク等）だけ | 管理イベント用とデータイベント用は分ける。横断はJOINで |
| **高度なイベントセレクタで取捨選択** | 何を取り込むかを advanced event selectors で精密に制御 | 取り込み量＝コスト。最初から外科的に絞る |
| **マルチリージョン/マルチアカウント対応** | 組織EDSなら複数アカウント・複数リージョンを1つに集約 | 全社の監査ログを1つのEDSでSQL横断できる |
| **デフォルトでKMS暗号化** | CloudTrailが既定で暗号化。任意で顧客KMSキーも指定可 | **顧客KMSキーを指定すると、後から外す・変更することはできない**。慎重に |

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

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

| 保持タイプ | デフォルト | 最大 | 用途の目安 |
| --- | --- | --- | --- |
| **One-year-extendable**（1年・拡張可能） | 366日 | 3,653日（約10年） | 通常の運用分析〜長期保管まで柔軟に |
| **Seven-year**（7年） | 約2,557日（約7年） | 約2,557日（約7年・固定） | 7年保管が要件で確定しているコンプライアンス用途 |

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

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

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

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

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

---

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

ここが本記事の主役です。CloudTrail Lake は **すべての有効な Trino `SELECT` 文・関数**をサポートします（[SQL constraints](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/query-limitations.html)）。`SELECT` のみで、データを変更・改ざんするクエリは一切通りません。以下のクエリは公式の[サンプルクエリ集](https://github.com/aws-samples/cloud-trail-lake-query-samples)・[クエリ生成例](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/lake-query-generator.html)のフィールドパスに忠実です。

> **使い方の前提（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 を最も呼んでいるプリンシパルは誰か」をあぶり出す、運用の基本クエリです。サービスを変えれば汎用的に使えます。

```sql
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 スパイクをプリンシパル別に検出

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

```sql
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 で拾っています。フォレンジック観点でのインシデント対応フレームは [脅威検知・インシデント対応ガイド](/blog/aws-cloudtrail-security-threat-detection-incident-response-guide) に委ねます。本記事のクエリはあくまで「分析・集計」に寄せています。

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

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

```sql
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` のものを拾います。

```sql
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`）が一致しない」イベントは、クロスアカウントアクセスです。意図しない外部アクセスの検出に使います。

```sql
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` で値を抜くのがポイントです。

```sql
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` 集計です。

```sql
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` 別に件数とユニークなプリンシパル数を出します。

```sql
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](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/query-limitations.html)）。サポートされる JOIN 系演算子は `UNION` / `UNION ALL` / `EXCEPT` / `INTERSECT` / `LEFT JOIN` / `RIGHT JOIN` / `INNER JOIN` です。

```sql
-- 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;
```

```sql
-- 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種類のダッシュボード

| 種類 | 内容 | 編集 | 更新 |
| --- | --- | --- | --- |
| **マネージドダッシュボード** | CloudTrail が提供する **14個**のすぐ使えるダッシュボード | 編集不可（ただしカスタムとして保存可） | — |
| **カスタムダッシュボード** | 自分で作る。**最大10ウィジェット**、各ウィジェット＝1つのSQLクエリ | 可 | 手動 or スケジュール更新 |
| **Highlights ダッシュボード** | マネージドの「一目で分かる」サマリ。**6時間ごとに更新**し、**直近24時間**を表示 | — | 6時間ごと自動 |

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

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

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

| 機能 | 成熟度 | 概要 | 制約・リージョン |
| --- | --- | --- | --- |
| **クエリ生成**（自然言語→SQL） | **GA（一般提供）** | 英語のプロンプトから実行可能なSQLを生成。CLI は `generate-query` | IAM `cloudtrail:GenerateQuery` が必要・**英語のみ・3〜500文字**・**生成自体は無料**・サポートリージョンは約7つ |
| **クエリ結果要約**（結果→自然言語） | **preview（変更の可能性あり）** | 実行結果を英語の自然言語で要約 | 利用可能リージョンは **東京・バージニア北部・オレゴン** |

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

```bash
# 英語プロンプトから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. 決定マトリクス

| 観点 | CloudTrail Lake（既存顧客のみ） | S3 + Athena | CloudWatch（公式推奨の移行先） |
| --- | --- | --- | --- |
| 新規で使えるか | **不可（2026/5/31終了）** | **可** | **可** |
| マネージド度 | 高（取り込み・変換・保持を自動） | 低（テーブル・パーティション・ライフサイクルを自前管理） | 高 |
| 不変性・改ざん耐性 | **EDSが不変** | S3のオブジェクトロック等で別途担保 | CloudTrail安全機能を継承 |
| クエリエンジン | **Trino（全SELECT）** | Trino系（Athena/Presto） | Logs QL / SQL / PPL（OpenSearch） |
| 横断分析の即時性 | **すぐSQL**（取り込めば即） | テーブルDDL定義が必要 | 取り込み後に分析 |
| スキャンコスト | $0.005/GB | $5/TB（≒$0.005/GB）＋**パーティション射影で読む範囲を削減** | OpenSearch分析の料金体系 |
| 組み込みダッシュボード | **14マネージド + カスタム + Highlights** | 自前（QuickSight等） | OpenSearch/組み込み分析 |
| 初期セットアップ | 軽い（EDS作るだけ） | 中（S3配信＋Glueカタログ＋DDL） | 中（パイプライン設定） |
| OCSF/OTel・サードパーティ連携 | 限定的 | 自前 | **ネイティブ対応・コネクタ豊富** |

### 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 監査ログ・ガバナンス・セキュリティ完全ガイド](/blog/aws-cloudtrail-audit-logging-governance-security-guide) に掲載しています。本記事で全文を重複させると保守が二重になるため、DDL はピラーに一本化します。Lake と Athena の**コスト計算の詳細**（$/TB スキャンの実額、ライフサイクルの効き）は [料金・コスト最適化ガイド](/blog/aws-cloudtrail-pricing-cost-optimization-guide) に委ねます。本章の役割は「**どちらを選ぶか**」の意思決定までです。

---

## 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](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/query-federation.html)）を正確に押さえます。

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

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

```json
{
  "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 使い分けチートシート

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

| あなたの問い | 答え |
| --- | --- |
| これから監査ログ分析を作る。Lake は使える？ | **使えない（2026/5/31 新規受付終了）** |
| 新規でいちばん安く・自前で作りたい | **S3 + Athena**（パーティション射影でスキャン削減） |
| 新規でマネージド・OCSF・OpenSearch が欲しい | **CloudWatch**（公式推奨の移行先） |
| 既存の Lake EDS がある | **継続利用OK**。3章のクックブックで使い倒す |
| 既存 Lake を将来どうする | パイロット移行で CloudWatch を検証。**2023年より前のデータは Lake/S3 に残す** |
| 組織に新アカウントを足す予定（既存顧客） | **組織EDS**があるか今すぐ確認（無いと新規アカウントを取り込めない） |
| Lake のデータを他の Athena テーブルと JOIN したい | **Glue へフェデレーション** → Athena で照会 |
| SQL が書けないメンバーにも分析させたい | **自然言語クエリ生成（GA）** + 14マネージドダッシュボード |
| 90日超・属性横断で SQL 集計したい（そもそもの動機） | イベント履歴では不可。**Lake / Athena / CloudWatch のいずれか**が必須 |

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

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

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

---

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

- [CloudTrail Lake availability change（新規受付終了・移行）](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-lake-service-availability-change.html)
- [Working with AWS CloudTrail Lake](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-lake.html)
- [CloudTrail Lake SQL constraints（Trino・JOIN・制約）](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/query-limitations.html)
- [Create queries from natural language prompts（クエリ生成：GA）](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/lake-query-generator.html)
- [Federate an event data store（Glue/Athena連携）](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/query-federation.html)
- [CloudTrail Lake sample queries（GitHub: aws-samples）](https://github.com/aws-samples/cloud-trail-lake-query-samples)
- [AWS CloudTrail Pricing](https://aws.amazon.com/cloudtrail/pricing/)