S3 Tablesレプリケーション×Intelligent-Tiering本番運用

1. この記事について

1-1. 本記事のゴール

本記事は「AWS Data Analytics 本番運用」シリーズのVol3として、すでに稼働しているS3 Tables(Icebergデータレイク)を対象に、「複数リージョン/アカウントへ読取専用レプリカを配置する」「アクセスパターンに応じてストレージコストを自動最適化する」という2つの運用課題を解決します。2025-12にGAしたS3 Tables レプリケーションとS3 Tables Intelligent-Tieringという2つの新機能を軸に、単一リージョン運用からマルチリージョン運用への発展を扱う点が本Volの主眼です。

第一の柱であるS3 Tables レプリケーションは、ソースのテーブルバケットに対する全ての更新を時系列で複製し、別リージョンまたは別アカウントに読取専用レプリカを作成する仕組みです。レプリカ側はソース側のsnapshotとparent-child関係を保持したまま分単位で同期され、暗号化設定や保持ポリシーはソースとは独立して設定できます。本記事では、この独立設定が可能な範囲と、読取専用という制約が分析ワークロードの設計にどう影響するかを整理します。

第二の柱であるS3 Tables Intelligent-Tieringは、テーブルバケットのアクセスパターンに応じて自動的にストレージクラスを切り替える、テーブルバケット専用の新ストレージクラスです。名称は通常のS3オブジェクト向けIntelligent-Tiering(Storage本番運用Vol2で解説済み)と似ていますが、対象がテーブルバケット(Icebergテーブルのデータ/メタデータ)に限定される点で別物です。本記事ではこの違いを明確に切り分けたうえで、マルチリージョン構成におけるコスト最適化への寄与を扱います。

両機能はいずれも2025-12にGAし、S3 Tablesが対応する全リージョン(東京含む)で利用できます。2026-05にはさらに2リージョンが追加され、対応範囲は拡大を続けています。本記事ではこの2機能を組み合わせ、Athena/EMR/Glueなどの分析ワークロードを各リージョンのレプリカから参照する構成、DR(災害復旧)を見据えたレプリカ配置、そして低アクセステーブルへのTiering適用によるコスト最適化という3つの観点から、マルチリージョンIcebergデータレイクの設計パターンを扱います。

本記事は、Data Analytics Vol1(Athena/Glue/Lake Formation/Redshift Serverless)・Vol2(Kinesis/MSK/QuickSight/EMR Serverless)で構築した分析基盤を前提に、その置き場所であるS3 Tablesをマルチリージョンへ拡張する内容です。Vol1/Vol2で扱った分析エンジン自体の設定には立ち入らず、あくまでデータの配置とコストという観点からVol3を位置づけます。

なお、本記事のコード例・設定例はすべて教育目的のサンプルです。プロダクション環境で適用する際は、クロスアカウントIAMロール・KMS暗号化・レプリカ側のアクセス制御・監視体制の整備を必ず検討してください。

2機能の比較

S3 Tables レプリケーションとS3 Tables Intelligent-Tieringは、いずれも「マルチリージョン運用を見据えたS3 Tables拡張機能」という共通点を持ちますが、解決する課題は異なります。全体像を以下の表に整理します。

この比較からもわかる通り、レプリケーションは「配置場所」、Intelligent-Tieringは「保存コスト」という別の軸の課題にそれぞれ対応します。マルチリージョン構成では、複製先の各リージョンにもIntelligent-Tieringを個別に適用できるため、両機能を組み合わせることで初めて「どこに置くか」と「いくらで持つか」の両方を最適化できます。

想定するユースケース

レプリケーションとIntelligent-Tieringを組み合わせることで、次のようなユースケースに対応できます。

• 分析基盤のグローバル展開 — 各リージョンのレプリカをAthena/EMR Serverless/Glueから直接参照し、リージョンをまたぐデータ転送を発生させずに分析クエリを実行します
• DR(災害復旧)対応 — ソースリージョン障害時に、別リージョンの読取専用レプリカを参照してデータ分析を継続します(書込はソース復旧後に再開します)
• クロスアカウントでのデータ共有 — 分析チームが所属する別アカウントに読取専用レプリカを配置し、ソース側のIAM権限を渡さずにデータを共有します
• コスト最適化 — 頻繁にアクセスされないレプリカや履歴用テーブルにIntelligent-Tieringを適用し、ストレージコストを自動的に抑制します

対象外とする範囲

本記事はS3 Tablesの新機能(レプリケーション/Intelligent-Tiering)とマルチリージョン設計に焦点を絞るため、以下は対象外とします。

• S3 Tables基礎(Table Bucket作成・Icebergメタデータ・snapshot・partition/schema evolution・compaction) — Storage本番運用Vol3 §3で実装レベルまで解説済みのため、本記事では前提知識として扱います
• 通常のS3オブジェクト向けIntelligent-Tiering(Storage本番運用Vol2) — 対象・課金モデルが異なるため本記事の範囲外です
• Athena/EMR Serverless/Glue自体の詳細な設定(Data Analytics Vol1/Vol2で解説済み) — 本記事ではレプリカ参照時の構成観点のみ扱います

本記事の構成は、§3でレプリケーション、§4でIntelligent-Tieringをそれぞれ独立して扱い、§5で両機能を組み合わせたマルチリージョン設計、§6で共通の詰まりポイントとアンチパターンを整理し、§7でシリーズ全体のクロスリンクとともにまとめます。

1-2. 読者像

本記事の対象読者は、すでにS3 Tables(Icebergデータレイク)を本番運用しており、複数リージョン/アカウントへの拡張・可用性向上・ストレージコスト最適化のいずれかに直面しているデータエンジニア・アナリティクス基盤担当です。

たとえば、単一リージョンで運用しているS3 Tablesデータレイクを別リージョンにも展開してDRやレイテンシ改善を図りたい方、複数アカウントにまたがる分析基盤で共通のIcebergテーブルを参照したい方、アクセス頻度の低いテーブルのストレージコストを見直したい方が該当します。

S3 Tablesの基本操作(Table Bucket作成・Icebergテーブルへの読み書き)とTerraformでのAWSリソース管理経験があれば、本記事の内容を実践できます。Storage本番運用Vol3 §3の知識があるとより理解が深まりますが、S3 Tablesを運用した経験があれば必須ではありません。

本記事が特に役立つ場面は、分析基盤のグローバル展開を検討している場面、既存のS3 Tables運用でストレージコストの増加が気になり始めた場面、そしてクロスアカウントでのデータ共有基盤を設計している場面です。

本記事の読み方

レプリケーション中心に知りたい場合は§3から、Intelligent-Tiering中心に知りたい場合は§4から読み進めても問題ありません。マルチリージョン設計全体を検討している場合は、§2で両機能の前提を確認したうえで§5に進むことを推奨します。

本記事で使用する検証環境

本記事のコード例は、東京リージョンをソース、別リージョン(例: 大阪または米国リージョン)を宛先としたS3 Tablesレプリケーション構成と、そこにIntelligent-Tieringを適用した構成を検証環境として想定しています。ソース側のTable Bucket・Icebergテーブルは、Storage本番運用Vol3 §3の手順に沿ってあらかじめ作成済みであることを前提とします。

レプリカ作成にはソースと宛先の双方でクロスアカウントIAM権限が必要になる場合があります。検証は本番相当のテーブルバケットではなく、同一構成の非本番環境で行うことを推奨します。

1-3. なぜ今これを書くか

本記事を執筆する動機は、S3 Tables レプリケーションとIntelligent-Tieringがいずれも2025-12にGAした新機能でありながら、既存のStorage本番運用Vol3 §3(S3 Tables基礎)ではカバーされておらず、マルチリージョン運用という観点でS3 Tablesを扱った記事が見当たらなかったことです。

S3 Tablesは2025-01に東京リージョンへ対応し、以後analytics基盤としての採用が進みましたが、単一リージョン運用を前提とした情報が中心でした。2025-12のレプリケーション・Intelligent-Tiering GAにより、複数リージョン/アカウントにまたがるIcebergデータレイクの設計が現実的な選択肢になった一方、2つの新機能を組み合わせた実務的な設計指針はまだ整理されていません。

Intelligent-Tieringについても、通常のS3オブジェクト向けIntelligent-Tiering(Storage本番運用Vol2で解説済み)と名称が酷似しているため混同されるケースが想定されます。本記事ではこの違いを§2で明確に切り分けて解説します。

また、レプリケーション設定やIntelligent-Tiering有効化に関するTerraform(hashicorp/awsプロバイダー)・AWS CLIの対応状況は、GA直後ということもあり変更が生じやすい領域です。本記事では執筆時点(2026年7月)で確認できた対応状況を§2以降に明記し、今後のプロバイダーアップデートで変わりうる点は注記します。

S3 Tables 新機能に関する公式発表タイムライン

本記事はこれらの発表内容のうち、本記事執筆時点(2026年7月)で一般提供済みの機能のみを対象とします。

S3 Tables基礎(Table Bucket・Iceberg)はStorage本番運用 Vol3で解説

2. 前提・環境・S3 Tables新機能の概要

2-1. 前提環境と S3 Tables 基礎の位置づけ(委譲)

本記事は、S3 Tables(Table Bucket・Icebergテーブル)がすでに本番稼働していることを前提とします。Table Bucketの作成方法、Icebergメタデータ(manifest・snapshot)の構造、Partition Evolution・Schema Evolution、compactionの仕組みといったS3 Tables基礎は、Storage本番運用Vol3 §3で実装レベルまで解説済みのため、本記事では再解説しません。基礎から確認したい場合は、まずそちらを参照してください。

本記事で前提とする検証環境の構成は次のとおりです。

IAMについては、レプリケーションが「S3 Tablesサービスがユーザーに代わってソースからデータを読み取り、宛先に書き込む」という代行動作であるため、通常の分析用ロールとは権限の性質が異なります。詳細は§3-1で扱いますが、ソース側の読み取り権限と宛先側の書き込み権限を同一ロールにまとめて付与する点が設計上のポイントです。

着手前の前提チェックリスト

本記事の手順を実際の環境で試す前に、以下の項目を確認しておくと手戻りを防げます。

• ソース側Table Bucketとテーブルが作成済みで、Icebergテーブルへの読み書き経験がある(Storage本番運用Vol3 §3相当の理解がある)
• 宛先リージョン(またはアカウント)でS3 Tablesが利用可能であることを確認済み(2025-01時点で東京含む主要リージョン対応、2026-05にさらに対象拡大)
• クロスアカウント構成を検討している場合、宛先アカウントの管理者と事前に調整済み(バケットポリシー設定には宛先側の作業が必要)
• KMS暗号化を使う場合、ソース・宛先双方のKMSキー管理者が明確になっている
• レプリケーション/Intelligent-Tieringの追加コストについて、事前に概算コストを試算している(§2-2・§4-4参照)

本記事で使用する用語

複数の節にまたがって同じ用語を使い続けるため、ここで定義を揃えておきます。

2-1-2. アカウント構成パターン — 単一アカウントかクロスアカウントか

マルチリージョンIcebergデータレイクを設計する際、最初に決めるべきはアカウント構成です。単一アカウント内で完結させるか、分析チーム・パートナー企業など別アカウントにもデータを共有するかで、必要な設定が変わります。

本記事のコード例は、まず単一アカウント・クロスリージョンの構成を基本形として示し、クロスアカウントが必要な場合の追加設定を§3-2で個別に扱う構成にしています。自分の環境がどのパターンに該当するかを最初に把握したうえで、該当する節を中心に読み進めてください。

2-1-3. Table Bucket命名規則の推奨

マルチリージョン構成では、複数のTable Bucketをリージョン・アカウントをまたいで管理することになるため、命名規則を先に決めておくと運用が煩雑になりません。本記事のコード例では、次の命名パターンを採用しています。

リージョン名やアカウントIDをそのままバケット名に含めると、将来的に宛先を追加・変更した際に名前と実態が乖離しやすくなります。役割ベースの命名にしておき、実際のリージョン・アカウントの対応関係はIaC(Terraformのstate)やドキュメント側で管理する方が、長期運用では保守しやすい構成になります。

2-2. 2つの新機能の概要と課金

S3 Tables レプリケーションとS3 Tables Intelligent-Tieringは、いずれも2025-12にGAした新機能ですが、解決する課題も課金モデルも異なります。まず全体像を整理します。

課金面での注意点は、レプリケーションが「複製先でも通常のS3 Tablesストレージ料金がかかる」のに対し、Intelligent-Tieringは「階層化の仕組み自体には追加料金がなく、アクセスの少ないデータほど安い階層に自動移動することでトータルコストが下がる」という、性質の異なる課金モデルを持つ点です。両機能を組み合わせると、複製先のストレージ料金をIntelligent-Tieringで抑える、という設計が可能になります(詳細は§5)。

GA時期とリージョン展開が実務に与える影響

§1で触れたとおり、両機能は2025-12にGAし、2026-05にはS3 Tables対応リージョンがさらに2リージョン追加されています。実務上は、以下の2点を踏まえて設計判断をすることを推奨します。

• 新機能ゆえの段階的なリージョン対応: S3 Tables自体が対応していても、レプリケーション・Intelligent-Tieringが同時に全リージョンで使えるとは限りません。宛先候補のリージョンで両機能が利用可能かは、設計前に必ずAWSの公式リージョン対応表またはコンソール上で確認してください。
• エコシステム(Terraform・監視ツール等)の追随ラグ: GA直後はTerraformプロバイダーやサードパーティ監視ツールの対応が後追いになりがちです。本記事執筆時点(2026年7月)でHashiCorp/AWSプロバイダーはレプリケーション用リソースを提供済みですが、細部の属性は変更されうるため、IaC化する場合は事前に手元の環境で疎通確認することを強く推奨します。

通常のS3オブジェクト向けIntelligent-Tieringとの違い

S3 Tables Intelligent-Tieringは、名称が通常のS3オブジェクト向けIntelligent-Tiering(Storage本番運用Vol2で解説済み)と酷似しているため、混同しやすい機能です。両者の違いを明確にしておきます。

両者は「アクセスパターンに応じて自動階層化する」という思想は共通していますが、対象・適用方法・階層数が異なる別サービスです。本記事で単に「Intelligent-Tiering」と書く場合は、特に断りがない限りS3 Tables向けのものを指します。

料金試算の考え方

両機能を導入する際の概算コストは、次の観点で試算します。

1. レプリケーションによる追加ストレージ: 宛先ごとに、ソースと同等のデータ量が複製されるため、宛先の数だけS3 Tablesストレージ料金が加算されます。3リージョンに複製すれば、ストレージ料金は理論上ソースの4倍(ソース1+宛先3)になります。
2. レプリケーションのリクエスト・データ転送料金: 初期バックフィルおよび継続的な差分同期に伴うリクエスト料金と、クロスリージョン/クロスアカウントのデータ転送料金が発生します。
3. Intelligent-Tieringによる削減効果: 宛先レプリカにIntelligent-Tieringを適用すると、30日アクセスなしでInfrequent Access、90日アクセスなしでArchive Instant Accessへ自動移行し、ストレージ単価が段階的に下がります。DR用の待機系レプリカのように、普段は参照されないものの緊急時には必須となるデータで、この効果は大きくなります。

このように、レプリケーションはストレージコストを増やす方向に働き、Intelligent-Tieringはそれを相殺する方向に働きます。DR目的でレプリカを持つ場合は、レプリカ側にIntelligent-Tieringを適用することがコスト設計上ほぼ必須の組み合わせになります(§5で具体的な設計パターンを扱います)。

試算イメージ(数値は説明用の仮定値)

具体的なイメージを持つために、仮の数値で試算の流れを示します。実際の料金は必ず最新のAWS料金ページで確認してください。

この場合、DR宛先はほとんどの期間90日超アクセスのない状態が続くため、Intelligent-Tiering適用によりArchive Instant Access階層に移行し、S3 Standard相当で保持し続けるより大幅にストレージ単価を下げられる見込みです。一方、データ共有宛先は週次アクセスがあるため大部分はFrequent Accessに留まり、Intelligent-Tieringによる削減効果はDR宛先ほど大きくありません。このように、宛先ごとのアクセス頻度を見積もったうえでIntelligent-Tiering適用の効果を判断することが、コスト設計の基本になります。

2-2-2. 検証手順とツールの使い分け(全体像)

§3・§4では、AWS CLIを主軸に手順を示します。CLIを使う理由は、レプリケーション設定に含まれるIAMロール作成・トラストポリシー・宛先バケットポリシー・KMSキーポリシーといった複数リソースの依存関係を、コマンド単位で明示的に確認しながら進められるためです。Terraformでの管理を前提とする場合の対応状況は各節末に「Terraform対応状況」として示しますが、GA直後の新機能であるため、実際の属性名・スキーマは必ず最新のプロバイダードキュメントで確認してください。

いずれの手順もAWS CLIの最新バージョンを前提としています。s3tables サブコマンド群は比較的新しいAPI体系のため、手元のCLIバージョンが古いためにコマンド未対応となることがあります。事前に aws s3tables help でサブコマンドの有無を確認してください。

# CLIバージョンとs3tablesサブコマンドの存在確認
aws --version
aws s3tables help | head -20

CLIのバージョンが古くコマンド未対応の場合は、aws configure で使用しているプロファイルのCLIを最新化してから作業を進めてください。設定投入前にこの確認を挟んでおくと、手順の途中で「コマンドが存在しない」というつまずきを防げます。

なお、クロスアカウント構成を検証する場合は、ソース側・宛先側それぞれのAWSプロファイルを --profile オプションで明示的に切り替えながらコマンドを実行することを推奨します。同一ターミナルセッション内で意図せず片方のアカウントの認証情報のまま操作してしまうと、権限エラーの原因特定に時間がかかるためです。

2-3. ゴール状態の定義

想定シナリオ

具体的にイメージしやすいよう、東京リージョンでECサイトの購買データをS3 Tables(Icebergデータレイク)として蓄積・分析している組織を想定します。この組織が抱える課題は、(1) 東京リージョンの障害時にも分析業務を止めたくない、(2) 海外拠点の分析チームにも同じデータを低レイテンシで参照させたい、(3) 過去データを長期保持したいがストレージコストは抑えたい、という3点です。これらはいずれも単一リージョン・単一アカウントのS3 Tables運用だけでは解決できず、レプリケーションとIntelligent-Tieringの組み合わせが必要になります。

本記事が到達点とするマルチリージョンIcebergデータレイクの完成状態は、このシナリオを踏まえた次の3条件を満たす構成です。

1. 配置: 東京リージョンのソースTable Bucketに対して、別リージョン(および必要に応じて別アカウント)に読取専用レプリカが構成されており、各リージョンの分析ワークロード(Athena/EMR Serverless/Glue)がリージョンをまたぐデータ転送なしにレプリカを直接参照できる状態
2. コスト: 複製先のレプリカのうち、アクセス頻度の低いテーブル(DR用の待機系や、履歴分析用の低頻度参照テーブル)にIntelligent-Tieringが適用され、ストレージコストが自動的に最適化されている状態
3. 運用: レプリケーションの同期状況(ステータス・最終同期メタデータ)とIntelligent-Tieringの階層分布(CUR経由)が監視され、障害時の切り替え手順(DR)が明文化されている状態

§3でレプリケーション単体の設定、§4でIntelligent-Tiering単体の設定を扱ったうえで、§5でこの3条件を満たすマルチリージョン設計へと組み立てます。

fig02は、この最終形の全体像を示しています。東京リージョンのソースTable Bucketを起点に、DR用の宛先リージョンと分析共有用のクロスアカウント宛先の2系統へレプリケーションが構成され、各宛先にはIntelligent-Tieringが適用されている構成です。ソース側はAthena/EMR Serverlessから通常どおり読み書きされ、各宛先のレプリカは、それぞれのリージョン/アカウントの分析ワークロードから読取専用で参照されます。

Before / After

単一リージョン運用からこのゴール状態に至ることで、想定シナリオの3つの課題がどう解決されるかを整理します。

ゴール状態チェックリスト

このBefore/Afterの差分を実現するために必要な設定・設計判断を、確認項目としてリスト化しておきます。§5まで読み終えた時点で、以下がすべて説明できる状態を目指します。

本節のまとめ

本節では、S3 Tables基礎(Storage本番運用Vol3 §3への委譲)を前提としたうえで、レプリケーションとIntelligent-Tieringという2つの新機能の違いを課金モデルの観点から整理し、両者を組み合わせたマルチリージョンIcebergデータレイクのゴール状態を、ECサイトの想定シナリオに沿って定義しました。ここで整理した用語・アカウント構成パターン・ゴール状態チェックリストは、§3以降の設定手順を読み進める際の共通の地図として使用します。次節からは、まずレプリケーション単体の設定に入ります。

3. S3 Tables レプリケーション — クロスリージョン/クロスアカウント

S3 Tables レプリケーションは、ソースのTable Bucket(またはテーブル単位)に対する更新を、同一アカウント内の別リージョン、または別アカウントの宛先Table Bucketへ自動的に複製する機能です。宛先には最大5つまで指定でき、複製はソース側の更新順序を保ったまま、通常は分単位で反映されます。

3-1. IAMロールと権限設計

レプリケーションの設定には、S3 Tablesサービスがユーザーに代わって読み書きするための専用IAMロールが必要です。設定するIAM ID自身にも、以下の権限が必要になります。

レプリケーションロール自体は、replication.s3tables.amazonaws.com を信頼するトラストポリシーを持ちます。

{
  "Version": "2012-10-17",
  "Statement": [
 {
"Effect": "Allow",
"Principal": {
  "Service": "replication.s3tables.amazonaws.com"
},
"Action": "sts:AssumeRole"
 }
  ]
}

このロールには、ソース側の読み取り権限として s3tables:GetTable / GetTableMetadataLocation / GetTableMaintenanceConfiguration / GetTableData / ListTables を、対象テーブルのARNを絞ったうえで付与します。あわせて宛先側の作成・書き込み権限として s3tables:CreateTable / CreateNamespace / PutTableData / GetTableData / UpdateTableMetadataLocation / PutTableMaintenanceConfiguration を、宛先バケットのARNを絞ったうえで付与します。KMS暗号化を使う場合は、ソース側で kms:Decrypt / kms:GenerateDataKey、宛先側で kms:Decrypt / kms:GenerateDataKey / kms:Encrypt をこのロールに追加します。

3-2. クロスアカウント設定 — 宛先バケットポリシーとKMSキーポリシー

宛先が別アカウントの場合、ソース側のロール設定だけでは不十分です。宛先アカウント側で、ソースアカウントのレプリケーションロールを許可するバケットポリシーを、宛先Table Bucketに設定する必要があります。

{
  "Version": "2012-10-17",
  "Statement": [
 {
"Effect": "Allow",
"Principal": {
  "AWS": "arn:aws:iam::{{ソースアカウントID}}:role/{{S3TablesReplicationRole}}"
},
"Action": [
  "s3tables:PutTableData",
  "s3tables:GetTableData",
  "s3tables:UpdateTableMetadataLocation",
  "s3tables:PutTableMaintenanceConfiguration"
],
"Resource": "arn:aws:s3tables:{{宛先リージョン}}:{{宛先アカウントID}}:bucket/{{宛先バケット名}}/table/*"
 },
 {
"Effect": "Allow",
"Principal": {
  "AWS": "arn:aws:iam::{{ソースアカウントID}}:role/{{S3TablesReplicationRole}}"
},
"Action": ["s3tables:CreateTable", "s3tables:CreateNamespace"],
"Resource": "arn:aws:s3tables:{{宛先リージョン}}:{{宛先アカウントID}}:bucket/{{宛先バケット名}}"
 }
  ]
}

このポリシーは宛先アカウント側で put-table-bucket-policy により適用します。KMS暗号化を使う場合は、ソース側KMSキーポリシーでレプリケーションロールに Decrypt/GenerateDataKey を、宛先側KMSキーポリシーで Encrypt/Decrypt/GenerateDataKey をそれぞれ許可します。ソース・宛先で異なるKMSキーを使えるため、リージョンごとに鍵管理ポリシーを分離できます。

3-3. レプリケーション設定 — バケットレベル/テーブルレベル

レプリケーションはTable Bucket単位(バケット内の全テーブルが対象)、またはテーブル単位(特定テーブルのみ)のいずれかで設定します。両方が設定されている場合、テーブル単位の設定がバケット単位の設定より優先されます。

バケット単位でクロスリージョン複製(同一アカウント内)を設定する例です。

aws s3tables put-table-bucket-replication \
  --table-bucket-arn arn:aws:s3tables:ap-northeast-1:{{アカウントID}}:bucket/prod-analytics-source \
  --configuration file://bucket-replication-config.json

{
  "role": "arn:aws:iam::{{アカウントID}}:role/S3TablesReplicationRole",
  "rules": [
 {
"destinations": [
  { "destinationTableBucketARN": "arn:aws:s3tables:ap-northeast-3:{{アカウントID}}:bucket/prod-analytics-dr" }
]
 }
  ]
}

特定テーブルのみをクロスアカウントで複製したい場合は、テーブル単位のAPIを使います。

aws s3tables put-table-replication \
  --table-arn arn:aws:s3tables:ap-northeast-1:{{ソースアカウントID}}:bucket/prod-analytics-source/table/sales-data \
  --configuration file://table-replication-config.json

実行に成功すると versionToken を含むレスポンスが返り、これは以降の設定更新時の競合防止トークンとして使われます。設定後はS3コンソールの「Table replication status」から、宛先ごとの複製状況・最終複製メタデータを確認できます。初回設定時はソーステーブルの既存データ全体を対象とした初期バックフィルが走るため、テーブルサイズによっては同期完了までに時間がかかる点に注意してください。

Terraform対応状況(要確認込み)

HashiCorp/AWSプロバイダーは、S3 Tablesレプリケーションのローンチと同時に aws_s3tables_table_bucket_replication(バケット単位)と aws_s3tables_table_replication(テーブル単位)の2リソースを提供しています。IAMロール・トラストポリシー・宛先ARNの組み合わせは、本節のCLI例と同じ構造(ロールARN・宛先Table Bucket ARNのリスト)で記述できますが、属性名や rule ブロックの正確な構文は執筆時点でプロバイダーのマイナーバージョンアップにより変わる可能性があるため、実装時は最新のTerraform Registryドキュメントで属性名を必ず確認してください(★要確認)。

3-4. 読取専用レプリカの制約と運用上の注意

レプリカは読み取り専用です。レプリカ側のテーブルに直接書き込むことはできません。DR構成でソースリージョン障害時にレプリカを使って分析を継続する場合でも、書き込みが必要な処理はソース復旧後に再開するよう設計しておく必要があります。

スナップショットの保持期間は、ソースとレプリカで独立して設定できます。たとえばソース側は30日保持、レプリカ側は90日保持といった設定が可能で、ソース側で失効したスナップショットもレプリカ側でまだ有効であれば、レプリカ経由でタイムトラベルクエリを実行できます。暗号化設定(KMSキー)も同様にソースと独立して指定できるため、リージョンごとに異なる鍵管理ポリシーを適用する構成が可能です。

監視の観点では、レプリケーションの遅延や失敗を検知する仕組みが必須です。S3コンソールの複製ステータス表示に加えて、Amazon CloudWatchのメトリクスやAWS Cost and Usage Reportsと組み合わせ、複製が正常に進んでいるか、また複製先ストレージが想定コストで推移しているかを定期的に確認する運用を組み込んでください。

4. S3 Tables Intelligent-Tiering — テーブルバケットの自動コスト最適化

S3 Tables Intelligent-Tieringは、テーブルバケット内のデータファイル(Icebergのデータ・メタデータファイル)を、アクセスパターンに応じて自動的に3つのアクセス階層間で移動させるストレージクラスです。階層移動によるパフォーマンス低下や取得課金は発生しません。

4-1. 3つのアクセス階層と移行条件

階層はファイル単位で管理されます。同一テーブル内でも、ファイルによって異なる階層に存在し得ます。

いずれの階層もミリ秒レイテンシ・高スループット・99.9%可用性・99.999999999%耐久性という点では同一です。「アクセスが少ないファイルほど安く保存されるが、いつでも即座に読み書きできる」という点が、Archive系ストレージクラス(取得に時間がかかるもの)とは異なります。

階層をFrequent Accessに戻す「アクセス」とみなされる操作は、テーブルデータ/メタデータファイルへの GetObject / PutObject / CompleteMultipartUpload、Iceberg REST APIの LoadTable / UpdateTable、そしてS3 Tablesレプリケーションの複製操作です。これら以外の操作(メタデータの一覧取得など)は階層移動のトリガーになりません。また128KB未満の小さなファイルは自動階層化の対象外で、常にFrequent Accessに留まります。compactionでこれらの小ファイルが結合され128KB以上になると、新しいファイルとして自動階層化の対象になります。

4-2. compaction・メンテナンスへの影響

S3 Tablesの自動メンテナンス(スナップショット管理・不参照ファイル削除・レコード有効期限管理)は、階層に関わらずすべてのファイルに対して実行され続けます。ただし、compactionはFrequent Access階層のファイルのみを対象とします。これは、頻繁にアクセスされるデータのパフォーマンスを優先しつつ、低頻度階層のデータに対する不要なメンテナンスコストを抑えるためです。

注意点として、Infrequent Access/Archive Instant Access階層にあるデータに対して削除操作を行うと、削除ファイル(delete file)が生成されますが、これはcompactionの対象外のままです。関連するデータファイルがアクセスされてFrequent Access階層に戻ったタイミングで、初めてcompaction対象になります。長期間アクセスされないテーブルでこの削除ファイルが蓄積している場合は、Amazon EMRを使った手動compactionを検討し、CloudWatchメトリクスでファイル増加を監視してください。

4-3. 有効化方法 — テーブル作成時指定 / バケットのデフォルト設定

Intelligent-Tieringの最大の運用上の制約は、テーブル作成後にストレージクラスを変更できない点です。すべてのテーブルはデフォルトのS3 Standardストレージクラスで作成され、Intelligent-Tieringを使うにはテーブル作成時に明示的に指定する必要があります。既存のS3 Standardテーブルを後からIntelligent-Tieringへ切り替える操作はサポートされていません。

有効化には2つの方法があります。

1. テーブル単位で指定 — CreateTable API呼び出し時に storage-class-configuration ヘッダーでIntelligent-Tieringを指定します。
2. Table Bucketのデフォルトとして設定 — Table Bucket側にIntelligent-Tieringをデフォルトストレージクラスとして設定しておくと、そのバケットで以後作成される新規テーブルは、個別指定がない限り自動的にIntelligent-Tieringで作成されます。既存テーブルのストレージクラスには影響しません。

# 新規Table Bucket作成時にデフォルトストレージクラスをIntelligent-Tieringに設定
aws s3tables create-table-bucket \
  --name prod-analytics-dr \
  --region ap-northeast-3 \
  --storage-class-configuration '{"storageClass":"INTELLIGENT_TIERING"}'

# 既存Table Bucketのデフォルトストレージクラスを確認・変更
aws s3tables get-table-bucket-storage-class \
  --table-bucket-arn arn:aws:s3tables:ap-northeast-3:{{アカウントID}}:bucket/prod-analytics-dr

aws s3tables put-table-bucket-storage-class \
  --table-bucket-arn arn:aws:s3tables:ap-northeast-3:{{アカウントID}}:bucket/prod-analytics-dr \
  --storage-class-configuration '{"storageClass":"INTELLIGENT_TIERING"}'

レプリカ用のTable Bucketは、DRや低頻度参照を目的に作成されるケースが多いため、作成時点でIntelligent-Tieringをデフォルト化しておくと、レプリケーションで新規作成される全レプリカテーブルに自動適用され、個別テーブルごとの設定漏れを防げます(§5で具体的な組み合わせ設計を扱います)。

4-4. 課金モデルとモニタリング

Intelligent-Tiering自体の設定・監視には追加課金がありません(通常のS3オブジェクト向けIntelligent-Tieringにある月額監視課金は、S3 Tables版には存在しません)。課金は各階層のストレージ従量課金とリクエスト課金のみです。

これらはAWS Cost and Usage Reports(CUR)から日次で確認できます。階層ごとの使用量を定期的に確認し、想定どおりInfrequent/Archive Instantへの移行が進んでいるかを確認します。想定に反してたびたびアクセスされFrequent Access階層から動かないテーブルがないかもあわせて監視し、コスト最適化の効果を確認します。

5. マルチリージョンIcebergデータレイク設計

S3 Tables レプリケーション(§3)とIntelligent-Tiering(§4)を単体で扱った前節までに対し、本節はこの両機能を組み合わせます。目的は、§2-3で定義したゴール状態(配置・コスト・運用の3条件)を満たすマルチリージョンIcebergデータレイクとして設計を組み立てることです。§3・§4が個別機能の設定手順を扱ったのに対し、本節は「読取専用レプリカを分析基盤としてどこにどう配置するか」という設計判断に焦点を当てます。

5-1. 設計の全体像 — 配置とコストを同時に決める

マルチリージョンIcebergデータレイクの設計は、次の2つの問いへの回答に集約されます。1つ目は「どのリージョン/アカウントに読取専用レプリカを配置するか」という配置の問い、2つ目は「配置したレプリカのうち、どれにIntelligent-Tieringを適用するか」というコストの問いです。

この2軸は独立に決められるものではありません。たとえばDR専用に配置したレプリカは、平常時はほとんどアクセスされないため、配置を決めた時点でIntelligent-Tieringの適用もあわせて決定しておくべきです。逆に、海外拠点の分析チームが日常的に参照するレプリカは、Frequent Access階層に留まり続けることを見込んだうえで配置する必要があります。本節では、想定シナリオ(§2-3)の3つの用途——DR・低レイテンシ分析共有・長期保持コスト最適化——ごとに、この2軸をどう組み合わせるかを具体的に扱います。

5-2. 分析ワークロードのリージョン配置 — Athena/EMR Serverless/Glueからのレプリカ参照

各リージョンの分析ワークロード(Athena/EMR Serverless/Glue)は、そのリージョンに配置された読取専用レプリカのTable Bucketを直接参照するように構成します。Data Analytics Vol1・Vol2で扱ったAthena/EMR Serverless/Glue自体の設定は変わらず、参照先のTable Bucket ARNをソースではなくレプリカのものに切り替えるだけで、同一リージョン内で完結するクエリ実行が可能になります。

ポイントは、レプリカが読取専用であるという§3-4の制約を、分析ワークロードの設計段階で明示的に前提とすることです。書き込みを伴う処理(ETLの出力・ユーザーによる更新クエリ)は必ずソース側で実行し、レプリカ側はあくまで参照専用の分析エンドポイントとして位置づけます。

5-3. DR構成の設計パターン

DR(災害復旧)を目的とする場合、宛先リージョンは地理的にソースから離れたリージョンを選び、平常時は分析ワークロードから参照しない「待機系」として配置するのが基本パターンです。

• ソースリージョン障害を検知した場合、分析基盤(Athena/EMR Serverlessの接続先設定)をDR宛先のレプリカへ切り替えます。切り替え自体はカタログ登録の変更で完結し、データそのものの移動は発生しません
• 書き込みを伴う処理(ETL・バッチ更新)は、ソースリージョンが復旧するまで一時停止します。DR宛先はあくまで読取専用の代替エンドポイントであり、書き込み系の障害復旧手段ではありません
• スナップショット保持期間(§3-4)は、DR宛先側を長めに設定しておくと、ソース側で失効した過去スナップショットへのタイムトラベルクエリがDR宛先経由で実行できる場合があります

DR宛先は平常時ほとんどアクセスされないため、Intelligent-Tieringのバケットデフォルト化(§4-3)を作成時点で必ず行っておきます。こうしておくことで、DR宛先にレプリケーションされる全テーブルが自動的にInfrequent Access/Archive Instant Access階層へ移行し、平常時のストレージコストを抑えながら、いざという時には即座に(ミリ秒レイテンシで)参照できる状態を維持できます。

5-4. クロスアカウントでの低レイテンシ分析共有の設計パターン

海外拠点や別部門の分析チームにデータを共有する場合は、クロスアカウント・別リージョンの宛先を用意し、共有先チームが持つアカウントのAthena/EMR Serverlessから直接参照させる構成にします。DR宛先との違いは、こちらは平常時から継続的にアクセスされる「稼働系」の共有先であるという点です。

• ソース側のIAM権限を共有先チームに渡す必要がなく、レプリカに対する読み取り権限のみを共有先アカウントに付与します(§3-2のバケットポリシー設定)
• 共有先チームのクエリ頻度が高い場合、Intelligent-TieringのFrequent Access階層に留まり続けることを前提に設計し、無理にIntelligent-Tieringを適用してコスト削減効果を狙う必要はありません
• 共有先チームが独自にテーブル単位のレプリケーション追加・削除を必要とする場合は、テーブル単位レプリケーション(§3-3)を使い、バケット単位の全テーブル共有と切り分けます

DR宛先は、アクセス頻度が低い一方で可用性を重視します。これに対し、データ共有宛先はアクセス頻度が高く、分析レイテンシを重視します。この違いを踏まえ、宛先ごとにIntelligent-Tieringの適用方針を個別に判断することが、マルチリージョン設計における実務上のポイントです。

5-5. コスト最適化の組み合わせ設計 — どのレプリカにIntelligent-Tieringを適用するか

§2-2で整理したとおり、レプリケーションはストレージコストを増やす方向に、Intelligent-Tieringはそれを相殺する方向に働きます。宛先ごとの用途とアクセス頻度の見積もりに基づき、Intelligent-Tieringの適用要否を次の観点で判断します。

コスト最適化の設計で見落としやすいのは、レプリケーション自体の追加ストレージ・データ転送料金(§2-2)と、Intelligent-Tieringによる削減効果を、宛先ごとに個別に試算する必要がある点です。全宛先を一律に扱うのではなく、DR宛先・データ共有宛先・履歴分析宛先という用途区分ごとに、コストの増加要因(レプリケーション)と削減要因(Intelligent-Tiering)を対で評価してください。

5-6. Terraformでの管理方針(要確認事項の整理)

マルチリージョン構成をIaC化する場合、リージョン/アカウントごとに増えるTable Bucket・レプリケーション設定・IAMロール・バケットポリシーをTerraformのmoduleとして共通化しておくと、宛先追加時の作業量を抑えられます。§3-3で触れたとおり、aws_s3tables_table_bucket_replication / aws_s3tables_table_replication の2リソースは提供済みですが、ruleブロック内の属性名やネスト構造はGA直後のため変更されうる点に注意が必要です(★要確認)。moduleを設計する際は、宛先の追加・削除がリソースの再作成を伴わずに完結するか、実際のプロバイダーバージョンで事前に疎通確認することを推奨します。

Intelligent-Tieringについても同様に、Table Bucket作成時のstorage-class-configurationに相当するTerraform属性が、aws_s3tables_table_bucketリソースのどの引数に対応するかは、実装時に最新のTerraform Registryドキュメントで確認してください(★要確認)。CLIでの動作確認(§4-3)を先に済ませたうえで、Terraform化はその後の工程として位置づけることを推奨します。

本節のまとめ

本節では、S3 Tables レプリケーションとIntelligent-Tieringを組み合わせ、DR・クロスアカウントデータ共有・履歴分析という3つの用途区分ごとに、レプリカの配置方針とIntelligent-Tiering適用方針を整理しました。設計の要点は、宛先ごとにアクセス頻度の見込みが異なることを前提に、配置(§3)とコスト(§4)の2軸を個別に判断することです。次節では、ここまでの内容を踏まえた詰まりポイントとアンチパターンを整理します。

6. 詰まりポイント / アンチパターン

本節では、S3 Tables レプリケーション・Intelligent-Tieringの導入・運用時につまずきやすい点を、想定される原因とあわせて整理します。

6-1. レプリカへの書き込み試行(読取専用制約の誤認)

レプリカは読取専用です(§3-4)。分析チームがレプリカ経由でCTAS/INSERTを実行しようとしてエラーになるケースが典型的なつまずきです。原因の多くは、ソースとレプリカを同じ感覚で扱えるカタログ登録(§5-2)をしたまま、書き込みが必要なジョブの参照先を切り替え忘れていることにあります。対策は、ジョブ定義やドキュメント上でレプリカを明示的に「read-only」とラベリングし、書き込み系ジョブの参照先チェックをCI/CDやレビュー手順に組み込むことです。

6-2. スナップショット保持期間の独立設定による想定外の挙動

ソースとレプリカでスナップショット保持期間を独立設定できる(§3-4)ことが柔軟性である一方、両者の設定を揃えていると誤解したまま運用すると、「ソース側で失効済みのスナップショットに対し、レプリカ側ではまだ有効なままタイムトラベルクエリが通ってしまう」といった想定外の挙動に遭遇します。不具合ではなく、仕様どおりの独立設定の結果です。監査・コンプライアンス要件がある場合は、ソース・レプリカ双方の保持期間を明文化し、意図的に揃えるか差をつけるかをドキュメントに残しておく必要があります。

6-3. クロスアカウントIAM設定の片手落ち

クロスアカウント構成(§3-2)では、ソース側のレプリケーションロール設定だけで完結すると誤解し、宛先アカウント側のバケットポリシー設定を忘れるケースが多く見られます。この場合、レプリケーション自体はAccessDeniedエラーで失敗し、初回バックフィルが完了しません。宛先が別アカウントかどうかを§2-1-2のアカウント構成パターン表で最初に確認し、クロスアカウントに該当する場合は必ず宛先側の設定(バケットポリシー・必要に応じてKMSキーポリシー)がセットであることをチェックリスト化してください。

6-4. Intelligent-Tiering未適用による低頻度テーブルのコスト放置

Intelligent-Tieringはテーブル作成時にしか指定できません(§4-3)。DR宛先や履歴分析用のTable Bucketを作成する際にデフォルト化を忘れると、以後作成される全テーブルがS3 Standard相当のコストのまま放置され、後から気づいても既存テーブルへの後付け変更はできません。宛先Table Bucket作成の手順に、Intelligent-Tieringのデフォルト化(§4-3のコマンド例)を必須ステップとして組み込み、作成後にCURで階層分布(§4-4)を定期確認する運用にしておくことが実務上の対策です。

6-5. Delete File蓄積によるストレージ増加の見落とし

Infrequent Access/Archive Instant Access階層にあるデータへの削除操作はcompaction対象外のまま蓄積します(§4-2)。長期間アクセスされないテーブルでこの削除ファイルが積み上がっていることに気づかず、ストレージ使用量の増加要因を特定できないケースがあります。CloudWatchメトリクスでファイル数・ストレージ使用量の推移を監視し、不自然な増加が見られる場合はEMRによる手動compactionの実行を検討してください。

6-6. 通常S3 Intelligent-Tieringとの混同

名称の類似から、通常のS3オブジェクト向けIntelligent-Tiering(Storage本番運用Vol2)の感覚のまま、S3 Tables Intelligent-Tieringを既存テーブルに後付けしようとして「変更できない」ことに気づくケースが想定されます(§2-2)。両者は対象・適用方法・階層数のいずれも異なる別サービスである点を、設計ドキュメントやチーム内の用語集に明記し、混同を防いでください。

詰まりポイント一覧(早見表)

7. まとめ + シリーズクロスリンク

本記事では、2025-12にGAしたS3 Tables レプリケーションとIntelligent-Tieringという2つの新機能を軸に、単一リージョン運用のS3 Tables(Icebergデータレイク)をマルチリージョン構成へ拡張する設計を扱いました。

本記事はS3 Tables基礎(Table Bucket・Icebergメタデータ・snapshot・partition/schema evolution・compaction)を前提とし、それらの実装レベルの解説はStorage本番運用Vol3 §3に委譲しています。またS3 Tables Intelligent-Tieringは、対象・課金モデルの異なる通常のS3オブジェクト向けIntelligent-Tiering(Storage本番運用Vol2)とは別物である点を、本記事を通じて明確に切り分けました。マルチリージョン設計の土台となる分析基盤(Athena/Glue/Lake Formation/Redshift Serverless、Kinesis/MSK/QuickSight/EMR Serverless)自体の設定は、Data Analytics本番運用Vol1・Vol2で扱った内容がそのまま適用できます。

Storage本番運用 Vol3 — S3 Tables基礎(Table Bucket・Iceberg)を解説
Storage本番運用 Vol2 — S3オブジェクトのIntelligent-Tieringを解説
Data Analytics本番運用 Vol1 — Athena/Glue/Lake Formation/Redshift Serverless
Data Analytics本番運用 Vol2 — Kinesis/MSK/QuickSight/EMR Serverless

マルチリージョンIcebergデータレイクは、レプリケーションによる配置とIntelligent-Tieringによるコスト最適化という2つの新機能によって、単一リージョン運用の延長として現実的に構築できる段階に入りました。本記事のゴール状態(§2-3)と設計パターン(§5)を土台に、まずはDR用途など影響範囲を限定した構成から着手し、運用実績を積みながら宛先を拡張していくことを推奨します。