Upgrade to Pro — share decks privately, control downloads, hide ads and more …

AWS Control Towerを 数年運用してきての気づきとこれから/aws-contro...

AWS Control Towerを 数年運用してきての気づきとこれから/aws-controltower-ops-tips

Ops-JAWS Meetup34 Organizations & ControlTower

中村匡志

April 16, 2025
Tweet

Other Decks in Technology

Transcript

  1. AWS Control Towerの運用でつらいところ介 ▪Control Towerのランディングゾーンアップデートに時間がかかる ・OU単位で実行となるが、アカウント数が多いと時間がかかる。。 ・機能追従のためにもやらないといけないが、OU数が多く関係部署が多い場合は結構工数がとられる。 ※作業自体はボタンを押すだけであっても、調整・影響確認が必要。 例)アップデートの際に意図しない課金が発生しはじめたりする 意図せず、CloudTrailのログがCloudWatch

    Logsに出力する挙動となり管理アカウントの費用が月額 数千ドル上乗せ課金されてしまった。。 ▪ドリフトに気をつかう必要がある ・あやまってControl Towerの設定を強制的に変えてしまうと(AWS Control Towerで作成されたリ ソースは変更・削除しないことが推奨)、ドリフトが発生しめんどくさいことになる。 ※Control TowerはAWS CloudFormation StackSetsで各種設定される。
  2. AWS Control Towerの運用でつらいところ介 ▪(仕様上) Security HubとGuardDutyはリージョナルサービス →素の監査アカウントでメンバーアカウントの状態を確認する際に、 リージョン切り替えがめんどくさい。 →あとUIが頻繁に変わる割に正直見づらい。。 →QuickSightを使うとかSecurity

    Lakeを使うとか3rdpartyの何か(Grafana)使うとか追加で工夫が必要 ▪マネージドサービスとしてのSIEMがない。 ・SIEMを使いたい場合外部のサービスに連携したり自前で用意が必要 →SIEM on Amazon OpenSearch Serviceは存在するがOSSなので、 マネージドサービスとしてネイティブに統合されてはいない認識でいます。 →Control Towerのログ取り込みは自体は可能ではあるようです。 https://github.com/aws-samples/siem-on-amazon-opensearch-service/blob/main/docs/controltower_ja.md
  3. Organizationsの運用でつらいところ介 ▪既存のアカウントを別の組織から組織編入した場合それまでの請求情報履歴が消える →割と罠ですが気づきづらい、、 →ほか、アカウントの編入・離脱は制限事項はあるのでドキュメントは精読したほうがよい (いまだとAWSのドキュメント検索MCPサーバで生成AIつかってがんばるとか、、) “アカウントがコストと使用状況データにアクセスできなくなる” https://docs.aws.amazon.com/ja_jp/organizations/latest/userguide/orgs_manage_accounts_remove.html https://repost.aws/ja/knowledge-center/organizations-move-accounts ▪同じ会社・部署で複数AWSアカウントがあるとマルチアカウントの運用がつらい →管理主体が別だとCost

    Explorerで一括で確認できずメンバーアカウント側の管理者の立ち場だと つらいことがあった。 ※組織規模が大きいと、組織のマスターアカウントで参照権限を全員に与えるのは現実的でない ※大きい組織でステークホルダーが多い場合安易に他の会社・部署の情報は見せることは難しいこと がある。 →これは、カスタム請求ビューというアップデートで対応可能になりました。(神) https://docs.aws.amazon.com/ja_jp/cost-management/latest/userguide/create-custom-billing-views.html
  4. 今後やっていきたいところ介 ▪リソースコントロールポリシー (RCP)や宣言型ポリシーの導入 →ちょっと前に話題になった、SSE-C攻撃の対策としてS3 オブジェクトの SSE-C 暗号化の 禁止するなど https://aws.amazon.com/jp/blogs/security/preventing-unintended-encryption-of-amazon-s3-objects/ ▪

    EC2インスタンスIMDSv1の撲滅 →一部アカウント単位での強制化設定は実施済みだが組織全体から撲滅させたい。 →v2でもSSRF攻撃が100%防げるわけはないが、Capital Oneの事例しかりクリティカルな 事象が発生しうる。 https://aws.amazon.com/jp/blogs/news/amazon-ec2-instance-metadata-service-imdsv2-by-default/ ▪AWS IAM Identity Centerの使いこなし →(日本語化対応した)Amazon Q DeveloperはIAM Identity Centerの使用が前提です。。 今後もこう言ったサービスは増えていくのではないかと思っています。 →また、 IAM Identity CenterはAWS Control Towerで使用が必須かつ推奨です。 →なお、 IAM Identity Centerは複数の外部IdPを接続できない制限があります。 https://aws.amazon.com/jp/iam/identity-center/faqs/ “いいえ。どのような場合も、IAM アイデンティティセンターに接続できるのは単一のディレクトリ、または単一 の SAML 2.0 アイデンティティプロバイダーのみです。”