🐈
AWS学びなおし(+TF)_organizations

2025/03/09に公開
AWS Organizationsは、複数のAWSアカウントを一元的に管理するためのアカウント管理サービスです。企業や組織がAWSを利用する規模が大きくなるにつれて、アカウントの数が増加し、管理が煩雑になるという課題が生じます。Organizationsは、このような課題を解決し、AWS環境全体のガバナンス、セキュリティ、コンプライアンス、コスト管理を効率化するために非常に重要な役割を果たします。
Organizationsの主な機能とメリット:

アカウントの一元管理: 複数のAWSアカウントを階層構造 (Organizations units: OU) で整理し、一元的に管理できます。これにより、アカウントの可視性が向上し、管理作業が効率化されます。

組織構造の反映: 企業や組織の部門、チーム、プロジェクトなどの組織構造をOUとしてOrganizationsに反映できます。これにより、組織構造に合わせた柔軟なアカウント管理が可能になります。

ポリシーによるガバナンス: Service Control Policies (SCP) をOUやアカウントに適用することで、AWS環境全体のガバナンスを強化できます。SCPは、アカウント内で実行できるAWSサービスやアクションを制限するポリシーであり、セキュリティとコンプライアンスを維持するために不可欠です。

統合請求: Organizationsに参加しているすべてのアカウントの請求をルートアカウントに集約できます。これにより、請求処理が簡素化され、ボリュームディスカウントなどのメリットを最大限に活用できます。

AWSサービスとの連携: Organizationsは、AWS Control Tower、AWS IAM Identity Center (旧 AWS Single Sign-On)、AWS Configなど、他のAWSサービスと深く連携し、より高度なガバナンスと管理機能を提供します。

アカウント作成の自動化: AWS Control Tower Account FactoryやAWS Organizations APIなどを利用することで、新しいAWSアカウントの作成プロセスを自動化できます。

委任管理者: Organizationsの管理権限を委任管理者アカウントに委譲できます。これにより、ルートアカウントの権限を最小限に抑え、セキュリティリスクを低減できます。
Organizationsの主要な構成要素:

ルートアカウント (Management account): Organizationsの最上位に位置するアカウントで、Organizations全体の管理を行います。請求の集約、OUの作成、SCPの適用など、Organizationsの主要な機能はルートアカウントから実行されます。ルートアカウントはOrganizations作成時に自動的に作成され、非常に重要なアカウントとなるため、厳重な管理が必要です。

メンバーアカウント (Member accounts): Organizationsに参加している個々のアカウントです。実際にワークロードが実行されるアカウントであり、OUに所属し、SCPの適用を受けます。

組織単位 (Organizational units: OU): メンバーアカウントを階層的にグループ化するためのコンテナです。OUはネスト構造にすることができ、組織構造や管理要件に合わせて柔軟な階層構造を設計できます。OUにSCPを適用することで、OUに所属するすべてのアカウントにポリシーをまとめて適用できます。

サービスコントロールポリシー (Service Control Policies: SCP): OUまたはアカウントに適用するポリシーで、AWSサービスやアクションの利用を制限します。SCPは、IAMポリシーとは異なり、許可 (Allow) ではなく拒否 (Deny) のポリシーであり、IAMポリシーよりも優先されます。SCPはOrganizationsにおけるガバナンスの要であり、セキュリティとコンプライアンスを維持するために重要な役割を果たします。
Organizationsの開始手順:

ルートアカウントの準備: Organizationsを作成するためのルートアカウントを準備します。既存のアカウントをルートアカウントとして指定することも、新しいアカウントを作成することも可能です。

Organizationsの作成: AWS OrganizationsコンソールまたはAPIからOrganizationsを作成します。Organizations作成時に、ルートアカウントがOrganizationsの管理アカウントとなります。

メンバーアカウントの追加: 既存のAWSアカウントをOrganizationsに招待してメンバーアカウントとして追加するか、Organizations内で新しいAWSアカウントを作成します。

OUの作成とアカウントの配置: 組織構造に合わせてOUを作成し、メンバーアカウントを適切なOUに配置します。

SCPの設計と適用: セキュリティ、コンプライアンス、コスト管理などの要件に基づいてSCPを設計し、OUまたはアカウントに適用します。

統合請求の設定: 統合請求を有効にすることで、メンバーアカウントの請求をルートアカウントに集約します。

委任管理者の設定 (オプション): 必要に応じて、Organizationsの管理権限を委任管理者アカウントに委譲します。

 【実務レベルの内容と重要事項】Organizationsは、大規模なAWS環境を運用する上で不可欠なサービスであり、実務レベルでは以下のような点が重要になります。
マルチアカウント戦略:
Organizationsは、マルチアカウント戦略を実装するための基盤となります。マルチアカウント戦略とは、ワークロードや環境ごとにAWSアカウントを分割し、セキュリティ、分離、権限委譲、コスト管理などを強化する考え方です。Organizationsを利用することで、マルチアカウント環境の管理を効率的に行うことができます。
OU設計のベストプラクティス:
OUの設計は、Organizationsの運用効率とガバナンスに大きく影響します。実務レベルでは、以下の点を考慮してOU設計を行うことが推奨されます。

組織構造との整合性: 組織の部門、チーム、プロジェクトなどをOUとして反映することで、管理体制を組織構造に合わせることができます。

機能別・環境別の分離: 開発環境、本番環境、部門別などでOUを分離することで、環境ごとのセキュリティポリシーやアクセス制御を適用しやすくなります。

SCPの適用範囲: SCPを適用する単位としてOUを設計することで、ポリシー管理を効率化できます。共通のポリシーを適用するアカウントをOUにまとめることで、ポリシー設定作業を削減できます。

アカウント数の増加への対応: 将来的なアカウント数の増加を考慮し、拡張性のあるOU構造を設計する必要があります。必要に応じてOUをネスト構造にすることで、柔軟な階層構造を実現できます。
SCPの設計と運用:
SCPは、Organizationsにおけるガバナンスの要であり、慎重な設計と運用が求められます。

必要最低限の制限: SCPは強力な制限機能を持つため、過剰な制限は開発や運用の妨げになる可能性があります。必要最低限の制限に留め、柔軟性を確保することが重要です。

影響範囲の事前評価: SCPを適用する前に、影響範囲を十分に評価する必要があります。SCPによって意図しないサービスやアクションが制限される可能性もあるため、テスト環境で十分に検証することが重要です。

段階的な適用: SCPは段階的に適用し、徐々に制限を強化していくことが推奨されます。まず監査目的のSCPから始め、徐々に予防的なSCPを適用していくことで、影響を最小限に抑えながらガバナンスを強化できます。

SCPのバージョン管理: SCPもコードと同様にバージョン管理を行い、変更履歴を追跡できるようにすることが望ましいです。TerraformなどのIaCツールを利用することで、SCPのバージョン管理を容易に行うことができます。

SCPの例外設定: 例外的に特定のIAMロールやユーザーにSCPの制限をバイパスさせる必要がある場合は、aws:PrincipalArn条件キーなどを利用して例外設定を行うことができます。ただし、例外設定はセキュリティリスクを高める可能性があるため、慎重に検討する必要があります。
統合請求の活用とコスト管理:
統合請求は、請求処理の効率化だけでなく、コスト管理の観点からも重要な機能です。

ボリュームディスカウントの最大化: 複数アカウントの利用料金を合算することで、ボリュームディスカウントの恩恵を最大限に受けることができます。

コスト配分タグとの連携: コスト配分タグをOrganizations全体で一貫して適用することで、OU別、アカウント別、プロジェクト別などの詳細なコスト分析が可能になります。

コスト最適化戦略: Organizations全体でRI (Reserved Instances) やSavings Plansを共有することで、コスト最適化を推進できます。
セキュリティ:
Organizations自体のセキュリティも非常に重要です。

ルートアカウントの厳重な保護: ルートアカウントはOrganizations全体の管理権限を持つため、MFA (Multi-Factor Authentication) の有効化、IAMアクセスの最小化、アクセスログの監視など、厳重な保護対策を講じる必要があります。

委任管理者の適切な設定: 委任管理者を設定することで、ルートアカウントの権限を分散し、セキュリティリスクを低減できます。委任管理者の権限範囲は、組織の管理体制に合わせて適切に設定する必要があります。

監査ログの活用: AWS CloudTrailと連携し、Organizations APIの操作ログを記録・監視することで、不正アクセスや設定変更を早期に検知できます。
大規模環境でのOrganizations運用:
大規模なAWS環境では、Organizationsの運用も複雑化します。

アカウントファクトリー: 新しいアカウントの作成プロセスを自動化するアカウントファクトリーを導入することで、アカウント作成作業の効率化と標準化を図ることができます。AWS Control Tower Account FactoryやTerraform Account Factoryなどが利用できます。

委任管理者と権限委譲: Organizationsの管理権限を複数の委任管理者に分散することで、管理負荷を分散し、可用性を高めることができます。

自動化: TerraformなどのIaCツールを活用し、Organizationsの構成管理、SCPの適用、アカウント作成などの作業を自動化することで、運用効率を向上させ、人的ミスを削減できます。
Organizationsの制限事項:
Organizationsには、アカウント数、OU階層数、SCPのサイズなど、いくつかの制限事項があります。大規模なOrganizationsを構築する場合は、これらの制限事項を事前に確認しておく必要があります。
移行計画:
既存のAWS環境をOrganizationsに移行する場合は、慎重な移行計画が必要です。

段階的な移行: 一度にすべてのアカウントを移行するのではなく、段階的に移行を進めることで、影響を最小限に抑えることができます。

移行手順のテスト: 本番環境への移行前に、テスト環境で移行手順を十分に検証することが重要です。

ロールバック計画: 万が一移行に失敗した場合に備えて、ロールバック計画を事前に準備しておく必要があります。

 【実務でどの程度使用されるのか】Organizationsは、実務において非常に高い頻度で使用されるサービスです。特に、中規模以上の企業や組織がAWSを利用する場合、Organizationsはほぼ必須のサービスと言えます。
Organizationsが実務で頻繁に使用される理由:

マルチアカウント管理の必要性: セキュリティ、分離、権限委譲、コスト管理などの観点から、マルチアカウント戦略を採用する企業が増加しており、Organizationsはマルチアカウント環境を効率的に管理するためのデファクトスタンダードとなっています。

ガバナンスとコンプライアンスの強化: SCPによる強力なガバナンス機能は、セキュリティとコンプライアンスを維持するために不可欠であり、多くの企業がOrganizationsを活用してガバナンス体制を強化しています。

コスト管理の効率化: 統合請求による請求処理の効率化、ボリュームディスカウントの最大化、コスト配分タグとの連携など、Organizationsはコスト管理を効率化するための強力なツールとなります。

AWS Control Towerとの連携: AWS Control Towerは、Organizationsを基盤として構築されており、Organizationsと組み合わせることで、より高度なガバナンスとAWS環境のプロビジョニング自動化を実現できます。AWS Control Towerの利用が増加していることも、Organizationsの利用頻度を高める要因となっています。
Organizationsが特に必要となるケース:

複数チーム・部門でAWSを利用する場合: チームや部門ごとにアカウントを分割し、Organizationsで一元管理することで、責任分界点を明確にし、セキュリティと独立性を確保できます。

開発環境、本番環境など複数の環境を運用する場合: 環境ごとにアカウントを分割し、Organizationsで管理することで、環境間の分離を強化し、誤操作やセキュリティインシデントのリスクを低減できます。

セキュリティ要件やコンプライアンス要件が厳しい業界: 金融機関、医療機関、政府機関など、セキュリティやコンプライアンス要件が厳しい業界では、Organizationsのガバナンス機能が不可欠となります。

AWS利用料金の最適化を重視する場合: 統合請求によるボリュームディスカウントの最大化、RI/Savings Plansの共有など、Organizationsはコスト最適化に貢献します。
Organizationsを利用しないケース:

小規模な個人利用や単一プロジェクトでの利用: アカウント数が少なく、管理が容易な場合は、必ずしもOrganizationsが必要となるわけではありません。

AWS Organizationsの機能が不要な場合: 単純な請求集約のみが目的で、OUやSCPなどの高度なガバナンス機能が不要な場合は、Organizationsを利用しないという選択肢もあります。
ただし、将来的なAWS利用規模の拡大やガバナンス強化の必要性を考慮すると、Organizationsを早期に導入しておくことが推奨されます。 Organizationsは、AWS環境の成長に合わせて柔軟に拡張でき、長期的な視点で見ると、導入によるメリットの方が大きいと言えます。

 【terraformのコードで記述する場合の基本的内容と実務レベルの内容】Terraformは、Infrastructure as Code (IaC) を実現するためのツールであり、Organizationsの構成管理を自動化するために非常に有効です。Terraformを利用することで、Organizationsの構成をコードとして記述し、バージョン管理、再利用、自動化を容易に行うことができます。
terraformのコードで記述する場合の基本的内容:
1. Organizations Organizationリソース:
Organizations自体を作成するための基本的なリソースです。
resource "aws_organizations_organization" "org" {
  aws_service_access_principals = [
    "organizations.amazonaws.com",
    "controltower.amazonaws.com", # Control Tower連携する場合
    "account.amazonaws.com",     # Account Factory連携する場合
  ]
  enabled_policy_types = ["SERVICE_CONTROL_POLICY", "TAG_POLICY", "BACKUP_POLICY", "AISERVICES_OPT_OUT_POLICY"] # 有効にするポリシータイプ
  feature_set            = "ALL" # すべての機能セットを有効にする (推奨)
}

aws_service_access_principals: Organizationsと連携するAWSサービスを指定します。Control TowerやAccount Factoryを利用する場合は、それぞれのサービスプリンシパルを追加します。

enabled_policy_types: 有効にするポリシータイプを指定します。SCP (SERVICE_CONTROL_POLICY) は必須であり、その他、Tag Policy、Backup Policy、AIServices Opt-Out Policyなどを必要に応じて有効にします。

feature_set: Organizationsの機能セットを指定します。"ALL" を指定することで、すべての機能セットを有効にできます (推奨)。
2. Organizations Accountリソース:
Organizationsに新しいメンバーアカウントを作成するためのリソースです。
resource "aws_organizations_account" "example" {
  name  = "example-account"
  email = "example-account@example.com" # 実在するメールアドレスである必要はありません
  parent_id = aws_organizations_organizational_unit.example_ou.id # OUを指定する場合
  role_name = "OrganizationAccountAccessRole" # 作成されるIAMロール名 (デフォルト)
  tags = {
    Environment = "Development"
    Project     = "ExampleProject"
  }
}

name: アカウントの名前を指定します。

email: アカウントに関連付けるメールアドレスを指定します。Organizationsの管理用であり、実在するメールアドレスである必要はありません。

parent_id: アカウントを作成するOUのIDを指定します。OUに所属させない場合は省略可能です。

role_name: 作成されるIAMロールの名前を指定します。デフォルトは "OrganizationAccountAccessRole" です。

tags: アカウントに付与するタグを指定します。コスト配分タグなどを設定することで、コスト管理に役立ちます。
3. Organizations Organizational Unitリソース:
OUを作成するためのリソースです。
resource "aws_organizations_organizational_unit" "example_ou" {
  name      = "example-ou"
  parent_id = aws_organizations_organization.org.roots[0].id # ルート直下に作成する場合
  tags = {
    Environment = "Common"
  }
}

name: OUの名前を指定します。

parent_id: OUを作成する親OUのIDを指定します。ルート直下に作成する場合は、aws_organizations_organization.org.roots[0].id を指定します。

tags: OUに付与するタグを指定します。
4. Organizations Policyリソース (SCP):
SCPを作成するためのリソースです。
resource "aws_organizations_policy" "example_scp" {
  content = jsonencode({ # SCPのポリシー内容をJSON形式で記述
    Version = "2012-10-17"
    Statement = [
      {
        Effect   = "Deny"
        Action   = ["ec2:RunInstances"] # EC2インスタンス起動を拒否する例
        Resource = "*"
      },
    ]
  })
  description = "Example SCP to deny EC2 instance launch"
  name        = "example-scp"
  type        = "SERVICE_CONTROL_POLICY" # ポリシータイプは SERVICE_CONTROL_POLICY を指定
}

content: SCPのポリシー内容をJSON形式で記述します。IAMポリシーと同様の構文で記述できますが、Effectは "Deny" のみを使用します。

description: SCPの説明を記述します。

name: SCPの名前を指定します。

type: ポリシータイプを指定します。SCPの場合は "SERVICE_CONTROL_POLICY" を指定します。
5. Organizations Policy Attachmentリソース:
作成したSCPをOUまたはアカウントにアタッチするためのリソースです。
resource "aws_organizations_policy_attachment" "example_scp_attachment_ou" {
  policy_id = aws_organizations_policy.example_scp.id
  target_id = aws_organizations_organizational_unit.example_ou.id # OUにアタッチする場合
}

resource "aws_organizations_policy_attachment" "example_scp_attachment_account" {
  policy_id = aws_organizations_policy.example_scp.id
  target_id = aws_organizations_account.example.id # アカウントにアタッチする場合
}

policy_id: アタッチするSCPのIDを指定します。

target_id: SCPをアタッチするOUまたはアカウントのIDを指定します。
実務レベルのterraformコード:
実務レベルでは、Organizationsの構成はより複雑になり、以下のような点を考慮する必要があります。

モジュール化: Organizationsの構成をモジュール化することで、コードの再利用性、可読性、保守性を向上させます。OU、アカウント、SCPなどをそれぞれモジュールとして定義し、組み合わせてOrganizations全体を構築します。

変数化: 環境ごとに異なる設定値 (アカウント名、メールアドレス、OU名など) を変数として定義することで、コードの柔軟性を高めます。terraform.tfvars ファイルや環境変数などを利用して変数を設定します。

バックエンド設定: TerraformのステートファイルをS3バケットやTerraform Cloudなどのリモートバックエンドに保存することで、チームでの共同作業やステートファイルの安全な管理を実現します。

データソースの活用: 既存のOrganizations構成 (OU構造、アカウント情報など) をデータソースとして取得し、Terraformコードで参照することで、既存環境との整合性を保ちながらOrganizationsの管理を自動化できます。

アカウントファクトリーとの連携: Terraform Account Factoryモジュールなどを利用することで、新しいアカウントの作成プロセスを自動化し、Organizationsへのアカウント登録を効率化できます。

IaCパイプラインの構築: Terraformコードの変更を自動的にデプロイするためのCI/CDパイプラインを構築することで、Organizationsの構成変更を安全かつ迅速に行うことができます。
実務レベルのTerraformコード例 (モジュール化):
# modules/organizational_unit/main.tf
resource "aws_organizations_organizational_unit" "ou" {
  name      = var.name
  parent_id = var.parent_id
  tags      = var.tags
}

# modules/organizational_unit/variables.tf
variable "name" {
  type = string
  description = "Organizational Unit name"
}

variable "parent_id" {
  type = string
  description = "Parent Organizational Unit ID"
}

variable "tags" {
  type = map(string)
  description = "Tags for the Organizational Unit"
  default = {}
}

# main.tf (ルートモジュール)
module "root_ou" {
  source = "./modules/organizational_unit"
  name      = "root-ou"
  parent_id = aws_organizations_organization.org.roots[0].id
  tags = {
    Environment = "Root"
  }
}

module "dev_ou" {
  source = "./modules/organizational_unit"
  name      = "dev-ou"
  parent_id = module.root_ou.organizational_unit.id
  tags = {
    Environment = "Development"
  }
}
上記はOUモジュール化の簡単な例ですが、アカウントモジュール、SCPモジュールなども同様にモジュール化することで、より複雑なOrganizations構成をTerraformで効率的に管理できます。
TerraformにおけるOrganizationsの注意点:

ステート管理: Organizationsの構成は複雑であり、Terraformのステートファイルが非常に重要になります。ステートファイルの破損や競合を防ぐために、リモートバックエンドを利用し、ステートロックを有効にすることが必須です。

依存関係: Organizationsリソース間には依存関係が存在するため、Terraformの実行順序に注意する必要があります。depends_on 属性などを利用して、リソース間の依存関係を明示的に定義することが重要です。

破壊的変更: Organizationsリソースの中には、削除時に破壊的な変更を伴うものがあります (例: Organizations Organizationリソースの削除)。Terraformの destroy コマンドを実行する際は、影響範囲を十分に理解し、慎重に行う必要があります。
Terraformを活用することで、Organizationsの構成管理を効率化し、IaCのメリットをOrganizationsの運用にもたらすことができます。実務においては、モジュール化、変数化、バックエンド設定、データソースの活用、IaCパイプラインの構築などを組み合わせることで、より堅牢で柔軟なOrganizations管理基盤を構築できます。
【実務レベルの内容と重要事項】

【実務でどの程度使用されるのか】

【terraformのコードで記述する場合の基本的内容と実務レベルの内容】

Discussion
