1. 조직을 생성하기 / terraform으로 cross account관리하기

1. AWS Organizations 개요

AWS Organizations는 여러 AWS 계정을 중앙에서 통합 관리할 수 있는 서비스입니다.
조직(Organization) 내에서 여러 계정을 Organizational Unit (OU) 단위로 구분하여 관리할 수 있고,
Service Control Policy (SCP) 등의 정책을 통해 계정 전체에 걸친 보안 및 규정을 적용할 수 있습니다.

조직을 만들기 위해서는 Root 계정(조직을 생성할 계정)이 이미 다른 조직에 속해 있지 않아야 합니다.
(만약 MSP를 사용하여 관리할 수 없는 별도의 prod계정이 존재한다고 하더라도 sso를 통하여 관리할 방법이 존재합니다. 향후 시리즈에 적도록 하겠습니다.)

2. Terraform을 이용한 조직 생성

AWS Organizations를 Terraform으로 관리하기 위해서는, 조직을 만들 Root 계정에 대한 자격 증명(AWS Access Key, Secret Key)이 필요합니다. 하지만 이 처음 자격증명에서만 사용하고 향후 sso가 준비된다면 더이상 access key, secret key를 저장하여 사용하지 않습니다.

2.1 조직 생성

resource "aws_organizations_organization" "example" {
  # Organizations에서 제공하는 모든 기능(고급 기능)을 활성화
  feature_set = "ALL"

  # 특정 AWS 서비스가 조직 내 계정에 자동으로 권한을 추가할 수 있도록 설정
  # (예: servicecatalog.amazonaws.com, config.amazonaws.com 등)
  aws_service_access_principals = [
    "config.amazonaws.com"
  ]

  # 조직 정책(SCP 등)을 사용하는 경우 enabled_policy_types를 설정할 수 있음
  # enabled_policy_types = ["SERVICE_CONTROL_POLICY"]
}

• feature_set
  • CONSOLIDATED_BILLING: 결제 통합 기능만 사용
  • ALL: 결제 통합 + 조직 정책(SCP) + 기타 기능 사용

feature_set 관련 문서

일단 CONSOLIDATED_BILLING에서 ALL로 전환하는것은 되지만
역으로 ALL에서 CONSOLIDATED_BILLING에서 으로 마이그레이션하는것은 안되니 알아두기만 합시다

• aws_service_access_principals(optional)
  조직 내 계정에 대하여 특정 AWS 서비스가 필요한 권한을 자동으로 부여하게끔 설정할 aws_service_access_principals은 AWS Organizations에서 특정 AWS 서비스가 조직 계정 전반에 걸쳐 Trusted Access(신뢰 액세스) 를 가질 수 있도록 설정하는 옵션입니다.
  즉, 여기에 명시된 서비스는 조직 내 여러 계정(OU 및 멤버 계정)을
  자동으로 관리할 수 있는 권한을 얻게 됩니다.

2.2 조직 루트와 OU(Organization Unit) 구조

조직이 생성되면 기본 루트(Root)가 자동으로 생깁니다. 이 루트 아래에 Organizational Unit(OU)를 생성해, 계정들을 논리적으로 분류할 수 있습니다. 예를 들어, Production OU, Development OU와 같이 환경별로 구분하거나 Security OU, Shared Services OU 등으로 구분할 수 있습니다.

# OU 생성 예시
resource "aws_organizations_organizational_unit" "prod_ou" {
  name      = "Prod"
  parent_id = aws_organizations_organization.example.roots[0].id
}

resource "aws_organizations_organizational_unit" "dev_ou" {
  name      = "Dev"
  parent_id = aws_organizations_organization.example.roots[0].id
}

2.3 새로운 계정 생성

resource "aws_organizations_account" "account" {
  name  = "my_new_account"
  email = "john@doe.org"

  # - (선택 사항) true인 경우 삭제 이벤트가 계정을 닫습니다. 그렇지 않으면 조직에서만 제거됩니다.
  # 계정이 닫혀도 90일간은 유지되니 테스트로 생성하고 삭제할때 주의가 필요합니다.
  close_on_deletion = true

  # (선택 사항) 계정의 상위 조직 단위 ID 또는 루트 ID. 기본적으로 조직 기본 루트 ID로 설정됩니다.
  parent_id = aws_organizations_organizational_unit.example.id
}

2.4 Service Control Policy(SCP) 적용

조직의 핵심 기능 중 하나가 SCP입니다.
OU나 계정에 걸쳐서 사용할 수 있는 일종의 상위 제한정책입니다.

# 예) 특정 리전을 제외하고는 사용 금지하는 SCP
resource "aws_organizations_policy" "limit_regions" {
  name        = "LimitRegions"
  description = "Allow only ap-northeast-2 (Seoul) region"
  content     = <<POLICY
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAllExceptSeoul",
      "Effect": "Deny",
      "NotAction": "aws-portal:*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": [
            "ap-northeast-2"
          ]
        }
      }
    }
  ]
}
POLICY
  type = "SERVICE_CONTROL_POLICY"
}

# SCP를 OU 또는 계정에 적용
resource "aws_organizations_policy_attachment" "attach_limit_regions_to_prod_ou" {
  policy_id = aws_organizations_policy.limit_regions.id
  target_id = aws_organizations_organizational_unit.prod_ou.id
}

Organizations의 feature_set이 ALL로 설정되어 있어야 하며,
enabled_policy_types에 SERVICE_CONTROL_POLICY가 활성화되어 있어야 합니다.

3. Best Practices & 추가 고려사항

1. 계정 및 unit 구조 설계

• Production, Staging, Development 등 계정 용도별로 OU 구성
• 보안/감사용 계정(예: Security, Audit) 분리

• 로깅, 공용 리소스 등을 담당하는 Shared Services 계정을 별도로 운영

2. SCP 설계

• 최소 권한(deny all, allow 필요 서비스만) 방식으로 설계
• OU별로 필요한 예외 사항을 정책에 반영

3. Root 계정의 보안

• Root 계정에는 Multi-Factor Authentication(MFA)을 반드시 적용

4. 모니터링 및 감사

• AWS CloudTrail, AWS Config, AWS Security Hub 등을 활용하여 조직 전반의 보안 및 규정 준수 상태를 모니터링
• Terraform State 관리를 위한 버전 관리, 백업/복원 전략 마련

5. 비용 문제

• 자체적으로 조직을 생성하는 것은 비용이 들지 않지만, 계정별로 사용하는 서비스 비용이 청구됨
• 계정 분리 시 인프라 비용이 더 많이 발생할 수 있으므로 적절한 분리 전략이 필요

4. terraform으로 multi account를 위해서 고려해야하는 부분

이제 여러계정을 생성할 수 있게 하였으니 terraform으로 여러계정에 대한 접근을 위해서는 provider설정이 필요합니다.

provider "aws" {
	# aws profile별로 assume role설정해두고 profile지정
	profile = "prod_account"

    # 혹은 직접 assume role을 이용하여 조직계정에 접근
	assume_role {
        role_arn = "arn:aws:iam::${local.aws_account_id}:role/OrganizationAccountAccessRole"
    }
}

terraform만으로도 어느정도 이런 multi account에 대한 처리를 할 수 있긴 하지만
추천하는것은 terragrunt나 cdktf같은 도구를 활용하는것이 좋습니다.

마무리하며

aws organization도 Terraform을 활용하면 이러한 작업을 코드로 관리하고, 재현성 있고 일관성 있게 적용할 수 있어 운영이 한결 수월해집니다.
이후 시리즈에서 다룰 SSO 연동, 외부 조직 계정 연결, 그리고 GitHub Actions를 통한 배포 자동화 등을 통해 여러 계정을 좀더 수월하게 운영할 수 있습니다.

다음 포스팅에서는 SSO 연결을 다루면서 iam user대신 sso를 통하여 조직계정 접근 관리에 대한 내용을 다루겠습니다.