はじめに
データ分析基盤でPII（個人識別情報）を取り扱う場合、インターネットへの露出を最小限に抑える閉域設計が絶対条件となります。
本記事では、強固なセキュリティガバナンスを満たしつつ、開発者のアジリティを損なわないための「Serverless優先」と「多層防御」の実践的なアーキテクチャについて解説します。
Serverless Firstという決断
運用負荷を最小化しつつ、PII環境でのPoCや運用検証のサイクルを素早く回すため、Databricks Serverless ComputeとS3を標準構成として採用しました。
実はPoCの初期段階では、インフラ側からコストの予測可能性を重視し、EC2ベースの「Classic Compute」を想定・提案していました。しかし、開発エンジニア陣から 「サーバー管理やスパイク時の監視にリソースを割くとDatabricksの旨味を失う」 という強い要望があがりました。
「データ処理とAI開発に集中する」という本来の目的を最優先し、Serverless主軸へ舵を切ったのです。懸念となるコスト変動リスクに対しては、自動停止機能やAWS Budgetsを用いた予算監視（超過時のSlack通知等）で厳密に管理しています。
理想の裏にある「コスト可視化」の泥臭い現実
しかし、Serverless環境におけるコスト管理の実態は、決してスマートなものばかりではありませんでした。Databricksの請求はDBU（コンピュート単価）で計算されますが、VMやディスク、ネットワークといった基盤コストはAWS側で別途発生します。この二重のコスト構造をPO（プロダクトオーナー）向けに統合・可視化するため、私たちは自前でカスタムノートブック（cost_dashboard_pipeline.py）を構築し、Unity Catalogのテーブルに集計するパイプラインを開発する必要がありました。
さらに想定外だったのは、Serverless Computeのネットワーク制約により、AWS Cost ExplorerのAPIへ直接アクセスできなかったことです。結果として、コスト情報取得のジョブだけは例外的に既存のClassic Computeクラスターに処理を逃がすという、苦肉の迂回策をとることで解決しています。Serverlessの恩恵を最大限に受ける裏側では、こうしたインフラ側の泥臭い運用カバーが不可欠でした。
多層防御のアーキテクチャ
PII保護の要件を満たすため、単なるネットワークの閉域化にとどまらない多段の防御策を講じています。以下がその全体像です。
上記の構成図の通り、各層で以下の防御策を徹底しています。
-
エンドポイントの統制（DLP対策）
ローカル端末へのPII持ち出しを回避しつつブラウザ作業を両立させるため、VPN + SSOを前提とした AWS WorkSpaces を標準アクセス経路として発行しています。 -
Control Planeの保護
AWS PrivateLink (Interface VPCE + Private DNS) を利用し、コントロールプレーンへのアクセス経路を保護しています。 -
IP Access Listによる二重防御
WorkspaceおよびAccountレベルでIP Access Listを有効化し、許可されたVPNやWorkSpacesの固定IP以外からのアクセスを弾く体制をとっています。 -
Data Planeの制御
Databricksのネットワーク設定である NCC (Network Connectivity Configuration) と Private Endpoint Rule により、データプレーンからAWSリソース（S3やRDSなど）への通信を厳密に制御しています。
💡 Tips: PrivateLink環境下のDNS名前解決
PrivateLink DNS（Route 53 Resolver等）が未整備な期間は、アクセス遮断を防ぐための暫定措置として、WorkSpaces側のC:\Windows\System32\drivers\etc\hostsに Workspace FQDN と VPCEのプライベートIPをマッピングし、運用を回避する工夫も行いました。
閉域化とServerlessが引き起こすネットワークの「罠」
こうした多層防御の仕組みは強力ですが、構築と運用には多くの摩擦（痛み）を伴いました。
アクセスリスト運用での締め出し: IP Access Listを有効化した直後、設定漏れにより正規の開発メンバーの自宅IPがブロックされたり、VPN切断時にセッションが強制終了するなど、アジリティとセキュリティのバランス調整に苦労しました。
ServerlessとNCC仕様の落とし穴: データプレーンの制御（NCCとPrivate Endpoint Rule）において、RDSへのセキュアな経路（NLB + VPC Lattice）は構築できたものの、S3アクセスに関しては「NCCのファイアウォールルールがS3をサポートしていない」という仕様の壁にぶつかりました。Serverless ComputeからS3への読み書きは、Databricksが管理する同一リージョンのS3ゲートウェイエンドポイントを自動的に経由する仕様となっており、ドキュメントの隅々まで仕様を読み解く必要がありました。
閉域網ゆえのデバッグ困難: トラブルシューティングの際も、AWS CloudShellからVPC内のプライベートRDSに直接アクセスできないため、AWS Secrets Managerから認証情報を取得し、Databricksのノートブック上（Python）で手動でMySQLコマンドを叩いて状況を確認するといった手間が発生しました。
まとめ
PII保護という高いセキュリティ要件は、AWSとDatabricksのネットワーク機能やID管理を組み合わせた「多層防御」によってクリアできます。
同時に、思い切ってServerlessアーキテクチャを採用することで、インフラ管理のオーバーヘッドを排除し、データエンジニアが本来の価値創造に集中できる環境を実現しました。強固なガバナンスと運用負荷軽減は、設計次第で両立可能です。