SageMaker Lakehouseとは？構成・料金とIceberg REST接続の手順【2026年版】

Amazon SageMaker Lakehouseは、S3のデータレイクとRedshiftのデータウェアハウスを1つのカタログにまとめ、Apache IcebergのAPIを通じて対応エンジンから読み書きできるようにするAWSの仕組みです。使えるエンジンと操作は、データの保存先によって変わります。2024年12月3日のre:Inventで発表され、現在のAWS公式ドキュメントでは「the lakehouse architecture of Amazon SageMaker（SageMakerのレイクハウスアーキテクチャ）」と呼ばれています。この記事では、独立したサービスではなくGlue Data CatalogとLake Formationの上に載る層であること、カタログの種類、ストレージの選び方、東京リージョンの料金内訳、SparkやPyIcebergからの接続設定、Redshift Managed Storageを使うときの制約を、2026年10月時点の公式情報をもとに整理します。

まとめ

• SageMaker LakehouseはGlue Data CatalogとLake Formationの上に作られた統合層です。専用の月額料金はなく、Data Catalog、S3、Redshift Managed Storage（RMS）、Redshift Serverlessなど、実際に使った下位サービスの分だけ課金されます。
• カタログはマネージド（S3かRMSに新しくデータを置く）とフェデレーテッド（既存のRedshiftやDynamoDB、Snowflakeなどをマウントする）の2種類です。
• 外部エンジンからの入り口はGlueのIceberg RESTエンドポイント（東京は https://glue.ap-northeast-1.amazonaws.com/iceberg）です。SigV4署名が必須で、署名名は glue です。
• RMSカタログでは、送信元Redshiftに設定した行レベルセキュリティと動的マスキングは適用されず、Lake Formationの権限だけが効きます。タイムトラベルも使えません。
• 東京リージョンは2024年12月の発表時点から対象です。Redshiftだけで分析が完結している組織では、急いで移行する理由はありません。

SageMaker Lakehouseの位置づけと名称の変遷

SageMaker Lakehouseは、2024年12月3日に発表された「次世代のAmazon SageMaker」を構成する要素の1つです。次世代SageMakerは、開発環境のSageMaker Unified Studio、カタログとガバナンスのSageMaker Catalog、データ層のLakehouseで構成されます。同じ日に、従来の機械学習サービスはSageMaker AIへ改称されました。学習や推論を扱うSageMaker AIについてはSageMaker AIへの改称とPython SDK v3移行の解説で扱っています。

AWS公式の説明では、レイクハウスアーキテクチャは利用者のAWSアカウント内のGlue Data CatalogとLake Formationの上に構築されています。クエリを実行するとLake Formationが権限を確認し、エンジンはS3やRedshiftにあるデータを元の場所のまま処理します。既存のData Catalogはそのまま既定のカタログとして使われるため、データの移行は必要ありません。

2024年12月から2026年9月までの主な変更

改称の告知は出ておらず、What’s Newの見出しは2025年4月まで「SageMaker Lakehouse」、2025年8月からは「SageMaker lakehouse architecture」です。検索や社内資料では旧名がまだ多く使われているため、両方の名前で調べると情報を取りこぼしにくくなります。

カタログ・データベース・テーブルの3層構造

データは「カタログ → データベース → テーブル／ビュー」の3層で整理されます。カタログの下にさらにカタログを入れ子にでき、Redshiftの「名前空間 → データベース → スキーマ」のような階層をそのまま写せます。作成したカタログはRedshiftにデータベースとして自動マウントされるため、RedshiftのSQLツールからも参照できます。

マネージドカタログの保存先とRMSカタログの作成設定

マネージドカタログは、メタデータとデータの保存先（S3かRMS）をLakehouse側で管理するカタログです。既存のGlue Data Catalogも、アカウントIDで識別される既定のマネージドカタログとしてそのまま使われます。RMSを選ぶと、Glue側でカタログが作られ、Lake Formationのデータロケーションとして登録され、専用のRedshift Serverlessワークグループが作られ、データ共有でRedshiftとつながります。CLIでは aws glue create-catalog に次のJSONを渡します。

{
  "Name": "sales_rms",
  "CatalogInput": {
    "Description": "RMS managed catalog",
    "CreateDatabaseDefaultPermissions": [],
    "CreateTableDefaultPermissions": [],
    "CatalogProperties": {
      "DataLakeAccessProperties": {
        "DataLakeAccess": true,
        "DataTransferRole": "arn:aws:iam::123456789012:role/LakehouseDataTransferRole",
        "CatalogType": "aws:redshift"
      }
    }
  }
}

公式ドキュメントのCLI例は "DataLakeAccess" : "true" と文字列で書かれていますが、aws-cli 1.46.1では Invalid type for parameter CatalogInput.CatalogProperties.DataLakeAccessProperties.DataLakeAccess, value: true, type: <class 'str'>, valid types: <class 'bool'> というパラメータ検証エラーになります。真偽値の true で渡してください。カタログ名は小文字のみで、あとから変更できません。

フェデレーテッドカタログの対応ソースと識別子の制約

フェデレーテッドカタログは、データを動かさずに既存のデータソースをLakehouseへマウントします。公式ドキュメントに載っている対応ソースは、Google BigQuery、Amazon DocumentDB、DynamoDB、Redshift、MySQL、PostgreSQL、SQL Server、Snowflake、Oracle、Aurora MySQL、Aurora PostgreSQL、Azure SQLの12種類です。接続を作ると、裏でGlue接続、Athenaのデータカタログ、Athenaフェデレーテッドクエリ用のLambda関数が作られます。

注意点として、公式ドキュメントのフェデレーテッドカタログの説明には「テーブル名・列名・データベース名は小文字のみ対応」と書かれています。大文字の識別子を多用しているSQL ServerやOracleのスキーマをつなぐ場合は、先に小文字のビューを用意するといった対処が必要です。Athenaからの書き方はAthenaでのフェデレーテッドクエリの実装を参照してください。

ストレージの選び方：汎用S3・S3 Tables・RMS

Lakehouseにデータを置く場所は3つあります。どれを選ぶかで、テーブル保守を自分でやるかどうかと、どのエンジンから書けるかが変わります。

判断の目安として、AWSの日本語ブログは、数百人が同時にダッシュボードを開くBIや、応答時間の保証が必要な財務レポートにはRMSを勧め、それ以外はS3系を中心に据える構成を示しています。S3 Tablesの料金と保守の既定値はS3 Tablesの仕組みと東京リージョンの料金、Icebergの基本はIcebergとParquetの違いで詳しく扱っています。

Iceberg RESTでSpark・PyIcebergから接続する設定

Iceberg対応のエンジンは、AWS以外の製品も含め、Glue Data CatalogのIceberg RESTエンドポイントからS3やS3 Tablesに置いたIcebergテーブルを操作できます。RMSのテーブルはこの標準のAPIでは届かず、後述の拡張エンドポイントへの対応が必要です。

Glue Iceberg RESTエンドポイントの設定値

AWS GlueのIceberg RESTエンドポイントの説明によると、必要な設定は、エンドポイントURI、warehouse（既定カタログならAWSアカウントID）、SigV4署名の有効化と署名名 glue です。PyIcebergでは次のように書きます。

from pyiceberg.catalog import load_catalog

cat = load_catalog(
    "glue_rest",
    **{
        "type": "rest",
        "uri": "https://glue.ap-northeast-1.amazonaws.com/iceberg",
        "warehouse": "123456789012",
        "rest.sigv4-enabled": "true",
        "rest.signing-name": "glue",
        "rest.signing-region": "ap-northeast-1",
    },
)
print(cat.list_namespaces())

PyIceberg 0.12.0（2026年9月1日公開）で、無効な認証情報を渡して東京のエンドポイントに接続すると The security token included in the request is invalid. の403が返ります。この結果で分かるのは、東京のエンドポイントに届き、認証情報の段階で拒否されたところまでです。カタログを実際に読めるかどうかは、有効な認証情報とLake Formationの権限をそろえて確認します。rest.sigv4-enabled の行を消すと、同じ403でも Invalid key=value pair (missing equal-sign) in Authorization header に変わります。この文言が出たら署名設定の漏れを疑ってください。Sparkの場合も同じ値を spark.sql.catalog.<名前>. の接頭辞で渡し、type を rest にします。あわせて spark.sql.catalog.<名前> に org.apache.iceberg.spark.SparkCatalog を指定し、使っているSparkのバージョンに合うIcebergランタイムのJARを入れておきます。

S3 Tables専用エンドポイントとの違い

S3 TablesにはS3側にもIceberg RESTエンドポイントがあり、設定値が異なります。

S3のユーザーガイドは、S3 Tables側のエンドポイントを「単一のテーブルバケットへの基本的な読み書き」などに限った用途とし、それ以外はGlue側を推奨しています。Lakehouseとして権限を一元管理したいなら、Glue側を選びます。

入れ子カタログの指定方法と名前空間の制約

REST APIを直接呼ぶ場合、URLの接頭辞は /catalogs/{catalog} の形になり、既定カタログは GET /v1/catalogs/:/namespaces、入れ子のカタログは rmscatalog1:db1 のように区切って指定します。エンジン経由なら、この値をwarehouseに入れれば足ります。GlueのIceberg RESTが扱う名前空間は1階層だけです。そのため、入れ子カタログの中のテーブルは カタログ.名前空間.テーブル の3部構成で参照します。エンドポイントのドキュメントが対応するIcebergテーブル仕様として挙げているのはv1とv2で、既定はv2です。

データの取り込み：ゼロETL統合とフェデレーテッドクエリ

データの持ち込み方には、GlueのジョブなどでETLを書く従来の方法に加えて、継続的に複製するゼロETL統合と、元の場所に置いたまま読むフェデレーテッドクエリがあります。ゼロETL統合の対応元は、DynamoDB、Aurora MySQL、RDS for MySQL、Aurora PostgreSQLのほか、Salesforce、SAP OData、ServiceNow、Zendesk、Zoho CRM、Facebook Ads、Instagram AdsなどのSaaSです。Aurora PostgreSQLからの統合は2025年10月15日に始まり、東京リージョンも対象です。複製されたデータはIcebergのAPIで参照できますが、書き込み先をRMSにした場合は、RMSの制約を受けます。

ゼロETL統合そのものに追加料金はかかりませんが、複製の処理には費用がかかります。書き込み先の処理は、S3ならGlueのDPU、RMSならRedshift ServerlessのRPUで課金されます。これとは別に、DynamoDBのエクスポートなど送信元側の費用も発生します。2026年9月14日からは、2つの統合が同じテーブルへ書き込もうとすると、Glueが競合として検知するようになりました。

S3 Tablesのテーブルは、Athenaから "s3tablescatalog/バケット名" をカタログ名として指定して操作します。次の例は、テーブルバケットを統合を有効にして作成し、Lake Formationで権限を付与した後に実行するものです。バケット名は実際の名前に置き換えてください。

CREATE DATABASE "s3tablescatalog/sales-bucket".sales_db;

CREATE TABLE "s3tablescatalog/sales-bucket".sales_db.orders (
  order_id string,
  amount double,
  ordered_at timestamp)
TBLPROPERTIES ('table_type'='ICEBERG');

権限管理：Lake Formationによる細粒度の制御

権限はLake Formationで定義し、Athena、Redshift、EMR、Glueなどの統合エンジンからのアクセスに同じ権限が適用されます。カタログ・データベース・テーブル・列の単位で権限を付けられ、S3 Tablesでは列やセルの単位まで絞れます。2025年4月24日にはIAMのプリンシパルタグやセッションタグで権限を決める属性ベースアクセス制御（ABAC）に対応しました。2025年8月29日には、タグベースアクセス制御がS3 Tables、Redshift、DynamoDBやPostgreSQLなどのフェデレーテッドカタログにも広がっています。Lake Formationの権限機能に追加料金はかかりません。設定手順はLake Formationの権限管理と使い方で解説しています。

RMSカタログで効かなくなる設定

既存のRedshiftをカタログとして公開する場合は、Lake Formationのドキュメントにある制約の一覧を事前に確認してください。影響が大きいのは次の4点です。

• 送信元のRedshiftクラスターに設定した行レベルセキュリティと動的データマスキングは適用されません。共有データにはLake Formationの権限だけが効きます。Lake Formationの列の権限は列を見せるか見せないかの制御で、値を書き換える動的マスキングの代わりにはなりません。送信元で行や値の秘匿に頼っていた箇所は、Lake Formationで付けられる権限の範囲を確かめたうえで設計し直します。
• RMSのテーブルではタイムトラベルを使えません。AthenaからRMSテーブルへのDDLと、マテリアライズドビューの作成もできません。
• RMSのテーブルに届くのは、Glue Iceberg RESTの拡張エンドポイント経由だけです。標準のIceberg RESTしか話せないサードパーティ製エンジンからは読めない前提で設計します。
• EMR on EC2では、RMSのテーブルとS3のテーブルを結合できません。結合できるのはEMR Serverlessだけです。

料金の内訳：Lakehouse自体は無料、課金は下位サービス

SageMakerのレイクハウスの料金ページには、使ったリソースの分だけ支払う形で、メタデータはGlue Data Catalogの料金（無料枠を含む）、データの保存と処理はS3かRMSの料金に従うと書かれています。東京リージョンの単価はAWS Price List APIで次のとおりです（2026年10月1日取得）。

Data Catalogのオブジェクトには、テーブルだけでなくテーブルのバージョンやパーティション、統計も数えられます。パーティションを日単位で細かく切ったテーブルが多いと、100万の無料枠は想像より早く超えます。

裏で作られるRedshift Serverlessの費用を追う方法

AthenaやEMRなど外部のエンジンがRMSのカタログを読むとき、AWSは変換役のRedshift Serverlessワークグループをサービス管理で自動作成し、その計算にRPU料金がかかります。自分で作った覚えのないワークグループなので、請求で見落としやすい費用です。AWSのブログは、このワークグループに付く aws:redshift-serverless:LakehouseManagedWorkgroup タグ（値は True）でコストを追跡するよう案内しています。コスト配分タグとして有効化したうえで、Cost Explorerで次のように絞り込みます。

aws ce get-cost-and-usage \
  --time-period Start=2026-09-01,End=2026-10-01 \
  --granularity MONTHLY \
  --metrics UnblendedCost \
  --filter '{"Tags":{"Key":"aws:redshift-serverless:LakehouseManagedWorkgroup","Values":["True"]}}'

Redshift内のテーブルを何度も結合する重いクエリは、外部エンジンから投げるとこのワークグループの計算が膨らみます。AWSのブログも、Redshiftのデータを多用する処理はRedshift内かSparkで実行するよう勧めています。

SageMaker Lakehouseの採用を見送る条件

次のいずれかに当てはまるなら、Lakehouseを新しく入れても得るものは少なく、今の構成を続けるほうが合理的です。

• 分析がRedshiftの中だけで完結している。ほかのエンジンから同じデータを読む予定がなければ、カタログを公開しても管理対象が増えるだけです。行レベルセキュリティやマスキングをRedshift側で作り込んでいる場合は、Lake Formationで作り直す手間も発生します。
• データ基盤の中心がDatabricksやSnowflakeにある。Unified Studioは2026年9月から外部のIceberg RESTカタログ（Unity Catalog、Snowflake Open Catalogなど）への接続に対応しましたが、権限の管理元が2つに分かれます。どちらを正とするかを決めずに併用すると、権限の二重管理になります。
• 接続元の識別子に大文字が多い。小文字しか扱えない制約があるため、フェデレーテッドカタログの前に命名の手直しが必要です。

逆に、S3のデータレイクとRedshiftが並立していて、同じテーブルをAthena、EMR、SageMaker AIから権限を揃えて読みたい組織なら、効果は大きくなります。追加料金なしで既存のData Catalogから始められるので、まずS3の既定カタログとLake Formationの権限から整え、RMSは必要になってから足す順番がおすすめです。一般的なデータレイクハウスの設計手順はデータレイクハウス実装の手順6ステップにまとめています。

よくある質問

SageMaker Lakehouseは名前が変わったのですか？

公式の改称告知は出ていませんが、2025年7月31日初版の専用ユーザーガイドと現行の製品ページでは「the lakehouse architecture of Amazon SageMaker」と呼ばれています。機能とAPIは同じで、What’s Newの見出しも2025年8月から新しい呼称に変わっています。

データレイクハウスとは何ですか？

データレイクの安さと拡張性に、データウェアハウスのトランザクション整合性やスキーマ管理を組み合わせた構成です。AWSではこれを、IcebergとGlue Data Catalog、Lake Formationで実現しています。製品に依存しない考え方はデータレイクハウスとは？データレイク・DWHとの違いで解説しています。

SageMaker Lakehouseは東京リージョンで使えますか？

使えます。2024年12月3日の発表時点で、東京を含む14リージョンが対象でした。S3 Tablesとの統合は、S3 Tablesが提供されているリージョンで使えます。

Lake Formationの設定は必須ですか？

レイクハウスアーキテクチャ自体がLake Formationの上に作られているため、細かい権限を付けるならLake Formationで定義します。既存のIAMベースの利用者を残したまま段階的に移したい場合は、IAMとLake Formationの権限を併用できるハイブリッドアクセスモードを使います。

SageMaker AIとSageMaker Lakehouseは何が違いますか？

SageMaker AIはモデルの学習・推論を担う旧来のSageMakerで、Lakehouseはデータを保存・統合する層です。どちらも次世代のAmazon SageMakerの構成要素で、Unified Studioから両方を使えます。

関連記事

• データレイクハウスとは？データレイク・DWHとの違いとアーキテクチャを実装視点で解説
• Amazon S3 Tablesとは？テーブルバケットの仕組みと東京リージョンの料金・作成手順【2026年版】
• AWS Lake Formationとは？データレイクの権限管理・使い方・料金と実装判断を解説【2026年版】
• SageMakerとは？SageMaker AIへの改称とPython SDK v3移行を実装手順で解説
• AWS Glueとは？機能・料金・使い方とWorkflowsの仕組みまで徹底解説