複数のワークロードを 1 つのアカウントに集約するかアカウントを分離するか決定する

この記事は Deciding between large accounts or micro accounts for distributed operations at AWS (記事公開日: 2022 年 10 月 6 日) を翻訳したものです。

AWS におけるクラウドジャーニーを開始する際には、 AWS アカウント戦略を定義する必要があります。AWS アカウントをどのように編成するかは、ワークロード別、チーム別、専門分野別、ビジネスドメイン別、機能ドメイン別など、多くのバリエーションが考えられます。お客様からのよくある質問は、「複数のワークロードを 1 つの AWS アカウントに展開すべきか、それとも 1 つのワークロードごとに 1 つの AWS アカウントを持つべきか」というものです。この質問に回答し、後でワークロードを別のアカウントに移行する必要がないようにするための意思決定フローを紹介します。

マルチアカウント戦略は、AWS において強固な基盤を構築するための最も重要な柱の 1 つです。マルチアカウントを採用すると、コスト、サービス制限、障害の影響範囲およびリソースを分離する区画を作成することができます。ホワイトペーパー「Organizing Your AWS Environment Using Multiple Accounts」には、その利点とさらに詳細な情報が掲載されています。このホワイトペーパーは、マルチアカウント戦略に関するベストプラクティスと、それを AWS Organizations を使用してどのように実装することができるかを説明しています。さらに、AWS 上に基盤を構築する際に基礎となるコンセプトは、AWS Prescriptive Guidance によってより深く調べることができます。この資料ではランディングゾーンについて説明しており、マルチアカウント、ネットワーク、セキュリティ、およびモニタリングのベストプラクティスに従ってワークロードをホストするために使用できるアーキテクチャが提示されています。お客様は Organizations を使用しマルチアカウント戦略を実現するランディングゾーンを作成するとともに、 AWS Control Tower によりベストプラクティスを適用した環境を迅速に構築することができます。

マルチアカウント戦略やランディングゾーンの概念を理解されているお客様でも、次のような疑問を持たれている場合があります。

新しいワークロードを展開する場合、新しいアカウントを作成するべきか、それとも既存のものを使用するべきか？
1 つのアカウントで複数のワークロードを持つか、1 つのワークロードごとに 1 つのアカウントを持つか、どのようにして決定すればよいのでしょうか？
マルチアカウント構成に適した運用モデルとはどのようなものか？

このブログでは、ラージアカウント（複数のワークロードを持つ）とマイクロアカウント（単一のワークロードを持つ）の使い分けにおける意思決定フローを紹介します。

運用モデルの理解

運用モデルは、運用における役割、チーム、プロセス、責任などを定義するものです。AWS はクラウド環境における運用モデルに関するドキュメントを公開しており、詳細なガイダンスを紹介しています。最初のステップは、AWS クラウドの運用モデルを選択することです。各運用モデルはそれぞれの強みと前提条件があり、柔軟なランディングゾーンを設計することが重要です。最も一般的な運用モデルは、次の 2 つです。

一元化された運用モデル：このモデルでは、アプリケーションのインフラストラクチャは一元化されたチームによってプロビジョニングと管理が行われます。つまり、このチームは、コンピューティング、ネットワーク、ストレージ、セキュリティなど、すべてのインフラリソースを担当することになります。インフラストラクチャにアクセスするのは 1 つのチームだけなので、異なるアプリケーションに属する異なるリソースへのアクセスを分離する必要はありません。従来のオンプレミス運用と同様に、一元化された管理チームの中に専門チーム（ DBA、ミドルウェア、Windows、Linux ）がある場合は、ロールベースのアクセスコントロールを使用することができます。また、Infrastructure-as-Code （ IaC ）を採用する場合、一元化された管理チームがすべてを処理し、パイプラインを通じてデプロイメントを提供することも可能で、それによって一種の一元化された DevOps モデルを実行することができます。どちらの場合も、アプリケーションチームはインフラチームから完全に分離されています。開発者はアプリケーションのコードを扱い、インフラとパイプラインの構築は一元化されたインフラチームに依存します。インシデント発生時には、一元化されたインフラチームが最初のコンタクトポイントとなり、環境全体の主担当として機能します。トラブルシューティングの際にはアプリケーションチームも参加しますが、一元化された管理チームがすべてを主導します。このオペレーティングモデルは、「完全に分離された運用モデル」とも呼ばれます。
分散された運用モデル：このモデルは、独自のアプリケーション環境を構築・運用し、所有するプロダクトの管理を自チームで担当する、多職種で構成されるチームに最も適しています。これはビジネスユニットやアプリケーションチームへの委任のような形になります。この場合、チームまたはビジネスユニットは運用に責任を負いますが、その範囲はアプリケーションが使用するリソースに限定されます。このような独立性の高さから、他のチームのリソースにアクセスする踏み台にされることを避けるため、リソースを分離することを強く推奨します。この運用モデルを適用すると、分散されたチームは担当する 1 つまたはある特定のプロダクトの専門となります。インシデント発生時には、一元化されたインフラチームに依存することなく、このチームがすべての進行中のタスクを実施する責任を負います。この運用モデルは、「分離されたアプリケーションエンジニアリングおよびオペレーション（AEO）と一元化されたインフラストラクチャーエンジニアリングおよびオペレーション（IEO）」とも呼ばれます。

これらの運用モデルは、運用の観点からリソースに必要な分離レベルを考慮し、どの種類のアカウントでワークロードをホストするかの決定に影響を与えます。しかし、検証すべき判断基準はこれだけではありません。障害の影響範囲の分離や、サービス制限の競合など、評価すべき技術的な側面はほかにもあります。たとえばアカウント内に複数のワークロードが存在している場合、システム障害の際には影響を受ける範囲を評価する必要があります。もう 1 つのポイントは、AWS のサービス制限を考慮することです。サービス制限は、アカウントにおけるリージョン単位に関連づけられ、各サービスごとに上限が割り当てられています。そのため、同じアカウント内に存在するワークロードが、サービス制限の割り当てを共有することができるかどうかを把握することが非常に重要となります。

では、運用からアプリケーションに視点を変えてみましょう。AWS のサービスやお客様のアプリケーションは、IAM のロールを引き受けることによって権限が付与されます。これは、アプリケーションが AWS サービスと相互作用を可能にするための方法です。例えば、Amazon DynamoDB テーブルを更新する AWS Lambda 関数がある場合、Lambda が引き受けたロールによって DynamoDB テーブルに対する更新アクションの実行を許可することができます。複数のワークロードがアカウントを共有する場合には、アプリケーションが必要とする分離のレベルを分析しなくてはなりません。Lambda 関数、コンテナ、Amazon Elastic Compute Cloud （ Amazon EC2 ）インスタンスは、関連するリソースのみにアクセスできるよう権限を制限すべきです。このレベルで権限の分離を実現するには、IAM のロールとポリシーの管理を担当するアイデンティティとアクセス管理（ IAM ）管理チームが必要となります。

IAM 管理チームは、属性ベースのアクセス制御（ ABAC ）、リソースレベルの許可、タグベースの認可を活用して、リソースを分離することができます。このことにより、各アプリケーションがそれ自身のリソースにのみアクセスすることを可能にします。AWS サービスごとに認可の条件は異なるため、IAM と連携する AWS サービスを参照し、各サービスでサポートされている機能を確認することが重要です。一方、マイクロアカウントの場合、アプリケーションのアクセス分離は、アカウントが分離されていることによりすでに実現されることになります。

マルチアカウントのベストプラクティスで説明されているように、ソフトウェア開発ライフサイクルごとにワークロードを分けることが推奨されます。つまり、開発、ステージング、本番がそれぞれ独自のアカウントを持つべきです。また、さらに 1 つのアカウントを「サイドカー」として機能させ、すべての環境のアカウントを通じてワークロードの変更を構築、検証、昇格、リリースするためのリソースやパイプラインを提供することもできます。以降、意思決定フローの説明はこのアカウント構成に従っていることを前提とします。この構成では、各環境（開発、ステージング、本番）に対応する Organizational Units（OU）が存在することになります。また、インフラストラクチャサービス、セキュリティ、ログ、および複数のワークロードをサポートするその他の共有サービスに関連するアカウントをサポートするために、他の OU が必要になる可能性があります。この投稿では、新規アカウントを作成するか、既存アカウントを再利用するかの意思決定フローに焦点を当てているため、これらの OU についての記載は省略します。これらの構成に関する詳細な情報は AWS Prescriptive Guidance を参照することにより得ることができます。

あなたがプロダクトオーナーで、新しいプロダクトを開発するために一緒に働いているチームがいて、新しいアカウントが必要かどうかわからないと仮定してみましょう。ここでも、上記の前提に従いあなたの組織にはすでに各環境に対応する OU が定義されているとし、アプリケーションを出発点に意思決定のフローを見ていきましょう。プロダクトオーナーが行うアプリケーションに関する意思決定は、運用モデル、障害の影響範囲の縮小、サービス制限の競合などに影響されるはずです。

運用モデル：最初に検討すべきは、一元化された運用モデルか分散された運用モデルかということです。これは、企業やプロダクトオーナーがどのような運用モデルを採用しているかによります。この意思決定フローの主な目的は、アカウントまたは環境の所有者を定義して、あいまいな境界（関連する問題や事象が発生した場合の連絡先がないリソース）が発生しないようにすることです。リソースのコンテナとして機能するアカウントにはアクセスや制限を決定できる所有者が必要であり、したがって所有者はセキュリティ問題、コンプライアンスルール、タグ、コスト、ワークロードの可用性などの運用に関する主要な連絡先となります。ベストプラクティスとして、IAM 管理チームはワークロードの管理から切り離されている必要があります。つまり、どちらの運用モデルを選択しても、以下の説明のとおりアクセス管理は一元化されたセキュリティチームに属することになります。
1. 一元化された運用モデル：
  1. アプリケーションチームは、アプリケーションコードに責任を持ちます。
  2. インフラストラクチャーチームは、コンピュート、ストレージ、ネットワーク、トラブルシューティングのタスクに責任を持ち、全体的な SLA を遵守します。ここにはアカウントの所有者が含まれます。
  3. IAM 管理チームはアクセス管理を担当します。
2. 分散された運用モデル：
  1. アプリケーションとインフラストラクチャーは同じチームによって管理され、ワークロードを構築し実行する。ここにはアカウントの管理者が含まれます。
  2. IAM 管理チームはアクセス管理を担当します。
障害の影響範囲の縮小：ワークロードの重要度によっては、一元化された運用モデルを選択した場合でも、障害の影響範囲を縮小する方法を検討する必要があります。その場合、新しいアカウントを作成し、ワークロードを分離することが必要になります。このステップにより、障害が複数のワークロードに影響を与える可能性がある「巨大なアカウント」を回避します。
サービス制限の競合：同じアカウントを共有しているワークロードは、リージョン単位のサービス制限を共有します。そのため、競合を慎重に分析し、新しいアカウントが必要かどうかを判断します。

意思決定フローを適用する

では、プロダクトオーナーになりきって、アプリケーションを起点に次のような意思決定フローを考えてみましょう。

図1. ワークロードを配置する AWS アカウント選択の意思決定フロー（訳注 Blast Radius : 障害の影響範囲）ステップ 1: アプリは一元化と分散のどちらの運用モデルを使用しているか？ステップ 2: アプリは障害の影響範囲の縮小を必要としているか？ステップ 3: 他のアプリケーションとサービス制限の競合が懸念されるか？

最初のシナリオとして、あなたがプロダクトオーナーであり、チームが AWS での運用について十分な知識を持っていない場合、あるいはあなたの会社がすべてのワークロードについて一元化された運用モデルを採用していると仮定してみましょう。その場合、フローの最初の質問に対する答えは、開発チームはアプリケーションを構築し、一元化された運用チームが提供するパイプラインとインフラを使用するだけの一元化された運用モデルを採用することです。しかし、さらに分析が必要な点があります。他のアプリケーションが原因でアカウントが侵害され、その影響があなたのアプリケーションに及んだらどうなるでしょうか？このリスクに直面したくない場合、あるいはビジネス上の影響が大きすぎる場合は、障害の影響範囲を小さくする必要があります。つまり、アプリケーションを分離するために一元化された管理チームが提供する新しいアカウントを作成する必要があります。一方、障害の影響範囲を小さくする必要がなく、同じアカウントでサービス制限の競合が発生しない場合、一元化された管理チームが所有する既存のアカウントを利用することもできます。また、明確であるものの強調すべきは、各アカウントに窓口となる所有者を設定することです。一元化された管理チームは、顧客の要件と上記の図に記載の意思決定フローに基づいて、ワークロードを配置する場所として最適なアカウントを決定していきます。前述したように、属性ベースのアクセス制御（ ABAC ）を使って、必要に応じて開発者が共有アカウントのリソースにアクセスできるようにすることも可能です。

2 つ目のシナリオは、チームが特定のプロダクトの構築と運用を合わせて行うことができる場合です。このシナリオでは、アプリケーションのコードとインフラストラクチャーの両方を 1 つのチームが担当します。このチームはコードとインフラストラクチャーのデプロイメント、インシデントのトラブルシューティングにも責任を持ち、運用を担当します。それを可能にするために、チームがアカウントの全リソースの所有者となるよう、アカウントへのアクセスをチームに委譲する必要があります。このモデルを採用する利点は、アプリケーションのバックログがチーム内で自己完結し、他のチームとの外部依存を避けられることです。また、チームはインシデントに対応し、アプリケーションの SLA を遵守する責任があります。そのためには、1 つのプロダクトのみをサポートする専用のアカウントが必要になります。

重要なことは、マイクロアカウントはチームと結びつけてはいけないということです。代わりに、アカウントはプロダクトに結びつけます。その理由は、プロダクトのライフサイクルの中でチームに変更が加わることがあるからです。マイクロアカウントをチームに結びつけるべきではない理由を説明するために、チーム A がマイクロアカウントを使って自分たちのプロダクト A を構築して運用しており、しばらくしてプロダクト B も担当するようになり、プロダクト A と同じアカウントにデプロイしたとします。プロダクト A とプロダクト B は同じアカウントにあるため、権限を共有し、同じリソースにアクセスします。こうなると、プロダクト B をチーム B のアカウントに移行することが必要になってきます。そうではなく、プロダクト B が独自のアカウントで作成されていれば（最初はチーム A が管理していたとしても）、よりシンプルに引き継ぎを行うことができます。プロダクト B のアカウントでチーム B にアクセス権を与え、チーム A のアクセス権を取り消せばよいのです。

一元化された運用モデルを採用する 1 つ目のシナリオと比較すると、新しいチームにコードリポジトリや開発環境へのアクセスを提供するだけでよいのです。すでにプロダクトに関するすべてが一元化されており、運用に必要な権限もすべて設定されているため、プロダクト B の引き継ぎ作業や、別の運用チームやアカウントに移行する必要もありません。

意思決定フローに沿って選択を行うことにより、ワークロードを既存の AWS アカウントにホストするか、新しいアカウントを作成するかを決定することができます。その結果、一元化と分散型の運用モデルは、ラージアカウントまたはマイクロアカウントと完全に対応するわけではないと言えます。それぞれのワークロードの要件に応じて、両方のオプションを選択することができるのです。つまり、ラージアカウントとマイクロアカウントのワークロードを同時に管理する一元化された運用チームを 1 つ持つこともできるのです。あるいは、マイクロアカウントでワークロードをサポートする分散された運用チームやビジネスユニットを持つことも可能です。

重要なポイント

新しいワークロードがどのようなアカウント群を使用するかは、運用モデル、障害の影響範囲、サービス制限、コストを考慮して決定することができます。それに加え、我々が現場から得た以下の教訓を共有します：

AWS をプラットフォームとして活用し、必要に応じてアカウントを分割します。必要に応じてマイクロアカウントを使って障害の影響範囲を小さくするとともに、自己完結型で独立してワークロードを構築して実行する、専門のアプリケーションチームにアカウントを委譲します。マイクロアカウントは分散された運用モデルに最適ですが、VPC の設定や NAT、IAM Permissions Boundary などの IAM コントロール、大量のガードレール配布のためのパイプライン、AWS Control Tower や他のサービスにおけるサービス制限の管理など、アカウントをプロビジョニングするサービスを自動化するためには一定の投資が必要となります。マイクロアカウントの増殖や不必要なアカウント作成を避けるために、バランスをとって集中管理型によるラージアカウントも検討してください。
一元化された運用モデルは、チーム間の障害の影響範囲の縮小や、リソースの分離を必要としないワークロードで使用されるべきです。さらに、アプリケーションの運用に十分なスキルを持っていない開発チームは、一元化された運用を活用する必要があります。インフラストラクチャーの運用を一元化されたチームが行う場合、アプリケーションチームのバックログと一元化された運用チームのバックログが統合して管理されないためにチーム間の依存関係が生まれ、プロジェクトの進行を遅らせる原因となってしまうかもしれません。AWS Service Catalog 、カスタマイズされたセルフサービスポータル、パイプラインなどは、このような依存関係を緩和するとともに、ラージアカウント内のコスト配分タグの適切な管理を促進することができます。巨大なアカウントの作成は、障害の影響範囲を拡大させるため、避けてください。
ラージアカウントの場合、アクセス管理チームは、リソースレベルの許可とタグに基づく認可を使用して、アカウント内のアプリケーション間でリソースを分離することができます。アクセス管理チームがボトルネックにならないように、必要に応じて IAM Permissions Boundaries やパイプライン、または自動化を採用して、IAM ロールとポリシーの作成を委譲します。
最小権限の原則は必須です。マイクロアカウントを使用することにより、最小権限の原則を適用しない影響を小さくすることができますが、それでも必須と考えるべきです。ラージアカウントとマイクロアカウントのいずれの場合でも、IAM API オペレーションを使用し、サービスへの最後のアクセスを定期的にエクスポートし、使用されていないアクションをアプリケーションのチームに報告し、ロールのポリシーを微調整することを促します。アプリケーションチームが現在の権限を認識し、適切に更新できるような検証サイクルを整備する必要もあるでしょう。
ランディングゾーンは、さまざまな種類のアカウントやオペレーティングモデルをサポートできるように整備しなくてはなりません。一元化または分散型の運用モデルや、ラージアカウントまたはマイクロアカウントを考慮し、柔軟なクラウド基盤を確立する必要があります。

結論

この投稿では、新しい AWS アカウントを作成するか、あるいは既存のアカウントを使用するかをガイドする意思決定フローを示しました。新規アカウント作成または既存アカウントへのワークロードの配置と、一元化と分散型の運用モデルをバランスを取って使い分けるためのメカニズムとして、この意思決定フローをご活用ください。

著者について

Alex Rosa

Alex Rosa は、フロリダを拠点とする AWS の Principal Cloud Infrastructure Architect です。過去数年にわたり、AWS クラウドを採用した数多くのエンタープライズ顧客を支援し、ビジネスサービスの向上を実現してきました。

Guilherme Greco

Guilherme Greco は、金融業界を専門とするエンタープライズソリューションアーキテクトです。インフラストラクチャとアーキテクチャの分野で19年以上の経験を持つ Guilherme は、2018 年以降、AWS へのクラウドジャーニーにおいて、ランディングゾーンの設定から大規模な移行まで、お客様の成功に貢献しています。

翻訳はプロフェッショナルサービスの野田隼平が担当しました。原文はこちらです。

Amazon Web Services ブログ