「AWS Lake Formationへの恐怖心はこれで解消！肝の3つを理解する」というタイトルで社内でお話したので資料公開します
2025.04.07はじめに
こんにちは、データ事業本部の渡部です。
S3 Tablesが登場し、Lake Formationでのアクセス制御をしなければならなくなったところから、Lake Formationをちゃんと理解しないといけない時が来たと感じています。
前回「AWS Lake Formationをざっくり解説」というタイトルの資料を共有しましたが、その続編となります。
今回はLake Formationに少し技術的に踏み込み、
「AWS Lake Formationへの恐怖心はこれで解消！肝の3つを理解する」というタイトルで社内でお話しました。その資料共有になります。
Lake Formationになんとなくの苦手意識・恐怖心を持っている方の役に立てれば嬉しいです。
資料
概要説明
タイトルにあるLake Formation理解の肝の3つは以下です。
- IAMAllowedPrincipals
- Data permissions
- Data lake locations
IAMAllowedPrincipals
IAMAllowedPrincipalsはLake Formationに登場してくる単語になります。
これが何かというと、「IAM ポリシーによってGlue Data Catalog リソースへのアクセスを許可されている、 IAM ユーザーとロールをまとめたグループのこと」です。
Lake Formationは機能としては常時オンなのですが、Lake Formationでのアクセス制御をしていないうちは、このIAMAllowedPrincipalsにDBやテーブルへのSUPER権限が付与されていたため、特にLake Formationを意識せずにデータアクセスが可能だったということです。
Data permissions
LFタグ方式・リソース方式でプリンシパル（IAM RoleやUserなど）へデータアセットに対する操作権限の付与をします。
Data lake locations
Data lake locationsでは、Lake Formationで管理する対象を宣言します。
ここで設定したものがLake Formationでのアクセス制御管理下になります。
Lake Formationのサービスリンクロールを確認すると、ポリシーにData lake locationで設定したS3パスが設定されていることが確認できます。
さいごに
いかがでしたでしょうか。
IAMAllowedPrincipalsを理解し、Data permissionsとData lake locationsに設定をすることで、Lake Formationでのアクセス制御が可能です。
あとは実際に触ってみて、タグの使い方をおさえていくとLake Formationが怖くなくなるでしょう。
私の苦労した記録は以下にあるため、ぜひご参考ください。
最後にLake Formationでの評価論理を載せます。
こちらの図は私が実際の挙動を確かめて作成したものになります。
これに当てはまらないケースも出てくるとは思いますが、基本的にはこの評価でアクセス制御がされます。
「なぜかアクセスできない」というときは、こちらの評価論理に立ち返ってみて確認をしてみてください。
この記事がどなたかのご参考になれば幸いです。
参考資料
- Black Belt
