Amazon DataZone

解決する課題

組織が大きくなると、データは部門ごとのアカウントやサービスに散らばり、「どこに何のデータがあるのか」「それを使ってよいのか」「誰に頼めばアクセスできるのか」が分からなくなります。技術者でないと中身を理解できないテーブル名や、申請から承認までの非効率な手続きが、データ活用の壁になりがちです。Amazon DataZone は：

• ビジネス用語を添えたデータカタログで、部門をまたいでデータを探せるようにする
• データの公開・アクセス申請・承認をプロジェクト単位のワークフローとして回す
• 承認されたアクセスを Athena や Redshift などの分析サービスへ自動でひも付ける

「データの所在と利用可否を組織横断で見える化したい」「アクセス申請と承認を仕組み化したい」という要件に向きます。他クラウドでは Google Cloud の Dataplex / Data Catalog や Microsoft Purview が近い位置づけです。

主要概念と用語

• ドメイン: DataZone の最上位の管理単位。組織やデータ活用の境界を表し、この中にプロジェクトやカタログがまとまる
• データポータル: 利用者がブラウザからデータを検索・閲覧し、アクセス申請を行う Web のフロントエンド
• ビジネスデータカタログ: テーブルなどの技術メタデータに、ビジネス用語や説明を付けて検索可能にしたカタログ
• ビジネスグロッサリ: 「顧客」「売上」など組織共通の用語集。資産にひも付けて意味を統一する
• データ資産（アセット）: カタログに登録された個々のテーブルやデータセット。スキーマや説明、用語が付与される
• プロジェクト: データを扱う作業の単位。メンバー、利用する環境、公開・購読する資産がここに集まる
• 環境（エンバイロメント）: プロジェクトが実際に分析を行う基盤。Athena や Redshift などの利用環境を表す
• パブリッシュ / サブスクライブ: 提供側が資産を公開（パブリッシュ）し、利用側が申請して購読（サブスクライブ）する共有モデル
• データソース: Glue データカタログや Redshift などから資産を取り込む接続元

仕様・制限・クォータ

• データはコピーせず、Glue データカタログや Redshift などのメタデータを取り込んでカタログ化するのが基本
• アクセス制御は購読の承認に連動し、許可された資産へのアクセスをLake Formation や Redshift の権限として反映する
• 利用者はコードを書かずにデータポータルから検索・申請でき、技術者は API や CLI でも操作できる
• ドメイン・プロジェクト・資産・グロッサリなどの個数にはサービスクォータがあり、必要に応じて引き上げを申請できる
• 機械学習によるメタデータの自動付与など、カタログ整備を補助する機能を備える

内部の仕組み

DataZone は、データそのものを保持するのではなく、各データソースのメタデータを取り込み、その上にカタログと共有のワークフローを重ねて動作します。

• データソース（Glue データカタログや Redshift など）から資産のスキーマや場所を取り込み、ビジネス用語を添えてカタログに登録する
• 提供側プロジェクトが資産をパブリッシュすると、データポータルで検索・閲覧できるようになる
• 利用側プロジェクトが資産をサブスクライブ申請し、提供側が承認すると、購読が成立する
• 承認に連動して、利用側の環境（Athena や Redshift など）に実アクセス権が自動で付与され、すぐにクエリできる
• 個人情報の有無やスキーマ変更などの情報を補助的に整理し、ガバナンスのレビューを支える

設計パターン / ベストプラクティス

• ドメインとプロジェクトで責任境界を切る: 部門やデータ領域に合わせてドメインを設計し、作業はプロジェクト単位に分ける
• ビジネスグロッサリを先に整える: 用語の定義を統一してから資産へ付与すると、検索性と意味の一貫性が高まる
• 公開と購読でデータ提供を仕組み化: 個別の手作業依頼ではなく、パブリッシュ／サブスクライブの申請・承認フローに乗せる
• 連携先の権限と整合させる: 承認で付与される Lake Formation や Redshift の権限が最小権限になるよう設計する
• メタデータ整備を継続運用に: スキーマ変更や新規資産の取り込みを定期的に回し、カタログを鮮度高く保つ

運用・監視

• ドメイン・プロジェクトの操作や購読の承認といったイベントは CloudTrail で監査できる
• 「誰がどの資産を購読しているか」を棚卸しし、不要になった購読を見直して過剰なアクセスを防ぐ
• データソースの取り込みを定期実行し、カタログと実データのスキーマのずれを抑える
• ビジネスグロッサリと用語付与のルールをドキュメント化し、レビューや引き継ぎを容易にする

コスト

• 費用は主に利用者数（ユーザー単位）やカタログに登録するメタデータの量などに応じて発生する従量制が中心
• 実際の分析処理やストレージのコストは、クエリを実行する Athena や Redshift、メタデータ基盤の Glue データカタログ、保管先の S3 といった連携先サービスの利用量で決まる
• データを複製せずメタデータで扱うため、カタログ整備に伴う追加のストレージコストは大きくなりにくい

セキュリティ

• アクセスは購読の承認を起点に統制され、承認結果が Lake Formation や Redshift の権限として反映される
• ビジネスグロッサリや分類により、機密度や部門に応じたガバナンスをスケールさせやすい
• ドメイン管理者やプロジェクト所有者の役割を分け、公開・承認の操作で職務分離を徹底する
• 保管時の暗号化は連携先の S3 や KMS、通信は TLS で保護し、操作の監査は CloudTrail で行う
• 連携先サービスへの直接アクセス経路を統制し、カタログ経由の承認フローを迂回されないようにする

関連サービス・比較

メタデータ基盤の AWS Glue データカタログ とよく対比されます。Glue データカタログがテーブルのスキーマを管理する技術メタデータの土台であるのに対し、DataZone はその上にビジネス用語・公開・申請・承認といった組織横断のデータガバナンスと発見の層を重ねる、補完関係にあります。

ハンズオン / CLI例

# データドメインを作成（組織のデータ活用の境界）
aws datazone create-domain \
  --name "analytics-domain" \
  --domain-execution-role arn:aws:iam::111122223333:role/DataZoneExecutionRole

# ドメイン内にデータプロジェクトを作成
aws datazone create-project \
  --domain-identifier dzd_xxxxxxxx \
  --name "sales-analytics" \
  --description "売上データの分析プロジェクト"

# カタログ上の資産を名前で検索（データの発見）
aws datazone search \
  --domain-identifier dzd_xxxxxxxx \
  --search-scope ASSET \
  --search-text "orders"