AWS ソリューションプロバイダー向け AWS Control Tower のベストプラクティス

皆様、こんにちは。
AWS Japan パートナーソリューションアーキテクトの大場 (@takaohba) です。

AWS ソリューションプロバイダープログラムの AWS コンサルティングパートナーの場合、マルチアカウントアーキテクチャを必要とするお客様がいる場合があります。

これは、複数のお客様の AWS Organizations 内で、お客様に分離された Organizational Units（OU）を提供することで実行できますが、これが不可能なシナリオもあります。最近見た中で最も一般的なシナリオは、AWS Control Tower を活用したいというお客様の要望です。

本投稿では、ソリューションプロバイダープログラムのお客様が AWS Control Tower を活用するためのアプローチについて詳しく説明します。最初に、ソリューションプロバイダープログラムと AWS Control Tower がどのように関連しているかについて簡単に説明し、次に導入から継続的な運用までのプロセスを機能させる方法について詳しく説明します。
この投稿では、 AWS Organizations の用語と概念に精通していることを前提としています。

AWS ソリューションプロバイダープログラムの概要

AWS ソリューションプロバイダープログラムは、システムインテグレーター、マネージドサービスプロバイダー（MSP）、Value-Added Reseller、および公共部門パートナーなど、付加価値をエンドカスタマーに提供するパートナーが AWS サービスを再販するためのプログラムです。
このプログラムでは、ソリューションプロバイダーがエンドカスタマーの AWS アカウントを管理、サービス、サポート、および請求をします。
ソリューションプロバイダープログラムには、エンドカスタマーアカウントモデル (ECAM) とソリューションプロバイダーアカウントモデル (SPAM) の 2 つのアカウント所有モデルがあります。
どちらのモデルでも、AWS パートナーがすべてのアカウントの請求を担当します。この 2 つのモデルはアカウントの所有権に関して違いがあります。アカウントの所有者は、AWS カスタマーアグリーメントに同意し、root ユーザーのメールアドレスを所有しているエンティティとして定義されます。

図1. 2つのソリューションプロバイダープログラムアカウントモデルの比較

ソリューションプロバイダーと AWS Organizations

ソリューションプロバイダープログラムの請求の背景は、AWS Organizations Consolidated Billing です。パートナーは、 AWS Organizations 内で次のようなアカウントアーキテクチャを自由に選択できます。

マルチカスタマーアーキテクチャに単一の AWS Organizations を活用します。この構造では、すべての顧客に対して単一の支払いアカウント (Payer Account) が存在します。
顧客ごとに個別の AWS Organizations を用意します。この構造では、パートナーはソリューションプロバイダープログラムの機構の中に複数の支払いアカウント (Payer Account) を持ちます。
または、複数顧客の Organization と単一顧客の Organization が混在している可能性があります。この構造の場合にも、複数の支払いアカウント (Payer Account) を持ちます。支払いアカウント (Payer Account) は Organization ごとに 1 つです。

アカウントアプローチは通常、顧客の要件またはパートナーのバックエンドの請求設定に基づいています。すべてのアカウントアーキテクチャでは、パートナーが Organization の管理アカウント (Management Account) を所有している必要があります。ソリューションプロバイダープログラムのアカウントモデルは、どのエンティティが子アカウントを所有しているかを決定します。
パートナーは、各支払いアカウント (Payer Account) をソリューションプロバイダープログラムに個別にオンボーディング※する必要があります。
ここからは、AWS Control Tower を活用することで AWS Organizations のアーキテクチャの決定をどのように推進するかに焦点を当てます。

※ここでの “オンボーディング” とはソリューションプロバイダープログラムへの管理アカウント (Management Account) の登録を指します。

AWS Control Tower の概要

AWS アカウントは、ワークロード、開発ライフサイクル、アクセスパターン、課金制御などを分離するためのリソースコンテナーとして機能できるため、お客様はますますマルチアカウント戦略を採用しています。詳細はマルチアカウントのベストプラクティスをご覧ください。
AWS Control Tower は、安全なマルチアカウント AWS 環境をセットアップおよび管理するための最も簡単な方法を提供します。

ソリューションプロバイダーと AWS Control Tower

ソリューションプロバイダープログラムと AWS Control Tower はどちらも AWS Organizationsを活用しているため、要件が交差する場所を理解する必要があります。
AWS Control Tower に関連するソリューションプロバイダープログラムの機能は次のとおりです。

パートナーは支払いアカウント (Payer Account) を所有する必要があります。
支払いアカウント (Payer Account) は、エンドカスタマーアカウントモデル (ECAM) またはソリューションプロバイダーアカウントモデル (SPAM) のいずれかに関連付けられています。
パートナーは、各タイプ (ECAM, SPAM) の複数の支払いアカウント (Payer Account)を持つことができます。
パートナーは、エンドカスタマーアカウントモデル (ECAM) で顧客に代わってアカウントを作成し、それらのアカウントを顧客が所有することができます。

ソリューションプロバイダープログラムに関連する AWS Control Tower の機能は次のとおりです。

支払いアカウント (Payer Account) でもある Organization の管理アカウント (Management Account) 内にデプロイされます。
AWS Control Tower を管理するには、顧客は支払いアカウント (Payer Account) にアクセスする必要があります。
ロギングアカウントと監査アカウントを含む子アカウントの電子メールドメインは、管理アカウント (Management Account) とは異なる場合があります。

※管理アカウント (Management Account) は支払いアカウント (Payer Account) の役割もあり、組織内のアカウントによって発生した料金すべてに対する支払いの責任を負います。

ソリューションプロバイダーアカウントモデル (SPAM) の場合、主な考慮事項は、パートナーが単一顧客または複数顧客の AWS Control Tower を持つかどうかです。単一の顧客の場合、顧客ごとに個別の支払いアカウント (Payer Account) が必要です。
パートナーはすべてのアカウントを所有および管理するため、パートナーは AWS Control Tower を使用してマルチカスタマーアーキテクチャの Landing Zone を管理できます。
エンドカスタマーアカウントモデル (ECAM) の場合、顧客は独自の AWS Control Tower を管理するため、パートナーは単一顧客のセットアップを実行する必要があります。

ベストプラクティス

ソリューションプロバイダープログラム内で AWS Control Tower を活用して成功を収めるために重点を置く分野は、オンボーディングと運用の2つです。

オンボーディング ※

※ここでの “オンボーディング” とはソリューションプロバイダープログラムへの管理アカウント (Management Account) の登録を指します。

ソリューションプロバイダープログラムへの新規顧客のオンボーディングプロセスは、いくつかの要因によって異なります。

顧客は、エンドカスタマーアカウントモデル (ECAM) またはソリューションプロバイダーアカウントモデル (SPAM) でオンボーディングしていますか？
顧客は既存のアカウントを持っていますか？
アカウントはすでに既存の AWS Organizations の一部ですか？
既存の支払いアカウント (Payer Account) はソリューションプロバイダープログラムに移行していますか？
既存のアカウントには、 AWS Organizations 全体の AWS Artifact 契約がありますか？
AWS Control Tower をデプロイする予定はありますか？

既存のアカウントがない場合

顧客が既存のアカウントなしで新しく始めている場合、プロセスは簡単です。パートナーは支払いアカウント (Payer Account) を所有する必要があるため、パートナーはメールアドレスで新しいアカウントを作成し、AWS カスタマーアグリーメントに同意して、この新しい支払いアカウント (Payer Account) を SPP (ソリューションプロバイダープログラム) にリンクします。
この時点で、AWS Control Tower をデプロイできます。使用するソリューションプロバイダープログラムのアカウントモデルに応じて、ログアーカイブアカウントと監査アカウントで適切なメールアドレスを使用する必要があります。

既存のアカウントがある場合

顧客が既存のアカウントをお持ちの場合、顧客が既存の AWS Organizations、AWS Control Tower をデプロイしているかどうか、またはそれが単なるスタンドアロンアカウントであるかどうかを理解する必要があります。

既存の Organization がある場合

既存の Organization はあるが AWS Control Tower がデプロイされていない場合、いくつかのオプションがあり、正式な推奨事項を提供することは本投稿の範囲外です。
オプションは次のとおりです。

新しい支払いアカウント (Payer Account) を作成し、既存のすべてのアカウントを既存の Organization から離れて、パートナーが所有する新しい Organization に参加させます。このアプローチには運用上の考慮事項があります。
既存の支払いアカウント (Payer Account) の所有権をパートナーに譲渡してから、AWS Control Tower をそのアカウントにデプロイします。

これらのオプションの詳細については、AWSパートナーネットワーク (APN) 開発チームに問い合わせることをお勧めします。

AWS Control Tower が存在する場合

AWS Control Tower がすでに存在する場合、推奨されるアプローチは、顧客が少なくとも管理アカウント (Management Account) の所有権をパートナーに譲渡することです。これは、所有権の譲渡プロセスを通じて行うことができます。この変更は舞台裏で行われ、アクティブなワークロードには影響しません。

エンドカスタマーアカウントモデル (ECAM) では、アカウントの所有要件は、パートナーが支払いアカウント (Payer Account) を所有することです。
したがって、AWS Control Tower がすでに存在する場合、譲渡する必要があるアカウントは管理アカウント (Management Account) のみ※です。他のすべてのアカウントはそのまま (つまり、顧客が所有) にすることができます。

ソリューションプロバイダーアカウントモデル (SPAM) では、すべてのアカウントをパートナーの所有権に譲渡する必要があります。

パートナーは、新たに AWS Control Tower をデプロイして新しい支払いアカウント (Payer Account) を作成し、アカウントを新しい支払いアカウント (Payer Account) に譲渡することができます。ただし、AWS Control Tower の設定を分割して新しい設定に追加するには、事前作業が必要であり、過去の請求に影響を与える可能性があります。
最も混乱の少ないパスは、所有権の譲渡を並行して実行することです。これは、既存のサービスコントロールポリシー (SCP) を含む既存のワークロードに影響を与えません。

スタンドアロンアカウントの場合

リンクの手順に従って、スタンドアロンアカウントを直接 AWS Control Tower に登録します。

AWS Artifact 契約

顧客が既存の AWS Artifact 契約を結んでいる場合：

エンドカスタマーアカウントモデル (ECAM) では、デジタル署名されている限り、非支払いの子アカウントに移行します。
契約が Organization 全体のポリシーである場合、Organization の所有権が譲渡されるため、ワークロードアカウントで個々の契約に署名する必要がある場合があります。

特定の使用例の詳細については、APN の担当者にお問い合わせください。

運用

AWS Control Tower がセットアップされ、すべてのアカウントが正しいエンティティによって所有されたら、継続的な運用に関するいくつかの考慮事項があります。

AWS Control Tower へのアクセス
新しいアカウントの追加
コストの可視性

AWS Control Tower へのアクセス

ソリューションプロバイダーアカウントモデル (SPAM) の場合、パートナーはすべてのアカウントを所有し、AWS Control Tower を管理しているため、通常どおりのビジネスになります。
ただし、エンドカスタマーアカウントモデル (ECAM) は、パートナーとカスタマーの両方が管理アカウント (Management Account) にアクセスする必要があるという独自のシナリオを作成します。パートナーは請求のためのアクセス権を必要とし、顧客は AWS Control Tower を管理するためのアクセス権を必要とします。
初めに管理者ユーザーに AWS Control Tower をデプロイさせることをお勧めしますが、パートナーは、顧客が AWS Control Tower を管理するために必要なものだけにアクセスを制限できます。
役割がどのように見えるかについてのアイデアの詳細をご覧ください。

新しいアカウントの追加

管理アカウント (Management Account) の所有者はパートナーであるため、AWS Control Tower Account Factory (または AWS Service Catalog) を介して新しいアカウントが作成されると、パートナーはそのアカウントを作成します。
ただし、顧客がソリューションプロバイダープログラムに参加する場合、顧客はパートナーに、顧客に代わって新しいアカウントを作成する権限を与えることができます。
顧客は、パートナーがこれを行うことを書面で承認します。顧客の名前が新しい AWS アカウントにあり、root メールアドレスが顧客のメールドメインにある限り、顧客はエンドカスタマーアカウントモデル (ECAM) に基づいて AWS カスタマーアグリーメントに有効な署名をすることになります。
顧客は、新しいスタンドアロンアカウントを作成して、AWS Control Tower に登録することもできます。

コストの可視性

もう 1 つの考慮事項は、顧客は AWS Control Tower の管理アカウント (Management Account) にアクセスする必要があるため、支払いアカウント (Payer Account) にアクセスする必要があるということです。パートナーは、顧客にマージンを見せたくない場合は、AWS Cost Explorer へのアクセスを制限する必要があります。

まとめ

AWS Control Tower がますます採用されるにつれて、AWS ソリューションプロバイダープログラム内の AWS コンサルティングパートナーが AWS Control Tower が提供するマルチアカウントのメリットを活用できることが重要です。

本投稿で、AWS ソリューションプロバイダープログラムは、許可する顧客モデルの種類に柔軟性があることを学びました。この柔軟性は、エンドカスタマーのビジネスニーズに対応します。ただし、パートナーは、お客様向けに AWS Organizations を設計する方法に注意を払う必要があります。これは、AWS Control Tower の使用に直接影響します。

ソリューションプロバイダープログラムパートナーは、現在のアカウントと AWS の使用モデルの詳細な顧客プロファイルを収集する必要があります。このナレッジは、導入および運用フェーズでのベストプラクティスを推進し、お客様にポジティブな結果をもたらします。このアプローチは、AWS Control Tower の正常な使用をサポートし、新しいアカウントを追加して請求管理を維持するためのプラットフォームを作成します。

AWS ソリューションプロバイダープログラムの詳細については、プログラムページにアクセスしてください。AWS Control Towerの詳細については、製品ページにアクセスするか、AWS マネジメントコンソールで実際に試してみてください。

原文はこちら。

AWS JAPAN APN ブログ