この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
AWS Organizations 管理しているメンバーアカウントに CloudFormation StackSets を使用して設定を入れるまでの流れを整理しました。AWS Organizations を利用しているため、CloudFormation StackSets はマネージド型で実行を前提に進めていきます。
AWS Organizations 環境下ではない場合はセルフマネージド型で同様に実現できます。
本記事で学べること
以下の設定手順を画面キャプチャをベースに設定の流れを把握できるように紹介します。
- CloudFormation StackSets 設定の有効化（マネージド型）
- 設定有効化に伴い作成される IAMロールの内容
- StackSet の実行
- CloudTrail の設定を有効化するサンプルテンプレートを使用
- メンバーアカウントに設定が反映されているか確認
- 自動デプロイ・削除機能の紹介
StacSets 有効化
管理アカウントの CloudFormation ダッシュボードから信頼されたアクセスを有効にするをクリックします。
以上で StackSets の有効化は完了です。
もう少し詳しく知る
設定を有効化するだけではあっさりしすぎているので有効化した裏側で起きていたことを少し知ってみましょう。
設定有効化に伴い以下の3つの IAMロールが作成されます。
- 管理アカウントに
AWSServiceRoleForCloudFormationStackSetsOrgAdminIAMロールを作成 - メンバーアカウントに以下2つのIAMロールを作成
stacsets-exec-*IAMロールAWSServiceRoleForCloudFormationStackSetsOrgMemberIAMロール
画像引用: AWS Black Belt Online Seminar - AWS CloudFormation deep dive
「信頼されたアクセスを有効にする」操作により管理アカウントに AWSServiceRoleForCloudFormationStackSetsOrgAdminIAMロールが作成されます。スタックセット実行時、ユーザーに代わり実行されるIAMロール（権限）です。引用した画像の左下のCFn(StacSets)の上にある IAMロールのことです。
今度はメンバーアカウントの IAMロールを確認します。stacksets-exec-*ロールとAWSServiceRoleForCloudFormationStackSetsOrgMemberロールが作成されています。
stacsets-exec-*
メンバーアカウント内でリソース作成するための IAMロールです。AdministratorAccessポリシーがアタッチされています。引用した画像の右上のCFn(Stack)の上にある IAMロールです。
管理アカウントのAWSServiceRoleForCloudFormationStackSetsOrgAdminロールを信頼しています。
{
"Version": "2012-10-17",
"Id": "stacksets-exec-251d50781e98790a942c1991e155f0f0-assume-role-policy",
"Statement": [
{
"Sid": "1",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:role/aws-service-role/stacksets.cloudformation.amazonaws.com/AWSServiceRoleForCloudFormationStackSetsOrgAdmin"
},
"Action": "sts:AssumeRole"
}
]
}AWSServiceRoleForCloudFormationStackSetsOrgMember
こちらはstacsets-exec-*ロールを生み出すために使われるロールでした。CloudFormationStackSetsOrgMemberServiceRolePolicyポリシーがアタッチされています。
CloudFormationStackSetsOrgMemberServiceRolePolicy
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"iam:CreateRole",
"iam:DeleteRole",
"iam:GetRole"
],
"Effect": "Allow",
"Resource": [
"arn:aws:iam::*:role/stacksets-exec-*"
]
},
{
"Action": [
"iam:DetachRolePolicy",
"iam:AttachRolePolicy"
],
"Effect": "Allow",
"Resource": [
"arn:aws:iam::*:role/stacksets-exec-*"
],
"Condition": {
"StringEquals": {
"iam:PolicyARN": "arn:aws:iam::aws:policy/AdministratorAccess"
}
}
}
]
}StakSet を試してみる
CloudTrail の設定を有効化するサンプルテンプレートを利用し、指定した OU 配下のメンバーアカウントに CloudTrail が設定されるか確認します。
ちなみにサンプルテンプレートはいろいろと用意されていました。
StacSet の実行
StakSet の作成をクリックします。
サービスマネージドアクセス許可を選択しました。AWS Organizations に付与された権限を利用して CloudFormation StackSet をデプロイします。
すべてのリージョンのログを1つのリージョンへ集約したいため、マルチリージョン設定を有効化するパラメーターはTrueにしています。
次へで進めます。実行設定はデフォルト値の非アクティブを選択しています。
詳しくは以下のリンクをご参照ください。
指定した OU に対して StackSet を実行したいため、組織単位（OU）へのデプロイを選択します。AWS OU ID はどこを確認すればよいのかというと
AWS Organizations のダッシュボードから対象の OU を選択すると ID を確認できます。こちらの ID を入力してください。
リージョンはバージニア北部（us-east-1）を選択しました。
スタックを実行するとオペレーションタブから実行状況を確認できます。
ステータスは数分でSUCCEEDになりました。
リージョンをすべて選択した場合の注意事項
今回サンプルで用いた CloudTrail の例ではすべてリージョンのログを1つのリージョン（ここではus-east-1）へ CloudTrail 自体に集約設定があるため、StacSet 実行時に複数のリージョンを設定することはありませんでした。
画像引用: 20210119_AWSBlackbelt_CloudTrail.pdf
StackSets の良いところは複数のリージョンに設定を入れることができます。一点注意して頂きたいことはすべてのリージョンを追加をクリックすると
文字通りすべてのリージョンが選択された状態になります。
本当にすべてのリージョンが選択された状態です。対象のアカウントでオプトインしていないリージョンがあるとスタックを実行すると以下のエラーになります。
オプトインされていないリージョンと言うのは、一部リージョンはデフォルトでは利用できない状態になっています。利用したい場合はオプトインする必要があります。
最新のデフォルトで利用できる・できないリージョン情報は以下のリンクを確認してください。
Regions and Zones - Amazon Elastic Compute Cloud
すべてのリージョンを追加を押した後に不要な（オプトインしていない）リージョンを削除するとエラーは回避できます。もしくは、手動で必要なリージョンを追加することになります。
メンバーアカウントから実行結果を確認
指定した OU（Sandbox）配下にあるメンバーアカウントへサインインしました。CloudFormation Stackset 実行前の CloudTrailの画面です。
before
CloudFormation Stackset 実行後に確認すると、証跡に設定が追加されています。
after
マルチリージョンの証跡も有効化されています。
ログが保存される S3バケットは指定したリージョンのus-east-1に作成されています。
以上が管理アカウントから指定した OU に対して CloudFormation Stackset を実行する流れでした。
OU 内のメンバーアカウントに自動的に設定が流しこまれるのは便利ですね。今回は OU 配下には1アカウントしかないため恩恵は感じにくいですが、100アカウントもあれば個別に設定を入れ込むのは大変ですからね。
補足
自動デプロイ・削除
自動デプロイという非常にありがたい機能があります。今回のスタックセット実行時、自動デプロイ・削除の設定はデフォルト値で有効化されていました。
- OU へアカウントを追加したときに CloudFormation テンプレートのスタックを自動でデプロイしてくれる
- OU からアカウントを削除（移動）したときに CloudFormation テンプレートを自動でスタックを削除してくれる
設定済みの OU にアカウントを追加すれば自動的に所定の設定が流し込まれ、OU からアカウントを移動すれば所定の設定を消してくれるという便利機能です。
詳しくは以下のリンクをご参照ください。
証跡一元管理
サンプルテンプレートでの CloudTrail 設定は個々のアカウントに対して、個々のアカウント内の S3バケットに証跡を保存するといった内容でした。
AWS Organizations の機能にはログアーカイブ用のアカウントを用意して、そのアカウントの S3バケットに各アカウントのログを保存し一元管理することが簡単にできます。
画像引用: 20210119_AWSBlackbelt_CloudTrail.pdf
詳しくは以下のリンクをご参照ください。
おわりに
AWS Organizations 環境下で StackSets を利用してメンバーアカウントに設定を入れ込むのは簡単そうな雰囲気を掴んでもらえれば幸いです。 実際には要件に合わせた CloudFromation のテンプレートを作成することになりますので、CloudFormation に関する学習コストが発生しますので念頭においていただければと思います。CloudFormation 経験者の場合は StackSets の使い方、パラメータの設定を把握するだけでよろしいかと思います。
また、本文中に画像を引用させていただいているAWS Black Belt Online Seminar - AWS CloudFormation deep dive資料が非常に参考になりました。
その他には AWS Organizations の環境ですと SCP で何かしら制限を設定している可能性があります。たとえば「東京リージョン以外にリソース作成させない」などリージョンによって制限がある場合は、 CloudFormation StackSets も同様に制限にひっかかりますのでご注意ください。
参考までに以下のリンクをご確認いただければと思います。
3
