AWS
AWS構成事例カタログ
データ活用 / DWHマルチAZManaged / SaaS

Snowflake エンタープライズDWH基盤 on AWS

S3ロード・PrivateLink閉域・SSO/RBAC・コスト分離した仮想WH

可用性 (SLA目標)

Snowflake エディション/契約のSLAに準拠(設計目標、構成に依存)

RTO(目標復旧時間)

Time Travel / レプリケーション設定に依存(設計目標)

RPO(目標復旧時点)

マイクロパーティション/レプリケーション設定に依存(設計目標)

概算コスト

月 数十万円〜(仮想WHの稼働時間・サイズに依存)

構成概要

可用性レベル
マルチAZ
コンピューティング
Managed / SaaS
想定システム規模
大規模(全社DWH・BI / 多数の分析ユーザー)
コスト感
¥¥¥高コスト

使用AWSサービス

  • Snowflake (Managed SaaS)
  • Snowflake Virtual Warehouse
  • Snowflake Database Storage
  • Snowflake Cloud Services
  • AWS PrivateLink
  • Amazon S3
  • AWS KMS
  • IdP / SSO (SAML/OIDC)
  • BIツール
  • AWS CloudTrail

概要

Snowflake をマネージドSaaSのデータウェアハウスとして利用する全社データ活用基盤です。AWS 側の S3 ランディングバケットへ集めた業務データを、Storage Integration / Snowpipe 相当で Snowflake の Database Storage へロード。BIツールや分析ユーザーは AWS PrivateLink を介して Snowflake へ閉域接続し、IdP / SSO と RBAC でアクセス制御します。Snowflake は『Cloud Services(認証・最適化・メタデータ)』『Virtual Warehouse(弾力的コンピュート)』『Database Storage(圧縮列指向)』の3層で構成され、用途別に仮想ウェアハウスを分離してコストを可視化・分離します。図では AWS Cloud と Snowflake Managed Platform の境界を明示しています。可用性・性能・データ保護は Snowflake のエディション・契約・設定に依存します。

設計のポイント

  • AWS Cloud と Snowflake Managed Platform の境界を明確化(SaaS責任分界)
  • Snowflake を Cloud Services / Virtual Warehouse / Database Storage の3層で表現
  • AWS PrivateLink による Snowflake への閉域接続
  • Storage Integration / Snowpipe による S3 からのデータロード
  • 用途別に分離した仮想ウェアハウスでコスト可視化・分離(設計目標)

システム構成図

AWS CloudSnowflake Managed Platform (on AWS / SaaS)VPCVirtual Warehouse(弾力的コンピュート)Database Storage(圧縮列指向)Cloud Services(認証 / 最適化 / メタデータ)Storage Integration/ SnowpipeクエリPrivateLink 閉域SSO / SAML社内データソース基幹 / 業務DBログ / イベントS3ランディングBIツールダッシュボード / 分析IdP / SSOAWSPrivateLink認証 / クエリ最適化 / メタデータ管理Virtual Warehouse (分析)BIクエリVirtual Warehouse (ロード)ETL / 取込Database Storage圧縮列指向 / Time Travel

周辺・運用機能(クロスカッティング / 全体に適用)

監視・運用

CloudWatchCloudWatchCloudTrailCloudTrail

セキュリティ・統制

IAMIAMKMSKMSSecrets ManagerSecrets Manager

連携・取込

S3 (Stage)S3 (Stage)EventBridgeEventBridge

コスト・ガバナンス

WH 使用量/コストWH 使用量/コストOrganizationsOrganizations
リージョンVPCプライベートパブリック概念図 / アイコン: AWS Architecture Icons

コピーしてすぐ使える IaC

Snowflake エンタープライズDWH基盤 on AWSを再現するためのスターターIaCです。事例固有のIP制限、監査、バックアップ、Secret参照は環境に合わせて追加してください。

typescript
import * as cdk from "aws-cdk-lib";
import { Construct } from "constructs";
import * as iam from "aws-cdk-lib/aws-iam";
import * as kms from "aws-cdk-lib/aws-kms";
import * as s3 from "aws-cdk-lib/aws-s3";

export class SnowflakeEnterpriseDwhAwsIntegrationStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    const key = new kms.Key(this, "DataKey", { enableKeyRotation: true });
    const bucket = new s3.Bucket(this, "LandingBucket", {
      encryption: s3.BucketEncryption.KMS,
      encryptionKey: key,
      blockPublicAccess: s3.BlockPublicAccess.BLOCK_ALL,
      enforceSSL: true,
    });

    new iam.Role(this, "ExternalPlatformAccessRole", {
      assumedBy: new iam.AccountPrincipal("123456789012"),
      inlinePolicies: {
        S3LandingAccess: new iam.PolicyDocument({
          statements: [
            new iam.PolicyStatement({
              actions: ["s3:GetObject", "s3:PutObject", "s3:ListBucket"],
              resources: [bucket.bucketArn, bucket.arnForObjects("*")],
            }),
          ],
        }),
      },
    });
  }
}

この構成を選ぶ理由

Snowflake エンタープライズDWH基盤 on AWSは、大規模(全社DWH・BI / 多数の分析ユーザー)を想定し、AZ障害への耐性と運用現実性を重視する場合に選びやすい構成です。

選定フロー

1

業務要件を確認する

データ分析で求められる可用性、RTO/RPO、データ分類を確認する。

要件に合う → 候補として採用不足がある → 上位の冗長化/統制構成を検討
2

運用体制を確認する

チームが Snowflake の運用、監視、権限管理を継続できるかを確認する。

運用可能 → 詳細設計へ負荷が高い → よりマネージドな代替案へ
3

コストと拡張性を比較する

月 数十万円〜(仮想WHの稼働時間・サイズに依存)を許容し、将来のスケールやDR要件に対応できるかを判断する。

許容できる → 本構成を採用過剰/不足 → 代替案を比較

代替案との比較

候補コスト運用保守負荷スケーラビリティ選定すべきケース
最小構成
低い単純だが手動復旧が多い限定的PoC、検証、小規模な開始段階
Snowflake エンタープライズDWH基盤 on AWS採用
高い責任分界と外部サービス管理が重要段階的に拡張可能全社DWH・BIによる経営/業務ダッシュボード
上位冗長化構成
高い設計・監視・訓練が増える高い厳格なSLA、DR、監査要件がある場合

採用時のトレードオフ

!

設計前提の確認が必要

Snowflake は AWS ネイティブサービスではなくマネージドSaaSであり、責任分界・契約が別途必要
!

コストと運用負荷のバランス

AWSネイティブではなくSaaSのため、責任分界・契約・データ持ち出しの整理が必要

🛡 セキュリティ・コンプライアンスのポイント

AWS PrivateLink による閉域接続で公衆経路を回避
IdP / SSO(SAML/OIDC)と RBAC によるアクセス制御・職務分離
S3 Storage Integration による最小権限のロード(鍵・資格情報を保護)
Snowflake 監査ログ + CloudTrail によるアクセス・操作の証跡化
KMS による S3 側暗号化、機微データのマスキング/行レベル制御を想定

🏛 エンタープライズ設計観点・統制

業務領域

データ分析

プラットフォーム

Snowflake

重要度

高(全社の分析・レポーティング基盤)

接続方式

AWS PrivateLink による Snowflake への閉域接続

データ分類

機密(業務データ / 個人情報を含みうる分析データ)

データ活用・統制の設計目標

  • AWS PrivateLink による Snowflake への閉域接続を設計目標とする
  • IdP / SSO(SAML/OIDC)と RBAC によるアクセス制御・職務分離
  • S3 Storage Integration による最小権限のデータロード(鍵・資格情報の保護)
  • アクセス履歴・クエリ履歴の監査(Snowflake 監査ログ + CloudTrail)
  • 用途別に分離した仮想ウェアハウスでコストを可視化・分離する

前提条件・留意事項

  • Snowflake は AWS ネイティブサービスではなくマネージドSaaSであり、責任分界・契約が別途必要
  • 可用性・性能・データ保護は Snowflake のエディション・リージョン・契約・設定に依存する
  • 記載のコストは仮想ウェアハウスの稼働時間・サイズ・自動停止設定に強く依存する
  • RTO/RPO は Snowflake のレプリケーション/Time Travel 設定に依存する(設計目標)

メリット

  • ストレージとコンピュートが分離し、用途別に弾力スケール・コスト分離が可能
  • PrivateLink 閉域接続と SSO/RBAC でエンタープライズの統制要件に対応しやすい
  • マネージドSaaSのため、DWH 自体の運用・パッチ負荷が小さい
  • Time Travel など Snowflake 機能でデータ保護・再現性を確保しやすい

デメリット

  • AWSネイティブではなくSaaSのため、責任分界・契約・データ持ち出しの整理が必要
  • 仮想ウェアハウスの稼働時間・サイズ次第でコストが膨らみやすい
  • AWS と Snowflake をまたぐ権限・監査の二重管理が必要
  • 可用性/データ保護はエディション・契約・設定に依存する

主なユースケース

  • 全社DWH・BIによる経営/業務ダッシュボード
  • 部門横断のデータ分析・セルフサービスBI
  • S3 データレイクと連携したスケーラブルな分析基盤
データ活用DWHSnowflakePrivateLinkBISSORBACManaged/SaaS