ある企業は、EC2 Image Builder のパイプラインで月に一度ゴールデン AMI を作成し、AWS Organizations の組織にある 30 個のメンバーアカウントで使用しています。メンバーアカウントは今後も増える予定です。 CloudOps エンジニアは、パイプラインを実行するたびに、追加されたアカウントを含むすべてのメンバーアカウントで新しい AMI からインスタンスを起動できるようにする必要があります。 運用上のオーバーヘッドを最小限に抑えながら、この要件を満たすソリューションはどれですか。
Image Builder で作った AMI を、組織のすべてのアカウントへ最小の手数で使わせる
ディストリビューション設定のターゲットアカウントに、メンバーアカウントの ID を指定する。
ディストリビューション設定のターゲットアカウント (targetAccountIds)を使うと、Image Builder は AMI を配布先のアカウントへコピーします。コピーされた AMI は各アカウントが所有するので、各アカウントで起動できます。
ただしこの方式には、すべての配布先アカウントに EC2ImageBuilderDistributionCrossAccountRole ロールを作成し、Ec2ImageBuilderCrossAccountDistributionAccess ポリシーをアタッチしておく前提があります。アカウントが増えるたびにロールの作成とアカウント ID の追加が必要になり、AMI とスナップショットも 30 個以上に増えます。運用上のオーバーヘッドが最小ではありません。
AWS Resource Access Manager (AWS RAM) のリソース共有を使用して、パイプラインが作成したイメージを組織全体と共有する。
AWS RAM では、Image Builder のコンポーネント・イメージ・レシピを組織と共有できます。共有を受けた側は、共有されたイメージを自分のレシピのベースイメージとして指定できます。
しかしパイプラインが作る AMI は Image Builder のリソースではなく、RAM で共有してもAMI の起動許可は付きません。共有を受けたメンバーアカウントは、この共有だけでは新しい AMI からインスタンスを起動できません。
ディストリビューション設定の起動許可に、AWS Organizations の組織の ARN を指定する。
ディストリビューション設定の起動許可 (launchPermission)には、アカウント ID のほかに組織の ARN (organizationArns) や組織単位 (OU) の ARN を指定できます。パイプラインを実行するたびに、作成された AMI へ自動で起動許可が付き、組織に後から加わったアカウントも対象に含まれます。
AMI の実体は所有アカウントに 1 つだけ残るため、配布先ごとのロールやコピーは必要ありません。
作成された AMI に起動許可を追加する AWS Lambda 関数を作成する。Amazon EventBridge ルールから関数を呼び出す。
EventBridge ルールでパイプラインの完了を受け、Lambda 関数から ModifyImageAttribute で起動許可を付ければ、各アカウントで起動できるようになります。
ModifyImageAttribute でも組織の ARN を指定できるので、アカウントの一覧は持たずに済みます。しかしルール・関数のコード・実行ロールを自分で作って保守し続ける必要があります。ディストリビューション設定の起動許可という組み込みの機能で同じことができるため、運用上のオーバーヘッドが大きくなります。
Image Builder の AMI を他のアカウントで使わせる問題は、AMI の実体をどこに置くかで選び分けます。
・起動許可 (launchPermission) — AMI は所有アカウントに 1 つ残り、アカウント・OU・組織に起動を許可します。組織の ARN なら追加されたアカウントも対象です。
・ターゲットアカウント (targetAccountIds) — AMI を各アカウントへコピーします。配布先ごとに専用のロールが必要です。
・AWS RAM — 共有できるのはコンポーネント・イメージ・レシピで、AMI の起動許可ではありません。
「組織全体で使わせる」「手数を最小に」なら起動許可に組織の ARN、「各アカウントが自分で所有する」ならターゲットアカウントです。