データレイクを作ったあと、「営業部には売上テーブルを見せたいが、顧客の氏名の列は隠したい」「地域担当者には自分の地域の行だけ」と言われて、S3 のバケットポリシーと IAM を書き足し続けると、いつか誰にも全体が読めなくなります。顧客や後輩に「Lake Formation を入れると何が変わるのか、IAM はどうなるのか」と聞かれて、うまく言葉にできない人に向けた記事です。
この記事の結論
- Lake Formation は、S3 上のデータと Glue Data Catalog のメタデータへのアクセスを、中央で細かく管理するサービスです。
- 独自の権限モデル（grant / revoke）を持ち、IAM の権限モデルを補います。IAM が不要になるわけではありません。
- 制御の粒度はデータベース・テーブル・列・行・セルです。行と列はデータフィルターで絞ります。
- 権限は Athena・Redshift Spectrum・EMR・Glue など、複数の分析サービスにまたがって効きます。
- リソースが増えたら LF-Tag（キーと値のタグ）を付け、タグに対して権限を渡します。名前で1つずつ渡すと、主体数×リソース数の付与が要ります。
- 複数アカウントへの共有と、CloudTrail による監査も同じ場所で扱えます。
AWS Lake Formation とは何か｜データレイクの「権限の窓口」
AWS Lake Formation は、データレイクの構築と、そのデータへのアクセス制御を担うサービスです。この記事では後者、つまり権限の話に絞ります。データレイクの基本形（S3 に置き、Glue Data Catalog に台帳を付け、Athena で読む）は 
READ ALSO — 実務向け・段3 基盤
データレイクとは何か｜S3・Glue Data Catalog・Athena の基本形と、データウェアハウスとの違い
にあるので、そちらを前提にします。
要点は、権限の単位が「S3 のパス」ではなく「Data Catalog に載っているデータベース・テーブル・列」になることです。利用者から見ると「売上テーブルの、この列とこの行」という言葉で権限を考えられます。
たとえるなら、倉庫の棚ごとに鍵を配るのをやめて、「商品台帳の項目」に対して閲覧の許可を出す形です。ただしたとえは入口まで。実際には、許可は Lake Formation の grant / revoke として持ち、IAM の権限と合わさって効きます。
ONE WINDOW権限の単位が変わる
権限の単位がS3 のパスからテーブル・列・行に変わる
S3 と IAM だけ
Lake Formation を挟む
S3 と IAM だけ: バケット・プレフィックス単位
Lake Formation を挟む: テーブル単位
S3 と IAM だけ: ファイル全体を見せる／隠す
Lake Formation を挟む: 列・行で絞る
S3 と IAM だけ: サービスごとに設定
Lake Formation を挟む: 一元で設定
なぜ IAM だけでは足りないのか｜S3 の単位とテーブル・列・行の単位のずれ
IAM とバケットポリシーが指せる単位は、バケットやプレフィックス、オブジェクトです。一方、分析の現場で権限を語る単位は、テーブル・列・行です。このずれが破綻の原因になります。
- 列で隠したいとき、1つのファイルの中に隠したい列と見せたい列が同居していて、ファイル単位の許可では切り分けられません。
- 行で絞りたいとき、地域ごとにファイルやテーブルを物理的に分ける設計に寄っていきます。
- 分析サービスごとに許可を書くと、Athena では絞れても、別のサービスから同じデータを読む経路が残ります。
Lake Formation はこのずれを埋めます。権限を Data Catalog の単位で一元的に持ち、対応する分析サービスから読むときに同じ権限が効きます。
ここで大事なのは、置き換えではなく補う関係だという点です。公式の説明でも、Lake Formation の権限モデルは IAM の権限モデルを補うものとされています。利用者が使う IAM のロールやユーザーは引き続き必要で、その上に Lake Formation の権限が重なります。
| 観点 | S3 と IAM だけ | Lake Formation を挟む |
|---|---|---|
| 権限の単位 | バケット・プレフィックス・オブジェクト | データベース・テーブル・列・行・セル |
| 列や行の絞り込み | ファイルやテーブルの分割で代用 | 権限とデータフィルターで直接指定 |
| 設定の場所 | サービスごと・ポリシーごと | Lake Formation で一元 |
| IAM の役割 | 権限の主役 | 引き続き必要。Lake Formation が補う |
CHECK 1ここまでの確認
Lake Formation を導入すると、IAM の権限設計は不要になる?
答えと解説
答え: 2. 不要にならない。Lake Formation の権限モデルが IAM を補う
公式の説明では、Lake Formation は独自の権限モデルで IAM の権限モデルを補います。利用者に渡す IAM の権限と Lake Formation の権限の両方が関わります。「なぜ IAM だけでは足りないのか」を読み直してください。
Lake Formation は何を管理するのか｜DB・テーブル・列・行・セルとデータフィルター
管理の対象は、Glue Data Catalog に登録されたデータベースとテーブル、そしてそのデータです。粒度は次の順に細かくなります。
- データベース単位
- テーブル単位
- 列単位
- 行単位
- セル単位（行と列の組み合わせ）
列を限定する
氏名や電話番号のような個人を特定できる列を隠したいときは、見せてよい列だけに限定した権限を渡します。許可されていない列は、クエリの結果に出ません。
行を絞る、セルで絞る
地域担当者に自分の地域の行だけを見せたいときは、データフィルターを使います。行フィルター式で見える行を決め、列の指定と組み合わせると、セルの単位まで絞れます。地域ごとにテーブルやファイルを分け直す必要はありません。
効く範囲
この権限は、Athena・Redshift Spectrum・EMR・Glue など、複数の分析サービスにまたがって効きます。サービスごとに同じ制約を書き直さなくて済むのが、一元管理の利点です。
CHECK 2ここまでの確認
分析担当者に、個人を特定する項目だけ見せたくない。Lake Formation ではどう絞る?
答えと解説
答え: 2. 見せてよい列だけに限定した権限を渡す、またはデータフィルターを使う
Lake Formation はデータベース・テーブル・列・行・セルの粒度で制御できます。列を限定した権限や、行と列を絞るデータフィルターを使います。「何を管理するのか」を読み直してください。
LF-Tag とは何か｜名前で1つずつ渡す方式とタグで渡す方式の違い
データベースやテーブルが数千に増えたとき、「このチームにこのテーブルを」と名前で1件ずつ権限を渡す方式は続きません。名前指定の方式では、主体の数×リソースの数だけ付与が要るからです。
そこで LF-Tag を使います。LF-Tag は、キーと値でできたタグ（たとえばキーが「機密度」、値が「公開」「社内」「機密」）です。
- リソース（データベース、テーブル、列）に LF-Tag を付ける
- 主体（ロールやユーザー）に、タグ式（このキーのこの値を持つものを読める、など）で権限を渡す
- 新しいテーブルにタグを付ければ、権限の付け直しなしで条件に合う主体から読める
付与の数は、掛け算ではなく「タグを付ける数＋タグ式で渡す数」の足し算になります。
TAG BASEDLF-Tag で渡す流れ
権限はタグに対して渡し、継承まで確かめる
-
タグを作る
キーと値を決める（例: 機密度）
-
リソースに付ける
データベース・テーブル・列に付与
-
主体にタグ式で権限を渡す
このタグの値を持つものを読める
-
継承を確認する
テーブルは DB から、列はテーブルから
継承を押さえる
タグはリソースの階層で引き継がれます。テーブルはデータベースから、列はテーブルから、LF-Tag を継承します。上位に付ければ下位にも効く一方、下位で付け直せば、その部分だけ別の扱いにもできます。そのため、付けたあとに「実際にどの値が効いているか」を確認する段が必要です。
名前指定とタグ指定の対比
GRANT COUNT付与の数の違い
名前指定は掛け算、タグ方式は足し算で付与が増える
名前指定方式
1件ずつ渡す
- 主体の数×リソースの数の付与
- テーブルが増えるたび渡し直し
タグ方式
タグに渡す
- タグを付ける数＋タグ式で渡す数
- 新しいテーブルはタグを付けるだけ
CHECK 3ここまでの確認
テーブルが数千に増えても付与作業を増やさないための方法は?
答えと解説
答え: 2. リソースに LF-Tag を付け、タグに対して権限を渡す
名前で渡す方式は主体の数×リソースの数の付与が要ります。タグ方式は「タグを付ける作業」と「タグに権限を渡す作業」の足し算で済みます。「LF-Tag とは何か」を読み直してください。
IAM のタグとは別物
LF-Tag は Lake Formation が Data Catalog のリソースへの権限に使う専用のタグで、IAM のタグとは別物です。用途が違い、互換性もありません。IAM のタグに慣れていると同じものと思いがちなので、顧客に説明するときは分けて話します。
CHECK 4ここまでの確認
LF-Tag と、IAM のタグは同じもの?
答えと解説
答え: 2. 別物。用途が違い、互換性はない
LF-Tag は Lake Formation が Data Catalog のリソースへの権限に使う専用のタグです。IAM のタグとは別物として扱います。「LF-Tag とは何か」を読み直してください。
複数アカウントでの共有と監査｜クロスアカウント共有と CloudTrail
組織が大きくなると、データレイクを置く中央のアカウントと、使う側の事業部のアカウントが分かれます。Lake Formation では、中央のアカウントで管理しているテーブルに対して、別のアカウントに権限を付与できます。これがクロスアカウント共有です。
- データのコピーを作らず、元のデータを参照させられる
- 権限は中央のアカウントで一元的に管理する
- 受け取った側は、自分のアカウントの Athena などから参照する
監査の面では、Lake Formation の操作と、データへのアクセスの記録を AWS CloudTrail で追えます。誰がどの権限を付け外ししたか、を後から確かめる材料になります。アカウントをまたぐ設計全体は 
READ ALSO — プロフェッショナル向け・段4 設計
マルチアカウント設計｜アカウントを「境界」として使い、Organizations と SCP で組織のガードレールを引く
で扱っています。
導入の考え方｜ハイブリッドアクセスモードで少しずつ移す
既に動いているデータレイクに、ある日 Lake Formation の権限を全面適用すると、既存の利用者のクエリが一斉に通らなくなる恐れがあります。そこで使えるのがハイブリッドアクセスモードです。同じ Data Catalog のリソースについて、既存の IAM 中心のアクセスを保ったまま、Lake Formation の権限を一部のテーブルや利用者に対して先に有効にできます。
考え方の順番は次のとおりです。
- 機密度の高いテーブルなど、効果の大きい対象を1つ選ぶ
- その対象と利用者に限って、Lake Formation の権限を有効にする
- 利用者への影響がないことを確かめてから、対象を広げる
具体的な設定の手順は変わりやすいので、公式ドキュメントで確認してください。
Lake Formation を使わない選択もあるか｜小さな構成での判断の目安
Lake Formation が効くのは、「権限の単位が S3 のパスより細かい」「利用者や部門が増える」「複数の分析サービスやアカウントから同じデータを読む」といった状況です。逆に、次のような構成なら IAM とバケットポリシーだけでも足りる場合があります。
- 利用者が少数で、テーブル全体を同じ人が読む
- 列や行で見え方を変える要件がない
- 単一のアカウントで、分析サービスも1つ
ただし、増える見込みがあるなら、後から権限を張り替える手間が大きくなります。判断の軸は「いま」より「半年後に誰が何を読みたがるか」です。組織全体の権限設計の軸は 
READ ALSO — プロフェッショナル向け・段4 設計
マルチアカウントの権限設計｜SCP・許可セット・権限境界・ABAC を「どこで絞るか」で組む
にまとめています。
参照ソース
- What is AWS Lake Formation?（AWS Lake Formation Developer Guide） — Lake Formation の定義、独自の権限モデルが IAM を補うこと、列・行・セルの粒度、対応サービス、ハイブリッドアクセスモード、クロスアカウント共有、CloudTrail 監査の根拠に使った
- Lake Formation tag-based access control（AWS Lake Formation Developer Guide） — LF-Tag の仕組み、キーと値、継承、名前指定方式との付与数の違い、IAM タグとは別物であることの根拠に使った
