AWS Lake FormationでGlue Crawler権限エラーを解決した話
最近、AWS Lake FormationとGlue Crawlerを組み合わせた環境で権限エラーに遭遇しました。
同じ問題に将来また遭遇した時のために、解決までの経緯とLake Formation特有の権限の依存関係について備忘録としてまとめておきます。
背景
データレイク基盤の構築で、以下の構成を作っていました：
- S3バケット: CSVやParquetファイルを配置
- Lake Formation: S3をData Locationとして管理
- Glue Crawler: 定期的にスキャンしてテーブル作成
セキュリティ要件により、Lake Formationでデータアクセスを制御する必要がありました。
遭遇した問題
クローラーを実行すると以下のエラーが発生：
Access Denied
LakeFormation.permissions最初の誤解
IAMの設定不備だと思い、Glueサービスロールを何度も見直しました：
- ✅ S3への読み書き権限
- ✅ Glueの基本権限
- ✅ CloudWatchログ出力権限
しかし、エラーは解消されず。
真の原因
その後の調査の結果、Lake Formation独自の権限体系が存在し、これらが複雑に依存し合っていることが判明しました。
Lake Formation権限の依存関係
権限の種類
Lake Formationには2つの権限体系があります：
| 権限タイプ | 役割 | 例 |
|---|---|---|
| Data permissions | Data Catalogリソースに対する権限 | CREATE_TABLE、SELECT、INSERT |
| Data location permissions | S3ロケーションを指すリソースの作成権限 | DATA_LOCATION_ACCESS |
🔗 重要な依存関係ルール
ルール1: テーブル作成の必須条件
S3ロケーションを指すテーブル作成 = CREATE_TABLE + DATA_LOCATION_ACCESS- CREATE_TABLE権限だけでは不十分
- さらに、対象S3ロケーションのDATA_LOCATION_ACCESS権限も必要
ルール2: データベースlocation propertyの暗黙的権限
- データベースにlocation propertyが設定されている場合
- CREATE_TABLE権限で、そのロケーション配下での暗黙的権限が付与
- ただし、他ロケーションについては明示的権限が必要
ルール3: 管理権限の分離
- Catalog Creators権限がないと作成系操作が拒否
- 一方で、これは他の権限とは独立した管理権限
ルール4: 前提条件
- S3ロケーションのLake Formation登録が必須
- なぜなら、登録なしではすべての権限が無効になるため
解決策
以下3つの設定を正しい順序で実行することで解決しました。
1️⃣ S3バケットのData Location設定
ステップ1: S3バケット登録
Lake Formationコンソール
→ Administration
→ Data lake locations
→ Register location- 対象S3パス指定（例：
s3://my-data-bucket/） - IAMロール指定
- 登録完了
💡 なぜ最初に必要？
これがすべてのLake Formation権限設定の前提条件
ステップ2: Data location権限付与
Lake Formationコンソール
→ Permissions
→ Data locations
→ Grantこのステップでは以下を設定:
- Principal: GlueクローラーのIAMロール
- Storage location: 登録済みS3パス
- Permission: DATA_LOCATION_ACCESS（自動付与）
2️⃣ Catalog Creators設定
Lake Formationコンソール
→ Administrative roles and tasks
→ Catalog Creators
→ Addここでの作業内容:
- GlueクローラーのIAMロールを追加
💡 なぜ必要？
カタログへの作成系操作の管理権限が付与される
3️⃣ Data permissions設定
Lake Formationコンソール
→ Permissions
→ Data permissions
→ Grant最後のステップで設定する項目:
- Principal: GlueクローラーのIAMロール
- Database: 対象データベース（または All databases）
- Database permissions: CREATE_TABLE
- Table permissions: SELECT、INSERT、DESCRIBE
⚠️ 正しい設定順序
1. S3バケットをData Locationとして登録 ← 前提条件
2. Data location権限を付与 ← CREATE_TABLEの前提
3. Catalog Creatorsに追加 ← 管理権限
4. Data permissions付与 ← 実際の操作権限設定後の確認
すべて設定後、クローラーを再実行：
- ✅ テーブル作成成功
- ✅ スキーマ認識正常
- ✅ パーティション認識正常
- ✅ Athenaからクエリ実行可能
学んだポイント
🔑 重要な理解
-
追加型アクセス制御
- IAM権限 + Lake Formation権限の両方が必要
- したがって、どちらか一方でも拒否されればアクセス不可
-
複雑な依存関係
- CREATE_TABLE ≠ テーブル作成可能
- 実際には、DATA_LOCATION_ACCESS権限も必須
-
登録の影響範囲
- Data Location登録でアクセス制御がLake Formationに移管
- そのため、既存アプリへの影響要確認
-
暗黙的権限の存在
- データベースlocation propertyによる自動権限付与
- つまり、明示的でない権限の仕組みを理解する重要性
💡 IAM権限について
なお、今回はIAMロールの基本権限（Glue、S3、lakeformation:GetDataAccess）は適切に設定済みでした。しかし、Lake Formation環境では必須の前提条件です。
まとめ
Lake FormationとGlueの組み合わせは強力な機能を提供しますが、権限設定の複雑さと依存関係が課題となることがあります。特にData Location権限とCatalog権限の複雑な依存関係を理解することが、問題解決の鍵となります。
今回の経験を通じて、段階的な検証とドキュメント化の重要性、そして権限間の依存関係を正しく理解することの重要性を改めて実感しました。