SAA / SAP 攻略ナビ
ホーム ガバナンス・マルチアカウント

共有サービスアカウント設計

共有サービスアカウントの設計、Transit Gateway、Active Directory、DNS、共有イメージ、SaaS ライセンス集約を SAA 基礎から SAP 高度設計まで解説。

最終更新: 2026-07-27 カテゴリ: ガバナンス・マルチアカウント

共有サービスアカウント は、組織全体で利用する 共有インフラを集約する専用アカウント です。 ネットワークハブ、Active Directory、DNS、共有イメージ等をここに集約し、 各ワークロードアカウントから利用します。 本記事では共有サービスアカウントの設計を SAA / SAP 両面から整理します。

SAA レベル：基礎概念

共有サービスアカウントの役割

共有サービスアカウントは 組織全体で使うインフラを一元提供 するアカウントです。

  • ネットワークハブ: Transit Gateway の中央ハブ
  • 認証基盤: Active Directory, IAM Identity Center 連携
  • 名前解決: DNS サーバー、Route 53 Private Hosted Zone
  • 共有イメージ: Golden AMI, Container Image の中央リポジトリ
  • SaaS ライセンス: 組織全体で共有するライセンス管理

SAA レベル：基礎概念

共有サービスアカウントの核心は 「組織全体で使うインフラを 1 箇所に集約」 です。 各ワークロードアカウントが独自にネットワーク / AD / DNS を持つと重複と不整合が生まれるため、 共有インフラは中央集約が基本。SAA では「共有サービス = 集約アカウント」として押さえます。

なぜ専用アカウントに分けるのか

共有インフラをワークロードアカウントに置かない理由：

課題ワークロードアカウントに混在専用アカウントに集約
影響範囲ワークロード障害が共有基盤に波及隔離で影響局限
責任所在ワークロードチームと共有基盤チームが混在共有基盤チームに一元化
セキュリティ境界境界が曖昧明確な境界
コスト配分共有基盤コストが特定ワークロードに偏る共有コストを適切配分

SAA 試験のポイント

共有インフラをワークロードアカウントに混在させると、ブラストレディウスが拡大 します。 共有サービスアカウントに分離することで、ワークロード障害が共有基盤に波及しない。 SAA では「機能別アカウント分離の代表例」として頻出します。

AWS 推奨ランディングゾーンでの位置づけ

AWS 推奨のランディングゾーン（Control Tower 等）では 機能別アカウント分離 が基本です。

アカウント役割自動作成
Management組織のルート・請求既存
LogArchiveログ集約Control Tower 自動
Auditセキュリティ管理Control Tower 自動
SharedServices共有インフラ手動追加（推奨）
Workloadsアプリごと環境分離Account Factory

SAA 頻出

LogArchive, Audit は Control Tower が自動作成 しますが、 SharedServices アカウントは手動で追加 するのが AWS 推奨。 SAA では「SharedServices は必須だが Control Tower 標準構成には含まれない」点が問われます。

SAP レベル：高度な設計シナリオ

共有サービスアカウントの構成要素

SAP では 共有サービスアカウントに何を置くか を設計します。

SAP レベル：高度な設計シナリオ

SAP の共有サービスアカウント設計定石は 「ネットワークハブ + 認証基盤 + 名前解決 + 共有イメージ + SaaS ライセンス」の集約 です。これらを 1 アカウントに集約することで、 各ワークロードアカウントは「共有基盤を利用するだけ」に専念できます。

構成要素サービス設計論点
ネットワークハブTransit Gateway全アカウントの通信ハブ
認証基盤AWS Managed Microsoft ADAD トラストで既存 AD 連携
名前解決Route 53 Resolver, PHZハイブリッド DNS
共有イメージAMI 共有, ECR PrivateGolden AMI / Container
SaaS ライセンスVPC エンドポイント, License Managerライセンス一元管理
共有ログ統合ログ基盤 (LogArchive と連携)集約分析

Transit Gateway によるネットワークハブ

Transit Gateway (TGW) を共有サービスアカウントに配置し、 全ワークロードアカウントを集約します。

[共有サービスアカウント]
  └── Transit Gateway (中央ハブ)
        ├── VPC-App-A (本番アカウント)
        ├── VPC-App-B (開発アカウント)
        ├── VPN / DX (オンプレミス接続)
        └── VPC-SharedServices (共有サービス自身)
  • TGW は共有サービスアカウントに作成: 中央集約
  • RAM 共有: TGW を他アカウントに共有 (AWS Resource Access Manager)
  • ルートテーブル: セグメンテーションで本番 / 開発を分離
  • TGW Peering: リージョン間 TGW 接続

TGW 配置の設計論点

TGW は共有サービスアカウントに作成し、AWS RAM で他アカウントに共有 するのが SAP 定石です。 各ワークロードアカウントは自分の VPC を共有 TGW にアタッチするだけ。 これで「中央管理のネットワークハブ + 各アカウントの自律的アタッチ」を実現します。

Active Directory の集約

AWS Managed Microsoft AD を共有サービスアカウントに配置し、 全ワークロードアカウントから利用します。

構成説明ユースケース
AWS Managed AD (単体)AWS 内に独立 ADクラウドネイティブ
AD トラスト (Forest Trust)オンプレミス AD と信頼関係既存 AD 活かす
AD Connectorオンプレミス AD へのプロキシ軽量統合
[共有サービスアカウント]
  AWS Managed Microsoft AD
       │ (AD トラスト / Connector)
       ▼
[オンプレミス AD]
       │
       ▼ (ハイブリッド認証)
[全ワークロードアカウント] が AD を利用
  - EC2 Windows のドメイン参加
  - RDS for SQL Server の Windows 認証
  - AWS SSO との連携

AD 集約の設計論点

AWS Managed AD はマルチ AZ で配置 し、AD Connector で二重化 するのが SAP 定石です。 AD が単一障害点 (SPOF) になると全ワークロードの認証が停止するため、可用性設計が必須。

ハイブリッド DNS の集約

Route 53 Resolver エンドポイント と Private Hosted Zone (PHZ) を 共有サービスアカウントに集約し、ハイブリッド DNS を一元管理します。

  • Inbound Endpoint: オンプレミスからの AWS 名前解決を受付
  • Outbound Endpoint: AWS からオンプレミスへの名前解決を転送
  • PHZ 共有: 共有サービスアカウントの PHZ を AWS RAM で全アカウントに共有

PHZ 共有の論点

1 つの PHZ を AWS RAM で全ワークロードアカウントに共有 すると、 DNS 管理を一元化できます。各アカウントが独自 PHZ を持つと不整合が生まれるため、 SAP では「共有サービスアカウントの PHZ を RAM 共有」が定石です。

Golden AMI と Container Image の共有

標準化されたゴールデンイメージ を共有サービスアカウントで管理し、 全ワークロードアカウントに共有します。

イメージ種別共有方法設計論点
Golden AMIAMI 共有 (Launch Permission) / KMS 共有セキュリティパッチ適用済み
Container ImageECR Private リポジトリ + RAM 共有プライベートレジストリ
Lambda LayerLambda Layer のクロスアカウント共有共通ライブラリ
[共有サービスアカウント]
  └── Golden AMI Pipeline (CodePipeline + EC2 Image Builder)
        ├── セキュリティパッチ適用
        ├── コンプライアンスチェック
        └── AMI 公開 (Launch Permission で全アカウントに共有)
              │
              ▼
[全ワークロードアカウント] が標準 AMI を起動

Golden AMI の設計論点

EC2 Image Builder で自動パイプラインを構築し、 定期的にセキュリティパッチ適用済み AMI を自動生成・共有するのが SAP 定石です。 これで「全アカウントが常にパッチ済み AMI を利用」を実現します。

License Manager によるライセンス管理

AWS License Manager で組織全体のソフトウェアライセンスを一元管理します。

  • ライセンス設定: vCPU 数等のライセンス条件を定義
  • 使用状況監視: 全アカウントのライセンス使用を追跡
  • ルール違反検知: ライセンス超過を検知して通知 / ブロック

ライセンス管理の重要性

ソフトウェアライセンス違反は法的リスク になります。 License Manager で組織全体のライセンス使用を一元監視し、 違反を自動検知する構成が SAP のコンプライアンス定石です。

共有サービスアカウントのサービスを PrivateLink で全アカウントに提供 します。

[共有サービスアカウント]
  └── NLB → 内部ツール (監視、CI/CD 等)
        │ (PrivateLink サービス公開)
        ▼
[全ワークロードアカウント]
  └── VPC Endpoint からプライベートアクセス
  • インターネット不経由: PrivateLink でプライベート接続
  • CIDR 重複許容: ワークロードアカウントの CIDR に依存しない
  • 中央管理: 共有サービスアカウントでサービスを一元管理

SAP レベル：高度な設計シナリオ

SAP では 「共有サービスは PrivateLink で全アカウントにプライベート提供」 が定石です。 CIDR 重複を許容するため、ワークロードアカウントのネットワーク設計に影響を与えず、 共有サービスを安全に提供できます。

共有サービスアカウントの可用性設計

共有サービスアカウントは SPOF になり得る ため、可用性設計が重要です。

要素可用性設計設計論点
Transit GatewayAWS 管理で自動マルチ AZAWS 任せ
Managed ADマルチ AZ 標準自動フェイルオーバー
Route 53 Resolver複数 AZ に ENI冗長化
NLBマルチ AZクロスゾーン負荷分散
EC2 Image Builderパイプラインの監視自動再実行

共有サービスアカウントの SPOF リスク

共有サービスアカウントが停止すると全ワークロードに影響 します。 TGW は AWS 管理で高可用性ですが、AD や Resolver は設計次第。 SAP では「全要素をマルチ AZ + 監視」が共有サービス可用性の定石です。

コスト配分の設計

共有サービスアカウントのコストを 各ワークロードに適切に配分 します。

コスト要素配分方法設計論点
TGW 料金アタッチメント数 / トラフィック量利用割合で按分
AD ライセンス利用アカウント数で均等割りシンプル
Golden AMI共有インフラとして一括経費扱い
PrivateLinkエンドポイント利用数利用ベース

コスト配分の政治的論点

共有インフラのコスト配分は政治的論点 になりやすいです。 「TGW コストをトラフィック量で按分」すると、大量トラフィックアカウントが不満を持つ可能性。 SAP では「配分ルールを事前合意」することが重要です。

制約と考慮事項

項目制約 / 注意
TGW RAM 共有AWS Resource Access Manager 経由
PHZ 共有AWS RAM でクロスアカウント共有
Managed ADマルチ AZ で冗長化必須
Golden AMIKMS キー共有が必要
PrivateLinkCIDR 重複許容

まとめ

  • SAA: 共有サービスアカウントは組織全体の共有インフラを集約、 ネットワーク / AD / DNS / イメージ等を一元管理、ワークロードと分離で影響局限、を理解する。
  • SAP: TGW ネットワークハブ、AD 集約、ハイブリッド DNS、Golden AMI 共有、 License Manager、PrivateLink 公開、可用性設計、コスト配分が求められる。

次は タグ戦略 で、コスト配分とリソース管理の基盤を学びましょう。

スポンサーリンク（広告枠） 728×90

関連記事