【AWS】S3 Tables と SageMaker Lakehouse で進化する Iceberg データレイク — 自動最適化とコスト分析
はじめに
本シリーズでは Apache Iceberg on AWS を段階的に解説してきました。
- 第 1 弾「Apache Iceberg 実践入門」: Iceberg の基本概念と Athena での操作、メダリオンアーキテクチャ
- 第 2 弾「運用コスト最適化」: コンパクション・スナップショット管理・コスト最適化
- 第 3 弾「Data Firehose ストリーミング取り込み」: CDC パイプラインとコンパクション戦略
- 第 4 弾「Lake Formation・マルチエンジン連携」: アクセス制御・エンジン連携・本番運用
第 4 弾の最後に、SageMaker Lakehouse を「統合データアクセスレイヤー」として紹介しました。本記事ではそこから一歩踏み込み、2025 年に GA した Amazon S3 Tables と Amazon SageMaker Lakehouse が Iceberg データレイクをどう進化させるかを解説します。
従来、Iceberg テーブルの運用には「S3 にデータを置き、Glue Data Catalog でメタデータを管理し、Glue テーブルオプティマイザでメンテナンスを自動化する」という構成が標準でした。S3 Tables と SageMaker Lakehouse は、この構成をさらにシンプルかつ高性能にする選択肢です。
S3 Tables — Iceberg ネイティブのオブジェクトストレージ
Table Bucket とは
Amazon S3 Tables は、Apache Iceberg をネイティブにサポートする新しい S3 のストレージタイプです。従来の S3 バケット（汎用バケット）とは別に、Table Bucket という専用のバケットタイプで Iceberg テーブルを管理します。
| 項目 | 汎用 S3 バケット + Glue | S3 Tables（Table Bucket） |
|---|---|---|
| テーブル管理 | Glue Data Catalog で手動管理 | S3 が Iceberg テーブルを直接管理 |
| メンテナンス | Glue テーブルオプティマイザ | S3 が自動実行 |
| メタデータ | Glue Data Catalog | Table Bucket 内蔵 |
| パフォーマンス | 標準 | クエリスループット最大 3 倍 |
| トランザクション性能 | 標準 | TPS 最大 10 倍 |
Table Bucket は Iceberg テーブルの格納に特化して設計されているため、メタデータの管理やトランザクション処理が通常の S3 バケット上で Iceberg を運用する場合よりも大幅に高速化されています。
自動テーブルメンテナンス
S3 Tables の最大の特徴は、テーブルメンテナンスが完全に自動化される点です。第 2 弾や第 4 弾で解説した 3 つのメンテナンス操作が、設定なしでデフォルトで動作します。
| メンテナンス | 動作 |
|---|---|
| 自動コンパクション | スモールファイルを統合し、クエリ性能を最適化 |
| スナップショット管理 | 古いスナップショットのメタデータとデータを自動削除 |
| 孤立ファイル削除 | メタデータから参照されない不要ファイルを自動削除 |
第 4 弾で紹介した Glue テーブルオプティマイザでは、テーブルごとに有効化の設定が必要でした。S3 Tables ではこれがデフォルトで有効です。テーブルメンテナンスのポリシーは Table Bucket レベルでカスタマイズ可能ですが、多くの場合はデフォルト設定のままで十分です。
対応エンジン
S3 Tables は Iceberg 標準に準拠しているため、以下のエンジンから直接アクセスできます。
- Amazon Athena: SQL によるアドホッククエリ
- Amazon Redshift: BI ダッシュボード用クエリ・書き込み
- Amazon EMR: 大規模な Spark / Hive ジョブ
- AWS Glue: ETL パイプライン
- Apache Spark / PyIceberg: Iceberg REST Catalog 経由でのアクセス
- Trino / DuckDB: Iceberg REST Catalog 経由での読み書き
S3 Tables は Iceberg REST Catalog 標準に対応しているため、上記以外の Iceberg 互換エンジンからもアクセス可能です。
SageMaker Lakehouse 経由で統合カタログに登録すると、これらのエンジンからシームレスに S3 Tables のテーブルを参照できます。
PyIceberg からのアクセス例:
from pyiceberg.catalog import load_catalog
catalog = load_catalog(
"s3tables",
type="rest",
uri="https://glue.ap-northeast-1.amazonaws.com/iceberg",
warehouse="<AWS_ACCOUNT_ID>:s3tablescatalog/my-table-bucket",
**{"rest.sigv4-enabled": "true",
"rest.signing-name": "glue",
"rest.signing-region": "ap-northeast-1"},
)
# テーブルの読み込み
table = catalog.load_table("my_namespace.sales")
df = table.scan().to_pandas()
Iceberg REST Catalog エンドポイント経由のため、AWS マネージドサービスだけでなくローカル環境や他クラウドからも SigV4 認証でアクセスできます。
リージョンと制約
S3 Tables は 2024 年 12 月に GA し、2025 年 1 月に東京リージョン（ap-northeast-1）を含む追加リージョンが発表されました。2026 年 3 月時点で 30 以上のリージョンに対応しています。以下の制約があります。
- Table Bucket 内のテーブルは Iceberg フォーマットのみ（Hudi、Delta Lake は非対応）
- 既存の汎用バケット上の Iceberg テーブルを Table Bucket に「移行」する機能はない（再作成が必要）
SageMaker Lakehouse — 統合データアクセスレイヤー
アーキテクチャ
Amazon SageMaker Lakehouse は、S3 データレイクと Redshift データウェアハウスを Apache Iceberg フォーマットで統合するアーキテクチャです。
データソース（S3 Tables / S3 汎用バケット / Redshift / 外部カタログ）が統合カタログ（Glue Data Catalog）に登録され、Lake Formation でアクセス制御された上で、Athena・Redshift・EMR・Unified Studio からアクセスできます。
SageMaker Lakehouse 自体は新しいサービスではなく、既存の AWS サービス（S3、Redshift、Glue Data Catalog、Lake Formation）を Iceberg を軸に統合した設計パターンとして理解するのが正確です。
S3 Tables との統合
SageMaker Unified Studio から S3 Tables を操作できます。
- テーブルの作成・管理: Unified Studio の UI から Table Bucket にテーブルを作成
- クエリの実行: SQL エディタから Athena / Redshift を使って S3 Tables のデータをクエリ
- データカタログの統合: S3 Tables のテーブルが Glue Data Catalog に自動登録され、全エンジンからアクセス可能
自動最適化ポリシー
SageMaker Lakehouse 経由では、Iceberg テーブルの最適化ポリシーをより細かく管理できます。
- コンパクション戦略の選択: Binpack（デフォルト）、Sort、Z-order から選択
- スナップショット保持ポリシー: タイムトラベル要件に応じて保持期間・最小保持数を設定
- 新規テーブルへの自動適用: Lakehouse 内で作成されたテーブルに最適化設定を自動適用
第 4 弾で解説した Glue テーブルオプティマイザの設定が、Lakehouse の統合コンソールからまとめて管理できるようになった、と捉えるとわかりやすいでしょう。
2026 年 3 月のアップデート
SageMaker Unified Studio は急速に進化しています。
- Glue 5.1 サポート: Spark 3.5.6 + Iceberg 1.10.0 が利用可能に。Athena の Iceberg 1.4.2 と比較してより新しいバージョンで、V3 テーブル対応や最新の API が使える
- サードパーティカタログ連携: Atlan、Collibra、Alation とのメタデータ同期に対応。用語集・資産説明・所有者情報がカタログ間で自動同期され、既存のデータガバナンスツールとの統合が容易に
クロスアカウントガバナンス
SageMaker Catalog と S3 Tables の組み合わせにより、クロスアカウントのデータ共有がシンプルになります。
- 共有側: S3 Tables のテーブルを Lake Formation で共有設定
- 利用側: SageMaker Catalog で共有テーブルを検索・利用
- 監査: Lake Formation のアクセスログで横断的に監査
既存 Iceberg 環境からの移行パターン
既に「汎用 S3 バケット + Glue Data Catalog」で Iceberg テーブルを運用している場合、S3 Tables への移行はどのように進めるべきでしょうか。
パターン 1: 新規テーブルを S3 Tables で作成
最もリスクの低いアプローチです。既存テーブルはそのまま運用を続け、新しく作成するテーブルから S3 Tables を採用します。
既存テーブルは汎用 S3 + Glue Data Catalog のまま変更せず、新規テーブルのみ S3 Tables（Table Bucket）で作成します。Glue Data Catalog で両方のテーブルを統合管理するため、Athena / Redshift から透過的にアクセスできます。
メリット: 既存環境への影響ゼロ。段階的に S3 Tables の性能・コストを評価できる。
パターン 2: 既存テーブルと S3 Tables の共存
既存テーブルのデータを S3 Tables に再作成し、検証後に切り替えるパターンです。
- S3 Tables に同一スキーマのテーブルを作成
- 既存テーブルから
INSERT INTO ... SELECT * FROM ...でデータをコピー - クエリ結果の整合性を検証
- アプリケーションの参照先を切り替え
- 既存テーブルを一定期間保持した後に削除
注意: S3 Tables にはネイティブなインプレース移行機能はありません。ただし、AWS が提供する移行ガイダンス（Step Functions + EMR パイプラインや Athena CTAS）を利用してデータを移行できます。
Athena CTAS による移行例:
-- 1. SageMaker Lakehouse 経由で S3 Tables にテーブルを作成
CREATE TABLE s3tablescatalog.my_bucket.my_namespace.sales
WITH (
table_type = 'ICEBERG',
format = 'PARQUET',
write_compression = 'ZSTD',
partitioning = ARRAY['month(sale_date)', 'region']
)
AS SELECT * FROM glue_catalog.analytics.sales
WHERE sale_date >= DATE '2025-01-01';
-- 2. データの整合性を検証
SELECT COUNT(*) AS row_count, SUM(total_amount) AS total
FROM s3tablescatalog.my_bucket.my_namespace.sales;
-- 3. 増分データの追加（日次バッチで実行）
INSERT INTO s3tablescatalog.my_bucket.my_namespace.sales
SELECT * FROM glue_catalog.analytics.sales
WHERE sale_date >= DATE '2026-03-01';
注意: Athena から S3 Tables にアクセスするには、SageMaker Lakehouse との統合設定が必要です。
s3tablescatalogは統合時に自動作成されるカタログ名です。
移行時の考慮事項
| 項目 | 確認ポイント |
|---|---|
| リージョン対応 | S3 Tables が利用可能なリージョンか確認 |
| テーブルサイズ | 大量データの再作成にかかる時間とコストを見積もる |
| メンテナンス設定 | Glue テーブルオプティマイザの設定が S3 Tables に引き継がれない |
| 既存パイプライン | Firehose / Glue ETL の出力先を変更する必要があるか |
| Lake Formation 連携 | S3 Tables のテーブルに既存のアクセス制御を再設定 |
コスト分析 — 従来構成 vs S3 Tables
ストレージコスト
| 項目 | 汎用 S3 Standard | S3 Tables Standard |
|---|---|---|
| ストレージ（先頭 50 TB） | $0.023/GB/月 | $0.0265/GB/月 |
| PUT リクエスト | $0.005/1,000 リクエスト | $0.005/1,000 リクエスト（+ オブジェクト監視料金） |
S3 Tables のストレージ単価は汎用 S3 より約 15% 高いです。ただし、S3 Tables は Intelligent-Tiering にも対応しているため、アクセス頻度の低いデータは自動的に低コスト層に移動します。
メンテナンスコスト
従来構成では Glue テーブルオプティマイザの DPU 課金（$0.44/DPU-Hour）が発生していました。S3 Tables ではメンテナンスが組み込みですが、コンパクション処理料金が別途発生します。
コンパクション料金は「処理されたオブジェクト数」と「処理されたデータ量」で課金されます。2025 年 7 月にコンパクション料金の大幅値下げが実施され、Binpack で最大 90%、Sort/Z-order で最大 80% 低下しました。ただし、頻繁にスモールファイルが書き込まれるワークロードでは、自動コンパクションの発火頻度が高くなり、コストが想定以上に膨らむ可能性がある点には引き続き注意が必要です。
月額 TCO 比較（1 TB テーブル）
第 2 弾と同じ前提（1 TB テーブル、日次コンパクション、週次スナップショット管理）で比較します。
| コスト項目 | 汎用 S3 + Athena | 汎用 S3 + Glue Optimizer | S3 Tables |
|---|---|---|---|
| ストレージ（月額） | $23.00 | $23.00 | $26.50（+15%） |
| コンパクション（月額） | $1.50 | ~$13.20 | ~$5.12 |
| スナップショット管理（月額） | $0.04 | ~$2.00 | 含む |
| モニタリング（月額） | — | — | ~$2.50 |
| 合計（月額） | ~$24.54 | ~$38.20 | ~$34.12 |
詳細な料金内訳と前提条件は第 2 弾「運用コスト最適化」を参照してください。
ユースケース別の推奨構成
| ユースケース | 推奨構成 | 理由 |
|---|---|---|
| 新規プロジェクト（中小規模） | S3 Tables | 運用負荷ゼロ、自動メンテナンス、高いスループット |
| 大規模本番環境（既存） | 汎用 S3 + Glue Optimizer | 移行コスト・リスクが大きい。段階的に S3 Tables 導入 |
| 頻繁なスモールファイル書き込み（IoT 等） | 汎用 S3 + EMR コンパクション | S3 Tables のコンパクション費用が高くなりやすい |
| BI ダッシュボード用のサマリーテーブル | S3 Tables | 読み取り中心でコンパクション費用が低い |
| マルチエンジン統合 | SageMaker Lakehouse + S3 Tables | 統合カタログとアクセス制御の恩恵が大きい |
シリーズ全体の構成選定ガイド
5 回にわたるシリーズの知見を踏まえ、Iceberg データレイクハウスを構築する際の構成選定フローを整理します。
ストレージの選択
| 運用チームの体制 | 推奨 |
|---|---|
| 専任チームあり | 汎用 S3 + Glue Optimizer（コスト最優先なら Athena） |
| チームが小さい | S3 Tables（自動メンテナンス） |
| 新規プロジェクト | S3 Tables を推奨（高頻度書き込みは従来構成も検討） |
データ取り込みの選択
| 取り込み方式 | 推奨 |
|---|---|
| バッチ | Glue ETL |
| ストリーミング（CDC あり） | DMS + KDS + Firehose |
| ストリーミング（CDC なし） | KDS + Firehose |
| 外部カタログ統合 | カタログフェデレーション |
エンジンの選択
| 主なワークロード | 推奨 |
|---|---|
| アドホック分析 | Athena |
| BI ダッシュボード | Redshift Serverless |
| 大規模 ETL / ML | EMR Spark |
| 定期バッチ | Glue ETL |
アクセス制御の選択
| アクセス制御の粒度 | 推奨 |
|---|---|
| バケット / プレフィックス単位 | IAM ポリシー |
| テーブル / 列 / 行レベル（既存環境あり） | Lake Formation（ハイブリッドモードで段階移行） |
| テーブル / 列 / 行レベル（新規） | Lake Formation |
| クロスアカウント共有 | Lake Formation + Resource Link |
まとめ
S3 Tables と SageMaker Lakehouse は、Iceberg データレイクの「次のステップ」です。本記事のポイントを整理します。
- S3 Tables: Iceberg ネイティブの Table Bucket でテーブルメンテナンスが完全自動化。クエリスループット 3 倍・TPS 10 倍の性能向上。ただしストレージ単価は約 15% 高く、コンパクション費用にも注意が必要
- SageMaker Lakehouse: S3 データレイクと Redshift DWH を Iceberg で統合する設計パターン。Unified Studio による一元管理とクロスアカウントガバナンスが強み
- 移行: 既存環境は新規テーブルから段階的に S3 Tables を導入するのが安全。インプレース移行機能はない
- コスト: 新規プロジェクトや読み取り中心のワークロードでは S3 Tables が有利。頻繁なスモールファイル書き込みには従来構成 + EMR の方がコスト効率が良い場合もある
Iceberg シリーズ全体の到達点
5 回にわたって解説してきた AWS Iceberg シリーズを振り返ります。
| 記事 | テーマ | 到達点 |
|---|---|---|
| 第 1 弾 | Athena で始める Iceberg | Iceberg の基本操作とメダリオンアーキテクチャ |
| 第 2 弾 | 運用コスト最適化 | コンパクション・VACUUM・スナップショット管理 |
| 第 3 弾 | Data Firehose × CDC | ストリーミング取り込みパイプライン |
| 第 4 弾 | Lake Formation × マルチエンジン | アクセス制御・エンジン連携・メンテナンス自動化 |
| 第 5 弾 | S3 Tables × SageMaker Lakehouse | Iceberg ネイティブストレージと統合管理基盤 |
第 1 弾で Iceberg テーブルを Athena で作成するところから始まり、第 5 弾で S3 が Iceberg をネイティブサポートするまで到達しました。Iceberg がデータレイクの「テーブルフォーマット」から AWS のデータ基盤全体を貫く「共通言語」へと進化していることが、このシリーズを通じて見えてきたのではないでしょうか。
Iceberg シリーズ:
- Apache Iceberg 実践入門 — Athena で始めるモダンデータレイクの設計と運用
- Iceberg テーブルの運用コスト最適化 — コンパクション・メンテナンス・ストレージ戦略
- Iceberg × Data Firehose ストリーミング取り込み — CDC パイプラインとコンパクション戦略
- Iceberg データレイクハウスの高度な設計 — Lake Formation・マルチエンジン連携・本番運用
- S3 Tables と SageMaker Lakehouse で進化する Iceberg データレイク — 自動最適化とコスト分析 ← 本記事