この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
AWS Control Tower Workshops の AWS CONTROL TOWER IMMERSION / ACTIVATION DAY から推奨講座をやってみました。
Control Tower の基本と、Account Factory からのアカウント作成と、新規作成したアカウントへの設定を入れ込む方法をハンズオン形式で学べました。この辺を勉強する予定のある方はワークショップを確認してみてください。
AWS Control Tower Workshops :: AWS Control Tower Workshop
AWS CONTROL TOWER IMMERSION / ACTIVATION DAY
こちらのワークショップは AWS Control Tower のハンズオン集で全11章ありボリューム感は満点です。
AWS Control Tower Immersion / Activation Day :: AWS Control Tower Workshop
- Core Labs
- Customization & Automation
- Resource Provisioning
- Authentication & Authoriation
- Networking
- Security & Comliance
- Ops at Scale
- Machine learning and analytics
- Migration
- Value Added labs
- Workshops
章の数だけを見るだけでお腹いっぱいになるのですが推奨受講講座の一覧が紹介されています。すべてやるほど時間がないので推奨講座だけやってみました。
やってみた感想
- 推奨講座だけでも12時間がかかりました
- ブログ用にキャプチャ、メモを取る時間を含めているため、ただ実行するだけなら短縮できます
Customizations for Control Tower（CfCT）のパートで Account Factory でアカウント発行時に任意の設定をアカウントへ入れ込む実装をやっと理解できた- 個人的にはもっとも有益だった
Resource Provisioningの章は Service Catalog で製品をメンバーアカウントへ共有できることを把握できていればスキップしてもよい- Service Catalog の機能なら以下の様な運用上のお作法を確認する時間に充てた方が効果的に感じた
- Control Towerのメンバーアカウントを削除・解約する [2022年版] | DevelopersIO
検証環境
検証時のランディングゾーンのバージョンは 3.0です。
Core Labs
Control Tower の有効化して Account Factory からアカウントの新規発行、既存の AWS アカウントを Control Towrt へ登録仕方を学べます。
Deployment
「Control Tower を触ってみるか」と思っても Control Tower を操作できるようになるまでに時間も労力もかかります。
AWS アカウント上で AWS Control Tower 有効化（デプロイ）します。Control Tower を有効化するのに必要なランディングゾーンのセットアップ処理に60 〜 90分程度かかります。 Control Tower の有効化を済ませておくと良いです。Control Tower の有効化するための前提条件の確認も必要ですので確認作業に60分、ランディングゾーンセットアップ待ちに60分ほどみておくとよろしいかと思います。
私は Organizaitions 環境で運用していた AWS アカウントがありました。先日、検証のため Control Tower 有効化し、直後の状態で維持してある環境を流用します。
Account Factory & Existing Accounts
Account Factory からアカウントの新規発行、既存の AWS アカウントを Control Towrt へ登録するパートです。
Account Factory と Account Factory - Existing Accounts の章をベースに個人的に検証したかったことを実施済みした。内容はこちらをご参照ください。
Tasks in Control Tower
IAM Identity Center からのサインインユーザー作成を除けばほぼ座学パートです。
Control Tower のダッシュボードでなにが確認できるのかなど簡単な説明があります。知っておいた方が良かったことをまとめておきます。
Tasks in Control Tower :: AWS Control Tower Workshop
学べたこと
- OU 作成、アカウント作成、ガードレールの有効化・無効化などの Control Towrt の操作はシングルスレッド処理
- 例）複数個のアカウント作成を同時に並列処理ができない
- ガードレールの有効化・無効化の操作のたびに適用対象の OU に対して StackSets の更新が実行される
- 処理が完了するまでの時間は OU 内のアカウント数に依存する
Customization & Automation
Account Factory からアカウントの新規発行時に AWS Config ルールを自動追加などのベースラインを導入するためのセットアップと、実際にメンバーアカウントに IAM ロール作成、AWS Config ルール追加を自動追加、OU に SCP を設定する体験できるパートです。
Control Tower Life Cycle Events - Introduction
Account Factory からアカウントを新規発行時になにか設定を入れ込もうとすると、CfCT（Customization for AWS Control Tower）や、AFT(Account Factory for Terraform)を利用することになります。
上記の様なソリューションを使う前に基本的な Control Tower のライフサイクルイベントを把握しておきなさいという講座です。EventBridge のルールでフックして実装していることを理解できていれば、スキップして良いと冒頭で述べられておりますがやってみましょう。
Control Tower Life Cycle Events - Introduction :: AWS Control Tower Workshop
やってみた
EventBridge のルール作成します。OU 削除と、ガードレールを解除時のイベントをフックするルールです。
イベントをフックしたら System Manager OpsItem にイベントを登録します。
EventBridge のルールでイベントをフックしていることを確認します。比較のため実行前は OpsCenter 上にはなにもアイテムがないことを確認しておきます。
作業用の OU 作成します。
作業用の OU に対してガードレールを有効化します。項目は「コントロール:インターネットゲートウェイ (IGW) のルートテーブルにパブリックルートが存在するかどうかを検出する」です。
ガードレールを無効化してイベントを発生させます。
作業用の OU を削除してイベントを発生させます。
OpsCenter を確認するとアイテムが登録されています。
詳細みたところで意味のないアイテムです。
ルールや、OpsCenter にアイテムを登録する意味自体はないですが、EventBridge のルールで検知できることを確認しました。
学べたこと
- Control Tower イベントは EventBridge のルールで拾える
Customizations for Control Tower（CfCT）
Account Factory から新規アカウント作成時にユーザーが任意の規定設定を入れ込む方法を学べる個人的にオススメのパートです。
Customizations for Control Tower (CfCT) :: AWS Control Tower Workshop
環境構築
マネジメントアカウントに CfCT の実行環境をセットアップします。
用意されているテンプレートを実行するだけでお手軽に環境構築ができます。
CodePipeline のソースは Code Commit に変更してデプロイします。
デプロイが完了したら、Codecommit に作成されたレポジトリをクローンしてきます。アカウント新規発行時に設定を入れ込むための設定ファイルはマニュフェストと呼ばれる YAML ファイルです。
git clone https://git-codecommit.ap-northeast-1.amazonaws.com/v1/repos/custom-control-tower-configuration今回編集対象のファイルはディレクトリ直下のmanifest.yamlのみです。サンプルでファイルがついてきますが利用しませんでした。
$ tree
.
├── example-configuration
│ ├── manifest.yaml
│ ├── parameters
│ │ ├── create-ssm-parameter-keys-1.json
│ │ └── create-ssm-parameter-keys-2.json
│ ├── policies
│ │ └── preventive-guardrails.json
│ └── templates
│ ├── create-ssm-parameter-keys-1.template
│ └── create-ssm-parameter-keys-2.template
└── manifest.yamlマニュフェストを編集します。リージョン指定を Control Tower のホームリージョン（ap-northeast-1）に置換しました。設定対象の OU 指定は自分の環境に合わせる必要があります。SecurityとSandboxOU を対象にしています。
---
# Home region for CodePipeline, StepFunctions, Lambda, SSM, StackSets
region: ap-northeast-1 # Control Tower Home Region
version: 2021-03-15
resources:
# ControlTower Custom SCPs - Additional Preventive Guardrails
- name: test-preventive-guardrails
description: Prevent deleting or disabling resources in member accounts
resource_file: s3://marketplace-sa-resources-ct-ap-northeast-1/ctlabs/preventive-guardrails.json
deploy_method: scp
# Apply to the following OU(s)
deployment_targets:
organizational_units:
# New Essential OU names since ControlTower v2.7 April 16.
# Observe the names of your existing OUs and comment out or uncomment below to match yours.
- Security # Foremerly Core
- Sandbox # Formerly Custom
#- Core
#- Custom
# ControlTower Custom CFN Resources - Create Additional IAM Role
- name: create-iam-role
resource_file: s3://marketplace-sa-resources-ct-ap-northeast-1/ctlabs/describe-regions-iam-role.template
deploy_method: stack_set
deployment_targets:
organizational_units:
# New Essential OU names since ControlTower v2.7 April 16.
# Observe the names of your existing OUs and comment out or uncomment these to match yours.
- Security # Foremerly Core
- Sandbox # Formerly Custom
#- Core
#- Custom
regions:
- ap-northeast-1
# ControlTower Config Rule - Additional Detective Guardrails
- name: rotate-access-keys-guardrail
resource_file: s3://marketplace-sa-resources-ct-ap-northeast-1/ctlabs/access_keys_rotated.template
parameters:
- parameter_key: maxAccessKeyAge
parameter_value: '24'
deploy_method: stack_set
deployment_targets:
organizational_units:
# New Essential OU names since ControlTower v2.7 April 16.
# Observe the names of your existing OUs and comment out or uncomment these to match yours.
- Security # Foremerly Core
- Sandbox # Formerly Custom
#- Core
#- Custom
regions:
- ap-northeast-1マニュフェストの設定内容は簡単に確認しておきましょう。この辺はワークショップで一切触れられていないです。任意の設定を入れ込むための Cloudformation をテンプレートはワークショップ用に S3 へアップロードされたものを使う設定となっていました。本来であれば以下の様なテンプレートを用意することになるのだろうと思います。
access_keys_rotated.template
---
AWSTemplateFormatVersion: '2010-09-09'
Description: Checks whether the active access keys are rotated within the number of days specified in maxAccessKeyAge.
Parameters:
maxAccessKeyAge:
Type: 'String'
Description: 'Maximum number of days within which the access keys must be rotated. The default value is 90 days.'
Resources:
CustomConfigRule:
Type: AWS::Config::ConfigRule
Properties:
ConfigRuleName: ACCESS_KEYS_ROTATED
Description: Custom Config Rule - Checks whether the active access keys are rotated within the number of days specified in maxAccessKeyAge
InputParameters:
maxAccessKeyAge : !Ref maxAccessKeyAge
Source:
Owner: AWS
SourceIdentifier: ACCESS_KEYS_ROTATED
Scope:
ComplianceResourceTypes: []以下の設定がされるようになっています。
- ControlTower Custom SCPs - Additional Preventive Guardrails
- マネジメントアカウントから確認できる指定の OU に対して独自の SCP 作成しアタッチ
- ControlTower Custom CFN Resources - Create Additional IAM Role
- 指定の OU 配下のメンバーアカウントに対して独自の IAM ロールを作成
- ControlTower Config Rule - Additional Detective Guardrails
- 指定の OU 配下のメンバーアカウントに対して AWS Config のマネージドルールを追加
AWS Config のマネージドルールについては以下を参考ください。
設定を入れ込む
git pushするとCodePipelineが実行される
10分ほど待ち完了したら、環境構築完了です。
実行結果
SandboxOUと、SecurityOUを対象にしていました。SandboxOUを例にみていきます。
SandboxOUにSCPがアタッチされている
SandboxOU配下にあるSandbox2アカウントへサインインしました。指定した IAM ロールが作成されています。
AWS Config にはルールが追加されています。
マニュフェストファイル内で指定したパラメーター（parameter_value: '24'）が反映され、24日指定になっています。
学べたこと
YAML ファイルを書いて CodeCommit にアップしておけば OU 内のアカウントに規定の設定を入れ込める
Resource Provisioning
Service Catalog に登録したものをメンバーアカウントへ共有する方法を試すセクションです。
Deploy Additional Services
Service Catalog の製品（CloudFormation テンプレート）を特定の OU へ共有するパートです。
Deploy Additional Services :: AWS Control Tower Workshop
私は Service Catalog に馴染みがなくワークショップの概要を読んでも実施内容を理解できませんでした。そのため、先に以下のリンクを確認し Service Catalog とは？からはじめました。
やってみた
「製品」「ポートフォリオ」などの Service Catalog 用語が頻出します。平たく言うと「所定のネットワーク構成（VPC, Subnets, NAT Gateway...）を任意にデプロイ可能とするテンプレートをメンバーアカウント内で共有する」をやっていきます。
新しい製品を登録します。
適当な製品名を付けます。本来は自前の CloudFormation テンプレートをアップロードして使うものでしょうけど、ワークショップでは準備済みの S3 で公開されているテンプレートを指定します。
製品として登録されました。
次にポートフォリオ作成します。先ほど作成した製品（CloudFormation テンプレート）をメンバーアカウントへ共有してユーザーが任意に実行できる環境を作成するためにはポートフォリオに関連付けて共有することになります。
適当な名前を入力します。
今作成したポートフォリオにさきほど作成した製品（Custom VPC）を関連付けます。
今度は共有させます。
共有先は特定の OU 対象にしたいです。共有を許可する設定がデフォルトのままで無効化されていたため有効化しました。
OU を指定できるようになりました。SandboxOU に共有しました。
設定完了です。共有したSandboxOU 内のアカウントから確認してみます。
Sandbox OU 内のメンバーアカウントで動作確認
SandboxOU 内のメンバーアカウントにサインインしました。
Service Catalog を開きインポートしたタブに共有されたポートフォリオを確認できました。
TagOption Migration not completeとエラーが表示されています。必要な IAM ロールを追加していきます。
IAM ロールを追加しました。これで管理アカウントから共有した製品を利用可能な状態となりました。
製品を起動してみます。
ワークショップで準備されていた CloudFormation テンプレートのパラメーター入力画面になりました。AZ を指定して実行してみました。
デプロイがはじまりました。
デプロイが完了しました。
実際に VPC が作成されており NAT Gatwayも起動していました。
製品で作成したリソースの削除
NAT Gateway が2台起動する構成だったため放置すると利用費がかさみます。リソースの削除は忘れずにしておきしょう。
プロビジョニングされた製品から製品の起動時に入力した名前を選択してアクションから終了を押します。
確認画面を表示されます。
しばらく放置するとリソース削除が終わります。これで製品（CloudFormation テンプレート）からデプロイしたリソースの作成・削除を試すことができました。
学べたこと
- 管理アカウントから規定の構成を CloudFormation テンプレートで作成し、メンバーアカウントへ共有するには Service Catalog を利用する
Add Service Catalog Products
Service Catalog の製品（CloudFormation テンプレート）を組織全体へ共有するパートです。
Add Service Catalog Products :: AWS Control Tower Workshop
やってみた
指定した OU へ共有する方法とほぼ変わりがありません。ポートフォリオの共有先を組織ノードに変更しただけです。
すると、すでに共有済みとエラーが表示されました。さきほど OU 指定で共有したポートフォリオを使いまわしたためでしょうか。
ポートフォリオの共有先を確認してみました。当然 OU は対象とされていましたが組織も共有対象に含まれていました。エラーメッセージのとおりでした。
学べたこと
- Service Catalog の製品は組織全体へも共有できる
おわりに
推奨講座だけでボリュームがありました。Control Tower の基本と、Account Factory からのアカウント作成と、新規作成したアカウントへの設定を入れ込む方法をハンズオン形式で学べるので、このあたりを学習したい方はやってみるとよいのではないでしょうか。やってみた感じですとまとまった時間を取って進めないと効率が悪かったので休日を利用して挑んだ方がよいです。
1
