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

Databricks Lakehouse基盤 on AWS

制御/コンピュートプレーン分離・Unity Catalog統制・PrivateLink閉域

可用性 (SLA目標)

Databricks プラン/契約のSLAに準拠(設計目標、構成に依存)

RTO(目標復旧時間)

クラスター再作成・ジョブ再実行に依存(データはS3で永続化)

RPO(目標復旧時点)

ほぼ 0 を目標(Delta Lake / S3 に永続化、設定に依存)

概算コスト

月 数十万円〜(クラスター稼働時間・インスタンスに依存)

構成概要

可用性レベル
マルチAZ
コンピューティング
Managed / SaaS
想定システム規模
大規模(データエンジニア / アナリスト / ML チーム)
コスト感
¥¥¥高コスト

使用AWSサービス

  • Databricks Control Plane (Managed)
  • Databricks Classic Compute Plane
  • Unity Catalog
  • Delta Lake
  • MLflow
  • Jobs / Workflows
  • Amazon S3
  • AWS PrivateLink
  • VPC Endpoint
  • AWS IAM (Role)
  • AWS KMS
  • Amazon CloudWatch
  • AWS CloudTrail

概要

Databricks を用いた Lakehouse 基盤を、制御プレーン(Databricks 管理アカウント)と Customer AWS Account(顧客管理VPC内の Classic Compute Plane)に分離して構成します。ノートブック / SQL / ジョブは制御プレーンから提供され、実際のクラスター(Spark)は顧客VPC内で起動。データは Amazon S3 を中心とした Delta Lake(Bronze / Silver / Gold)に蓄積し、Unity Catalog がデータ・モデルの権限と系譜を一元統制します。制御プレーン接続は AWS PrivateLink で閉域化し、S3 へはクロスアカウント IAM Role と VPC Endpoint で最小権限アクセス。データエンジニアリング・BI・ML(MLflow)を一つの基盤に統合します。図では Databricks 管理アカウント / Customer AWS Account / Data Lake の境界を明示しています。可用性・性能・コストは構成・契約・設定に依存します。

設計のポイント

  • Databricks 制御プレーンと Customer AWS Account(コンピュート)を明確に分離
  • S3 を中心とした Delta Lake(Bronze/Silver/Gold)の Lakehouse
  • Unity Catalog によるデータ・モデルのガバナンス(権限・系譜)
  • AWS PrivateLink による制御プレーン接続の閉域化 + VPC Endpoint
  • データエンジニアリング / BI / ML(MLflow)を統合(設計目標)

システム構成図

Customer AWS AccountDatabricks Control Plane(Databricks 管理アカウント)Customer-managed VPCData Lake (Amazon S3)Classic Compute Plane(クラスター)セキュア接続ジョブ実行権限制御データ統制VPC Endpoint (閉域)モデル記録Workspace / Web UIノートブック / SQLJobs / Workflowsジョブ スケジューラUnity Catalogデータ / モデル統制MLflow(モデル管理)AWS PrivateLink(制御プレーン接続)クラスター (Driver/Worker)Spark 実行IAM Role(クロスアカウント)VPC Endpoint(S3 閉域)S3 (Bronze)生データS3 (Silver)Delta LakeS3 (Gold)集計 / 特徴量

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

監視・運用

CloudWatchCloudWatchCloudTrailCloudTrail

セキュリティ・統制

IAM RoleIAM RoleKMSKMSSecrets ManagerSecrets Manager

データ・ML

S3 (Delta Lake)S3 (Delta Lake)外部クエリ (任意)外部クエリ (任意)

ガバナンス・コスト

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

コピーしてすぐ使える IaC

Databricks Lakehouse基盤 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 DatabricksLakehouseAwsIntegrationStack 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("*")],
            }),
          ],
        }),
      },
    });
  }
}

この構成を選ぶ理由

Databricks Lakehouse基盤 on AWSは、大規模(データエンジニア / アナリスト / ML チーム)を想定し、AZ障害への耐性と運用現実性を重視する場合に選びやすい構成です。

選定フロー

1

業務要件を確認する

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

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

運用体制を確認する

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

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

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

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

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

代替案との比較

候補コスト運用保守負荷スケーラビリティ選定すべきケース
最小構成
低い単純だが手動復旧が多い限定的PoC、検証、小規模な開始段階
Databricks Lakehouse基盤 on AWS採用
高い責任分界と外部サービス管理が重要段階的に拡張可能データエンジニアリング(ETL / Delta Lake パイプライン)
上位冗長化構成
高い設計・監視・訓練が増える高い厳格なSLA、DR、監査要件がある場合

採用時のトレードオフ

!

設計前提の確認が必要

Databricks は AWS ネイティブサービスではなくマネージドプラットフォームであり、責任分界・契約が別途必要
!

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

AWSネイティブではなくマネージドプラットフォームで、責任分界・契約整理が必要

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

制御プレーンとコンピュートプレーンの分離(責任分界の明確化)
AWS PrivateLink による制御プレーン接続の閉域化
Unity Catalog による集中的なデータ/モデルの権限・系譜管理
クロスアカウント IAM Role + VPC Endpoint による最小権限の S3 アクセス
KMS による暗号化、CloudTrail / クラスターログによる監査証跡

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

業務領域

データ分析・機械学習

プラットフォーム

Databricks

重要度

高(データエンジニアリング / BI / ML の統合基盤)

接続方式

AWS PrivateLink による制御プレーン接続の閉域化 + VPC Endpoint

データ分類

機密(業務データ / 学習データ / モデル)

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

  • Databricks 制御プレーンと Customer AWS Account(コンピュート)を分離する
  • AWS PrivateLink で制御プレーン接続を閉域化し、公衆経路を避ける
  • Unity Catalog によるデータ・モデルの一元的なガバナンス(権限・系譜)
  • クロスアカウント IAM Role と VPC Endpoint による最小権限の S3 アクセス
  • CloudTrail / クラスターログによる監査証跡、KMS による暗号化

前提条件・留意事項

  • Databricks は AWS ネイティブサービスではなくマネージドプラットフォームであり、責任分界・契約が別途必要
  • 可用性・性能はクラスター構成・リージョン・契約・設定に依存する(設計目標)
  • コストはクラスターの稼働時間・インスタンス種別・自動停止設定に強く依存する
  • Unity Catalog / PrivateLink の利用可否はプラン・リージョンに依存する

メリット

  • 制御プレーンとコンピュートプレーンの分離で、データを顧客VPC/S3 に保持しやすい
  • Unity Catalog でデータ・モデルの権限と系譜を一元統制
  • Delta Lake により Lakehouse でBI/MLを同一基盤に統合
  • PrivateLink / VPC Endpoint で閉域化し統制要件に対応しやすい

デメリット

  • AWSネイティブではなくマネージドプラットフォームで、責任分界・契約整理が必要
  • クラスター稼働時間・インスタンス種別でコストが膨らみやすい
  • 制御/コンピュート分離・Unity Catalog 等の設計/運用に学習コスト
  • 可用性/性能は構成・契約・設定に依存する(設計目標)

主なユースケース

  • データエンジニアリング(ETL / Delta Lake パイプライン)
  • 全社のセルフサービスBIと機械学習(MLflow)の統合基盤
  • データ・モデルガバナンスが必要なエンタープライズ分析
データ活用LakehouseDatabricksUnity CatalogDelta LakeMLflowPrivateLinkManaged/SaaS