AWS Lake Formationとは?データレイクの権限管理・使い方・料金と実装判断を解説【2026年版】
AWS Lake Formation は、Amazon S3 上に構築するデータレイクの「作成・保護・権限管理」を一元化するフルマネージドサービスです。従来は IAM ポリシーやバケットポリシーを個別に書き分けていたデータレイクのアクセス制御を、AWS Glue データカタログを土台に、データベース・テーブル・列・行・セルの粒度でまとめて管理できます。本記事では、実装者の視点で Lake Formation の定義・権限モデル・S3 登録からクエリまでの使い方・料金体系を整理し、採用すべき場面と見送るべき場面まで解説します。
目次
まとめ(先に結論)
- AWS Lake Formation は、S3 上のデータレイクに対する権限を一か所で管理するためのサービス。AWS Glue データカタログのテーブルやデータベースに対して権限を付与し、Athena・Redshift・EMR などのクエリ側がその権限を尊重して動く。
- 権限の与え方は2系統ある。テーブル名・列名を直接指定する「名前ベースの権限」と、リソースにタグを付けてタグ単位で許可する「LF-Tags(タグベースアクセス制御)」で、テーブル数が増えるほど後者が運用を軽くする。
- 行レベル・列レベル・セルレベルのデータフィルタを定義でき、同じテーブルでも利用者ごとに見える範囲を絞れる。個人情報の列を隠す、担当地域の行だけ見せるといった制御を、クエリ側の実装を変えずにかけられる。
- Lake Formation そのものの利用料は無料。費用は S3 のストレージ、Glue のクローラーやカタログ、Athena や Redshift のクエリといった基盤サービス側で発生する。権限管理レイヤーを足すこと自体に追加コストはかからない。
- 「S3 のデータレイクを複数チーム・複数部門で使い、アクセス範囲を細かく分けたい」なら Lake Formation が合う。利用者が少なく IAM の権限設計で十分回る小規模構成では、導入の手間に見合わないこともある。
AWS Lake Formationとは何か|データレイク構築と権限管理の一元化
AWS Lake Formation は、S3 に置いたデータの集合をデータレイクとして登録し、そのアクセス権限を中央で管理するためのサービスです。データの実体は S3 に、メタデータは AWS Glue データカタログに置き、Lake Formation はその上で「誰がどのデータベース・テーブル・列・行に触れてよいか」を決める役割を担います。データレイクという概念そのものや、データウェアハウス・レイクハウスとの違いを先に押さえたい場合は、データレイクとは?データウェアハウス・レイクハウスとの違いを実装視点で解説を起点にすると、Lake Formation が担う範囲がはっきりします。
データレイク構築で生じる従来のIAM権限管理とガバナンスの課題
S3 だけでデータレイクを組むと、アクセス制御は IAM ポリシーや S3 バケットポリシーで表現することになります。データセットが数十・数百と増え、部門ごとに見せてよい範囲が異なってくると、この方式はプレフィックス単位のポリシーが膨れ上がり、管理が追いつかなくなります。列単位・行単位で見せる範囲を分けたいときに、S3 のオブジェクト単位の権限では表現しきれない点も壁になる。IAM の基本的な仕組みは AWS IAMとは?仕組み・ユーザー/ロール/ポリシーの違いと権限設計のベストプラクティスを実装者目線で解説で整理していますが、Lake Formation はこの「S3 の物理的な権限」より一段上の、データカタログ上の論理的な権限で制御を組み立て直します。
AWS Glueデータカタログを土台にしたメタデータと権限の一元管理
Lake Formation の権限は、AWS Glue データカタログのデータベースとテーブルに対して付与します。Glue クローラーが S3 のファイルをスキャンしてスキーマを推定し、テーブルとしてカタログに登録すると、そのテーブルが権限付与の対象になります。カタログという「データの目録」を土台にする発想は、データカタログとは?意味・メタデータ管理の仕組みからAI時代の導入判断まで解説で扱うメタデータ管理の考え方と地続きです。実体データを動かさずに、メタデータ側で権限とアクセス範囲を定義できるため、S3 のディレクトリ構造を作り替えずにガバナンスをかけられます。
Lake Formationがデータレイク運用で担う立ち位置の整理
Lake Formation はデータを保存するサービスでも、クエリを実行するエンジンでもありません。保存は S3、クエリは Athena や Redshift、メタデータ管理は Glue データカタログが担い、Lake Formation はそれらの上で「アクセスの許可・拒否を一元的に決める門番」に徹します。データ分析基盤全体の中でどの層に位置するかを俯瞰したい場合は、データ分析基盤の構築とは?5層アーキテクチャとBigQuery実装手順を技術視点で解説の層構造と対応づけると、Lake Formation が「収集・保存層のガバナンス」を受け持つ位置づけだと整理できます。
Lake Formationのきめ細かなアクセス制御と権限管理の仕組み
Lake Formation の中心は権限モデルです。ここを理解すると、設計時に「どの粒度で誰に許可を出すか」を迷わず決められます。権限は Glue データカタログのリソースに対して与え、クエリエンジンが実行時にその権限を評価します。
データレイク管理者の設定とS3上のデータロケーションの登録手順
導入の最初の一歩は、データレイク管理者(Data Lake Administrator)を指定することです。この管理者が以降の権限付与の元締めを務めます。次に、データレイクとして扱う S3 のパスを Lake Formation に「データロケーション」として登録します。登録した S3 の保存層については、Amazon S3とは?オブジェクトストレージの仕組み・ストレージクラスと料金・採用判断を実装者目線で解説で扱うバケット・プレフィックスの設計がそのまま前提になる。登録によって Lake Formation が S3 へのアクセスを仲介する形になり、利用者は S3 の権限を直接持たなくても、Lake Formation が発行する一時的な認証情報を通じてデータへ到達できるようになります。
名前ベースの権限とLF-Tagsによるタグベースアクセス制御
権限の与え方は2通りあります。ひとつは名前ベースの権限で、「このデータベースのこのテーブルのこの列に、この利用者が SELECT してよい」と対象を名指しで許可する方式です。対象が少なければ分かりやすい一方、テーブルが増えると付与の手数が膨らみます。もうひとつが LF-Tags(タグベースアクセス制御)で、データベースやテーブル、列にタグ(例:機密度=高、部門=経理)を付け、「このタグを持つリソースに、この利用者が触れてよい」とタグ単位で許可する方式です。新しいテーブルにタグを付ければ既存の許可規則が自動で及ぶため、規模が大きいデータレイクほど付与・棚卸しの運用が軽くなります。
行レベル・列レベル・セルレベルのデータフィルタリングによる制御
Lake Formation は、同じテーブルでも利用者によって見える範囲を変えるデータフィルタを定義できます。列レベルでは、個人情報を含む列を特定の利用者から隠す。行レベルでは、条件式(例:region = ‘east’)に一致する行だけを見せる。両者を組み合わせたセルレベルでは、特定の列かつ特定の行だけを許可する。これらはクエリ側のアプリケーションを書き換えずに、Lake Formation の設定として一元的にかけられます。分析用途に応じて、ひとつのマスターデータから利用者ごとの見え方を切り出せる点が、この仕組みの実務的な値打ちです。
Lake Formation権限とIAM権限の関係とハイブリッドアクセスモード
混乱しやすいのが IAM との関係です。Lake Formation の権限は IAM を置き換えるものではなく、その上に重ねて働きます。利用者はまず IAM で Athena や Glue の API を呼ぶ権限を持ち、そのうえでデータへのアクセス可否を Lake Formation が判定する二段構えです。既存の IAM ベースで動いているテーブルと、Lake Formation で管理するテーブルを混在させたい場合は、テーブル単位で管理方式を選べるハイブリッドアクセスモードがあり、IAM 運用から段階的に移行できます。どちらの経路でアクセスが評価されるかをテーブルごとに把握しておくと、意図しない拒否や過剰な許可を避けられます。
Lake Formationの使い方|S3登録からクエリ実行までの流れ
実際の導入は、決まった順序をたどれば見通しが立ちます。「保存層を登録し、カタログに載せ、権限を付け、クエリで確かめる」という流れです。
初回セットアップとデータレイクの初期設定で最初に押さえる前提
初回は、Lake Formation のコンソールでデータレイク管理者を設定し、既定のアクセス制御の挙動を確認するところから始めます。アカウントを新規に使う場合、既定で Lake Formation の権限モデルが有効になっている前提で設計を進めるのが安全です。次に、対象の S3 パスをデータロケーションとして登録し、Glue データベースを作成します。ここまでで「どの箱を、誰が元締めで管理するか」の骨格が決まります。既存の S3 バケットへ後から Lake Formation を被せることもでき、その際は現行の IAM 権限との整合を先に棚卸ししておくと移行が滑らかです。
ブループリントとワークフロー機能によるデータ取り込みの自動化
データレイクへの取り込みには、ブループリントと呼ばれるテンプレートが用意されています。データベースやログからの取り込みパターンを選ぶと、Glue クローラーとジョブを組み合わせたワークフローが自動生成され、S3 への取り込みとカタログ登録までを一連で動かせる。取り込み時の変換や、ETL の考え方そのものを整理したい場合は、ETLとは?仕組み・ELTとの違い・ツール選定から導入判断まで解説で扱う抽出・変換・ロードの流れが下敷きになります。ブループリントで枠組みを作り、要件に応じて Glue ジョブを足していくと、取り込みパイプラインを段階的に育てられます。
AthenaやRedshiftからのクエリとクロスアカウント共有
権限を付けたテーブルは、Amazon Athena や Amazon Redshift Spectrum、Amazon EMR、Amazon QuickSight といったクエリ側から参照でき、いずれも Lake Formation の権限を尊重して結果を返します。サーバーレスでクエリを試したい段階では、Amazon Redshift Serverlessとは|サーバーレスDWHの仕組みと料金・実装・移行判断を解説で扱う構成から検証を始めると、レイク側の権限が効いているかを確かめやすい。さらに、AWS Resource Access Manager(RAM)と連携すると、LF-Tags を使ってテーブルを別アカウントへ共有でき、データをコピーせずに複数アカウント横断でのアクセス制御を組めます。
AWS Lake Formationの料金体系とコスト設計の考え方
費用の考え方はシンプルですが、誤解されがちです。Lake Formation の権限管理機能そのものに利用料はかかりません。費用が生じるのは、その下で動く基盤サービスの側です。
Lake Formation自体は無料|課金は基盤サービス側で発生
Lake Formation で権限を定義し、LF-Tags を運用し、データフィルタをかける——これらの操作に対する直接の課金はありません(時点:2026年7月・AWS公表の料金体系)。実際に費用として積み上がるのは、データを置く S3 のストレージ料金、スキーマを収集する Glue のクローラーとカタログ、そして Athena や Redshift でのクエリ実行料金です。つまり Lake Formation を足しても、権限管理のためだけに新たな固定費が乗るわけではない、という位置づけになります。金額の単価はリージョンと時点で変わるため、各基盤サービスの公式料金ページで確認してください。
ストレージとクエリ実行の費用を抑えるためのコスト設計上の判断
総額を抑える勘所は、Lake Formation の外側にあります。第一に、S3 のデータを Parquet/ORC などの列指向フォーマットで持ち、Athena のスキャン量を減らして1クエリあたりの費用を下げる。第二に、Glue クローラーの実行頻度を要件に合わせ、常時クロールで課金が積み上がるのを避ける。第三に、パーティション設計を整え、クエリが不要なデータまで読まないようにする。データレイクの権限設計とあわせて、こうした保存・クエリの設計まで含めて基盤を組みたい場合は、データ分析基盤構築・MLOps構築支援で、S3・Glue・Lake Formation・クエリ層までを受託開発の実務として支援します。
AWS Lake Formation を採用すべき場面と見送るべき場面
ここは判断を言い切ります。Lake Formation を採用すべき条件は、(1) S3 のデータレイクを複数のチーム・部門・アカウントで共用し、利用者ごとにアクセス範囲を分けたい、(2) 列レベル・行レベルでのきめ細かな制御が要件にある、(3) テーブル数が多く、IAM ポリシーでの個別管理が破綻しかけている、のいずれかに当てはまる場合です。この条件では、S3 バケットポリシーを書き足し続ける運用より、LF-Tags を軸にした一元管理へ寄せたほうが、権限の棚卸しと監査が回しやすくなります。
一方で見送る、あるいは急がない場面もはっきりしています。利用者が少数で、データセットも限られ、IAM とバケットポリシーの権限設計で十分に見通せる小規模構成では、Lake Formation を被せる手間が得られる制御の細かさに見合わないことがある。また、そもそも分析基盤が S3 データレイクではなく、DWH 単体(Redshift や BigQuery)で完結している場合は、Lake Formation の主戦場から外れます。失敗しやすいのは、既存の IAM 権限と Lake Formation 権限の関係を整理しないまま被せてしまい、意図しない拒否でクエリが通らなくなるパターンです。導入時はハイブリッドアクセスモードを使い、テーブル単位で段階的に移行して、都度クエリが通ることを確かめながら広げるのが堅実です。データレイクを本格的にチーム横断で運用する段階に入ったら、Lake Formation の導入を判断の俎上に載せてください。
よくある質問
AWS Lake Formationは無料で使えますか?
Lake Formation の権限管理機能そのものに利用料はかかりません。ただし、データを保存する S3、スキーマを収集する Glue のクローラーやカタログ、クエリを実行する Athena や Redshift には、それぞれの基盤サービスとしての料金が発生します。Lake Formation を足すこと自体で固定費が増えるわけではない、と捉えると分かりやすいです。
Lake FormationとIAMの権限はどちらが優先されますか?
両者は置き換えではなく重なって働きます。利用者はまず IAM で Athena や Glue の API を呼ぶ権限を持ち、そのうえで対象データへのアクセス可否を Lake Formation が判定します。どちらか一方でも許可がなければアクセスは通りません。既存 IAM 運用と混在させたい場合は、テーブル単位で方式を選べるハイブリッドアクセスモードで段階移行できます。
Lake FormationとAWS Glueの違いは何ですか?
Glue はデータの収集・変換(ETL)とメタデータ管理(データカタログ)を担うサービスで、Lake Formation はその Glue データカタログのリソースに対する権限とアクセス制御を担うサービスです。Glue が「データを整えて目録に載せる」役、Lake Formation が「その目録への入場券を配る」役、と役割で分けて捉えると整理できます。
LF-Tagsとは何のために使いますか?
LF-Tags は、データベース・テーブル・列にタグを付け、そのタグ単位でアクセスを許可する仕組みです。テーブルごとに名指しで権限を付ける方式に比べ、新規テーブルにタグを付けるだけで既存の許可規則が及ぶため、テーブル数の多い大規模データレイクで付与と棚卸しの運用を軽くできます。別アカウントへのクロスアカウント共有にも用いられます。
既存のS3データレイクにも後から導入できますか?
後からの導入は可能です。既存の S3 パスをデータロケーションとして登録し、Glue データカタログにテーブルを載せれば、後から Lake Formation の権限管理を被せられます。その際は現行の IAM 権限との整合を先に棚卸しし、ハイブリッドアクセスモードでテーブル単位に段階移行すると、既存のクエリを止めずに切り替えられます。
関連記事
- データレイクとは?データウェアハウス・レイクハウスとの違いを実装視点で解説(データレイクの概念・DWHとの違い)
- AWS IAMとは?仕組み・ユーザー/ロール/ポリシーの違いと権限設計のベストプラクティスを実装者目線で解説(IAM権限との関係)
- データカタログとは?意味・メタデータ管理の仕組みからAI時代の導入判断まで解説(Glueデータカタログの前提)
- データ分析基盤の構築とは?5層アーキテクチャとBigQuery実装手順を技術視点で解説(分析基盤の中でのレイク層)
- データレイクハウスとは?データレイク・DWHとの違いとアーキテクチャを実装視点で解説(レイクハウスとの位置づけ)