EC部 技術1課の松田です。こんにちは。
今回はAWS Control TowerがやってくれるAWS Configの設定と、やってくれない設定についてお話しします。やってくれない設定についてはどうすればよいのか？という話にも触れていきたいと思います。
なおタイトル詐欺のようで申し訳ないのですが、Config Rulesについては本記事では言及しておりませんのでご容赦ください。こちらは機会があればまとめてみたいと思います。
AWS Control TowerとAWS Configの関係
AWS Control TowerとAWS Configの関係について、簡単に触れておきます。
AWS Control Towerとは
AWS Control Tower は、規範的なベストプラクティスに従って、AWS 複数アカウント環境を設定して管理するための簡単な方法を提供します。AWS Control Tower は、AWS Organizations、AWS Service Catalog、AWS IAM Identity Center (successor to AWS Single Sign-On) など、他のいくつかの AWS のサービスの機能の「オーケストレーション」を行い、1 時間足らずでランディングゾーンを構築します。リソースは、ユーザーに代わって設定および管理されます。*1
早速引用でアレなのですが、すごくざっくり言うと、AWSベストプラクティスを複数アカウントに適用するために必要な色々なサービスが自動でセットアップされるといった具合です。そして、この「色々なサービス」の中にAWS Configが含まれています。
改めてになりますが、本記事の主題は「AWS Control TowerがやってくれるAWS Configの設定と、やってくれない設定について」です。
例えばこのアカウントのこのリージョンでAWS Configを有効化してくれるとか、あのアカウントでは有効化してくれないとか、アグリゲータはここに作られるといった話をつらつらと書いていきたいと思います。
ちなみにランディングゾーンに作成されるリソースの一覧は以下に公開されていますが、AWS Config Recorderが載っていなかったりと記載基準がよく分からず、本記事の執筆に至りました。
AWS Control Tower有効化直後の状態
確認した限りでは管理アカウント、監査アカウント、その他のメンバーアカウントで設定内容が分かれていましたので、その分類で記載します。
公式なソースが見つからなかったので、あくまで実環境を目視確認した範囲での記載になります。その点はご留意頂ければと思います。
※確認日は2023年3月中旬、Landing Zoneのバージョンは3.1となります。
管理アカウント
AWS Config関連リソースの作成状況は以下の通りでした。
AWS Config Recorder
全てのリージョンで作成されていませんでした。
AWS Config Delivery Channel
全てのリージョンで作成されていませんでした。
AWS Config Aggregator
東京リージョンでのみ作成されていました。Control Towerのホームリージョンで作成されるようです（レコーダとか作らなくてもアグリゲータ作れるの初めて知った...）。
先述の通り管理アカウントのAWS ConfigはControl Towerにより有効化されないため、CLIでのみ存在を確認できます。
Describeコマンドの応答は以下の通りです。
[cloudshell-user@ip-xx-xx-xx-xx ~]$ aws configservice describe-configuration-aggregators --region ap-northeast-1
{
"ConfigurationAggregators": [
{
"ConfigurationAggregatorName": "aws-controltower-ConfigAggregatorForOrganizations",
"ConfigurationAggregatorArn": "arn:aws:config:ap-northeast-1:[自身のアカウントID]:config-aggregator/config-aggregator-jaxdwuf4",
"OrganizationAggregationSource": {
"RoleArn": "arn:aws:iam::[自身のアカウントID]:role/service-role/AWSControlTowerConfigAggregatorRoleForOrganizations",
"AllAwsRegions": true
},
"CreationTime": "2023-01-18T01:53:19.146000+00:00",
"LastUpdatedTime": "2023-01-18T01:53:19.975000+00:00"
}
]
}
当然ですが、AWS Configを有効化するとマネジメントコンソールからも確認できるようになります。
AWS Configの委任
てっきり監査アカウントに委任されていると思っていましたが、されていませんでした（！）。
[cloudshell-user@ip-xx-xx-xx-xx ~]$ aws organizations list-delegated-administrators --service-principal=config.amazonaws.com
{
"DelegatedAdministrators": []
}
利用者側で委任することはできますが、今後Control Towerのアップデートで委任されるようになるのでは？という気もするので、下手に触らない方が賢明なのかなーと思います。Control Towerを使うなら、AWS Configは全てControl Towerにお任せしてしまった方がいいのではないかというのが私の感想です（良くも悪くもブラックボックス化してしまうので）。
監査アカウント
AWS Config Recorder
Control Towerの管理対象リージョンで作成されていました。
ちなみに「Control Towerの管理対象リージョン」とは、Landing Zone設定で指定したリージョンを指します。以下の画像で State が Governed となっているリージョンです。
※2023年4月1日現在、Control Towerではデフォルトで有効なリージョンのうち大阪・北カリフォルニアリージョンがサポートされていませんが、これは大阪・北カリフォルニアリージョンのAWS ConfigがControl Towerで有効化できないことを意味します。対策などについては本記事後半で触れます。
※2023年5月26日追記：下記のアップデートにて大阪および北カリフォルニアリージョンがサポートされました。デフォルトで有効なリージョンのAWS Configは、全てControl Towerにて有効化が可能です。
AWS Control Tower is now available in 7 additional Regions
Describeコマンドで取得した設定値も記載しておきます。
なお以下はホームリージョンである東京リージョンで取得しているため includeGlobalResourceTypes が true となっていますが、それ以外のリージョンだと false となります。
[cloudshell-user@ip-xx-xx-xx-xx ~]$ aws configservice describe-configuration-recorders --region ap-northeast-1
{
"ConfigurationRecorders": [
{
"name": "aws-controltower-BaselineConfigRecorder",
"roleARN": "arn:aws:iam::[自身のアカウントID]:role/aws-service-role/config.amazonaws.com/AWSServiceRoleForConfig",
"recordingGroup": {
"allSupported": true,
"includeGlobalResourceTypes": true,
"resourceTypes": []
}
}
]
}
AWS Config Delivery Channel
AWS Config Recorderと同様に、Control Towerの管理対象リージョンで作成されていました。
こちらはリージョンごとに設定値は異なりませんでした（厳密には snsTopicARN は各リージョンのSNSトピックのARNが指定されるので、微妙に異なりますが）。
[cloudshell-user@ip-xx-xx-xx-xx ~]$ aws configservice describe-delivery-channels --region ap-northeast-1
{
"DeliveryChannels": [
{
"name": "aws-controltower-BaselineConfigDeliveryChannel",
"s3BucketName": "aws-controltower-logs-[ログアカウントID]-ap-northeast-1",
"s3KeyPrefix": "[Organizations ID]",
"snsTopicARN": "arn:aws:sns:ap-northeast-1:[自身のアカウントID]:aws-controltower-AllConfigNotifications",
"configSnapshotDeliveryProperties": {
"deliveryFrequency": "TwentyFour_Hours"
}
}
]
}
AWS Config Aggregator
東京リージョンでのみ作成されていました。Control Towerのホームリージョンで作成されるようです。監査アカウントではAWS Configが自動で有効化されるため、管理アカウントと異なりマネジメントコンソールからも存在を確認できます。
なお監査アカウントのアグリゲータには、管理アカウントは集約されませんのでご注意ください。管理アカウントのアグリゲータには組織内の全アカウントが集約されますが、監査アカウントの場合は管理アカウントを除く組織内の全アカウントが集約されます。
もう1つ管理アカウントと異なる点として、1つのアカウントを除き Status が Failed となっています（ OK となっているものは監査アカウント自身）。
これについては、アカウントの詳細を確認すると、 OK となっているリージョンと Failed となっているリージョンが混在しており、更に OK となっているリージョンは「Control Towerの管理対象リージョン」と一致していました。
このことから、見かけ上はエラーだが動作上の問題はなさそうだということが言えそうです。
補足しておくと、これはアグリゲータの Source type という設定値の差に起因します。管理アカウントでは Source type が My organization となっており、監査アカウントでは Individual accounts となっていますが、ここがポイントです。以下の公式ドキュメントも合わせて読んでみると良いです。
アグリゲーターには、個別アカウントアグリゲータと組織アグリゲータの 2 種類があります。
個々のアカウントアグリゲータでは、外部アカウントリージョンまたは組織メンバーアカウントリージョンを含むすべてのソースアカウントリージョンに認可が必要です。
組織アグリゲータの場合、認可は組織サービスと統合されるため、組織メンバーアカウントリージョンに対する認可は必要ありません。*2
値が Individual accounts の場合、全てのソースアカウントリージョンに対する認可が必要となりますが、そもそもリージョンでAWS Configが有効化されていなかったり、リージョン自体が有効化されていない場合は認可ができないので Failed となってしまうということでしょう。
一方 My organization の場合は、組織内のアカウントであれば認可をスキップできるので、リージョンが無効だろうと無視して OK になるということでしょう。
その他のメンバーアカウント
AWS Config Recorder
監査アカウントと同様でした。
AWS Config Delivery Channel
監査アカウントと同様でした。
AWS Config Aggregator
監査アカウントのアグリゲータに対する承認がありました。
AWS Control Towerでやってくれない設定と対応方法
では最後に、Control Towerがやってくれない設定と、それらの対処方法について簡単に触れたいと思います。これまで話してきた内容をまとめると、やってくれないことは大きく以下の2つですね。
- メンバーアカウント（Control Tower非サポートリージョン）のAWS Config有効化
- 管理アカウント（全リージョン）のAWS Config有効化
これらの対応について、以下に記載します。
Control Tower非サポートリージョンのAWS Configを有効化する方法
まず前提として、Control Tower環境下では、ユーザーがAWS Configの有効化を行うことは原則できません。
Control Tower環境下では「コントロール」と呼ばれる環境内でのコンプライアンス違反を検出または予防するルール（実体はSCPやConfig Rulesなど）が適用されるのですが、強制的に適用される必須コントロールの中にAWS Configの有効化を禁止するものが存在します。
本来AWS Configの設定変更を禁止するために用意されたコントロールの様ですが、どういうわけか config:PutConfigurationRecorder アクションもDenyされており、AWS Configを有効化することができなくなっています。
この件への対策ですが、以下のAWS公式ブログで公開されている方法を利用するのが最適解ではないかなと思います。
簡単に説明すると、ブログ内で公開されているCloudFormationテンプレートを実行すると、組織内のアカウント（管理アカウントは除く）のControl Towerがサポートしていないリージョンで、AWS Configを有効化してくれます。また今後発行されるアカウントのControl Towerがサポートしていないリージョンでも、AWS Configが自動的に有効化されるようになります。
更に、今後Control Towerが大阪リージョンなどに対応した際の移行方法についても言及されているため、その点も安心して採用できる印象です。
具体的な手順もブログ内に記載してくれています。手順自体はCloudFormationスタックを実行するだけで非常に簡単ですので、興味があれば一度試してみてください。
管理アカウントのAWS Configを有効化する方法
メンバーアカウントと異なり、管理アカウントはAWS Configに関する制限が設けられていませんので、好きな方法で有効化することができます。
マネジメントコンソールから手作業で有効化しても良いですが、複数リージョンで有効化するのであれば、セルフマネージド型のCloudFormation StackSetsが有用です。 具体的な方法は割愛しますが、以下の記事を参考にしてみてください。
AWS Configを有効化するサンプルテンプレートも公式から公開されていますので、ご活用ください。
さいごに
ということで、AWS ConfigとAWS Control Towerのお話でした。
AWS Configはとりあえず有効化しておきたい割にセットアップが面倒なので、Control Towerがまるっと管理を引き受けてくれるのは大きなメリットだと思います。とはいえ完全に丸投げできるようになるまでにはもう少しかかりそうなので、今後のアップデートに期待ですね。
最後までお付き合いいただき、ありがとうございました。
*1:https://docs.aws.amazon.com/ja_jp/controltower/latest/userguide/what-is-control-tower.html
*2:https://docs.aws.amazon.com/ja_jp/config/latest/developerguide/aggregate-data.html
松田 渓(記事一覧)
2021年10月入社。散歩が得意です。
