みなさん、こんにちは。
明るい笑顔がトレードマーク、ルイボスティーが大好きな芦沢(＠ashi_ssan)です。
先日AWS Control Towerのサポート対象に大阪リージョンが追加されました。
アップデートが発表された後、担当しているお客様や社内メンバーから「大阪リージョンが追加されたのはいいけど、実際使えるの？何か注意事項はないの？」という質問を見聞きすることが多くありました。
本エントリでは、Control Tower環境への大阪リージョンの追加を検討するための材料となる、注意事項をまとめてみます。
ここでいう、Control Towerへの大阪リージョンの追加とは？
Control Towerには、ランディングゾーンリージョンという概念があります。
ランディングゾーンリージョンに任意のリージョンを追加することで、Control Towerによって追加したリージョン内にConfig/CloudTrail/CloudWatchなどのリソースが自動で展開されます。こうして初めてControl Towerで管理しているリージョンとみなされます。
冒頭で紹介しているアップデートブログの内容は「ランディングゾーンリージョンに大阪リージョンを追加できるようになった」というものです。
追加できるようになったことはただ嬉しい話なのですがいろいろと制約がある、ということが次の話の趣旨になります。
本題:ランディングゾーンリージョンに大阪リージョンを追加する注意事項って何？
ここからが本題になりますが、以下のような制約があることが注意すべき観点になります。
- 既に大阪リージョンでサポートされていないControl Towerの機能を有効化しているとき、ランディングゾーンに大阪リージョンを追加できない
- 既にランディングゾーンに大阪リージョンを追加しているとき、大阪リージョンでサポートされていないControl Towerの機能を有効化できない
これらは、大阪リージョンをはじめとするオプトインリージョン特有の事情が原因で制約になってしまっているようです。
オプトインリージョンとは、Control Towerドキュメント内（Considerations for activating AWS opt-in Regions）で定義されている、Control Towerが利用できる かつ デフォルトでは有効化されていない手動でアクティブ化する必要のあるリージョンのことを指します。
現時点では、以下の7リージョンがオプトインリージョンです。
- 米国西部 (北カリフォルニア) リージョン、us-west-1
- アジアパシフィック (香港) リージョン、ap-east-1
- アジアパシフィック (ジャカルタ) リージョン、ap-southeast-3
- アジアパシフィック (大阪) リージョン、ap-northeast-3
- ヨーロッパ (ミラノ) リージョン、eu-south-1
- アフリカ (ケープタウン) 地域、af-south-1
- 中東 (バーレーン) 地域、me-south-1
オプトインリージョンは、2019年3月20日以降にリリースされた比較的新しいリージョンで、商用リージョンと比較するとIAM通じて管理されるすべてのデータの共有に関して高いセキュリティ要件を持っています。
そういった理由が背景にあるのかは不明ですが、オプトインリージョンは商用リージョンと比べると利用できるサービスや機能に制限があります。
オプトインリージョンすべてではありませんが、少なくとも大阪リージョンではControl Towerの以下の機能が未サポートとなっています。
- 検出コントロール、プロアクティブコントロール、Security Hubの『サービスマネージドスタンダード: AWS Control Tower』に含まれる一部のコントロールをサポートしていない
- CfCT(Customizations for AWS Control Tower)のアーキテクチャをサポートしていない
Control Towerの一部コントロール、未サポート
コントロールとは？
Control Towerには、コントロールと呼ばれるAWS環境全体のガバナンスを提供するルールがあります。過去「ガードレール」と呼ばれていたため、旧称の方が馴染み深い方もいるかもしれません。
コントロールには、動作や実装の異なる3つのものがあります。
- 予防コントロール
- 検出コントロール
- プロアクティブコントロール
予防コントロールは、ポリシー違反につながるアクションを禁止するための利用されるものです。AWS OrganizationsのSCPを利用して実装されています。
検出コントロールは、ポリシー違反のリソースを検出しダッシュボードにアラートを提供するために利用されるものです。AWS Configルールを利用して実装されています。
プロアクティブコントロールは、CloudFormationを利用してリソースがプロビジョニングされる前にリソースをスキャンし、リソースがコントロールに準拠していることを確認します。違反があった場合、そのリソースはプロビジョニングされません。実装はCloudFormation Guardを利用して行われています。
参考： About controls in AWS Control Tower - AWS Control Tower
その他、Control TowerがSecurity Hubと統合されている場合、「サービスマネージドスタンダード: AWS Control Tower」という特別なコントロールを利用できます。このコントロールを有効化すると、Security Hubのセキュリティ標準「AWS 基礎セキュリティのベストプラクティス v1.0.0」とほぼ同等の内容のセキュリティ標準をControl Towerのコントロールとして管理できます。
詳しくは以下ブログをご覧ください。
また、Control Towerのコントロールは以下のガイダンス別に分類されています。
- 必須のコントロール
- 強く推奨されるコントロール
- 選択的コントロール
「必須のコントロール」はランディングゾーン全体でデフォルトで有効化されており無効化できません。「強く推奨されるコントロール」と「選択的コントロール」はデフォルトは無効化ですが、任意のタイミングでOU単位で有効化できます。
ちなみに、次に説明する未サポートのコントロールはすべてデフォルト無効化のコントロールです。
未サポートのコントロールについて
そんなControl Towerのコントロールですが、本日2023/7/7時点のControl Towerでは、冒頭で記載したような注意点があります。
例えば、検出コントロールについてですが、既にControl Towerで大阪リージョンを有効化している状態で大阪非対応のコントロールの有効化すると以下のようなエラーになります。
また、大阪非対応のコントロールが事前に有効になっている場合は後から大阪リージョンを追加できません。以下のエラーが表示されます。
どのコントロールが大阪リージョンに対応していないのか、具体的な例と調査方法をここから説明します。
Control Towerドキュメント(Limitations and quotas in AWS Control Tower)に記載のある検出コントロールに含まれる未サポートコントロールの例は以下です。北カリフォルニアリージョンを除き、未サポートとなっています。
- AWS-GR_AUTOSCALING_LAUNCH_CONFIG_PUBLIC_IP_DISABLED
- AWS-GR_REDSHIFT_CLUSTER_PUBLIC_ACCESS_CHECK
- AWS-GR_LAMBDA_FUNCTION_PUBLIC_ACCESS_PROHIBITED
- AWS-GR_EMR_MASTER_NO_PUBLIC_IP
- AWS-GR_EBS_SNAPSHOT_PUBLIC_RESTORABLE_CHECK
- AWS-GR_NO_UNRESTRICTED_ROUTE_TO_IGW
- AWS-GR_SAGEMAKER_NOTEBOOK_NO_DIRECT_INTERNET_ACCESS
- AWS-GR_EC2_INSTANCE_NO_PUBLIC_IP
- AWS-GR_EKS_ENDPOINT_NO_PUBLIC_ACCESS
- AWS-GR_ELASTICSEARCH_IN_VPC_ONLY
- AWS-GR_RESTRICTED_SSH
- AWS-GR_DMS_REPLICATION_NOT_PUBLIC
- AWS-GR_RDS_SNAPSHOTS_PUBLIC_PROHIBITED
- AWS-GR_SUBNET_AUTO_ASSIGN_PUBLIC_IP_DISABLED
- AWS-GR_ENCRYPTED_VOLUMES
- AWS-GR_RESTRICTED_COMMON_PORTS
その他、プロアクティブコントロールやSecurity Hubの『サービスマネージドスタンダード: AWS Control Tower』が大阪リージョンをサポートしているか？について知りたい方は、Control Towerドキュメント(Tables of control metadata)を確認してください。
各コントロールが大阪リージョン(ap-northeast-3)のコントロールAPI識別子arn:aws:controltower:ap-northeast-3::control/で始まるものが存在しているかをチェックしましょう。WebページをコントロールAPI識別子で検索すると確認しやすいです。
コントロールIDがAWS-GRで始まるものは検出コントロール、CT.[サービス名].PR.[番号]という命名規則を持つものはプロアクティブコントロール、SHで始まるものはSecurity Hubの『サービスマネージドスタンダード: AWS Control Tower』になります。
↓ コントロールが大阪リージョンに対応している場合
↓ コントロールが大阪リージョンに未対応の場合
CfCT(Customizations for AWS Control Tower)アーキテクチャの未サポート
CfCTとは、その名の通りControl Towerをベースにしたカスタマイズソリューションです。
CfCTはControl Towerのホームリージョンに以下のようなAWSアーキテクチャを構築して実装しますが、オプトインリージョンの一部(大阪、ジャカルタ)ではAWS CodePipelineをサポートしていないため、リージョン内への展開ができません。
参考：AWS CONTROL TOWERのカスタマイズ (CFCT)-アーキテクチャ
ただ、別リージョンに展開したCfCTアーキテクチャを利用した大阪リージョンへのリソースのデプロイはサポートされています。
CfCTのアーキテクチャはホームリージョンに構築する必要があるため、ホームリージョンが大阪以外(東京など)の環境では問題なく利用できるはずです。
ホームリージョンは後から変更できないため、初期構築時に大阪リージョンをホームリージョンとして設定する場合はよく検討してから行うようにしてください。
結論: 結局、ウチのControl Tower環境で大阪リージョンを追加できるの？？？？
ここまで大阪リージョンが利用できないパターンを説明してきました。結論として、どういった観点に気を付けて検討すれば良いのか、大阪リージョンを使いたいけど利用できないパターンにある場合はどのように対応すべきかをまとめてみます。
どういった観点に気をつけるべきか？はこちらです。
- 大阪リージョンに対応していない検出コントロール、プロアクティブコントロール、Security Hubの『サービスマネージドスタンダード: AWS Control Tower』を利用しないこと
- CfCTを使用する場合は、ホームリージョンに大阪リージョンを指定しないこと
大阪リージョンを利用する新規環境の場合は、これらに気を付けて大阪リージョンに対応しているコントロールの範囲で利用するコントロールを設計したり、ホームリージョンの設定を大阪リージョン以外にすれば問題はないと思われます。
しかし、既存の環境で既に大阪リージョン非対応のコントロールを利用して運用し初めている環境もあるかと思います。そんな既存環境で大阪リージョンをランディングゾーンリージョンに追加したい場合、残念ながら現在時点では非対応のコントロールをControl Tower全体で無効化する必要があります。
該当のコントロールを無効化するか、もしくは大阪リージョンが該当のコントロールに対応するまでリージョンの追加を行わないようにするしかありません。
最後に
今回は、Control Tower環境で大阪リージョンを利用し始める際の注意事項そしてその背景の解説を行いました。
周りのControl Towerを運用している環境での大阪リージョン追加にまつわる話をよく耳にします。Control Towerの必須コントロールのみを利用している環境では早くも大阪リージョンを有効化して運用を始めているそうです。一方で、必須コントロール以外のコントロールを多数有効化して運用を始めている環境では大阪リージョンの有効化を諦めた例も見かけました。
現状、たくさんのコントロールが有効化してControl Towerの機能をより使っている環境ほど大阪リージョンを使えない状況にあり、不便な状況が続いているので大阪リージョンなどオプトインリージョンを利用していても非対応のコントロールが他のリージョンで利用できるようにアップデートしていただきたいです。
本エントリが、運用中のControl Tower環境への適用もしくは新規Control Tower環境で大阪リージョンを管理するかしないかを判断する材料として参考になれば幸いです。
以上、芦沢(＠ashi_ssan)でした。
3
