--- title: "SageMaker Lakehouseとは？構成・料金とIceberg REST接続の手順【2026年版】" url: "https://www.issoh.co.jp/tech/details/4763/" published: 2025-01-09 updated: 2026-10-01 categories: ["AWS"] publisher: "株式会社一創" --- # 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移行の解説](/tech/details/17509/)で扱っています。 AWS公式の説明では、レイクハウスアーキテクチャは利用者のAWSアカウント内の**Glue Data CatalogとLake Formationの上に構築**されています。クエリを実行するとLake Formationが権限を確認し、エンジンはS3やRedshiftにあるデータを元の場所のまま処理します。既存のData Catalogはそのまま既定のカタログとして使われるため、データの移行は必要ありません。 ### 2024年12月から2026年9月までの主な変更 | 日付 | 変更内容 | | ---------- | ---------------------------------------- | | 2024-12-03 | SageMaker Lakehouse発表。東京を含む14リージョンで提供 | | 2024-12-03 | DynamoDBと8つのSaaSからのゼロETL統合 | | 2025-03-13 | Unified Studio一般提供・S3 Tables統合の一般提供 | | 2025-04-24 | 属性ベースアクセス制御（ABAC）に対応 | | 2025-06-30 | Aurora MySQL・RDS for MySQLからのゼロETL統合 | | 2025-07-31 | 専用ユーザーガイド初版。呼称がレイクハウスアーキテクチャへ | | 2025-08-08 | Icebergテーブルの自動最適化をカタログ単位で設定可能に | | 2025-08-29 | フェデレーテッドカタログでタグベースアクセス制御 | | 2025-10-15 | Aurora PostgreSQLからのゼロETL統合 | | 2026-05-18 | RedshiftからData Catalog経由でIcebergへ書き込み | | 2026-08-21 | Glue 6.0でIceberg v3に対応 | | 2026-08-31 | RedshiftがIceberg v3の読み書きに対応 | | 2026-09-14 | ゼロETLの書き込み先の競合検知 | | 2026-09-28 | Unified Studioで外部のIceberg RESTカタログに接続可能に | 改称の告知は出ておらず、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: , valid types: ` というパラメータ検証エラーになります。真偽値の `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関数が作られます。 注意点として、[公式ドキュメントのフェデレーテッドカタログの説明](https://docs.aws.amazon.com/sagemaker-lakehouse-architecture/latest/userguide/federated-catalogs.html)には「テーブル名・列名・データベース名は小文字のみ対応」と書かれています。大文字の識別子を多用しているSQL ServerやOracleのスキーマをつなぐ場合は、先に小文字のビューを用意するといった対処が必要です。Athenaからの書き方は[Athenaでのフェデレーテッドクエリの実装](/tech/details/17734/)を参照してください。 ## ストレージの選び方：汎用S3・S3 Tables・RMS Lakehouseにデータを置く場所は3つあります。どれを選ぶかで、テーブル保守を自分でやるかどうかと、どのエンジンから書けるかが変わります。 | 保存先 | テーブル保守 | 東京の保存単価 | 向いている用途 | | ------------ | ---------------- | ----------------------- | --------------- | | 汎用S3＋Iceberg | 自前（自動最適化は有料で追加可） | S3の標準料金 | 保守を細かく制御したい | | S3 Tables | 自動（既定で有効） | 最初の50TBは0.0288 USD/GB・月 | 保守を任せたい小規模チーム | | RMS | Redshiftが自動最適化 | 0.0261 USD/GB・月 | 高同時実行のBI・定型レポート | 判断の目安として、AWSの日本語ブログは、数百人が同時にダッシュボードを開くBIや、応答時間の保証が必要な財務レポートにはRMSを勧め、それ以外はS3系を中心に据える構成を示しています。S3 Tablesの料金と保守の既定値は[S3 Tablesの仕組みと東京リージョンの料金](/tech/details/5405/)、Icebergの基本は[IcebergとParquetの違い](/tech/details/4812/)で詳しく扱っています。 ## Iceberg RESTでSpark・PyIcebergから接続する設定 Iceberg対応のエンジンは、AWS以外の製品も含め、Glue Data CatalogのIceberg RESTエンドポイントからS3やS3 Tablesに置いたIcebergテーブルを操作できます。RMSのテーブルはこの標準のAPIでは届かず、後述の拡張エンドポイントへの対応が必要です。 ### Glue Iceberg RESTエンドポイントの設定値 [AWS GlueのIceberg RESTエンドポイントの説明](https://docs.aws.amazon.com/glue/latest/dg/connect-glu-iceberg-rest.html)によると、必要な設定は、エンドポイント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エンドポイントがあり、設定値が異なります。 | 項目 | Glue Iceberg REST | S3 Tables Iceberg REST | | ------------------- | -------------------------------- | ------------------------------------ | | URI | glue.リージョン.amazonaws.com/iceberg | s3tables.リージョン.amazonaws.com/iceberg | | 署名名 | glue | s3tables | | S3 Tablesのwarehouse | アカウントID:s3tablescatalog/バケット名 | テーブルバケットのARN | | 権限の制御 | Lake Formation | S3 TablesのIAMポリシー | | 扱える範囲 | S3・S3 Tables・RMSを横断 | 1つのテーブルバケット | 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の権限管理と使い方](/tech/details/15517/)で解説しています。 ### RMSカタログで効かなくなる設定 既存のRedshiftをカタログとして公開する場合は、[Lake Formationのドキュメントにある制約の一覧](https://docs.aws.amazon.com/lake-formation/latest/dg/notes-ns-catalog.html)を事前に確認してください。影響が大きいのは次の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のレイクハウスの料金ページ](https://aws.amazon.com/sagemaker/lakehouse/pricing/)には、使ったリソースの分だけ支払う形で、メタデータはGlue Data Catalogの料金（無料枠を含む）、データの保存と処理はS3かRMSの料金に従うと書かれています。東京リージョンの単価はAWS Price List APIで次のとおりです（2026年10月1日取得）。 | 課金項目 | 東京リージョンの単価 | | ---------------------- | ----------------------------- | | Data Catalogの保存 | 月100万オブジェクトまで無料、超過10万あたり1 USD | | Data Catalogのリクエスト | 月100万回まで無料、超過100万回あたり1 USD | | Icebergの自動最適化 | 0.44 USD/DPU時間 | | 列統計の生成 | 0.44 USD/DPU時間 | | RMSの保存 | 0.0261 USD/GB・月 | | Redshift Serverlessの計算 | 0.494 USD/RPU時間 | | Lake Formationの権限 | 無料 | 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ステップ](/tech/details/15381/)にまとめています。 ## よくある質問 ### 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との違い](/tech/details/13628/)で解説しています。 ### 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との違いとアーキテクチャを実装視点で解説](/tech/details/13628/) - [Amazon S3 Tablesとは？テーブルバケットの仕組みと東京リージョンの料金・作成手順【2026年版】](/tech/details/5405/) - [AWS Lake Formationとは？データレイクの権限管理・使い方・料金と実装判断を解説【2026年版】](/tech/details/15517/) - [SageMakerとは？SageMaker AIへの改称とPython SDK v3移行を実装手順で解説](/tech/details/17509/) - [AWS Glueとは？機能・料金・使い方とWorkflowsの仕組みまで徹底解説](/tech/details/7251/) --- 出典: [SageMaker Lakehouseとは？構成・料金とIceberg REST接続の手順【2026年版】]()（株式会社一創）