Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
AWS Control Towerを 数年運用してきての気づきとこれから/aws-contro...
Search
中村匡志
April 16, 2025
Technology
0
220
AWS Control Towerを 数年運用してきての気づきとこれから/aws-controltower-ops-tips
Ops-JAWS Meetup34 Organizations & ControlTower
中村匡志
April 16, 2025
Tweet
Share
Other Decks in Technology
See All in Technology
クラウドネイティブ環境の脅威モデリング
kyohmizu
2
410
ペアーズにおける評価ドリブンな AI Agent 開発のご紹介
fukubaka0825
9
2.6k
経済メディア編集部の実務に小さく刺さるAI / small-ai-with-editorial
nkzn
2
400
猫でもわかるS3 Tables【Apache Iceberg編】
kentapapa
2
200
Tailwind CSS の小話「コンテナークエリーって便利」
yamaday
0
120
LINE 購物幕後推手
line_developers_tw
PRO
0
470
地に足の付いた現実的な技術選定から魔力のある体験を得る『AIレシート読み取り機能』のケーススタディ / From Grounded Tech Choices to Magical UX: A Case Study of AI Receipt Scanning
moznion
4
1.5k
Terraform にコントリビュートしていたら Azure のコストをやらかした話 / How I Messed Up Azure Costs While Contributing to Terraform
nnstt1
1
500
TanStack Start 技術選定の裏側 / Findy-Lunch-LT-TanStack-Start
iktakahiro
1
130
自動化の第一歩 -インフラ環境構築の自動化について-
smt7174
1
130
大規模サーバーレスプロジェクトのリアルな零れ話
maimyyym
3
220
Global Azure2025(GitHub Copilot ハンズオン)
tomokusaba
2
770
Featured
See All Featured
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
129
19k
The Invisible Side of Design
smashingmag
299
50k
Building Flexible Design Systems
yeseniaperezcruz
329
39k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
227
22k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
16k
Testing 201, or: Great Expectations
jmmastey
42
7.5k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
Scaling GitHub
holman
459
140k
Documentation Writing (for coders)
carmenintech
71
4.8k
YesSQL, Process and Tooling at Scale
rocio
172
14k
Statistics for Hackers
jakevdp
799
220k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
60k
Transcript
AWS Control Towerを 数年運用してきての気づきとこれから Ops-JAWS Meetup34 Organizations & ControlTower 中村
匡志
自己紹介 名前:中村 匡志 経歴:2021年8月より現職でCCoEとして入社 (前職はSierで常駐してAWSの設計/構築を実施、その前はオンプレの仮想基盤の構築) 資格:AWS AIF/CLF/SAA/SOA/DVA/SAP/DOP/SCS その他etc… 今年こそはAWS全冠を目指します!!(所属企業はAPNではないけど、、) 趣味:音楽系いろいろ(ライブに行ったりとかレコード集めたりとかギター弾いたりだとか)
バンドだとRed Hot Chili Peppersが一番好き 写真はre:Invent 2024で行ったラスベガスのハードロックカフェに なぜかあった写真スポットでとったもの。
自己紹介介 □現職でやっていること CCoEとして活動をしています!! 所属企業グループ内のクラウド推進のほかに、 他の会社の方と合同でイベント/交流を実施したり、 AWS GameDayをグループ内で実施したりしています! 参考:越境するクラウド CoE(CCoE)〜組織を越えて広がる、イノベーションの共創 https://aws.amazon.com/jp/blogs/news/inter-ccoe-enables-co-creation-of-innovation-1/
https://aws.amazon.com/jp/blogs/news/inter-ccoe-enables-co-creation-of-innovation-2/ 参考:AWS × SOMPO GameDay https://tech.sompo.io/entry/2025/04/03/173308 Cloud CoE Since 2021 ロゴを作ってポロシャツやステッカーなどSWAG もつくったりしています!!を
注意事項 ▪おことわり▪ 本資料のおける記載や本発表における発言は 個人の見解に基づくものであり、 所属組織を代表するものではありません
ここから本題 □現職において 2021年9月からAWS Control Towerの利用を開始しました。(継続して3年半ほど利用中です。) 「予防的統制」と「発見的統制」と「訂正的統制」をマネージドサービスで実現。 (3rdParty製品は使用していない) 安全なクラウド活用の要、セキュリティガードレール導入のねらいとこれから より抜粋 https://aws.amazon.com/jp/builders-flash/202304/ccoe-security-guardrail/
実際、AWS Control Towerってどうなの?介 最初に結論… AWSベストプラクティスな セキュリティ環境を ネイティブ機能で すぐに使えるので 素晴らしい!
実際、AWS Control Towerってどうなの?介 ・Organizationsを組む場合最初から使用を推奨 →既存のAWSアカウント群に適用できなくもないがわりと手間がかかる。(最初から使用を推奨) →例えば、SCPの適用影響確認や既存AWS Configを使用している場合にコンフィグレーションレ コーダーとデリバリチャネルの削除が必要だったりOU設計であったり、、 ・AWS セキュリティリファレンスアーキテクチャ
(AWS SRA)に準拠したセキュリティ環境 をすぐに準備できるので非常に便利(下記URLの内容) ※勉強になるのでおすすめ https://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/security-reference- architecture/welcome.html
実際、AWS Control Towerってどうなの?介 ・Account Factoryという機能で新規にメンバーアカウントを作成する際にControl Tower に準拠したセキュリティ設定を自動で展開できる仕組みがあるため非常に楽 ※最初はできなかったがTerraformでもセキュリティ設定のブループリントを作ることが可能になり ました。 Terraformが使えるのは大きなメリットかと思います。
・3rd party製品をいれるよりコストメリットに優れる(と思われる) ※規模にもやワークロードなど環境に左右されるがメンバーアカウント側での課金は利用金額の数 パーセント程度
実際、AWS Control Towerってどうなの?介 つまり… ベストプラクティスな セキュリティ環境を やすく・はやく・かんたんに 提供できる
AWS Control Towerの運用でつらいところ介 ▪Control Towerのランディングゾーンアップデートに時間がかかる ・OU単位で実行となるが、アカウント数が多いと時間がかかる。。 ・機能追従のためにもやらないといけないが、OU数が多く関係部署が多い場合は結構工数がとられる。 ※作業自体はボタンを押すだけであっても、調整・影響確認が必要。 例)アップデートの際に意図しない課金が発生しはじめたりする 意図せず、CloudTrailのログがCloudWatch
Logsに出力する挙動となり管理アカウントの費用が月額 数千ドル上乗せ課金されてしまった。。 ▪ドリフトに気をつかう必要がある ・あやまってControl Towerの設定を強制的に変えてしまうと(AWS Control Towerで作成されたリ ソースは変更・削除しないことが推奨)、ドリフトが発生しめんどくさいことになる。 ※Control TowerはAWS CloudFormation StackSetsで各種設定される。
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
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
Organizationsの運用でつらいところ介 ▪一括請求を利用している場合、AWSの仕様で適切に計算されない割引や費用が存在する →厳密にアカウント単位で請求管理をする場合は必要となってきます。 →クレジットの扱いやSP/RIの共有設定もどうするかは考慮が必要です。 例)discount/BundledDiscountという割引がAWS Network Firewallを利用かつNATゲートウェイ を利用していると発生するが、適切なアカウントで割引されないので何らかの方法で割り戻し計算が 必要。 https://docs.aws.amazon.com/cur/latest/userguide/discount-details.html
今後やっていきたいところ介 ▪リソースコントロールポリシー (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 アイデンティティプロバイダーのみです。”
まとめ介 ・(いろいろ書きましたが) AWS Control Towerは素晴らしいサービスなので つかいましょう。 ・ AWSでガバナンスを効かせる立場としては なくてならないサービスです。 ・
導入することで、 より安全に組織全体を管理することが可能なの でぜひ使用しましょう。
ご清聴ありがとうございました。 (下記はLinkedInプロフィールへのQRコードです)