AWS / Google Cloud / Azure のアカウントについて調べてみた

2022.07.07

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは。

CX事業本部 Delivery部 MADグループ の田中孝明です。

弊社には AWS / Google Cloud / Azure の資格を合わせて40個以上獲得している社員がおり、自分も追いつけるように頑張っています。

3クラウドを学ぶ中で、一番最初に気になった組織・開発環境の分け方の思想について書き記しました。

最近では クラウド二刀流エンジニア というキーワードも出ており、複数のクラウドを学ぶことでプライマリクラウドに関する知識の拡充もできたりするメリットがあると思います。

ちなみに Google Cloud さんが 7月15日(金) にイベントをやるので是非参加してみてください。

AWS

AWS では環境ごとにアカウントをわける方法を推奨しており、複数のアカウントで運用するのが基本戦略になります。

例えば「Prod環境」「STG環境」「ITG環境」「Dev環境」ごとに AWSアカウント を分けます。

https://pages.awscloud.com/rs/112-TZM-766/images/20220428_17th_ISV_DiveDeepSeminar_Control_Tower.pdf より抜粋

Assume Role

「Prod環境」「STG環境」「ITG環境」「Dev環境」の各アカウントでデプロイなどの作業を行う場合、対象の環境に IAM ロールを用意し、この IAMロール に対して Assume Role を使って各環境で作業します。

Assume Role に関しては弊社のブログに知見が溜まってますので、是非そちらを参照してください。

AWS Organizations

複数の AWSアカウント を管理する方法に AWS Organizations を利用します。

新しいアカウントを作成する際に、組織単位 (OU)、またはサービスを提供する単位でグループ化できます。

AWS Resource Allocation Management (RAM) を使用して、組織内で AWS リソースを共有できたりします。

Google Cloud

Google Cloud で最初に当たる概念として Projects というものがあります。

構造としては Organization → Folders → Projects → Resources となります。

一つの 組織アカウント で複数プロジェクトを管理するのが基本戦略になります。

フォルダ

プロジェクトの上位に フォルダ というものがあり、ここでは部署、チームなどを階層で持たせることができ、その下に Product (例えば、あるサービスのバックエンドAPIなど)を作って管理できるようになります。

階層構造を持たせることで、適切なレベルの組織ポリシーに IAMポリシー を割り当てることができ、権限管理がしやすくなります。

プロジェクト

Folders の配下に「Prod環境」「STG環境」「ITG環境」「Dev環境」などの環境ごとに プロジェクト を作ることができます。

利用するリソースは全て プロジェクト に結びついており、請求先のアカウントも プロジェクト ごとに設定できます。

同じブロジェクト内のリソースは簡単に連携させることができます。別のプロジェクトのリソースにアクセスすることはできませんが、 共有 VPC または VPC ネットワーク ピアリング を使用することで、それが可能になります。

Azure

Azure は、 管理グループサブスクリプション の単位で環境を定義します。

管理グループとサブスクリプションを用いることで、柔軟な構造を作成しリソースを階層に整理して、統一されたポリシーとアクセス管理を適用できます。

以下はその例です。

サブスクリプション

サブスクリプションは、ユーザー アカウントと、それらのユーザー アカウントによって作成されたリソースをグループ化します。

Azureアカウントにリンクされている Azure サービスの論理ユニットで、いわゆる「Prod環境」「STG環境」「ITG環境」「Dev環境」毎にサブスクリプションを作成します。

サブスクリプションごとに使用できるリソースの量などの制限があります。

組織はサブスクリプションを使用して、ユーザー、チーム、またはプロジェクトによって作成されたコストとリソースを管理できます。

リソースグループ

Webアプリ、データベース、ストレージアカウントなどの Azure リソースをデプロイして管理するための論理コンテナーで、リソースはすべてリソースグループに属する必要があります。

注意する点として、リソースは1 つのリソースグループのみにしか所属することができません。 先にリソース グループを用意しておかないと、リソースをプロビジョニングすることができません。

Azure 管理グループ

Azure 管理グループ は、複数のサブスクリプションのアクセス、ポリシーなどを管理するのに役立ちます。 Azure 管理グループ は、サブスクリプションより上の階層になります。

Azure 管理グループ内のすべてのサブスクリプションは、管理グループに適用された条件を自動的に継承します。 組織に多数のサブスクリプションがある場合は、それらのサブスクリプションのアクセスやポリシーを効率的に管理する方法が必要になることがあります。

余談

IAM の違いを書こうとして力尽きました。これはまたの機会に・・・

3社のネットワークの違いについては「Google Cloud でクラウド二刀流エンジニアを目指すための「早わかり集中技術講座」」の第一回目の放送、「Google Cloud でクラウド二刀流エンジニアを目指すための「早わかり集中技術講座」 〜 インフラ編 〜(60分)」がおすすめです。

登録すれば見れると思いますので、是非ご参照を。