本文へスキップ
BecomeCoder

AWS SAP（ソリューションアーキテクト プロフェッショナル）コース　·　第1章　SAP試験の全体像とプロフェッショナルの設計思考　·　レッスン4

AWSアカウントの分割と統治という発想

導入

SAP最大の特徴は、「1つのアカウントの中の設計」から「複数アカウントをまたいだ設計」へ視点が上がることです。なぜ組織はアカウントを分けるのか。その動機を先につかむと、第2章以降の統治の話が腑に落ちます。

説明

小さなシステムなら1つのAWSアカウントで十分ですが、組織が大きくなると 複数のアカウントに分割 するのが定石です。分ける理由は主に次の4つです。

分ける理由具体例
分離（Blast Radius の限定）本番と開発を別アカウントにし、事故の影響範囲を閉じ込める
セキュリティ境界アカウント単位で権限・データを隔離する
課金の分離事業部・プロジェクトごとにコストを可視化・按分する
制限の緩和サービスクォータはアカウント単位。分ければ枠が増える

こうして増えたアカウントを、バラバラに放置すると統制が効きません。そこで AWS Organizations で全アカウントを1つの組織にまとめ、OU（組織単位） でグループ化し、SCP（サービスコントロールポリシー） で「そもそも何を許すか」の上限を一括でかけます。

flowchart TD
    ROOT["管理アカウント<br/>（AWS Organizations）"] --> OU1["OU: 本番"]
    ROOT --> OU2["OU: 開発"]
    ROOT --> OU3["OU: セキュリティ"]
    OU1 --> A1["本番アカウントA"]
    OU1 --> A2["本番アカウントB"]
    OU2 --> A3["開発アカウント"]
    OU3 --> A4["ログ集約アカウント"]

読んでみよう

「1アカウント1システム」から「たくさんのアカウントを組織として束ねる」へ ―― この発想の転換がSAPの入り口です。第2章では、この Organizations・OU・SCP・Control Tower を使った マルチアカウント統治 を本格的に学びます。ここでは「大きな組織はアカウントを分ける。分けたら束ねて統治する」という骨格だけ押さえてください。