AWS Lake Formation はどう進化してきたのか – データレイク権限管理からAmazon SageMaker Lakehouse のガバナンス基盤へ
クラウド事業本部の石川です。AWS Lake Formation は 2018 年 re:Invent でプレビュー発表されてから、本記事の執筆時点（2026 年 5 月）でおよそ 7 年半 が経ちました。当初の「S3 上のデータレイクのアクセス管理を一元化するサービス」から、現在では SageMaker Lakehouse / S3 Tables / Iceberg / Zero-ETL を横断する Lakehouse のガバナンス基盤へと、その意味合いが大きく変わってきました。
本記事では、Lake Formation がたどってきた進化を 5 つのフェーズ に区切って、時系列で整理してみたいと思います。
最初にまとめ
- AWS Lake Formation の進化は 大きく 5 フェーズに分けて理解できる
- データレイク権限モデルを作った時代（2018–2020）
- 行・列・セルまで絞り込む時代（2020–2022）
- コピーせずにアカウントを越える時代（2021–2023）
- Iceberg と既存 IAM 運用をつなぐ時代（2023–2024）
- Lakehouse の統制面になる時代（2024–現在）
- 当初の主役は テーブル / 列レベル権限 で、やがて LF-Tags / 行・セルレベル に広がり、その後 クロスアカウント・クロスリージョン共有、Iceberg / Hybrid Access Mode を経て、いまは S3 Tables / SageMaker Lakehouse までを収めるようになった
- 現在地は「データレイクのアクセス管理サービス」というより、Lakehouse 全体のガバナンス基盤
- 設計時の判断軸としては、まず Iceberg / S3 Tables を使うか を決め、次に 既存 IAM/S3 と共存させるか、最後に マルチアカウント / OU で配るか という順番で決めていくと、5 フェーズの何を選択するべきか決まる
進化のタイムライン
まずは全体像を見てください。フェーズの位置関係はおおよそ次のようになっています。
フェーズ別マップ
まず、各フェーズの テーマ・代表機能・解いた課題 を 1 枚にまとめます。
| フェーズ / 期間 | テーマ | 代表機能 | 解いた課題 |
|---|---|---|---|
| Phase 1 データレイク権限モデル（2018–2020） | S3 データレイク権限の標準化 | LF 発表 / GA、Glue Data Catalog 連携、Athena・QuickSight 連携、Table/Column 権限 | S3 バケットポリシー・IAM・Glue 権限の分散 |
| Phase 2 行・列・セルの権限管理（2020–2022） | Fine-Grained Access Control | Row-level / Cell-level / Column-level、LF-Tags（TBAC）、Governed Tables | Table・Column 単位だけでは PII / 地域 / 部署制御が困難 |
| Phase 3 コピーせずにアカウント共有（2021–2023） | クロスアカウント共有・Data Mesh | Cross-account database sharing（V1〜V3）、AWS RAM 連携、IAM principal / OU 共有、Cross-Region 参照 | アカウント・リージョンごとにデータ複製で破綻 |
| Phase 4 Iceberg と既存 IAM 運用の共存（2023–2024） | Open Table Format 統合 | Iceberg / Hudi / Delta への FGAC、Hybrid Access Mode（V4）、Iceberg 自動 compaction | 既存 IAM/S3 運用を止めずに段階的に Lake Formation へ移行 |
| Phase 5 Lakehouse の統制基盤（2024–現在） | Lakehouse 共通ガバナンス | Amazon S3 Tables、SageMaker Lakehouse、Iceberg REST endpoint、Zero-ETL、Federated Catalog、Cross-account sharing V5 | DWH / AI/ML / SaaS 連携の広がりで権限管理が再分散 |
フェーズ 1. データレイク権限モデルを作った時代（2018–2020）
このフェーズのテーマは、S3 データレイクの権限管理を「ひとつの管理面」にまとめることに尽きます。Lake Formation 発表前は、S3 バケットポリシー / IAM / Glue Data Catalog の権限がそれぞれ分散していました。
Lake Formation はここに対して、データレイクの作成・カタログ化・アクセス制御を 1 つのサービスで扱える ようにしてきた、というのが大きな貢献です。代表機能としては、Lake Formation の発表と GA、Glue Data Catalog 連携、Blueprints によるデータ取り込み、Table / Column レベル権限、Athena / QuickSight からの保護データ参照、あたりがこの時期の柱になります。「S3 にデータを置く」から「データレイクとして安全に共有する」までの面倒を、まとめて見てくれるサービスが初めて登場した時期、という整理がしっくりきます。
| 年月 | 機能 | カテゴリ | 概要 |
|---|---|---|---|
| 2018-11 | re:Invent プレビュー発表 | 全般 | S3 データレイク構築・管理・セキュリティを簡素化するサービスとしてプレビュー発表 |
| 2019-08 | GA（一般提供開始） | 全般 | Glue Data Catalog 連携、Blueprint によるデータ取り込み、Table/Database 権限が提供開始 |
| 2020-06 | QuickSight が Lake Formation 保護データに対応 | 連携 | BI 側まで Table / Column レベル制御が伝搬 |
フェーズ 2. 行・列・セルまで絞り込む時代（2020–2022）
このフェーズのテーマは Fine-Grained Access Control（FGAC） です。PII / 地域制限 / 部署別権限といった「同じテーブルでも見える範囲を変えたい」ユースケースが増えてくると、テーブル単位の権限だけではすぐに破綻します。とくに、個人情報を含むテーブルを完全に隠すと分析が回らないが、フルアクセスを許すとガバナンス的に NG、というジレンマは多くの組織で同時多発的に起きていました。
Lake Formation はこの時期に、Row-level security / Cell-level security / Column-level security を順次提供し、「テーブルを見せる / 見せない」だけでなく 特定の行・列・セル単位 で見える範囲を出し分けできるようにしてきました。さらにこのフェーズの後半で登場した LF-Tags（Tag-Based Access Control / LF-TBAC） は、今ではこちらが推奨になっています。
主なリリース
| 年月 | 機能 | カテゴリ | 概要 |
|---|---|---|---|
| 2020-12 | Transactions / Row-level Security / Governed Tables（プレビュー） | 権限 | ACID トランザクション、行レベル権限、Governed Tables をまとめてプレビュー |
| 2021-05 | LF-Tags（Tag-Based Access Control） | 権限 | リソースに LF-Tag を付与し、タグでまとめて権限を付与できる。大規模データレイクの権限管理を一気にスケーラブルに |
| 2021-11 | Governed Tables / 行・セルレベル権限 GA | 権限 | re:Invent 2021 で本機能群が正式提供開始 |
| 2022 | Cell-level / Column-level filtering の各種強化 | 権限 | Athena・Glue・Redshift Spectrum などの実行系からも FGAC を尊重する整備が継続 |
LF-TBAC が変えたもの
特に大きかったのは LF-Tags の登場です。リソースが数千・数万単位になってくると、grant SELECT on table A to role B を一つひとつ書く運用はすぐに破綻しますが、LF-Tags なら以下のように 属性ベースで権限をスケールできます。
リソースとプリンシパルそれぞれにタグ条件を設定するだけで、総当り的な権限付与が一気に消えます。「個別 grant の海から抜け出す」 という意味で、ここは画期的なリリースでした。
フェーズ 3. コピーせずにアカウントを越える時代（2021–2023）
このフェーズのテーマは、クロスアカウント / クロスリージョン共有、そして Data Mesh です。セキュリティ・課金・組織境界の都合でマルチアカウント構成が前提になるなか、データレイクをアカウント単位で分断して「コピーし続ける」運用は、コスト面でも鮮度面でも成立しなくなっていきました。
Lake Formation はこの時期に、Cross-account database sharing（V1）からスタートし、AWS RAM 連携、直接 IAM principal 共有 / AWS Organizations・OU 単位共有（V3）、LF-TBAC のクロスアカウント対応、Cross-Region table access、Resource links といった機能を順に積み上げていきました。これらが揃ったことで、実体をコピーしなくてもアカウント / リージョンを越えて安全に参照できる 基盤が初めて整い、AWS 上で Data Mesh 的アーキテクチャを素直に組めるようになった、というのがこのフェーズの大きな成果です。
2020年に改正された個人情報保護法の大改定、2022年4月1日に全面施行ありましたね。
主なリリース
| 年月 | 機能 | カテゴリ | 概要 |
|---|---|---|---|
| 2020-10 | Cross-account database sharing（V1） | データ共有 | AWS RAM を使った他アカウントへの DB/テーブル共有が登場 |
| 2021–22 | Cross-account version V2（RAM Share 集約） | データ共有 | 複数 Grant を 1 つの RAM Resource Share に集約。RAM Share 爆発を抑える最適化 |
| 2022-11 | Cross-account version V3 | データ共有 | LF-TBAC の RAM 統合、直接 IAM principal / OU 共有 が同時に解禁 |
| 2023-06 | Cross-Region table access | データ共有 | メタデータ・実データをコピーせず、別リージョンからの参照に対応 |
Cross-account version は V1 から V3 でこう変わった
このフェーズで地味に大事なのが、Lake Formation コンソールの Cross account version settings という設定値です。V1〜V3 の違いを 1 枚にまとめると次のとおりです。
| 観点 | V1（2020-10） | V2（〜2022） | V3（2022-11） |
|---|---|---|---|
| AWS RAM 統合 | △ 1 grant ＝ 1 RAM Share | ○ 複数 grant を集約 | ◎ LF-TBAC も RAM 経由 |
| Glue Data Catalog Resource Policy | 必須（LF-TBAC 含む） | LF-TBAC で必要 | 不要（RAM 経由に統一） |
| 直接 IAM principal 共有 | ✕ | ✕ | ○ |
| AWS Organizations / OU への共有 | ✕ | ✕ | ○ |
| 受信側 Data Lake Admin の再委任作業 | 必須 | 必須 | 削減 |
V3 は「共有の単位がアカウントから IAM principal へ降りてきた」点が大きく、Glue Resource Policy との二重管理から解放されました。Gemini で調べると「直接 IAM principal 共有は V4 から」と誤って回答されることがありますが、公式 What's New（2022-11）では V3 リリース時に同時提供 されています。
Data Mesh とどうつながるか
このフェーズは、Data Mesh 的なアーキテクチャを AWS でやるための“パイプライン” が一気に揃った時期でもあります。
「コピー禁止・参照だけ許可」という Data Mesh の現実的な落としどころを、Lake Formation + AWS RAM の組み合わせで素直に実装できるようになったのが、ここの大きな価値です。
フェーズ 4. Iceberg と既存 IAM 運用をつなぐ時代（2023–2024）
このフェーズのテーマは、Open Table Format（OTF）統合と、既存運用との橋渡しです。Apache Iceberg を中心とする「データレイクの上のトランザクション」前提の世界が広がるなか、Lake Formation 側もその影響を大きく受けました。一方で現実問題として、Lake Formation を入れたい組織ほど すでに IAM/S3 で動いている本番ワークロードを抱えており、「いきなり全員を切り替える」のはほぼ不可能でした。
このフェーズの代表機能は、Apache Iceberg / Hudi / Delta への Fine-Grained Access Control、Hybrid Access Mode、Iceberg 自動 compaction、Hive Metastore 連携、EMR からの FGAC あたりです。とくに Hybrid Access Mode は、Lake Formation に opt-in したユーザーだけを LF 経路で評価し、それ以外は従来どおり IAM/S3 経路 で動かせる、という現実解を提供しました。これにより、Lake Formation の導入は「Big Bang から Incremental」へ転換し、既存 IAM/S3 運用と並走しながらの段階移行が初めて現実的になります。
主なリリース
| 年月 | 機能 | カテゴリ | 概要 |
|---|---|---|---|
| 2023 | Apache Iceberg テーブルへの FGAC 対応 | Iceberg | Glue Data Catalog 上の Iceberg テーブルに Lake Formation の Table / Column / Row レベル権限が適用可能に |
| 2023-09 | Hybrid Access Mode（Cross-account version V4） | 権限 / 移行 | 同じテーブルでも、ユーザー単位で IAM/S3 ポリシー vs Lake Formation 権限 を切り替え可能に。Cross-account 側も V4 で Hybrid に対応 |
| 2023 | Iceberg 自動 compaction / メンテナンス | Iceberg / 運用 | テーブルメンテ運用を Glue / Lake Formation 側に寄せる動き |
| 2023–24 | Federated Catalog（Redshift / 外部）の共有 | データ共有 / 権限 | Cross-account version V4 以上で、Federated Catalog のオブジェクトもクロスアカウント共有が可能に |
| 2023–24 | Nested column / struct への権限制御強化 | 権限 | ネストされた構造体内のフィールド単位での権限制御 |
Hybrid Access Mode の何がうれしいか
Hybrid Access Mode のポイントは、「1 つのテーブルに対して、ユーザー X は IAM/S3 ポリシー経由で参照、ユーザー Y は Lake Formation 経由で FGAC 付き参照」という併存ができることです。
「全員一斉に切り替える」を回避できるため、運用を止めずに Lake Formation を導入する道が現実的になりました。Lake Formation の導入が PoC 止まりだった組織にとって、ここでようやく実運用へ進む準備が整ったという意味で、地味ながら最重要のリリースの一つだと考えています。
フェーズ 5. Lakehouse のガバナンス基盤の時代（2024–現在）
このフェーズのテーマは、Lakehouse（S3 Tables / SageMaker Lakehouse / Iceberg REST / Zero-ETL / Federated Catalog）の共通ガバナンス基盤になる、という一段大きな話です。データソースも処理エンジンも増え続けるなかで、「権限管理が再び分散する」問題が再燃しており、S3 データレイク単体ではなく Lakehouse 全体に通じる共通ガバナンスが必要になってきました。
代表機能としては、Amazon S3 Tables、SageMaker Lakehouse、Iceberg REST endpoint、Zero-ETL 連携、Redshift / DynamoDB / Snowflake / DataBricsなどを取り込む Federated Catalog、EMR on EKS の FGAC、そして Cross-account sharing V5 あたりが並びます。これらにより、Lake Formation は「S3 データレイク」から、S3 + DWH + 外部カタログ + SaaS / DB + AI/ML を含む Lakehouse 全体へと一気に広がりました。「Lake Formation = S3 のためのサービス」という従来のイメージから、いちばん大きく性格を変えたのがこのフェーズ、と言えます。
Snowflake / DataBrics などを取り込む Federated Catalogの要望も一気に増えた気がします。
主なリリース
| 年月 | 機能 | カテゴリ | 概要 |
|---|---|---|---|
| 2024-12 | Amazon SageMaker Lakehouse 発表 / Amazon S3 Tables 発表 | Lakehouse / S3 Tables | S3 上の Iceberg、Redshift、ML エンジンを統合する Lakehouse のビジョンが明確化。S3 Tables も同時に発表 |
| 2024-12 | S3 Tables × Glue Data Catalog × Lake Formation 統合 | S3 Tables | S3 Tables 上の Iceberg テーブルに Lake Formation grants でアクセス制御 |
| 2024-12 | Iceberg REST endpoint | Iceberg | Iceberg REST 仕様に準拠したエンドポイントから外部エンジン（OSS Spark 等）でカタログ参照 |
| 2024–25 | Zero-ETL 連携の拡張 | Zero-ETL | SageMaker Lakehouse / Redshift などへ Zero-ETL がさらに拡張 |
| 2025 | Federated Catalog の拡張（Redshift / DynamoDB / Snowflake など） | Federated Catalog | 外部の DWH / DB / OTF カタログを Lake Formation のガバナンス下に取り込み |
| 2026-02 | Cross-account version V5（ワイルドカード共有） | データ共有 | 1 RAM Resource Share で 数十万テーブル を別アカウントに共有可能。テーブル数比例で増えていた RAM Association 上限を実質撤廃 () |
「S3 のためのサービス」から「Lakehouse の統制基盤」へ
このフェーズで Lake Formation の位置づけがいちばん変わりました。位置関係を図にすると、おおむね以下のようになります。
S3 Tables / SageMaker Lakehouse / Iceberg REST endpoint のいずれの新サービスも、裏側のアクセス制御に Lake Formation を使う前提で設計されているのが、このフェーズの最大の特徴です。
Cross-account V5 で「スケールの上限」が外れた
このフェーズで併せて押さえたいのが、2026 年 2 月の Cross-account V5 です。V4 までは「Share 数は減ったが Association 数がテーブル数に比例する」構造で、テーブル数が数千〜数万を超えると RAM Resource Association の上限 が現実的な課題になっていました。V5 は AWS RAM の ワイルドカードパターンを自動採用することで、ここを本質的に解決しています。
ただし V5 は ダウングレード不可 です。IaC・監査・RAM 可視化ツールがワイルドカード共有の表現に追従できるかを事前に検証してから本番反映する、というのがフェーズ 5 を採用するうえでの実務的なお作法です。
Cross-account version V1 から V5 への進化
フェーズをまたいで進化してきた Cross-account version（V1〜V5）も、最後に 1 枚で振り返っておきます。これは Lake Formation コンソールの Cross account version settings から選ぶ設定値で、単なる互換フラグではなくデータ基盤の運用モデルそのものという重みのある値です。
| バージョン / リリース | 解いた課題 |
|---|---|
| V1 最初の Cross-account 共有（2020-10） | マルチアカウントのデータサイロ解消 |
| V2 RAM Share 数の最適化（〜2022） | RAM Share 爆発・受信側 Invitation の増殖 |
| V3 RAM 統合の本格化、直接 IAM principal / OU 共有（2022-11） | LF-TBAC の Glue Resource Policy 依存・委任地獄 |
| V4 Hybrid Access Mode / Federated Catalog 共有対応（2023-09〜） | 既存 IAM/S3 運用との共存・段階移行 |
| V5 ワイルドカード共有（2026-02-11） | RAM Association 上限・数十万テーブル規模 |
新規構築は V5 一択、既存環境は V4 へ寄せてから V5 へ が現時点の答えです。V5 は downgrade できないため、IaC・監査・RAM 可視化との整合性検証が前提になります。Cross-account version の各バージョンの詳細は別記事に整理しているので、踏み込みたい方はそちらをご参照ください。
全体まとめ表
ここまで見てきた進化を 1 枚の表にまとめると次のとおりです。
| # | フェーズ | 期間 | 一言サマリ |
|---|---|---|---|
| 1 | データレイク権限モデルを作った時代 | 2018–2020 | S3 + Glue + Athena の権限を 1 つの管理面に統合 |
| 2 | 行・列・セルまで絞り込む時代 | 2020–2022 | FGAC と LF-Tags で「個別 grant の海」から抜け出した |
| 3 | コピーせずにアカウントを越える時代 | 2021–2023 | クロスアカウント / クロスリージョン共有が現実解になり Data Mesh の配管が揃った |
| 4 | Iceberg と既存 IAM 運用をつなぐ時代 | 2023–2024 | Hybrid Access Mode で「段階移行」を可能にし、Iceberg 前提の世界へ移行 |
| 5 | Lakehouse の統制面になる時代 | 2024–現在 | S3 Tables / SageMaker Lakehouse / Iceberg REST / Zero-ETL / Federated Catalog を横断する共通ガバナンス |
どのフェーズの機能まで使うか – 採用判断フロー
「結局、自分たちはどのフェーズの設計思想を採用すれば良のか？」をフローチャートにまとめました。新規 / 既存 から入るよりも、Iceberg / S3 Tables を採用するか をまず決め、次に 既存 IAM/S3 と共存させるか を見極める順番のほうが、実務の感覚に合います。
ざっくり言うと、
- 新規構築で Iceberg / S3 Tables を使うなら Phase 5 一択。Cross-account 共有を伴うなら V5 まで上げて、ワイルドカード共有を前提に IaC を設計する
- 既存 IAM/S3 運用が強い既存環境なら、Phase 4 の Hybrid Access Mode から段階移行。同時に Cross-account も V4 へ
- マルチアカウント共有のニーズがあれば、最低でも Phase 3（Cross-account V3）以上を入れて、LF-TBAC + 直接 IAM principal 共有で委任地獄を回避する
- 小規模・単一アカウント・FGAC 不要なら Phase 1 / 2 で十分。LF-Tags の導入は早めに検討しておくと、後でテーブル数が増えたときに楽
逆に言うと、Phase 5 を選んでも Phase 1〜4 の機能はすべて使えるので、迷ったときは「主役の機能をどこに置くか」をフェーズで読み替えると判断しやすくなります。
現在地（2026 年 5 月時点）
現在の Lake Formation は、もはや「S3 上のデータレイクを作るためのサービス」というより、AWS 上の Lakehouse に対する共通ガバナンス基盤です。
- 権限管理: テーブル / 列 / 行 / セル / Nested / LF-Tags まで、Fine-Grained Access Control がひと通り揃った
- 共有: マルチアカウント / マルチリージョン / OU 単位の共有まで対応し、Data Mesh 的アーキテクチャを素直に組める
- OTF: Apache Iceberg を中核に据え、S3 Tables / Iceberg REST endpoint / 自動 compaction まで一体化
- Lakehouse: SageMaker Lakehouse / Zero-ETL / Federated Catalog を通じ、Redshift / DynamoDB / 外部カタログまで射程に
- 移行: Hybrid Access Mode により、既存 IAM/S3 運用との 段階移行が可能
一方で、フェーズが進むほど 学習コストと“どこから手を付ければよいか問題” は強まっており、設計の最初に「自分たちはどのフェーズの機能まで使うのか」を見定めることが、これからの Lake Formation 採用ではいっそう重要になりそうです。
個人的にとくに**「これは入れて損はないと言える」**と感じているのは、
- LF-Tags（フェーズ 2） – 個別 grant の海から早めに脱出しておく
- Hybrid Access Mode（フェーズ 4） – 既存運用との同居・段階移行を確保する
- S3 Tables + Lake Formation + Cross-account V5（フェーズ 5） – これから新規で Iceberg 系・データ共有系を立ち上げるなら、ほぼデフォルト構成
の 3 つです。
なお、フェーズ 5 で V5 まで上げる場合は、ダウングレードができないことは強く意識しておいてください。Cross-account version は「単なる互換フラグ」ではなく、AWS RAM Share の表現形式・Glue Resource Policy への依存・IaC 上の差分 に直結する設計値です。本番反映前に、IaC・監査・RAM 可視化ツールが新しい表現に追従できるかを必ず検証する、という運用にしておくのが安全です。
最後に
正直なところ、Cross-account V3より前は、Redshiftの権限管理と組み合わせて、できる限りLake Formation を使わなくて済むワークアラウンドを提供していました。データガバナンスが当たり前、Iceberg / S3 Tables台頭の時代に、その基盤技術である Lake Formation は避けては通ることができません。
AWS Lake Formation を振り返ってみると、「データレイクの権限を一元管理する」というシンプルな出発点から、Lakehouse 全体のガバナンス基盤へとスコープを広げてきた 7 年半 だった、と整理できそうです。
これから Lake Formation を本格採用する場合は、5 つのフェーズのどこまでを採用するかを最初に決めることをおすすめします。とくにこれから新規構築なら、フェーズ 4・5 を前提に Iceberg / S3 Tables / Hybrid Access Mode を組み込んだ設計がベースになるかと思います。
