はじめに

AWS Community Builderのぺんぎん（@jitepengin）です。

データ基盤を構築する際に、AWSとSnowflakeのどちらに寄せるべきかという議論は今もよく見かけます。
Apache Icebergの普及によってデータとプラットフォームを切り離せるようになった今、この問いの立て方自体を見直す必要があるのではないかと考えています。
より本質的な問いは「データの主導権をどこに置くか」だと思っています。

今回の記事ではこの「主導権」を定義し、AWSとSnowflakeそれぞれに寄せた場合の構成とトレードオフを整理してみたいと思います。

なぜデータ主導権を考える必要があるか

Apache Icebergの普及により、プラットフォームとデータを切り離せるようになりました。
S3上のIcebergテーブルをAthenaでもSnowflakeでもそれ以外のツールでも読める今、プロダクトの選択よりも「データの管理責任をどう設計するか」の方が重要になっていると思います。
詳細は後述しますが、まずこの変化がなぜ重要かを整理します。

「主導権」を3層で定義する

今回の記事では「データの主導権」を以下の3層で定義します。

この3層を一貫して制御できて初めて「主導権を持つ」と言えます。
逆に、この3層が分散していたり曖昧になっていると、設計・運用・セキュリティのいずれかで混乱が起きやすくなったり、考慮事項が増えたりします。

ベンダロックインのリスク

Apache Icebergが普及した今でも、プラットフォームへの依存は形を変えて残ります。

• カタログ依存：Snowflake Open Catalogで管理したテーブルは、Open Catalog自体の管理がSnowflakeのサービスに依存した運用になります（REST Catalog APIを通じてSparkなど他エンジンからの操作は可能です）
• 書き込みエンジン依存：Snowflake-managed IcebergテーブルへのDMLはSnowflake経由が主体ですが、Horizon Catalog経由で外部エンジン（Spark等）からの書き込みもGAとなっています。ただし外部カタログ（Glue等）で管理するテーブルへの書き込みも含め、いずれの構成でも書き込みエンジンの選択はカタログ設計と密接に連動します
• ガバナンス依存：Lake Formationの細粒度制御はAWSエコシステム内でのみ完結します

「Icebergを使えばベンダロックインがなくなる」というのは正確ではなく、ストレージ形式のロックインは解消されますが、カタログ・書き込み・ガバナンスの各層で依存は残ります。
実際、データ基盤の移行などもありますが、権限含むガバナンス、履歴管理、各機能に依存したものなど移行に際して課題は多くある印象です。

拡張性と戦略的な選択肢

データ基盤は一度作ったら終わりではありません。
昨今のAIの急速な発展や、MDS（Modern Data Stack）の移り変わりなど様々なものに起因した変更が入ります。
実際に起きやすい変化をいくつか挙げると、以下のようなものがあります。

• 分析ツールの追加・変更：当初はAthenaだけで足りていたが、BI部門からSnowflakeでも見たいという要望が出てくる
• AIワークロードの追加：SageMakerやSnowflake Cortex AIとの連携が必要になる
• コスト最適化の要求：クエリ量が増えてSnowflakeのコンピュートコストが無視できなくなり、バッチ処理をEMRに切り出したくなる
• ガバナンス要件の強化：列レベルのマスキングや行アクセス制御を後から追加したくなる

3層の主導権が設計段階で明確になっていれば、こうした変化が起きたときの判断の起点が明確になります。
曖昧なまま構築が進むと、変化のたびにどこを変えればいいのかわからない状態に陥りやすくなります。

Iceberg以後に何が変わったか

以前はプラットフォームとデータが一体で、いわゆるベンダロックインが起きやすい構造でした。

Icebergはこれを変えたテーブルフォーマットです。

S3上のIcebergテーブル
 ↓ 同一データを参照
Athena / Glue / Snowflake / Spark / Redshift...

S3上のParquetファイルにメタデータ層を重ねることで、エンジン非依存でACIDトランザクションやスキーマ進化を実現します。
テーブルのメタデータ（どのファイルが有効か、スキーマは何か）を追跡するカタログが整合性を担保することで、複数エンジンからの同時アクセスが成立します。

データファイルは共有できるようになりました。
ただし、カタログ・書き込み・ガバナンスの主導権は設計によって変わります。
つまり、カタログを誰が管理するかが主導権の「カタログ管理権」に直結し、この3層をどう設計するかで「AWSに寄せる」「Snowflakeに寄せる」「組み合わせる」の判断が決まってきます。

Snowflakeに寄せる

構成の特徴

Snowflakeをカタログ・クエリエンジン・ガバナンスの中心に据え、データファイルだけをS3等の外部ストレージに置く構成です。
分析体験と運用シンプルさを優先する場合に向いていると思います。

3層の主導権

データファイルはS3等に残るため、外部エンジンからのIcebergアクセスには2つの経路があります。

• Open Catalog経由：Snowflake-managed IcebergテーブルをOpen CatalogにsyncしてREST Catalog APIで公開する方法です。このsyncシナリオでは外部エンジンからの操作は読み取り専用となります（Open Catalog自体をInternal catalogとして使う場合は読み書き可能です）
• Horizon Catalog経由：Open CatalogへのsyncなしにHorizon Iceberg REST Catalog APIで直接公開する方法です。外部エンジンからの読み取り・書き込みの両方が可能で、Snowflakeのユーザーやロールをそのままアクセス制御に利用できます

メリット

• Snowflake Horizonによるガバナンス（列マスキング・行アクセスポリシー）をネイティブテーブルと同様にIcebergにも適用でき、Horizon Catalog経由で外部エンジンからの読み取り時にも同じポリシーを適用できます。ただし、マスキングポリシーやタグが付いたテーブルへの外部エンジンからの書き込みはサポートされていないため注意が必要です
• Power BI等のBIツールへのネイティブコネクタが充実しており、分析フロントとして扱いやすいです
• Open CatalogまたはHorizon Catalogを通じて外部エンジンからもIcebergテーブルにアクセスでき、Snowflakeのユーザーやロールをそのままアクセス制御の単位として利用できます

デメリット

• Snowflakeのウェアハウスを使ったDMLは一般的にコンピュートコストが高めです。Horizon Catalog経由で外部エンジン（Spark等）が書き込む場合はSnowflakeのウェアハウスを使わないため別途コスト設計が必要ですが、Horizon Catalog自体のAPI呼び出しに対して0.5クレジット/100万コールの課金が発生します
• AWSサービス（Glue ETL等）からの書き込みとの整合性管理には、カタログ管理権を誰が持つかを明確にする必要があります

特にエンタープライズ環境や保守性を加味した設計だと、Snowflake内で閉じた運用を志向するケースも多く、Icebergを採用していても「実質的にはSnowflake中心のプラットフォーム」に収束することがあります。
Icebergで形式上のオープン性は確保されていても、カタログ・ガバナンス・書き込みがすべてSnowflakeに集約されれば、主導権の観点ではSnowflakeへの依存度は変わりません。

AWSに寄せる

構成の特徴

S3をデータの置き場とし、Glue Data CatalogをカタログとしてAWSサービス群でETL・分析・ガバナンスを完結させる構成です。
コンピュートエンジンを用途に応じて選択できる柔軟性と、Lake Formationによる細粒度ガバナンスが強みになります。

3層の主導権

Glue Data CatalogはIceberg REST Catalog APIに対応しており、SnowflakeやDatabricks等の外部エンジンからも同一テーブルを参照できます。
なので、AWSがデータ主導権を持ちながら、Snowflakeを分析フロントとして併用する構成が成立します。

メリット

• Athena・EMR・Glue・Redshiftが同一カタログを参照でき、サービス間の統合がシームレスです
• Lake Formationによる列・行レベルの細粒度制御をIcebergにも適用できます
• 大規模バッチはEMR、インタラクティブはAthenaと、コンピュートを用途別に使い分けられます

デメリット

• 組み合わせるAWSサービスが多く、設計・運用の複雑さが増しやすいです
• カタログがAWS依存のため、マルチクラウド展開には追加設計が必要となります

特にLake Formationの権限制御は強力であると同時に、権限トラブル時の切り分けが難しい場合もあり、それをカバーできる運用体制の構築が必要となります。
「なぜこのユーザーがこのテーブル、このレコードにアクセスできないのか」の原因特定に時間がかかるケースも多く、権限設計は慎重に行う必要があります。

AWSとSnowflakeを組み合わせる

「どちらかを選ぶ」ではなく役割分担をさせる構成も現実的な選択肢だと思います。
その場合、3層の主導権を最初に明示することが設計の鍵になります。

データ主導権をAWSに、分析をSnowflakeに寄せる

こちらはよくあるパターンとなります。
ベンダロックインを避けること、そしてデータの原本をすべてAWS上で管理することを目的とした構成です。
また、Snowflakeの高度な分析機能と豊富なBIのコネクタを活用することもできます。

┌──────────────────────────────────────────────────┐
│ AWS │
│ S3（Icebergデータファイル） │
│ Glue Data Catalog（カタログ管理権） │
│ Lake Formation（ガバナンス権） │
│ Glue / EMR（書き込み権） │
└──────────────────────┬───────────────────────────┘
 │ Iceberg REST Catalog API
 ┌──────────────┼───────────────────┐
 ▼ ▼ ▼
 Athena Glue Snowflake
 （インタラクティブ） （ETL） （分析）

この構成では3層の主導権が明確になります。

この構成には2つのバリエーションがあります。

① Glue Catalog Integration（読み取り専用）
SnowflakeはExternal Iceberg Tables経由でGlue管理のテーブルを参照します。書き込み権はAWSにあるため、Snowflakeは純粋に分析フロントエンドとして機能します。ガバナンスはLake Formationに集約できます。

② Catalog-Linked Database（読み書き可）
SnowflakeがGlueのIceberg REST Catalog経由でテーブルに書き込みも行う構成です。データ実体はS3に残ったまま、SnowflakeのDMLでIcebergテーブルを更新できます。BI・AIユーザがSnowflake主体で運用したい場合に向いています。

AWSとSnowflakeの組み合わせパターンの具体的な設定手順（External Volume、Catalog Integration、Catalog-Linked Databaseの作成方法）については以下の記事を参考にどうぞ！

https://zenn.dev/penginpenguin/articles/97f30cc1ac8377

3つのパターンのまとめ

どの構成を選ぶべきか

整理したパターンをもとに、実務での判断軸を簡単にまとめます。

Snowflake寄りが向くケース

• BI主導・非エンジニア主体の分析チームが中心
• データ量よりも開発速度や分析体験を優先したい
• ガバナンスをSnowflake Horizonで一元管理したい

AWS寄りが向くケース

• データ量が多く、ETL処理が中心のワークロード
• データエンジニアリングチームがいてAWSエコシステムを活用している
• Lake Formationによる細粒度の権限制御が必要

組み合わせが向くケース

• 部門ごとに利用ツールが異なる（エンジニアはAWS、アナリストはSnowflake等）
• 将来的なAI・ML・マルチエンジン対応を見据えた拡張性を重視したい
• データ主導権はAWSに置きつつ、Snowflakeのクエリ性能も活かしたい

主導権が曖昧な設計で起きること

実務でよく見かけるのは、「とりあえず動く」状態で構築が進み、後から3層の主導権が曖昧なことに気づくケースです。
具体的にはこういった問題が起きます。

• 誰がテーブル定義を変更してよいのかわからない：GlueとSnowflakeの両方にスキーマの管理者がいて、どちらの変更が正なのか判断できない状態になります
• SnowflakeでINSERTしたデータをAthenaが認識しない：異なるカタログが同一テーブルを管理しようとする状態になると、一方のカタログが最新スナップショットを追跡できなくなりメタデータの不整合が起きる可能性があります
• Lake FormationとSnowflake Horizonの設定がずれる：同じテーブルに対して両側でアクセス制御を持つと、片方の設定漏れがセキュリティホールになります
• 障害時に責任の所在が曖昧になる：書き込みエンジンが複数あると「どこで何が起きたか」の追跡が難しくなり、インシデント対応が遅れます

これらは単なる設計の問題ではなく、実務では以下のような「調整コスト」として顕在化します。

• 部門間で責任のなすりつけが起きる
• 監査対応で説明ができない（誰が権限を持っているか説明不能）
• インシデント時に復旧が遅れる（意思決定ができない）

結果として、システムの問題ではなく「組織の問題」に発展することがあります。
「動いている」と「設計されている」は別の話であり、主導権の設計は後から直すほど影響範囲が広くなります。

「AWSかSnowflakeか」は設計上の副作用

実務では「AWSとSnowflake、どちらに寄せるか」を最初に議論しがちです。
ただ、Iceberg時代のレイクハウスでは、これは問いの順序が逆だと思っています。

先に決めるべきなのは次の3点です。

• カタログ管理権：メタデータを誰が持つか
• 書き込み権：データの更新・削除を誰が行えるか
• ガバナンス権：アクセス制御ポリシーを誰が統制するか

この3層の所在を決めると、「AWSかSnowflakeか」という選択はその結果として決まるものだと思っています。

• 3層ともSnowflakeに集約したいなら → Snowflake寄りの構成
• 3層ともAWSで完結させたいなら → AWS寄りの構成
• 3層はAWSが持ち、Snowflakeは分析フロントに使いたいなら → 組み合わせ構成

プロダクト選定を先に行うと、後から主導権を整理しようとしたときに設計上の矛盾が出やすくなります。
「なんとなくSnowflakeを使いながら、書き込みはGlueで、ガバナンスはLake Formationで…」という状態は、3層の主導権が分散・曖昧なまま構築が進んだ結果であることが多いです。

Icebergによって「データをどこに置くか」の自由度は大きく向上しました。
しかし自由度が増えた分だけ、アーキテクトは「誰が責任を持つのか」を明確に設計する必要があります。

また、技術的な接続性だけを見るとAWSとSnowflakeは以前よりも容易に共存できるようになりました。
しかし、実際のプロジェクトで難しいのは接続ではなく責任分界点です。

まとめ

今回は「データの主導権」について考えてみました。
Apache Icebergによってストレージ形式のロックインは大幅に解消されました。
ただし、カタログ管理権・書き込み権・ガバナンス権の3層は、設計しなければ曖昧なまま残ります。

迷ったときはこの順番で考えると整理しやすくなります。

1. カタログ管理権をどこに置くかを決める（Glue / Snowflake Open Catalog / Snowflake Horizon）
2. 書き込みエンジンを誰が担うかを決める（AWSサービス中心 / Snowflake中心）
3. ガバナンスポリシーをどこで統制するかを決める（Lake Formation / Snowflake Horizon / 両方）

この3点が決まれば、「AWSに寄せるか、Snowflakeに寄せるか」という答えが導きやすくなると思います。
その結果、要件に沿ったベストな構成を組むことができます。

とはいえ、今回の3層以外にも様々な考慮事項が存在します。
Icebergによって技術的な相互運用性は大きく向上しました。
しかし実際のプロジェクトでは、どのチームがカタログを管理し、誰がデータ更新を行い、どこでガバナンスを統制するのかという責任分界点の合意形成が必要になります。

そして、技術よりも組織設計の方が難しいケースも少なくありません。

いつの時代も最終的にはツールではなく、「人とプロセス」が課題や障壁になるのは変わらないと思っています。

今回の記事がAWSとSnowflakeのレイクハウスアーキテクチャを検討している方の参考になれば幸いです。