In Silico

クラウド

AWSマルチアカウントとは？分ける理由とOrganizationsの設計

2026/10/16 シリーズ「AWS 入門」 第2回 / 全4回

🤖 AIを使用して執筆

  • マルチアカウント
  • AWS アカウント
  • クラウド
  • AWS Organizations
  • OU
  • SCP
  • RCP
  • 管理アカウント
  • メンバーアカウント
  • マルチアカウント戦略
  • マルチアカウント構成
  • AWS Control Tower
  • ランディングゾーン
  • ルートユーザー
  • 無料プラン
  • 無料利用枠
  • 一括請求
  • 宣言型ポリシー
  • 委任管理者
  • Service Quotas
  • Account Factory
  • IAM Identity Center
目次
背景・問い・要点
背景

一つの契約の中で、本番のシステムも、開発中の機能のテストも、新しいサービスの検証も動かしていると、どれかの失敗がほかに及ぶことがある。権限を細かく設定して防ぐこともできるが、設定が増えるほど、誤りも見つけにくくなる。

契約そのものを用途ごとに分けておけば、権限を一つずつ絞らなくても、用途どうしは初めから切り離される。ただし、分けた後には、分けたものどうしをつなぐ道と、全体をまとめて管理する仕組みが要る。

問い

AWS のアカウントは何を区切るものか。なぜ AWS はアカウントを複数に分けるよう勧め、分けた後には何が難しくなるのか。

要点

AWS のアカウントは、権限、費用、サービスの上限、事故の影響を区切る境界である。AWS は、用途と環境ごとにアカウントを分けて AWS Organizations で束ね、推奨の構成の一部から始めて、必要に応じて広げるよう勧めている。ただし、アカウントどうしをつなぐほど境界はあいまいになり、束ねる管理アカウントには強い権限が集まる。

モデル・例示

負荷テストが、模試の本番を止める塾

※ この節の数値は説明のための仮定で、測定値ではありません。

オンラインで模試を受けられるようにしている塾があるとする。模試を配信する本番のシステムも、開発中の新しい機能のテストも、職員が新しいサービスを試す環境も、一つの AWS アカウントの中にある。

模試の前日、開発の担当者が、本番と同じ規模で負荷テストを始め、テストは翌朝まで続いた。テスト用の処理が、同じリージョンでアカウントの上限の多くを使っていたため、模試の当日、答案を受け付ける処理を増やせなくなった。

  1. 負荷テストアカウントの上限1. テスト用の処理を大量に動かす
  2. 受験者答案の受付2. 答案を送る
  3. 答案の受付アカウントの上限3. 処理を増やしたい
  4. アカウントの上限答案の受付4. 上限に達したので断る
※概念図（やりとり）：本文の手順を図式化したもの。

同じアカウントの中では、上限のほかに権限と費用も共有している。テストのために強い権限を持った担当者は、本番のデータも消せる。月末の請求では、模試の配信とテストの費用が区別されずに届く。本番、開発、検証の環境を別々のアカウントに分けていれば、上限はアカウントごとに分かれ、費用もアカウントごとの内訳で見られる。アカウントの間のアクセスを明示的に許さない限り、テストの担当者は本番のデータに触れられない。

分けた後に、本番の模試の答案を使って、開発のアカウントで新しい機能を試したくなったとする。本番のアカウントのロールが開発のアカウントを信頼するように設定すれば答案を読めるが、開発のアカウントで強い権限を持つ人も、その道を通って答案に届くようになる。三つのアカウントを束ねる管理アカウントからは、三つすべてに手が届く。

AWS アカウントとは：資源と権限と費用を区切る単位

AWS によれば、AWS アカウントは、利用者が作るすべての資源を入れる基本の入れ物であり、資源を守る基本のセキュリティの境界でもある1。資源にはそれぞれ ARN（Amazon Resource Name）という名前が付き、その中に資源を持つアカウントの ID が入る1。

AWS のホワイトペーパー「Organizing Your AWS Environment Using Multiple Accounts」は、アカウントを、権限の管理を分ける境界と呼んでいる。アカウントの間で資源を共有するには明示的な許可が要り、既定では、アカウントの間のアクセスは一切許されない2。

境界になるのは権限だけではない。同じホワイトペーパーによれば、アカウントは AWS の費用を割り振る既定の単位で、サービスの上限（Service Quotas）と、API を呼べる頻度の上限も、アカウントごとに割り当てられる2。上限には、アカウント全体にかかるものと、リージョンごとにかかるものがある3。料金は資源の使用量で決まり、アカウントの数では決まらない2。

マルチアカウントとは：アカウントを分ける八つの理由

マルチアカウント構成は、一つの組織が AWS のアカウントを複数持ち、用途や環境ごとに分けて使う構成である。ホワイトペーパーは、複数のアカウントを使う利点を八つ挙げている2。ここでのワークロードは、注文の受付や社内の経費の精算のように、一つの目的のために動くアプリと資源のまとまりのことである。

  1. 事業の目的と持ち主ごとに、ワークロードをまとめられる
  2. 本番や開発などの環境ごとに、別のセキュリティの統制をかけられる
  3. 機密のデータへのアクセスを絞れる
  4. 新しい試みを素早く始めやすくなる
  5. 事故の影響の範囲を限れる
  6. 複数の IT の運用のやり方を併存させられる
  7. 費用を管理しやすくなる
  8. サービスの上限と、API を呼べる頻度の上限を分散できる

五つ目の事故として、ホワイトペーパーは、アプリの不具合、設定の誤り、悪意のある操作を挙げている。どれかが一つのアカウントで起きても、影響をそのアカウントの中に抑え、ほかのアカウントのワークロードに及ばないようにできる2。三つ目についても、一つの広いアカウントの中で細かい権限を管理するのではなく、アカウントの単位で粗く絞れると書いている2。

本番については、一つのアカウントに一つのワークロードか、密接に関係する少数のワークロードを置くよう勧めている2。本番と本番以外を別のアカウントにすれば、ある環境の資源とデータは、既定でほかの環境から切り離される2。

ホワイトペーパーは、AWS を使い始めるときから、一つのアカウントに頼らずにマルチアカウント戦略をとるよう勧めている。一方で、一つのアカウントで AWS を試し、学んでいる段階なら、最初のいくつかの本番のワークロードを計画し始めるまで、これらを考えなくてよいとも書いている2。

AWS Organizations：アカウントを束ね、上限をかける

AWS Organizations は、複数のアカウントを一つの組織にまとめるサービスである。組織を作ったアカウントは管理アカウントになる。管理アカウントは組織の最終的な持ち主で、セキュリティ、基盤、費用の方針を決める権限を握り、組織に入ったメンバーアカウントのすべての料金を払う4。メンバーアカウントが入れる組織は、一度に一つだけである4。

請求は一つにまとまる。一括請求は追加の料金なしで使え、組織内のすべてのアカウントの使用量を合わせて、使用量に応じた割引や Savings Plans（一定の利用を約束して単価を下げる契約）を共有できる5。

アカウントは、組織単位（OU）という入れ物に入れて階層を作る。OU は、親の OU に付いたポリシーを引き継ぐ4。

組織にかけるポリシーの中心は、二つの上限である。IAM は、AWS の中で誰が何をできるかを決める仕組みで、人やプログラムの ID をユーザーやロールとして作り、権限を付ける。SCP（サービスコントロールポリシー）は、組織の IAM のユーザーとロールが持てる権限の上限を決める。2024 年 11 月に加わった RCP（リソースコントロールポリシー）は、反対に、資源の側で許される権限の上限を決める6。たとえば、組織の外からは組織の S3 バケットにアクセスできない、という決まりを組織全体にかけられる6。発表の時点で RCP が使えたのは、Amazon S3、AWS STS、AWS KMS、Amazon SQS、AWS Secrets Manager の資源だった6。2026 年 10 月の時点では、Amazon DynamoDB や Amazon CloudWatch Logs を含む 62 のサービスが、AWS の文書の一覧に載っている7。

AWS の文書は、組織のポリシーを二つの種類に分けている8。

種類何を決めるか
認可のポリシー組織のアカウントのセキュリティを一か所で管理する。SCP と RCP がある
宣言型ポリシーサービスとその機能の設定を、組織全体で一か所で決める。バックアップやタグのポリシーなどもこの種類に入る

2024 年 12 月には、EC2、EBS、VPC の設定を組織全体で決める新しいポリシーが、宣言型ポリシーの名前で加わった。一度決めておけば、サービスに新しい API が加わったり、組織に新しいアカウントが入ったりしても、その設定が保たれる9。

組織のポリシーの管理や、Organizations と連携する AWS のサービスの管理は、管理アカウントのかわりに、指定したメンバーアカウントから行える。このアカウントを委任管理者と呼ぶ4。

OU は組織図ではなく、統制の違いで分ける

OU の分け方について、ホワイトペーパーは、社内の報告の系統（組織図）を写すのではなく、役割、コンプライアンスの要件、共通の統制で分けるよう勧めている2。推奨の OU のうち、基盤の OU とされるのは Security と Infrastructure の二つである2。主な OU は次のとおりである。

OUまとめるアカウント
Security（基盤）組織全体にセキュリティの方針と統制をかけるアカウント。ログを集めて保管するアカウントなど
Infrastructure（基盤）組織で共有するネットワークなどの基盤を持つアカウント
Workloads業務のワークロードを動かすアカウント。本番と本番以外の両方
Sandbox検証、テスト、開発に使うアカウント。本番の資源へのアクセスは限られる
Policy Staging新しいポリシーや変えたポリシーを、本番に付ける前に試すアカウント
Suspendedセキュリティ上の懸念などで、使用を一時的に止めたアカウント

ホワイトペーパーは、このほかに、例外の扱いが要るアカウントや、移行の途中のアカウントのための OU なども挙げている。ただし、推奨の OU とアカウントの一部から始め、必要になったときに広げるよう勧めている。何年も先のアカウントの構成を、使い始めの段階で時間をかけて設計する必要はないという2。

管理アカウントには、業務の資源を置かない

ホワイトペーパーによれば、組織のアカウントは管理アカウントを信頼する関係を持つので、管理アカウントの管理者の権限は、組織全体の特権に等しい。そのうえ、SCP は管理アカウントに効かない2。RCP も、管理アカウントの資源には効かない7。宣言型ポリシーは、組織のルートに付ければ管理アカウントにもかかる4。ホワイトペーパーは、管理アカウントへのアクセスを絞り、業務のワークロードにも業務の資源にも使わないよう勧めている2。

AWS の話題を扱うニュースレター Last Week in AWS を書く Corey Quinn は、2020 年の時点で、管理アカウントは強大な力を持ち、そこでしかできない作業があると書いた。費用の明細（Cost & Usage Reports）は管理アカウントに届き、AWS の解説記事の多くは、それを分析する仕組みも管理アカウントに作っていた。Quinn は、AWS との契約も、組織の内と外の線引きも、このアカウントに結びつくので、そのすべてに誰かがアクセスできれば問題になると指摘している10。

委任管理者を使っても、サービスによっては、管理アカウントでしかできない作業がある。Rowan Udell は 2025 年に、IAM Identity Center（複数のアカウントへの人のログインをまとめる AWS のサービス）の管理をメンバーアカウントに委任しても、管理アカウントの中の利用者と権限の設定を変えるには、管理アカウントに入る必要があると書いた11。Udell は、この制限は権限の昇格（与えられた以上の権限を自分に付けること）を防ぐので、セキュリティの面では理にかなっているとも書いている11。

メンバーアカウントの側にも、強い権限の入り口がある。アカウントのすべてに完全にアクセスできる、各アカウントのルートユーザーである。AWS は 2024 年 11 月に、メンバーアカウントのルートユーザーを一か所で管理する機能を加えた。メンバーアカウントからルートユーザーの長期の認証情報を消し、ルートユーザーの権限が要る一部の作業だけを、一時的な認証情報で行える12。この作業は、メンバーアカウントに入らずに中央のアカウントから行い、AWS が示す手順では、管理アカウントから一時的な認証情報を取っている12。AWS は、何百、何千のアカウントを持つ大企業が、すべてのアカウントのルートユーザーを同じように守るのに苦労していたと説明している12。

AWS Control Tower：推奨の構成をまとめて作る

ここまでの OU、ポリシー、管理アカウントの設定を一から組むかわりに、AWS Control Tower を使う方法もある。Control Tower は、セキュリティとコンプライアンスのベストプラクティスに基づく、複数のアカウントの環境を作る。この環境をランディングゾーンと呼ぶ13。

Control Tower の統制（コントロール）には、予防、検出、プロアクティブの三種類がある13。予防の統制は Organizations の SCP、RCP、宣言型ポリシーで、検出の統制は AWS Config のルールで、プロアクティブの統制は CloudFormation のフックで実装されている14。一つの統制は OU 全体にかかり、その OU のすべてのアカウントに効く15。ただし管理アカウントでは、ルートユーザーと管理者は、統制が禁じる作業もできる。AWS は、この扱いを意図したものだと書いている15。新しいアカウントは、承認済みの設定のひな形である Account Factory から作る13。

無料プランのアカウントは、Organizations に入ると有料プランになる

2025 年 7 月 15 日以降に作るアカウントでは、作るときに無料プランか有料プランを選ぶ16。初めて AWS を使う人は、作ると 100 ドル分のクレジットを受け取る17。無料プランは、作ってから 6 か月たつか、クレジットを使い切るか、早いほうで終わる18。終わるとアカウントは自動で閉じ、資源とデータにアクセスできなくなる17。AWS は内容を 90 日保管してから、アカウントとすべての資源を消す。アカウントへのアクセスを保つには、この 90 日のうちに有料プランへ移す17。それより前に作ったアカウントは、以前の無料利用枠のままである16。

AWS の文書によれば、無料プランのアカウントは、AWS Organizations に参加したり、Control Tower のランディングゾーンを作ったりすると、自動で有料プランに切り替わる17。

アカウントをつなぐほど、境界はぼやける

AWS の外の実務者にも、アカウントを境界とみなす人がいる。Ben Kehoe は 2021 年に、アカウントの中では権限の昇格が起こりうると考えておくべきで、昇格に境界を引くなら、アカウントが最良の境界だと書いた。そのうえで、別のアカウントにロールの利用を許すときは、そのアカウントの特定のロールではなく、アカウント全体を信頼するよう勧めた。ただし Kehoe は、この勧めは一般的な指針で、絶対の規則ではないとも断っている19。

一方で、境界は、分けた後のつなぎ方で弱くなる。Scott Piper は 2021 年の文書で、アカウントを分けることは強いセキュリティの境界になるが、アカウントの間に信頼関係を作るにつれて、境界はぼやけ、複雑になると書いた。そのため、新しいアカウントをいつ、どう作り、どうつなぐかの計画を文書にしておくよう勧めている20。

組織全体にかける仕組みにも、別の難しさがある。

AWS のホワイトペーパーが Policy Staging の OU を勧めるのも、影響の広いポリシーの変更を、本番に付ける前に安全に試すためである2。

少数のアカウントにまとめた形は、何年も危険の源になりうる

AWS のアカウントは、権限、費用、サービスの上限、事故の影響を区切る境界である。AWS は、用途と環境ごとにアカウントを分け、Organizations の OU とポリシーで束ね、管理アカウントには業務の資源を置かないよう勧めている。構成は推奨の一部から始め、必要になったときに広げればよい。

ただし、少数のアカウントに多くのワークロードをまとめた形は、何年も残ることがある。Farris によれば、勤め先では 2015 年の終わりに、ネットワークを手で作る手間を避けるため、基盤のチームがアカウントを五つにすると決めた。その五つのアカウントは、五年後も運用とセキュリティの危険の源になっていた。Farris は、チームごとに一つ、できれば二つのアカウントを持たせるよう求めたと書いている24。

分けたアカウントは、互いにつなぐほど境界があいまいになる。アカウントを分けた後も、アカウントの中で誰が何をできるかは、IAM のロールとポリシーで別に決める。

出典24件

  1. AWS「What is an AWS account?」（AWS Account Management リファレンスガイド）2026年10月16日取得. https://docs.aws.amazon.com/accounts/latest/reference/accounts-welcome.html — 資源の入れ物、セキュリティの境界、ARN にアカウント ID が入ること。 ↩ ↩2

  2. AWS「Organizing Your AWS Environment Using Multiple Accounts」AWS Whitepaper、2025年4月30日、2026年10月16日取得. https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html — 分離の境界、八つの利点、推奨の OU、管理アカウントの扱い。日本語版は公開されていない。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14 ↩15

  3. AWS「What is Service Quotas?」（Service Quotas ユーザーガイド）2026年10月16日取得. https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html — アカウント単位の上限とリージョン単位の上限。 ↩

  4. AWS「Terminology and concepts for AWS Organizations」2026年10月16日取得. https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html — 管理アカウントとメンバーアカウント、OU の継承、委任管理者、宣言型ポリシーと管理アカウント。 ↩ ↩2 ↩3 ↩4 ↩5

  5. AWS「AWS Organizations の請求の統合」（AWS Billing ユーザーガイド）2026年10月16日取得. https://docs.aws.amazon.com/ja_jp/awsaccountbilling/latest/aboutv2/consolidated-billing.html ↩

  6. AWS「Introducing resource control policies (RCPs) to centrally restrict access to AWS resources」2024年11月13日、2026年10月16日取得. https://aws.amazon.com/about-aws/whats-new/2024/11/resource-control-policies-restrict-access-aws-resources/ ↩ ↩2 ↩3

  7. AWS「Resource control policies (RCPs)」（AWS Organizations ユーザーガイド）2026年10月16日取得. https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html ↩ ↩2

  8. AWS「Managing organization policies with AWS Organizations」2026年10月16日取得. https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies.html — 認可のポリシーと宣言型ポリシー。 ↩

  9. AWS「Amazon Web Services announces declarative policies」2024年12月1日、2026年10月16日取得. https://aws.amazon.com/about-aws/whats-new/2024/12/aws-declarative-policies/ ↩

  10. Corey Quinn「Reader Mailbag: AWS Accounts」Last Week in AWS、2020年10月14日、2026年10月16日取得. https://www.lastweekinaws.com/blog/reader-mailbag-accounts/ — 「master account」は管理アカウントの以前の名前。 ↩

  11. Rowan Udell「AWS Identity Center Delegation」2025年7月24日、2026年10月16日取得. https://blog.rowanudell.com/aws-identity-center-delegation/ — 筆者は AWS の IAM の本を書き、2022 年から AWS Community Builder で、このブログで相談と講座を売っている. https://blog.rowanudell.com/about/ ↩ ↩2

  12. Sébastien Stormacq「Centrally managing root access for customers using AWS Organizations」AWS News Blog、2024年11月15日、2026年10月16日取得. https://aws.amazon.com/blogs/aws/centrally-managing-root-access-for-customers-using-aws-organizations/ ↩ ↩2 ↩3

  13. AWS「AWS Control Tower とは」2026年10月16日取得. https://docs.aws.amazon.com/ja_jp/controltower/latest/userguide/what-is-control-tower.html — ランディングゾーン、三種類の統制、Account Factory。 ↩ ↩2 ↩3

  14. AWS「Control behavior and guidance」（AWS Control Tower コントロールリファレンス）2026年10月16日取得. https://docs.aws.amazon.com/ja_jp/controltower/latest/controlreference/control-behavior.html — 統制の種類ごとの実装。 ↩

  15. AWS「About controls in AWS Control Tower」2026年10月16日取得. https://docs.aws.amazon.com/ja_jp/controltower/latest/userguide/controls.html ↩ ↩2

  16. Channy Yun「AWS Free Tier update: New customers can get started and explore AWS with up to $200 in credits」AWS News Blog、2025年7月15日、2026年10月16日取得. https://aws.amazon.com/blogs/aws/aws-free-tier-update-new-customers-can-get-started-and-explore-aws-with-up-to-200-in-credits/ ↩ ↩2

  17. AWS「Choosing a plan」（AWS Billing ユーザーガイド）2026年10月16日取得. https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/free-tier-plans.html — 初めての利用者へのクレジット、終了時にアカウントが閉じることと削除までの 90 日の保管、Organizations に参加したときの有料プランへの切り替え。 ↩ ↩2 ↩3 ↩4

  18. AWS「AWS Free Tier now offers $200 in credits and 6-month free plan to explore AWS at no cost」2025年7月16日、2026年10月16日取得. https://aws.amazon.com/about-aws/whats-new/2025/07/aws-free-tier-credits-month-free-plan/ ↩

  19. Ben Kehoe「Cross-account role trust policies should trust AWS accounts, not roles」2021年10月13日、2026年10月16日取得. https://ben11kehoe.medium.com/cross-account-role-trust-policies-should-trust-aws-accounts-not-roles-32737dfeaa03 — 筆者は 2017 年から AWS Hero. https://aws.amazon.com/developer/community/heroes/ben-kehoe/ ↩

  20. Scott Piper「AWS Security Maturity Roadmap」Summit Route、2021年1月、2026年10月16日取得. https://summitroute.com/downloads/aws_security_maturity_roadmap-Summit_Route.pdf — 筆者は NSA などを経て AWS 環境のセキュリティに取り組み、CloudMapper などの道具を作り、会議 fwd:cloudsec の運営者の一人. https://summitroute.com/ ↩

  21. Chris Farris「AWS Organizations - Checklist for 2021」2021年7月31日、2026年10月16日取得. https://www.chrisfarris.com/post/aws-organizations-in-2021/ — 筆者は最初の AWS Security Hero の一人で、fwd:cloudsec の運営者の一人. https://aws.amazon.com/developer/community/heroes/chris-farris/ ↩

  22. Scott Piper「AWS SCP Best Practices」Summit Route、2020年3月25日、2026年10月16日取得. https://summitroute.com/blog/2020/03/25/aws_scp_best_practices/ ↩

  23. Ian McKay「Resource Control Policies: Closing the data perimeter gap」One Cloud Please、2024年11月17日、2026年10月16日取得. https://onecloudplease.com/blog/resource-control-policies-closing-the-data-perimeter-gap — 筆者は 2020 年から AWS Community Hero. https://aws.amazon.com/developer/community/heroes/ian-mckay/ ↩

  24. Chris Farris「Multi-Account, Multi-Payer Strategy for 2020」2020年5月3日、2026年10月16日取得. https://www.chrisfarris.com/post/multi-payer/ ↩

この記事はAIを使用して執筆されました。内容には誤りが含まれる可能性があります。事実や数字の出典は脚注から確かめられます。