AWS re:Invent 2024 で考える AWSマルチアカウント管理における複雑性とシンプルな設計 ~AWS Organizations の活用と組織管理に関するアップデート~

AWS re:Invent 2024 で考える AWSマルチアカウント管理における複雑性とシンプルな設計 ~AWS Organizations の活用と組織管理に関するアップデート~ 2025年1月22日 NRIネットコム株式会社
クラウド事業推進部丹勇人 NRIネットコム TECH & DESIGN STUDY #55

1 Copyright（C） NRI Netcom, Ltd. All rights reserved. 転載、複製、改変等、および許諾のない二次利用を禁止します丹
勇人（たんはやと）自己紹介 ◼ NRIネットコム株式会社（2015年入社）クラウド事業推進部主任 ⚫ AWSマルチアカウント環境の組織管理・運用支援 ⚫ AWSアカウント管理サービスプリセールス ◼ 2024 Japan AWS Ambassador（Associate Ambassador） ◼ 2024 Japan AWS Top Engineers（Security） ◼ AWS Community Builders（Security）since 2023 ◼ 2022 APN AWS Top Engineers（Service） ◼ AWS Certifications ⚫ 2024 Japan ALL AWS Certifications Engineers ◼ 秋田県出身 ◼ 子供５人

2 Copyright（C） NRI Netcom, Ltd. All rights reserved. 転載、複製、改変等、および許諾のない二次利用を禁止します #nncstudy
本日お話すること 01 AWSマルチアカウント管理の必要性と組織管理 02 複雑さにどのように取り組むか（Dr. Werner Vogels Keynote） 03 組織管理に関するAWSアップデート 04 組織管理における複雑性と課題例 05 組織管理の役割とシンプルな設計観点 06 Summary, References & Appendix 07

AWSマルチアカウント管理における複雑性とシンプルな設計本日お話すること AWS re:Invent 2024 の Dr. Werner Vogels Keynote では、大規模な分散システム構築の経験に基づいて、複雑さを受け入れるための原則について語られました。組織管理においても、AWS Organizations に関する機能や管理者の役割が増える中で複雑さを受け入れ、いかにシンプルに設計するかという観点が必要となります。 AWS re:Invent 2024 前から発表されたアップデート機能を見ながら、組織管理における"Simplexity"について考えてみます。 Complexity Simplicity

用語本日お話すること ◼ AWS Organizations ⚫ 複数のAWSアカウントを一元管理できる無料のAWSサービス ▪組織内のAWSアカウントの一元管理 ▪すべてのメンバーアカウントの一括請求など ◼ マネジメントアカウント ⚫ AWS Organizations の管理に使用する AWSアカウント ⚫ AWS Organizations で発生した料金の支払いを行う ⚫ AWS Organizations 内のアカウント作成や管理 ◼ メンバーアカウント AWS Organizations の組織に所属する管理アカウント以外のアカウント Management account Member accounts AWS Organizations

AWSアカウントのマルチアカウント運用の必要性組織において必要な環境 AWSマルチアカウント管理の必要性と組織管理セキュリティ＆コンプライアンス拡張性＆高可用性柔軟性組織のセキュリティや監査要件に適合するスケーラブルで安定したシステムであるビジネス要件の変更に柔軟な対応が可能

AWSアカウントのシングル運用ではリスクが多い AWSマルチアカウント管理の必要性と組織管理 AWS Cloud 開発サーバ本番サーバ重要情報利用料請求開発者管理者 ◼シングルアカウントのリスク ⚫ 環境ごと（開発・本番）のアクセス制御が難しい ⚫ 意図しない本番環境の停止、データ漏洩 ⚫ 部門ごとのコスト管理が難しい ⚫ リソースが乱立し、管理されない設定がセキュリティホールに ⚫ 他システムの影響で、リソース上限の制約をうける可能性利用規模が拡大するに従って限界がくる

マルチアカウントにより、管理やリスク範囲を分離する AWSマルチアカウント管理の必要性と組織管理 AWS Cloud 開発サーバ本番サーバ重要情報利用料請求開発者管理者 ◼マルチアカウントのメリット ⚫ 環境ごと（開発・本番）のアクセス制御をアカウント単位で設定できる ⚫ 意図しない本番アクセスを防げる ⚫ 部門ごと（アカウントごと）のコスト管理ができる ⚫ リソースがアカウント単位に分割され管理対象が明確になる AWS Cloud 利用料請求組織において、マルチアカウント化は必須事項

9 Copyright（C） NRI Netcom, Ltd. All rights reserved. #nncstudy 転載、複製、改変等、および許諾のない二次利用を禁止します
アカウント管理の悩みは尽きないセキュリティに精通した人材が足りない管理するアカウントが多くて大変アカウントごとに管理者が違う

マルチアカウントのセキュリティを維持するのは大変？ ◼組織として沢山のAWSアカウントを同じ水準で管理できますか？ ⚫ 組織内でも、異なるビジネス要件 ⚫ 様々な管理形態 ⚫ 投下できる人的リソースも様々 AWSマルチアカウント管理の必要性と組織管理 AWS Account AWS Account AWS Account AWS Account AWS Account 管理者一律の水準で管理するには、仕組みが必要

AWSサービスによるマルチアカウントの自動設定とガバナンス~AWS Organizations~ AWSマルチアカウント管理の必要性と組織管理 AWS Organizations マネジメントアカウント Organizational unit (OU) Organizational unit (OU) SCP IAM Policy IAM Policy SCP GuardDuty GuardDuty GuardDuty ◼AWS Organizationsで解決できる課題 ⚫ 複数アカウントの一括請求、アカウントごとの利用料明細管理 ⚫ AWSアカウントの高速な作成 ⚫ 組織単位（Organizational Unit）によるアカウントのグループ管理 ⚫ セキュリティサービスの自動設定 ⚫ Service Control Policy (SCP)による予防的ガードレールの設定有効となるポリシー（可能な操作）請求（カード）情報 ◯ ◯ ◯ ◯ IAM Policy

AWS re:Invent 2024 - Dr. Werner Vogels Keynote をおさらい複雑さにどのように取り組むか（Dr. Werner Vogels Keynote）米Amazon.com のCTOであり、AWS の設計者の一人である Dr. Werner Vogels がAWSの開発経験などを例に挙げながら、Keynoteでシンプルな設計の重要性を説いた。大きく２部構成: • 第一部：複雑さにどのように取り組むか • 第二部：分散Database とそれを支える時計 ※新サービスの発表はなし２名のゲストスピーカー: • Brendan Humphreys/ CTO, Canva • Robert Christiansen / VP of Engineering, Too Good To Go （出典：Announcements and updates from AWS re:Invent 2024 https://www.aboutamazon.com/news/aws/aws-reinvent-2024-keynote-live-news-updates）

オッカムの剃刀 - シンプルさを指向する複雑さにどのように取り組むか（Dr. Werner Vogels Keynote）必要以上にオブジェクトを掛け算してはいけない、物事をシンプルに保つという考え方。 • 「ある事柄を説明する際に、必要以上に多くのことを仮定してはならない」 = シンプルな形を目指すべきもしくは、KISS原則: • Keep it simple (,) stupid.（シンプルで愚鈍にする） • Keep it short and simple.（簡潔で単純にしよう）

複雑さからは逃れられない複雑さにどのように取り組むか（Dr. Werner Vogels Keynote）多くの場合複雑さは避けられない。システムは時間の経過とともに複雑になるが、より多くの機能が追加され良いことである。規模の拡大やセキュリティの問題など、あらゆる問題に対処する必要がある。 • 複雑化することは悪いことではない、むしろ目指すべきこと（多機能化、スケール）問題なのは結果として、「イノベーションが遅くなること」 • テスラーの複雑性保存の法則「どんなシステムにもそれ以上減らせない複雑さがある」 →どこか別の場所へ移動することしかできない • 意図した複雑性と意図しない複雑性の見極めが重要「意図した複雑性」システムの拡張、新機能への適応「意図しない複雑性」パフォーマンス低下やデバッグ時間の増加 Unintended Complexity Intended Complexity

複雑さは警告であり、シンプルさには規律が必要複雑さにどのように取り組むか（Dr. Werner Vogels Keynote）複雑さは警告であり、進歩を妨げ、システムの柔軟性と信頼性を同時に維持することを妨げる。物事をシンプルに保ちながら複雑さを加えるには、規律が必要。 exity Simpl 複雑さとシンプルさの間に相補的な関係がある可能性を示唆する造語 Simplicity requires discipline

６つの教訓複雑さにどのように取り組むか（Dr. Werner Vogels Keynote） 1. Make Evolvability a requirement（進化可能性を要件にする）進化できるシステムを作る / 警告を見逃さない 2. Break Complexity into pieces（複雑さ細かく分解する） Expand or New / ビルディングブロック 3. Align organization to architecture（組織をアーキテクチャに合わせる）組織はソフトウェアと同等以上に複雑である / 「いつもそうやっています」は危険信号 4. Organize into cells（セルベースのアーキテクチャについて）複雑なシステムでは問題の影響範囲を減らす仕組みが必要 / 設計・開発より運用フェーズの方が長いことを意識する 5. Design predictable systems（予測可能なシステムを設計する）不確実性の影響を低減する / より、シンプルな選択を 6. Automate complexity（複雑さは自動化する）自動化は複雑さを管理できるようにする / 「何を自動化しないか」が重要進化する力複雑性の細分化組織形態セルベースアーキテクチャ予測可能なシステムの設計自動化

AWS Organizations によるガバナンスの変革組織管理に関するAWSアップデート Management & Governance/Security, Identity, & Compliance ⚫ https://aws.amazon.com/new/?nc1=h_ls&whats-new-content-all.sort- by=item.additionalFields.postDateTime&whats-new-content-all.sort-order=desc&awsf.whats- new-categories=marketing-marchitecture%23security-identity-and-compliance AWSサービスアップデート: • マルチアカウント環境を管理するための新しいポリシー 1. Introducing resource control policies (RCPs) to centrally restrict access to AWS resources（2024/11/14） 2. Amazon Web Services announces declarative policies（2024/12/2） • AWS Organizationsのメンバーアカウントのルートアクセスを一元管理できるようにする新しい機能 1. Centrally manage root access in AWS Identity and Access Management (IAM) （2024/11/16）

AWS Organizations の３つのポリシーの整理組織管理に関するAWSアップデート Service Control Policies（SCP）, Resource Control Policy（RCP）, Declarative Policies （宣言的ポリシー）の特徴 SCP RCP（新規） Declarative policies（新規）目的プリンシパルの権限の中央管理リソースへのアクセス権限の中央管理 AWSサービスの設定の中央管理制限方法 APIレベルの制限 APIレベルの制限 APIレベルの制限ではなく AWSサービスの望ましい設定を強制例プリンシパルが利用できるリージョンを制限リソースへのアクセスをHTTPS に制限 VPC がパブリックアクセスできないように設定ポリシー承認ポリシー承認ポリシー管理ポリシー（出典：OpsJAWS32 re:Invent 2024 Ops系アップデートまとめ https://speakerdeck.com/takahirohori/opsjaws32-re-invent-2024-opsxi-atupudetomatome?slide=17） ※出典の表に対して「ポリシー」の種類を追加しています

リソースへのアクセスを一元的に管理する Resource Control Policy（RCP）組織管理に関するAWSアップデート組織内外からのリソースアクセスをより安全にするポリシーを簡単に適用 ※SCPよりも前に評価される ◼課題 ⚫ SCPはあくまでプリンシパル単位の制限でリソースへのアクセスに一元的な制限をかけられなかった ◼実現すること ⚫ 組織内の複数のAWSアカウントにまたがるリソースに対して、一貫性のあるアクセス制御を強制適用 ⚫ リソースがアクセスされる際に評価され、誰がAPIリクエストを行っているかに関係なく適用 ⚫ サポート対象サービス ▪Amazon S3 ▪Amazon SQS ▪AWS STS（AWS Security Token Service） ▪AWS KMS（AWS Key Management Service） ▪AWS Secrets Manager （出典：OpsJAWS32 re:Invent 2024 Ops系アップデートまとめ https://speakerdeck.com/takahirohori/opsjaws32-re-invent-2024-opsxi-atupudetomatome?slide=18）

RCP と SCP によるアクセス制御の適用組織管理に関するAWSアップデート（出典：OpsJAWS32 re:Invent 2024 Ops系アップデートまとめ https://speakerdeck.com/takahirohori/opsjaws32-re-invent-2024-opsxi-atupudetomatome?slide=19） RCP SCP 組織内のリソースに一貫したアクセス制御を適用組織内のプリンシパルに一貫したアクセス制御を適用ユースケースの例： • 外部IDによるリソースへのアクセスを防ぐ • 混乱する代理問題を統制 • 機密リソースへの統制の適用 AWS Organizations ユースケースの例： • IDが外部リソースにアクセスするのを防ぐ • 開発者が使用できるサービスやリージョンを定義 • クラウドプラットフォームのリソースを保護 ※出典の図に対して各ポリシーが影響を及ぼす方向性を追記しています

宣言的ポリシー（Declarative Policies for EC2）による予防的統制組織管理に関するAWSアップデート組織全体へのポリシー適用の維持が複雑な作業なく簡単に実現可能（GUIによる設定が可能） ◼課題 ⚫ SCPでの制限や AWS Config での検知を APIレベルで行っても望ましい制限で永続的に実現するためには、新しいAPIや機能ごとにポリシーを見直す必要がある ◼実現すること ⚫ AWSサービスのコントロールプレーンにおいて、サービスレベルで直接適用されるため、宣言的ポリシーで設定した状態は常に強制的に維持される ⚫ サポート機能（EC2）シリアルコンソールアクセス（EC2） AMIのブロックパブリックアクセス（EC2）許可されたAMIの利用設定（EC2）インスタンスメタデータのデフォルト設定（VPC） VPCのブロックパブリックアクセス（EBS） EBSのスナップショットのブロックパブリックアクセス（出典：OpsJAWS32 re:Invent 2024 Ops系アップデートまとめ https://speakerdeck.com/takahirohori/opsjaws32-re-invent-2024-opsxi-atupudetomatome?slide=20）

AWSサービスのコントロールプレーンとは？組織管理に関するAWSアップデート IAMリソースはIAMのコントロールプレーンに保管されており、AWSリソースの操作は各AWSサービスのエンドポイント経由でAPIからレプリカ相当のデータプレーンで認証・認可を実施（出典：AWS アイデンティティおよびアクセス管理における回復力 https://docs.aws.amazon.com/IAM/latest/UserGuide/disaster-recovery-resiliency.html） IAMリソースの操作 AWSリソースの操作 AWSサービスバージニア北部リージョン各リージョン AWS Identity and Access Management (IAM) AWS Identity and Access Management (IAM) コントロールプレーンデータプレーン IAMエンドポイント IAMエンドポイント構成変更の伝搬 ※簡素化のため、バージニア北部リージョンのデータプレーンを省略しています

宣言的ポリシー（Declarative Policies）の機能詳細組織管理に関するAWSアップデート ◼Account status report ⚫ アカウントステータスレポートを利用することで、現在のAWSリソースのステータスを把握し、ポリシー適用による影響を事前に評価可能 ⚫ 定期的にレポートを生成することで、組織のセキュリティ状態や設定の一貫性を継続的に監視 ◼Custom error message ⚫ カスタムエラーメッセージにより、ポリシー違反の理由や次のステップについて明確な情報を提供可能 ⚫ 社内のWikiページやサポートポータルなど、より詳細な情報を提供するリソースにユーザーを誘導可能（出典：OpsJAWS32 re:Invent 2024 Ops系アップデートまとめ https://speakerdeck.com/takahirohori/opsjaws32-re-invent-2024-opsxi-atupudetomatome?slide=21）

AWS Organizations のメンバーアカウントのルートアクセスを一元管理できるようにする機能組織管理に関するAWSアップデート（出典：OpsJAWS32 re:Invent 2024 Ops系アップデートまとめ https://speakerdeck.com/takahirohori/opsjaws32-re-invent-2024-opsxi-atupudetomatome?slide=22）煩雑だった組織全体のメンバーアカウントのルートユーザー認証情報の管理が簡単および不要に ◼課題 ⚫ AWS Organizations の各メンバーアカウントのルートユーザーの認証情報管理（MFA 等）や保護は煩雑 ⚫ 誤って設定した Amazon S3, Amazon SQS をロック解除するなど特定のアクションでルートアクセスは必要 ◼実現すること ⚫ ルートユーザーの認証情報をダッシュボードで管理アカウントから一元管理 ⚫ 管理アカウントからメンバーアカウントのルートユーザー認証情報の削除 ⚫ 管理アカウントからメンバーアカウントのS3バケットポリシー、SQSキューポリシーのロック解除

複雑さからは逃れられない組織管理における複雑性と課題例多くの場合複雑さは避けられない。システムは時間の経過とともに複雑になるが、より多くの機能が追加され良いことである。規模の拡大やセキュリティの問題など、あらゆる問題に対処する必要がある。 • 複雑化することは悪いことではない、むしろ目指すべきこと（多機能化、スケール）問題なのは結果として、「イノベーションが遅くなること」 • テスラーの複雑性保存の法則「どんなシステムにもそれ以上減らせない複雑さがある」 →どこか別の場所へ移動することしかできない • 意図した複雑性と意図しない複雑性の見極めが重要「意図した複雑性」システムの拡張、新機能への適応「意図しない複雑性」パフォーマンス低下やデバッグ時間の増加再掲組織管理における複雑性とは何か？

組織管理における複雑性組織管理における複雑性と課題例「利用者」が負担するはずの複雑さ ↓（移動） <組織管理における複雑性> 規模の拡大やセキュリティの問題などあらゆる問題意図しない複雑性イノベーションが遅くなること「組織」として負担する複雑さ

AWSアカウント管理における複雑性組織管理における複雑性と課題例 AWS利用初期段階で１アカウント単独での管理をする場合、１つのAWSアカウント上にVPCを作成して、VPC上にワークロード（システム）を構築していきます。 Amazon Elastic Compute Cloud (Amazon EC2) Amazon EC2 Amazon EC2 Virtual private cloud (VPC) VPC VPC AWS account

単独アカウントで管理し続けると、やがてこんな課題に直面・・・組織管理における複雑性と課題例 Virtual private cloud (VPC) Amazon Elastic Compute Cloud (Amazon EC2) VPC Amazon EC2 VPC Amazon EC2 AWS account 開発環境、本番環境が混在するリソースのトラッキングが難しいクォータ制約を受けやすいコスト配分タグを利用したコスト分離が必要リソースに対する操作の間違いが発生してしまうリスクがある利用部門ごとにコスト配分するのが大変他チームのリソース利用の影響により、リソース制約を受けてしまう結果として、「グレーな」境界で曖昧になり、責任の押し付け合いが発生

マルチアカウントで管理しても課題は残る・・・組織管理における複雑性と課題例規模の拡大に伴いAWSアカウントを増やして管理する形になり、マルチアカウントで個々にAWSアカウントを管理します。この場合、IAMの踏み台アカウントを用意して、IAMユーザを管理します。クロスアカウントIAMロールにより各AWSアカウントへスイッチするアクセス制御を考えます。 VPC Amazon EC2 AWS account AWS account Role VPC Amazon EC2 AWS account Role AWS CloudTrail AWS CloudTrail 各アカウントにユーザが増えることにより管理負荷が増加各アカウントの状況を把握できない個々のアカウント単位の請求組織として一元管理できる仕組みが必要

「AWS Organizations」を利用して組織としてマルチアカウントで管理する組織管理における複雑性と課題例 AWSアカウントが１０アカウントを超えると、アカウントを個々で管理することが難しくなり、「AWS Organizations」を利用した組織としてのマルチアカウント管理が必要となります。 AWS IAM Identity Center、AWS Organizationsの一括請求やService Control Policy（SCP）、 CloudFormation StackSets等のAWSサービス・機能を利用してマルチアカウントを管理します。 AWS Organizations Management account Organizational unit Organizational unit Organizational unit AWS CloudTrail Accounts Accounts AWS IAM Identity Center Accounts

「AWS Organizations」を利用してマルチアカウント管理すれば、課題はおおむね解消組織管理における複雑性と課題例課題①：管理するユーザが増加する課題②：トラッキング、利用料金の請求処理が難しい課題③：クォータ制約を受けやすい AWS IAM Identity Centerによるユーザおよびアクセス制御の一元管理が可能 AWS CloudTrail等の組織単位のログ一元管理が可能、複数アカウントの一括請求アカウント毎のリソース管理となり、他アカウントのリソースによる影響を受けない ※ただし、アカウント単位でクォータ制約は存在するため上限の意識は必要…！

「AWS Organizations」を利用できるマルチアカウント管理で万事解決？組織管理における複雑性と課題例 A. いいえ、運用においても課題は発生します。 …etc. これらの課題に対処しながら、組織管理が必要になります AWSアップデートに伴う組織管理機能の適応制御すべき操作を制御できていないことによる問題発生操作を制御しすぎた利用しづらい環境組織単位の設計考慮不足による、組織レベルの障害が起きてしまう

６つの教訓組織管理の役割とシンプルな設計観点 1. Make Evolvability a requirement（進化可能性を要件にする）進化できるシステムを作る / 警告を見逃さない 2. Break Complexity into pieces（複雑さ細かく分解する） Expand or New / ビルディングブロック 3. Align organization to architecture（組織をアーキテクチャに合わせる）組織はソフトウェアと同等以上に複雑である / 「いつもそうやっています」は危険信号 4. Organize into cells（セルベースのアーキテクチャについて）複雑なシステムでは問題の影響範囲を減らす仕組みが必要 / 設計・開発より運用フェーズの方が長いことを意識する 5. Design predictable systems（予測可能なシステムを設計する）不確実性の影響を低減する / より、シンプルな選択を 6. Automate complexity（複雑さは自動化する）自動化は複雑さを管理できるようにする / 「何を自動化しないか」が重要進化する力複雑性の細分化組織形態セルベースアーキテクチャ予測可能なシステムの設計自動化再掲

「進化する力」組織管理の役割とシンプルな設計観点 1. Make Evolvability a requirement（進化可能性を要件にする）進化できるシステムを作る / 警告を見逃さない進化する力 AWS Organizations Management account Organizational unit Organizational unit Organizational unit AWS CloudTrail Accounts Accounts AWS IAM Identity Center Accounts AWS Organizations を利用できる環境を導入して、進化できる組織管理を実現

「複雑性の細分化」組織管理の役割とシンプルな設計観点 2. Break Complexity into pieces（複雑さ細かく分解する） Expand or New / ビルディングブロック複雑性の細分化 AWSアカウントを増やして分離することが可能組織単位（OU) 用語説明組織一元管理可能なAWSアカウントの集まり管理アカウント組織を管理するAWSアカウント。組織に１つだけ存在するメンバーアカウント組織に属するAWSアカウント組織単位（OU) 組織内のAWSアカウントの管理単位サービスコントロールポリシー（SCP） AWSリソースの利用許可・禁止を定義したルールセット組織ルート組織単位（OU) 組織単位（OU) 管理アカウントメンバーアカウントメンバーアカウントメンバーアカウントメンバーアカウント SCP SCP SCP

「アーキテクチャーに合わせた組織形態」組織管理の役割とシンプルな設計観点 3. Align organization to architecture（組織をアーキテクチャに合わせる）組織はソフトウェアと同等以上に複雑である / 「いつもそうやっています」は危険信号組織形態各チームにオーナーシップを持たせる中央集権化が必要か考える非中央集権型中央集権型 or

「（小さく分割した『セル』単位で考える）セルベースアーキテクチャ」組織管理の役割とシンプルな設計観点 4. Organize into cells（セルベースのアーキテクチャについて）複雑なシステムでは問題の影響範囲を減らす仕組みが必要 / 設計・開発より運用フェーズの方が長いことを意識する組織単位（Organizational Units：OUs）を正しく設計することにより、問題の影響範囲を減らすことができるセルベースアーキテクチャ Root/OU名説明想定アカウント Root Organizationsのルートマネジメントアカウント Security OU セキュリティ関連のアクセスやサービスをホスト監査、ログアーカイブ、セキュリティツール Infrastructure OU ネットワーク/ITサービス等の共有インフラストラクチャサービスを管理バックアップ、監視、ネットワーク、メッセージングサービスなど Workload OU ソフトウェアライフサイクルに関連するAWSアカウントを管理子OU(DEV-OU/STG-OU/PROD-OU)の実装も検討事業部アカウント Sandbox OU 技術者がAWSサービスを学び、試すためのOU 個々の技術者アカウント Policy Staging OU ポリシーや構造の変更をテストするためのOU テスト用アカウント Suspended OU 閉鎖され、削除待ちのAWSアカウントを含むOU 停止アカウント Individual Business Users OU ビジネスユーザーのためのAWSアカウントを含むOU S3バケット設定用アカウント Exceptions OU 特定ユースケースに対する例外ポリシーを適用するためのOU 特殊プロジェクト用アカウント Deployments OU CI/CDデプロイ用AWSアカウントを管理するためのOU デプロイ用アカウント（出典：AWSのマルチアカウント管理で意外と知られていないOU設計の話 https://speakerdeck.com/pikosan0000/awsnomarutiakauntoguan-li-teyi-wai-tozhi-rareteinaioushe-ji-nohua?slide=32） ※出典の表に対して「Sandbox OU」等を追記しています

「予測可能なシステムの設計」組織管理の役割とシンプルな設計観点 5. Design predictable systems（予測可能なシステムを設計する）不確実性の影響を低減する / より、シンプルな選択を解約済みアカウントを考慮した設計も必要予測可能なシステムの設計 Root/OU名説明想定アカウント Root Organizationsのルートマネジメントアカウント Security OU セキュリティ関連のアクセスやサービスをホスト監査、ログアーカイブ、セキュリティツール Infrastructure OU ネットワーク/ITサービス等の共有インフラストラクチャサービスを管理バックアップ、監視、ネットワーク、メッセージングサービスなど Workload OU ソフトウェアライフサイクルに関連するAWSアカウントを管理子OU(DEV-OU/STG-OU/PROD-OU)の実装も検討事業部アカウント Sandbox OU 技術者がAWSサービスを学び、試すためのOU 個々の技術者アカウント Policy Staging OU ポリシーや構造の変更をテストするためのOU テスト用アカウント Suspended OU 閉鎖され、削除待ちのAWSアカウントを含むOU 停止アカウント Individual Business Users OU ビジネスユーザーのためのAWSアカウントを含むOU S3バケット設定用アカウント Exceptions OU 特定ユースケースに対する例外ポリシーを適用するためのOU 特殊プロジェクト用アカウント Deployments OU CI/CDデプロイ用AWSアカウントを管理するためのOU デプロイ用アカウント

「自動化」組織管理の役割とシンプルな設計観点 6. Automate complexity（複雑さは自動化する）自動化は複雑さを管理できるようにする / 「何を自動化しないか」が重要自動化 AWS Control Tower Management Amazon S3 • CloudTrail Logs • Config Logs Log Archive Audit AWS Config Aggregator AWS Organizations AWS IAM Identity Center Security Baseline Network Baseline Amazon Simple Notification Service (Amazon SNS) Security OU Workloads OU AWSアカウント管理やガードレール、セキュリティ設定の自動化を考える

（参考）AWSマルチアカウント管理で活用できるAWSサービスや機能組織管理の役割とシンプルな設計観点 ◼AWSマルチアカウント管理の考え方!（5分編）p.22～ https://speakerdeck.com/htan/awsmarutiakauntoguan-li-nokao-efang-5fen- bian?slide=23

本日お話すること 01 AWSマルチアカウント管理の必要性と組織管理 02 組織管理に関するAWSアップデート 03 組織管理における複雑性と課題例 04 組織管理の役割とシンプルな設計観点 05 Summary, References & Appendix 06

Summary Summary, References & Appendix ◼AWSマルチアカウント管理の必要性と組織管理 ➢一律の水準で管理するには、仕組み（AWS Organizations によるマルチアカウント管理）が必要 ◼複雑さにどのように取り組むか（Dr. Werner Vogels Keynote） ➢ 複雑さからは逃れられない ➢ 「意図しない複雑性」を見極めて、「イノベーションが遅くなる」問題を避ける ➢ ６つの教訓 ◼組織管理に関するAWSアップデート ➢マルチアカウント環境を管理するための新しいポリシー（RCP、宣言的ポリシー） ➢AWS Organizationsのメンバーアカウントのルートアクセスを一元管理できるようにする新しい機能 ◼組織管理における複雑性と課題例 ➢「利用者」が負担するはずの複雑さ → 「組織」として負担する複雑さ ➢AWS Organizations を利用したマルチアカウント管理 ➢AWS Organizations を利用したマルチアカウント管理で万事解決ではない ◼組織管理の役割とシンプルな設計観点 ➢６つの教訓から組織管理の役割を考える

References Summary, References & Appendix ◼ AmazonのボーガスCTOがre:Inventで語った、システムをシンプルに保つ6カ条 https://xtech.nikkei.com/atcl/nxt/column/18/03027/120700006/ ◼ AWSのマルチアカウント管理で意外と知られていないOU設計の話 https://speakerdeck.com/pikosan0000/awsnomarutiakauntoguan-li-teyi-wai-tozhi-rareteinaioushe-ji-nohua ◼ OpsJAWS32 re:Invent 2024 Ops系アップデートまとめ https://speakerdeck.com/takahirohori/opsjaws32-re-invent-2024-opsxi-atupudetomatome ◼ AWS Organizations の新しいタイプの認可ポリシーであるリソースコントロールポリシー (RCP) のご紹介 https://aws.amazon.com/jp/blogs/news/introducing-resource-control-policies-rcps-a-new-authorization-policy/ ◼ 宣言型ポリシーでガバナンスを簡素化する https://aws.amazon.com/jp/blogs/news/simplify-governance-with-declarative-policies/ ◼ AWS Organizations を使用するお客様のためのルートアクセスの一元管理 https://aws.amazon.com/jp/blogs/news/centrally-managing-root-access-for-customers-using-aws- organizations/ ◼ AWS Organizations は、メンバーアカウントを閉鎖するためのシンプルでスケーラブルかつより安全な方法を提供します https://aws.amazon.com/jp/blogs/mt/aws-organizations-now-provides-a-simple-scalable-and-more-secure- way-to-close-your-member-accounts/ ◼ Organizations で、メンバーアカウントのメールアドレスを変更する方法を教えてください。 https://repost.aws/ja/knowledge-center/organizations-change-member-email

References（Others） Summary, References & Appendix ◼ Managing organization policies with AWS Organizations https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies.html ◼ How AWS enforcement code logic evaluates requests to allow or deny access https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic_policy-eval- denyallow.html ◼ SCP・RCP・宣言型ポリシーの違いを簡単に整理してみた https://tech.nri-net.com/entry/scp_rcp_declarative_policies ◼ AWS アイデンティティおよびアクセス管理における回復力 https://docs.aws.amazon.com/IAM/latest/UserGuide/disaster-recovery-resiliency.html

Appendix Summary, References & Appendix Xのおすすめハッシュタグ #地味でも大事なAWS AWS公式ブログやAWSサービスアップデート情報 AWSサービスアップデートの中でも役に立つアップデート情報をワンポイント日本語コメント付きで発信してくれています組織管理や運用に役立つ情報が多いので注目してます！

2025/1/29（水）12:00~13:00 ウェビナー Appendix ◼「SaaS企業様向けAWSコストの徹底削減とマルチアカウント管理への移行事例」 AWSガバナンス統制とコスト削減方法 AWS直接契約から請求代行への移行事例を２件ご紹介します【ウェビナーアジェンダ】 ⚫NRIネットコムの紹介 ⚫AWSアカウントにまつわるセキュリティとガバナンス ⚫SaaS企業でのアカウント管理、コスト削減事例 ⚫AWS利用料削減のノウハウ ⚫NRIネットコムのAWS請求代行&アカウント管理サービス是非お申込みください

2025/1/29（水）19:00~20:00 共催ウェビナー Appendix ◼運用視点で考えるAWSマルチアカウントとECS運用の最適化是非お申込みください

2025/1/30（木）12:00~13:00 ウェビナー Appendix ◼「次世代大規模サイトリニューアルの罠と成功へのプロセス」徹底解説ご好評につき4回目の開催が決定！是非お申込みください

AWS re:Invent 2024 で考える AWSマルチアカウント管理における複雑性とシン...

AWS re:Invent 2024 で考える AWSマルチアカウント管理における複雑性とシンプルな設計 ~AWS Organizations の活用と組織管理に関するアップデート~

More Decks by Hayato Tan

Other Decks in Technology

Featured

Transcript

AWS re:Invent 2024 で考えるAWSマルチアカウント管理における複雑性とシン...