ある大手メディア企業が複数のサービス（動画配信、音楽配信、ゲーム）を個別の AWS アカウントで運用しており、これらの間で同一ユーザーのサブスクリプション状態を共有する必要があります。現在は各サービスが個別にユーザーデータベースを持っており、データが重複しています。最小限の変更でデータの単一ソースを確立したいと考えています。最も適切なアーキテクチャはどれですか？
- A. 各サービスアカウントに DynamoDB グローバルテーブルをデプロイし、複数リージョンのアカウント間でユーザーデータを双方向同期する
- B. 全サービスを同一の AWS アカウントに統合し、単一の RDS データベースにユーザーデータを集約する
- C. Amazon Cognito User Pool を全サービスで共有し、カスタム属性にサブスクリプション状態を保存する
- D. 専用の「ユーザーサービス」アカウントに Amazon DynamoDB（ユーザーデータの単一ソース）を配置し、AWS PrivateLink でエンドポイントサービスを公開する。各サービスアカウント（動画、音楽、ゲーム）から PrivateLink 経由で ユーザーサービスの API（API Gateway + Lambda + DynamoDB）にアクセスし、サブスクリプション状態を取得する
解答と解説を見る
正解: D
専用の「ユーザーサービス」アカウントにデータの単一ソースを確立し、PrivateLink でプライベートかつセキュアな API アクセスを提供するアーキテクチャが最適です。各サービスはユーザーデータを持たず、ユーザーサービスの API を呼び出すだけです。PrivateLink はアカウント間のネットワーク設定を最小化し、サービスのネットワーク詳細を公開せずに API アクセスを提供できます。 B: 全サービスを単一アカウントに統合することは、独立したチームと製品ラインの運営に支障をきたし、セキュリティと可用性の分離も失われます。 A: DynamoDB グローバルテーブルのアカウント間複製は標準的な機能では対応していません（グローバルテーブルはリージョン間のみ）。また双方向同期は競合状態の管理が複雑になります。 C: Cognito のカスタム属性はユーザー認証情報に付随するデータに適していますが、複雑なサブスクリプション状態（複数サービスの組み合わせ、履歴、請求情報等）の管理には機能が限定的です。
📚 関連サービスの解説: Amazon DynamoDB ・ AWS PrivateLink／VPCエンドポイント