AWS Lake Formation

解決する課題

S3にデータを集めてデータレイクを作るとき、「どのチームがどのテーブル・どの列・どの行まで見てよいか」を整理するのは難しい問題です。素のS3とIAMだけで制御しようとすると、バケットポリシーやプレフィックス単位の権限が増え続け、列や行のレベルでは細かく絞れず、サービスごとに権限定義もばらばらになりがちです。Lake Formationは：

• S3上のデータレイクの構築・取り込み・カタログ整備を効率化する
• テーブル・列・行・セル単位のきめ細かなアクセス権限を一元管理する
• AthenaやRedshift Spectrum、EMR、Glueなど複数の分析サービスに同じ権限定義を統一的に適用する

「データレイクのアクセス権を中央で統制したい」「列ごと・行ごとに見せる範囲を変えたい」という要件に向きます。

主要概念と用語

• データレイク: S3上に多様な形式のデータを集約した保管領域。Lake Formationはその上のアクセス制御とカタログ管理を担う
• データカタログ: テーブルのスキーマ（列名・型・S3の場所）を管理するメタデータ。Lake FormationはGlueデータカタログを基盤に権限を付与する
• データレイク管理者: Lake Formation上で権限の付与・剥奪を行える管理者ロール。最初に明示的に指定する必要がある
• Lake Formation権限（LF権限）: データベース・テーブル・列・行などのリソースに対し、SELECTやINSERTなどをプリンシパルへ付与する仕組み
• データロケーション権限: 特定のS3パスをデータレイクのストレージとして登録し、利用を許可する権限
• LFタグ（タグベースアクセス制御）: データベースやテーブル、列にタグを付け、タグ条件で権限をまとめて管理する方式。リソースが増えても付与ルールを少数に保てる
• データフィルタ: 行レベル条件や列の許可・除外を定義し、同じテーブルでもプリンシパルごとに見える範囲を変える仕組み
• ブループリント / ワークフロー: データベースやログを取り込んでカタログ化する処理をテンプレート化したもの

仕様・制限・クォータ

• 権限の対象はデータベース、テーブル、列、行、セルといったカタログ上の論理リソースで、付与先はIAMプリンシパルなど
• きめ細かなアクセス制御は、それに対応した分析エンジン（Athena、Redshift Spectrum、EMR、Glueなど）を通じてクエリしたときに適用される
• S3をデータレイクのロケーションとして登録し、Lake Formation経由でアクセスさせるのが基本構成
• LFタグやデータフィルタ、登録ロケーション、各種ポリシーの個数などにサービスクォータがあり、必要に応じて引き上げを申請できる
• クロスアカウントでのデータ共有にも対応する

内部の仕組み

Lake Formationは、データそのものを保持するのではなく、Glueデータカタログの上にアクセス制御の層を重ねる形で動作します。S3上の実データはそのまま、カタログ上のテーブル定義に対して権限を付与します。

• 管理者がS3パスをデータレイクのロケーションとして登録し、利用するサービスロールに対してそのパスの利用を許可する
• 利用者がAthenaなど対応エンジンからテーブルにクエリすると、エンジンはLake Formationに権限を問い合わせ、許可された列・行だけを返す
• 列の除外や行のフィルタはデータフィルタとして定義し、クエリ時にエンジン側で適用される
• 権限はリソースを直接指定する方式と、LFタグで条件付けする方式の2通りがあり、後者は大規模カタログでも付与ルールを少数に保てる

設計パターン / ベストプラクティス

• タグベースアクセス制御（LFタグ）を基本に: テーブルや列にタグを付け、タグ条件で権限を付与すると、リソース増加に対して付与ルールが膨らみにくい
• データレイク管理者を限定: 権限を操作できる管理者は最小限にし、職務分離を徹底する
• S3直アクセスを絞る: 登録したS3ロケーションへは原則Lake Formation経由でアクセスさせ、IAMでの直接アクセスは抑制する
• 列・行フィルタで職責に合わせる: 個人情報を含む列はマスクや除外、地域や部門で行を絞るなど、職務に応じた最小可視範囲を設計する
• クロスアカウント共有の活用: 中央のデータレイクから各アカウントへ、必要なリソースだけをタグや個別指定で共有する

運用・監視

• 権限の付与・剥奪、ロケーション登録などの操作はCloudTrailで監査できる
• 「誰がどのリソースにどの権限を持つか」をLake Formation上で棚卸しし、過剰な付与を定期的に見直す
• ブループリントやワークフローで取り込み処理をテンプレート化し、カタログ整備を再現性高く運用する
• LFタグの体系をあらかじめ設計し、タグの命名・付与ルールをドキュメント化しておくと、権限のレビューが容易になる

コスト

• Lake Formationの権限管理機能そのものには、一般に追加の専用料金がかからない範囲が多い
• 実際のコストは、基盤となるGlueデータカタログ、取り込みや変換に使うGlueジョブ、クエリを実行するAthenaやRedshift、EMR、保管先のS3といった周辺サービスの利用量で決まる
• きめ細かな制御を付けても、データ自体は移動・複製しないため、追加のストレージコストは基本的に発生しない

セキュリティ

• アクセス制御はIAMとLake Formation権限の二層で構成され、Lake Formationが列・行・セル単位の粒度を担う
• LFタグにより、データの分類（機密度や部門など）に基づいた権限付与をスケールさせられる
• データレイク管理者の権限を絞り、付与・剥奪の操作を職務分離する
• 保管時の暗号化はS3とKMS、通信はTLSで保護し、操作監査はCloudTrailで行う
• 登録S3ロケーションへの直接アクセス経路を統制し、きめ細かな制御の迂回を防ぐ

Well-Architected の観点

• セキュリティ: 列・行・セル単位の最小権限を中央で一元管理し、複数の分析サービスへ統一適用する。職務分離と監査ログを徹底
• 運用上の優秀性: タグベースで権限ルールを少数に保ち、ブループリントで取り込みを再現性高く運用する
• コスト最適化: データを複製せずカタログ上で制御するため、ガバナンス強化に伴う追加ストレージが発生しにくい
• パフォーマンス効率: 行・列フィルタにより必要なデータだけを返し、不要な範囲の処理を避ける

試験で問われるポイント

関連サービス・比較

アクセス制御の基盤である AWS IAM とよく対比されます。IAMはサービスやリソース単位の認可を担い、Lake Formationはその上でデータレイク内部の列・行といった粒度を担う、補完関係にあります。

ハンズオン / CLI例

# S3パスをデータレイクのロケーションとして登録
aws lakeformation register-resource \
  --resource-arn arn:aws:s3:::my-data-lake/sales/ \
  --use-service-linked-role

# 特定テーブルの「指定した列だけ」をロールにSELECT許可（列レベル制御）
aws lakeformation grant-permissions \
  --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:role/analyst \
  --resource '{"TableWithColumns":{"DatabaseName":"sales_db","Name":"orders","ColumnNames":["order_id","amount","region"]}}' \
  --permissions "SELECT"

# 付与済み権限の確認
aws lakeformation list-permissions \
  --resource '{"Table":{"DatabaseName":"sales_db","Name":"orders"}}'