アカウントの分け方。本番・検証・開発を分ける設計

クラウドでは、本番・検証・開発の環境を、同じ1つのアカウントの中で分けるのではなく、アカウントなどの単位ごとに分ける設計が基本です。アカウントは、権限・費用・障害の影響の境目になるため、分けておくと、開発の作業の誤りが本番に及ぶことや、費用の内訳が混ざることを防げます。

使い始めの時期は、1つのアカウントにすべてを置いても困りません。ただ、利用が広がった後で分け直すのは手間がかかるため、早い段階で分け方を決めておくほうが、後の負担が小さくなります。こうした最初の土台の設計は、ランディングゾーンと呼ばれます。

分ける理由

AWS は、複数のアカウントを使う利点として、次のような点を挙げています。

• 本番と本番以外を別のアカウントにすると、既定の状態で、資源とデータがほかの環境から分かれる
• アカウントは、セキュリティ・アクセス・請求の境目になり、1つのアカウントで設定の誤りや不正な操作が起きても、影響をそのアカウントの中に抑えられる
• 費用は、既定でアカウントごとに分けて集計される
• サービスの利用の上限（クォータ）はアカウントごとに決まるため、1つの処理が上限を使い切っても、ほかに及びにくい
• 事業を買い取った場合、その事業のアカウントをそのまま自社の組織に移せる

出典：Benefits of using multiple AWS accounts（AWS）

1つのアカウントの中で、権限の細かな設定で環境を分けることもできますが、設定が複雑になり、誤りに気づきにくくなります。アカウントの単位で大きく分け、その中で最小の権限を設定するほうが、管理が単純になります。M&A の後に別の会社の環境をまとめる場面での考え方は、M&Aの後のクラウドの統合。アカウントと権限をどうまとめるかで説明しています。

各クラウドの単位と束ね方

3つのクラウドは、環境を分ける単位と、複数の単位を束ねる仕組みの名前が違います。

AWS

AWS は、組織単位（OU）の構成の例として、組織全体のセキュリティの決まりを当てるアカウントを置く「Security」、共通のネットワークなどの基盤を置く「Infrastructure」、業務の処理を置く「Workloads」、試しや開発のための「Sandbox」などを示しています。Workloads には本番と本番以外の両方を置く例になっており、Sandbox は本番の資源への接続を限った試しの場とされています。どう分けるかは、それぞれの会社が自社の要件に合わせて決める、と AWS は説明しています。

出典：Recommended OUs and accounts（AWS）

Microsoft Azure

Microsoft は、サブスクリプションを管理・請求・規模の単位とし、統制と分離のための管理の境目になる、と説明しています。開発・検証・本番の環境は管理の面で分けられることが多く、開発の環境は本番より緩い決まりで運用されることがあるため、サブスクリプションは Azure Policy の決まりを当てる境目として使われます。同じ決まりと権限を当てるサブスクリプションは、同じ管理グループの下に置き、管理・セキュリティ・接続・認証の基盤のサブスクリプションは、1つにまとめずに分けるよう勧めています。

出典：Subscription considerations and recommendations（Microsoft Learn）

Google Cloud

Google Cloud では、組織（会社）・フォルダ・プロジェクトの階層で資源を整理します。フォルダは部署・チーム・アプリケーションを表すのに使え、組織の中の小さな組織のように、分離と管理の委任の境目になります。フォルダに与えた権限は、その下のプロジェクトに引き継がれます。

出典：Resource hierarchy（Google Cloud）

分け方の例

中堅・中小の会社で始めやすい分け方の例を示します。会社の規模や業務に合わせて、増やしたり減らしたりしてください。

たとえば、ログの保管とセキュリティの確認を担う共通の基盤のアカウントを1つ、業務のシステムの本番のアカウントを1つ、検証と開発のための本番以外のアカウントを1つ置き、これらを束ねる仕組みの最上位で、組織全体の決まりを当てる形です。新しい技術を試すための試しのアカウントは、本番の資源につながらないようにしたうえで、必要になった時点で加えます。

本番と本番以外を分けたうえで、ログの保管やセキュリティの確認のためのアカウントを、業務の処理とは別に置くと、業務のアカウントで管理者の権限を持つ人がいても、記録を消されにくくなります。ログの扱いの基本は、ログの取り方と見方。何を、どのくらい残すかで説明しています。

分ける単位が増えるほど、それぞれに権限・監視・費用の通知を設定する手間も増えます。単位を作るたびに同じ設定を手で行うのではなく、インフラのコード化（IaC）とは。手作業の構築をやめる理由などで、決まった設定を自動で当てる仕組みを用意すると、設定のばらつきを防げます。

始めるときの注意

アカウントの分け方を決めるときは、次の点に気をつけます。

1. はじめから細かく分けすぎない：本番・本番以外・共通の基盤（ログ・セキュリティ）の3つ程度から始め、事業やシステムが増えたら足します
2. 管理者の権限を持つ人を絞る：束ねる仕組みの最上位（AWS の管理アカウントなど）に入れる人は、ごく少数にし、多要素認証をかけます
3. 費用の通知を単位ごとに設定する：開発のアカウントで消し忘れた資源が費用を生むことがあるため、予算の通知を設定します
4. 名前の付け方をそろえる：単位の名前に、環境（本番・検証・開発）とシステムの名前を入れ、タグの付け方も決めておきます
5. 作った単位の一覧を管理する：誰が責任者で、何に使っているかを記録します

2つ目の束ねる仕組みの最上位は、一般の業務には使わず、組織の管理だけに使うのが基本です。管理者のアカウントの守り方は、管理者アカウントの守り方。多要素認証と緊急用のアカウントで詳しく説明しています。

当社のご支援

当社は、AWS・Microsoft Azure・Google Cloud の環境の分け方の設計と、決まった設定を自動で当てる仕組みづくりを、クラウドの構築と運用管理でお手伝いしています。すでに1つのアカウントにさまざまな環境が混ざっている場合は、いまの状態の整理から、分け直す順番の計画までご一緒します。いまの状態を確かめたい場合は、クラウドの自己診断（無料）もお使いいただけます。