AWS Lake Formation データレイクガバナンス設計パターン5選｜SAA-C03 頻出 Fine-Grained アクセス制御・クロスアカウント共有完全攻略
AWS SAA-C03 で頻出の AWS Lake Formation を完全整理。S3データレイクの列・行レベルアクセス制御・クロスアカウント共有・LF-TBAC タグベース制御・Glue+Athena パイプライン・Redshift Spectrum ハイブリッドの5つの設計パターンを体系化。試験シナリオを即断できる粒度で分解する。
「Lake Formation は “S3データレイクの上に乗るガバナンス層” だ。S3バケットポリシーと IAM だけでは実現できない列レベル・行レベルのアクセス制御と、クロスアカウント共有の複雑さを劇的に簡素化する。SAA-C03 が問うのは『誰に何のデータをどの粒度で見せるか』という制御設計の選択力。Lake Formation を選ぶのは『Glue Data Catalog で管理されたデータに対し、チーム・ロール・アカウント単位で細粒度アクセス制御をかけたい』というシナリオだ。この判断を即答できるかどうかが合否を分ける」 — 本記事では SAA-C03 頻出の AWS Lake Formation 設計パターン5選を体系化し、データレイクガバナンスの選択軸から試験シナリオを即断できる粒度まで分解する。
※ 本記事はアフィリエイト広告（Amazon アソシエイト等）を含みます
📑 目次
- 結論：Lake Formation を選ぶ判定軸
- Lake Formation の基本構造（データカタログ・パーミッション・LF-Tags）
- パターン1：Fine-Grained Access Control（列・行レベルのアクセス制御）
- パターン2：Lake Formation + Glue ETL + Athena 分析パイプライン
- パターン3：クロスアカウントデータ共有（RAM + LF タグベース制御）
- パターン4：LF-TBAC（Tag-Based Access Control）スケーラブルガバナンス
- パターン5：Lake Formation + Redshift Spectrum ハイブリッドクエリ
- Lake Formation vs S3バケットポリシー vs IAM 比較
- 試験頻出シナリオ → 解法パターン早見表
- 次のアクション チェックリスト
- 関連記事
- 関連サイト
1. 結論：Lake Formation を選ぶ判定軸
AWS Lake Formation は「S3 データレイクの上に乗るフルマネージドなデータガバナンス・セキュリティサービス」だ。Glue Data Catalog と連携し、S3に保存されたデータに対してテーブル・列・行・セルの各粒度でアクセス制御を実現する。
Lake Formation が最適なシナリオ：
| シナリオ | 理由 |
|---|---|
| 特定の列（個人情報・機密フィールド）を特定ロールに隠したい | カラムレベルセキュリティ（Column-Level Security）で列単位のアクセス制御が可能 |
| データのサブセット（例：自部門のデータのみ）を行単位で絞り込みたい | 行フィルタ（Row-Level Security）でデータサブセットを制御 |
| 複数の AWS アカウント間でデータカタログを安全に共有したい | RAM + LF タグでクロスアカウント共有をコード最小で実現 |
| 数百テーブルへのアクセス権をロールタグで一括管理したい | LF-TBAC（Tag-Based Access Control）で権限爆発を防止 |
| Glue Data Catalog を中央集権的なデータ資産として管理したい | Lake Formation が Catalog の「Information Resource」管理者になる |
2. Lake Formation の基本構造
Lake Formation を理解するには「データレイク登録・データカタログ・パーミッション・LF-Tags」の4層を押さえる。
データレイク登録（Register）
S3 バケットまたはプレフィックスを Lake Formation に「データレイクの場所」として登録する。登録後は Lake Formation がその S3 パスへのアクセスを管理する。
S3 バケット（s3://my-data-lake/）
└─ [Lake Formation に Register（登録）]
└─ LF-managed credential（lakeformation.amazonaws.com がアクセス権を仲介）データカタログ（Data Catalog）
AWS Glue Data Catalog のデータベース・テーブル・列がアクセス制御の単位になる。Lake Formation はテーブルや列への Select・Describe・Alter・Drop などの Data Catalog パーミッションを IAM プリンシパル（ユーザー/ロール）に付与する。
パーミッションの種類
| パーミッションレベル | 対象 | 代表的な権限 |
|---|---|---|
| Data location | S3 パス | CREATE_TABLE_READ_WRITE などのストレージアクセス |
| Database | Glue データベース | CREATE_TABLE、DESCRIBE、ALTER、DROP |
| Table | Glue テーブル | SELECT、INSERT、DELETE、ALTER |
| Column（列） | テーブル内の列 | SELECT（対象列のみ）、または除外列の指定 |
| Row filter（行） | テーブルの行サブセット | 条件式で行を絞り込み（例：department = 'sales'） |
LF-Tags（Lake Formation Tags）
Lake Formation タグ（LF-Tag）は「キー-値ペア」で Data Catalog リソースにラベルを付け、ロールへのタグアクセス制御を一括で管理する仕組みだ。詳細はパターン4で解説する。
3. パターン1：Fine-Grained Access Control
課題：S3 に保存した従業員マスタ（employees テーブル）に対し、HR チームは全列を参照できるが、一般マネージャーには salary・ssn（社会保障番号）列を非表示にしたい。さらに自部門の行のみ参照させたい。
アーキテクチャ：
S3（s3://hr-data-lake/employees/）
↓ [Lake Formation Register]
AWS Glue Data Catalog（employees テーブル）
↓
Lake Formation パーミッション
├─ HR ロール: SELECT（全列）+ Row Filter なし
└─ Manager ロール: SELECT（salary・ssn を除外）+ Row Filter（department = '{user_dept}'）
↓
Amazon Athena（クエリエンジン）
→ HR は全列・全行が見える
→ Manager は PII 列なし＋自部門行のみ設計のポイント：
| 設定 | 方法 | 効果 |
|---|---|---|
| 列の除外 | テーブルパーミッションで「Exclude columns」に salary, ssn を指定 | Manager ロールのクエリ結果からこれらの列が自動除外される |
| 行フィルタ | department = 'sales' などの条件式を Row Filter として設定 | Athena クエリが WHERE 句を自動付加したように動作 |
| 複数フィルタの組み合わせ | 同一ロールに複数フィルタを OR 条件で付与可能 | 複数部門の Manager に柔軟対応 |
| Cell-Level Security | 列 × 行の組み合わせで特定セルを制御 | 特定部門の salary のみマスク、等のきめ細かな制御 |
4. パターン2：Lake Formation + Glue ETL + Athena 分析パイプライン
課題：オンプレミスの販売データを S3 に取り込み、Glue ETL で整形後、Athena で分析。データサイエンスチームには分析用テーブルへの SELECT 権限のみ付与し、生データ（raw/ プレフィックス）には触れさせたくない。
アーキテクチャ：
オンプレミス DB / SaaS
↓ [AWS DMS / AppFlow / DataSync]
Amazon S3
├─ raw/（生データゾーン）
└─ curated/（整形済みデータゾーン）
↓
[Lake Formation に Register（raw + curated 両方）]
↓
AWS Glue ETL Job
└─ LF パーミッション：Glue サービスロールに raw/SELECT + curated/INSERT
↓ ETL 変換後
Glue Data Catalog（curated テーブル）
↓
Lake Formation パーミッション
├─ Glue ETL ロール: raw SELECT + curated INSERT
├─ Data Science ロール: curated テーブルのみ SELECT（raw へのアクセスなし）
└─ Admin ロール: 全テーブル全権限
↓
Amazon Athena（分析クエリ）ゾーン設計のポイント：
| ゾーン | 格納データ | アクセス権 |
|---|---|---|
| raw/ | 生の取り込みデータ（CSV/JSON等） | ETL ロールのみ |
| curated/ | Glue ETL 後の Parquet/ORC | Data Science・BI ロール |
| archived/ | 90日以上の古いデータ | Admin のみ（コスト最適化） |
Glue ETL ジョブの Lake Formation 連携設定：
Glue ジョブが Lake Formation で保護されたデータにアクセスするには、ジョブのサービスロールに以下の2つが必要：
- IAM ポリシー：
glue:*、s3:GetObject、s3:PutObject等 - LF パーミッション：対象テーブルへの
SELECT（読み取り元）・INSERT（書き込み先）
5. パターン3：クロスアカウントデータ共有
課題：中央データプラットフォームアカウント（Account A）の Glue Data Catalog にある分析用テーブルを、消費者アカウント（Account B / Account C）の Athena から参照させたい。各アカウントのユーザーには最小権限のみ付与する。
アーキテクチャ：
Account A（データプラットフォーム）
└─ S3 バケット（s3://central-datalake/）
└─ Glue Data Catalog（sales_db / analytics テーブル）
└─ Lake Formation パーミッション：
Account B に sales_db.analytics の SELECT を GRANT WITH GRANT OPTION
Account C に sales_db.summary の SELECT を GRANT
AWS RAM（Resource Access Manager）
└─ Glue Data Catalog リソース共有を Account B / C に送付
Account B（消費者）
└─ RAM 招待を承認
└─ Local Glue Data Catalog にリモートデータベース参照を作成
└─ Athena クエリ → Account A の analytics テーブルを参照
└─ IAM ロールに LF パーミッション（Account B 側でも付与）
Account C（消費者）
└─ 同様（summary テーブルのみ参照可）クロスアカウント共有の手順（試験で問われる設定順）：
| ステップ | 作業者 | 操作 |
|---|---|---|
| 1 | Account A 管理者 | Lake Formation で Account B の AWS アカウント ID に SELECT パーミッション付与 |
| 2 | Account A 管理者 | RAM リソース共有を作成し、Glue Database を Account B に共有 |
| 3 | Account B 管理者 | RAM 招待を承認 |
| 4 | Account B 管理者 | Account B の Glue Catalog に「リモートデータベース」としてリンクを作成 |
| 5 | Account B 管理者 | Account B 側でも IAM ロールに LF パーミッション（Describe/Select）を付与 |
| 6 | Account B ユーザー | Athena で Account A のテーブルをクロスアカウントクエリ |
| 評価項目 | S3バケットポリシー単体 | Lake Formation（RAM共有） |
|---|---|---|
| アクセス制御の粒度 | バケット・プレフィックス単位 | テーブル・列・行単位 |
| クロスアカウント設定 | S3ポリシー記述のみ | RAM + LF パーミッションの2段階 |
| データカタログ共有 | 不可（S3パスのみ） | Glue テーブル定義ごと共有可 |
| 列・行レベル制御 | 不可 | 可（Fine-Grained Access Control） |
| 監査ログ | S3アクセスログ | CloudTrail + LF アクセスログ（テーブル単位） |
6. パターン4：LF-TBAC（Tag-Based Access Control）
課題：200テーブルを持つデータレイクで、テーブルごとに IAM ポリシーや LF パーミッションを個別付与すると管理が爆発する。部門・機密度・地域でタグ分類し、タグベースでアクセス権を一括管理したい。
LF-TBAC の仕組み：
LF-Tag の設計例：
TagKey: department → Values: [sales, hr, finance, engineering]
TagKey: sensitivity → Values: [public, internal, confidential, restricted]
TagKey: region → Values: [apac, emea, amer]
テーブルへのタグ付け：
employees テーブル → {department: hr, sensitivity: confidential}
sales_metrics テーブル → {department: sales, sensitivity: internal}
public_dashboard テーブル → {sensitivity: public}
ロールへのタグアクセス権付与：
HR-ロール → SELECT on {department: hr}
→ hr タグが付いた全テーブルへ一括アクセス
Sales-ロール → SELECT on {department: sales, sensitivity: internal}
→ sales + internal タグを両方持つテーブルのみLF-TBAC の管理フロー：
| タスク | TBAC あり | TBAC なし（従来型） |
|---|---|---|
| 新テーブル追加時の権限設定 | タグを付けるだけ（既存ロール権限が自動適用） | 全ロールへ個別 GRANT 操作が必要 |
| 新ロール追加時 | タグキー=値を指定するだけ | 全対象テーブルへ個別 GRANT 操作が必要 |
| 権限変更時 | タグ値を更新 | 全テーブルの GRANT/REVOKE をやり直し |
| 誤設定リスク | タグ設計の精度に依存 | テーブル数×ロール数の組み合わせ誤りリスク |
LF-Tag 設計の原則：
- タグキーの数は 5〜10 個程度に絞る（多すぎると管理が複雑化）
- タグ値は組織の分類軸（部門・機密度・地域・データドメイン）に対応させる
- タグの継承：Database に付与したタグはその中の全 Table に継承される
- 上書き可：Table 単位でタグを上書き（Database タグを無効化）できる
7. パターン5：Lake Formation + Redshift Spectrum ハイブリッドクエリ
課題：Redshift（DWH）にある構造化データと、S3データレイクの半構造化データ（JSON/Parquet）を、単一の SQL クエリで結合して分析したい。Lake Formation のアクセス制御も一貫して効かせたい。
アーキテクチャ：
Amazon Redshift（DWH）
├─ 内部テーブル：orders（過去3ヶ月の受注データ、高頻度アクセス）
└─ Redshift Spectrum 外部テーブル（Lake Formation 連携）
↓
AWS Glue Data Catalog（external_schema でリンク）
└─ S3 データレイク（3年分の注文履歴 Parquet）
↓
Lake Formation パーミッション
└─ Redshift クラスターの IAM ロールに LF パーミッション付与
クエリ例：
SELECT r.order_id, r.amount, h.product_category
FROM orders r -- Redshift 内部テーブル
JOIN spectrum.order_history h -- S3 上の外部テーブル
ON r.order_id = h.order_id
WHERE h.year BETWEEN 2022 AND 2024;設定の要点：
| 設定項目 | 内容 |
|---|---|
| Redshift の外部スキーマ作成 | CREATE EXTERNAL SCHEMA spectrum FROM DATA CATALOG DATABASE 'sales_db' IAM_ROLE 'arn:...' CREATE EXTERNAL DATABASE IF NOT EXISTS; |
| IAM ロールへの LF パーミッション | Redshift クラスターの IAM ロールに Glue テーブルへの SELECT を LF パーミッションで付与 |
| Redshift Spectrum の IAM ロール | lakeformation:GetDataAccess 権限が必要（Spectrum が LF 経由で S3 認証情報を取得するため） |
| 列・行フィルタの適用 | LF の Fine-Grained 設定は Spectrum 経由クエリにも適用される |
8. Lake Formation vs S3バケットポリシー vs IAM 比較
| 評価項目 | S3バケットポリシー | IAM ポリシー単体 | Lake Formation |
|---|---|---|---|
| アクセス制御の粒度 | バケット・オブジェクト単位 | API アクション単位 | テーブル・列・行・セル単位 |
| 列レベル制御 | 不可 | 不可 | 可（Column-Level Security） |
| 行レベル制御 | 不可 | 不可 | 可（Row Filter） |
| Data Catalog との統合 | なし | なし | Glue Data Catalog と完全統合 |
| クロスアカウント共有 | バケットポリシーで S3 共有可能 | クロスアカウントロール委任 | RAM + LF でカタログごと共有 |
| タグベース管理（ABAC） | 不可 | IAM タグ条件（サービス境界） | LF-TBAC でデータカタログ ABAC |
| 監査ログ詳細度 | S3 アクセスログ（オブジェクト単位） | CloudTrail API 履歴 | CloudTrail + LF（テーブル・クエリ単位） |
| 最適ユースケース | S3 直接アクセス制御 | 一般的な AWS API アクセス制御 | データレイクの構造化データガバナンス |
9. 試験頻出シナリオ → 解法パターン早見表
| シナリオ | 解法 | キーポイント |
|---|---|---|
| 「S3 のデータに特定列だけ見せたい」 | Lake Formation → Column-Level Security | S3バケットポリシーでは不可 |
| 「部門ごとに自部門の行のみ参照」 | Lake Formation → Row Filter | 行フィルタ条件式を設定 |
| 「200テーブルの権限管理を効率化」 | LF-TBAC（LF-Tag）でタグベース制御 | ロール×テーブルの組み合わせ爆発を防ぐ |
| 「別アカウントに Glue テーブルを共有」 | RAM + Lake Formation パーミッション | RAM 単体では LF 保護データにアクセス不可 |
| 「Glue ETL ジョブが S3 データを読めない」 | IAM ポリシー かつ LF パーミッションの両方を確認 | and-条件：どちらか欠けても失敗 |
| 「Athena でクロスアカウントの S3 を分析」 | RAM + LF パーミッション + Account B 側でもパーミッション付与 | 3ステップ必要 |
| 「Redshift と S3 のデータを結合して分析」 | Redshift Spectrum + Lake Formation 外部スキーマ | lakeformation:GetDataAccess 権限が必要 |
| 「コード不要でデータレイクを素早く構築」 | Lake Formation の「Create Data Lake」ウィザード | S3 + Glue Crawler + LF を自動構成 |
| 「PII データを機密性タグで分類管理」 | LF-TBAC の sensitivity タグ + Macie 連携 | Macie で PII 検出 → LF タグ付けを自動化 |
| 「データレイクのアクセス監査証跡」 | CloudTrail + Lake Formation Data Access ログ | テーブル単位でクエリ実行者を追跡可能 |
10. 次のアクション チェックリスト
11. 関連記事
- SAA-020：データレイク設計パターン — Lake Formation が管理するデータレイクの全体構成
- SAA-016：暗号化設計パターン — Lake Formation + KMS によるデータ暗号化
- SAA-043：AppFlow × SaaS 統合設計パターン — Lake Formation との連携パターン（データ取り込み後のガバナンス）
- SAA-011：IAM 設計パターン — IAM + Lake Formation の組み合わせによる最小権限設計
- SAA-035：マルチアカウント設計パターン — RAM による Lake Formation クロスアカウント共有の基盤