AWS 멀티 계정 중앙관리 #5

AWS Control Tower 실제 구축하기

앞선 글에서는 AWS Organizations, IAM Identity Center, Control Tower, CfCT가 각각 어떤 역할을 하는지 알아봤습니다.

이번 글에서는 개념 설명이 아니라 실제로 AWS Control Tower 기반 Landing Zone을 처음부터 구축하는 과정을 살펴보겠습니다.

이번 구성의 목표는 단순합니다.

Management Account로 사용할 AWS 계정 하나만 준비하고, 이후 과정은 가능한 한 AWS Control Tower에 맡깁니다.

최종적으로 다음과 같은 Multi-Account 환경을 만드는 것이 목표입니다.

AWS Organizations
│
├── Management Account
│
├── Security OU
│   ├── Log Archive Account
│   └── Audit Account
│
├── Infrastructure OU
│
├── Workloads OU
│   ├── Prod
│   └── Dev
│
└── Sandbox OU

그리고 이후에는 Account Factory/AFT와 CfCT를 이용하여

계정 생성
   ↓
OU 배치
   ↓
보안 통제 적용
   ↓
IAM 권한 연결
   ↓
공통 리소스 배포

과정까지 자동화하는 것이 최종 목표입니다.

---

1. Management Account 준비

가장 먼저 AWS Control Tower를 관리할 AWS 계정 하나를 준비합니다.

AWS Account
└── Management Account

이 계정은 앞으로 다음 서비스를 중앙에서 관리하는 역할을 담당합니다.

• AWS Organizations
• AWS Control Tower
• IAM Identity Center
• 조직 전체 Billing
• OU 및 Account 관리
• Control 및 SCP 관리
• Account Factory
• CfCT

Management Account는 일반적인 서비스 운영 계정과 분리하는 것이 좋습니다.

즉,

Management Account
├── EC2 서비스 운영 X
├── RDS 서비스 운영 X
├── Application 운영 X
│
└── AWS 조직 관리 전용

형태로 사용하는 것을 권장합니다.

Management Account는 조직 전체에 강력한 권한을 가지고 있기 때문에 Root User MFA를 활성화하고 일반적인 운영 작업은 IAM Identity Center를 통해 수행하는 구조를 권장합니다.

---

2. Organizations를 먼저 만들 필요가 있을까?

신규 AWS 환경에서 Control Tower 콘솔을 이용해 Landing Zone을 구성한다면 기본 Organizations 구조와 OU, Shared Account 등을 일일이 수동으로 구성할 필요가 없습니다.

우리가 원하는 방향은 다음과 같습니다.

Management Account 준비
        │
        ▼
AWS Control Tower
        │
        ▼
Set up landing zone
        │
        ├── Organizations 기반 구성
        ├── Security OU
        ├── Additional OU
        ├── Log Archive
        ├── Audit
        ├── IAM Identity Center
        └── Control Tower Baseline

즉, 처음부터 Organizations 콘솔에 들어가서 모든 OU와 Account를 직접 만드는 것이 아니라 Control Tower의 Landing Zone 구축 프로세스를 최대한 활용합니다.

참고
AWS Control Tower를 API만 이용해서 구축하는 경우에는 절차가 다릅니다. Organizations, Shared Account 및 필요한 IAM Role을 사전에 준비해야 합니다. 이번 글에서는 가장 일반적이고 자동화 수준이 높은 AWS Console 기반 신규 Landing Zone 구축을 기준으로 설명합니다.

---

3. AWS Control Tower 시작

Management Account로 로그인합니다.

AWS Console에서 다음 메뉴로 이동합니다.

AWS Console
    ↓
Control Tower
    ↓
Set up landing zone

Control Tower Landing Zone은 단순히 Control Tower라는 서비스를 활성화하는 과정이 아닙니다.

AWS Multi-Account 환경에 필요한 기본 구조를 만드는 과정이라고 이해하는 것이 좋습니다.

                Control Tower
                     │
              Landing Zone
                     │
        ┌────────────┼────────────┐
        │            │            │
 Organizations     Logging      Identity
        │            │            │
       OU        CloudTrail     Identity
     Account       Config        Center
        │
     Controls

---

4. Home Region 결정

Landing Zone 구축 과정에서 가장 먼저 중요한 것이 Home Region입니다.

예를 들어 국내 서비스를 중심으로 운영한다면 다음과 같이 구성할 수 있습니다.

Home Region

Asia Pacific (Seoul)
ap-northeast-2

Control Tower의 주요 관리 작업은 이 Home Region을 기준으로 수행됩니다.

따라서 회사에서 주로 사용하는 Region을 기준으로 결정하는 것이 좋습니다.

예제에서는 다음과 같이 설정합니다.

Home Region
└── ap-northeast-2

---

5. OU 구성

Control Tower는 Landing Zone 구축 과정에서 Foundational OU를 구성합니다.

기본 이름은 다음과 같습니다.

Root
│
└── Security OU

Security OU에는 Control Tower에서 사용하는 중앙 보안/로그 관련 Shared Account가 위치합니다.

그리고 Additional OU도 설정할 수 있습니다.

예제에서는 Sandbox OU를 추가합니다.

Root
│
├── Security
│
└── Sandbox

AWS 역시 Security OU 이외에 최소 하나 이상의 Additional OU를 구성하는 것을 권장합니다.

중요한 점은 회사 전체 OU 구조를 이 단계에서 완성할 필요는 없다는 것입니다.

먼저 Landing Zone을 정상적으로 구축한 후,

Infrastructure
Workloads
Prod
Dev

등 실제 회사 구조에 맞는 OU를 추가해도 됩니다.

---

6. Log Archive / Audit Account 설정

다음으로 Control Tower에서 사용할 Shared Account를 설정합니다.

기본적으로 두 개의 계정이 사용됩니다.

Security OU
│
├── Log Archive Account
│
└── Audit Account

각 Account에는 서로 다른 이메일 주소가 필요합니다.

예를 들어 다음과 같이 준비합니다.

Management
aws-management@example.com

Log Archive
aws-log@example.com

Audit
aws-audit@example.com

Log Archive Account

조직에서 발생하는 로그를 중앙 보관하기 위한 계정입니다.

개념적으로 다음과 같은 구조입니다.

Prod ───────┐
Dev ────────┤
Sandbox ────┤
            ▼
       CloudTrail
       AWS Config
            │
            ▼
      Log Archive
            │
            ▼
           S3

서비스 계정과 로그 보관 계정을 분리함으로써 서비스 계정 관리자에 의한 로그 삭제나 변경 위험을 줄일 수 있습니다.

Audit Account

보안 담당자 또는 감사 담당자가 조직의 보안 및 규정 준수 상태를 확인하기 위한 계정입니다.

쉽게 구분하면 다음과 같습니다.

Log Archive
    =
로그를 보관하는 곳

Audit
    =
보안 상태를 확인하는 곳

---

7. Landing Zone 생성

필요한 설정을 완료했다면 마지막으로 설정 내용을 검토합니다.

Management Account

Home Region
└── ap-northeast-2

OU
├── Security
└── Sandbox

Shared Accounts
├── Log Archive
└── Audit

문제가 없다면

Set up landing zone

을 실행합니다.

여기서부터는 AWS Control Tower가 상당 부분을 자동으로 처리합니다.

Landing Zone 구축에는 약 30분 정도가 소요될 수 있습니다.

---

8. Control Tower가 자동으로 하는 일

이 부분이 이번 구축에서 가장 중요합니다.

우리가 직접 Organizations, OU, Shared Account 등의 구성 요소를 하나씩 만드는 것이 아니라 Control Tower가 Landing Zone에 필요한 환경을 구축합니다.

결과적으로 다음과 같은 구조가 만들어집니다.

Management Account
       │
       ▼
AWS Organizations
       │
       ▼
      Root
       │
       ├───────────────┐
       │               │
       ▼               ▼
   Security         Sandbox
      OU               OU
       │
   ┌───┴────┐
   │        │
   ▼        ▼
Log Archive Audit

여기에 Control Tower의 관리 기능이 연결됩니다.

AWS Organizations
       +
Control Tower
       +
IAM Identity Center
       +
CloudTrail
       +
AWS Config
       +
Controls
       =
AWS Landing Zone

즉, Control Tower는 단순한 Organizations 관리 화면이 아니라 AWS Multi-Account 운영에 필요한 여러 서비스를 하나의 Landing Zone으로 구성하는 서비스라고 볼 수 있습니다.

---

9. 구축 결과 확인

Landing Zone 구축이 완료되면 가장 먼저 Organizations를 확인합니다.

AWS Organizations
    ↓
AWS accounts

대략 다음 구조를 확인할 수 있습니다.

Root
│
├── Management Account
│
├── Security
│   ├── Log Archive
│   └── Audit
│
└── Sandbox

여기서 중요한 점이 하나 있습니다.

Management Account는 Security OU 안에 들어가는 것이 아닙니다.

Root
│
├── Management Account
│
└── Security OU
    ├── Log Archive
    └── Audit

형태입니다.

---

10. IAM Identity Center 확인

다음으로 IAM Identity Center를 확인합니다.

AWS Console
    ↓
IAM Identity Center

Control Tower에서는 IAM Identity Center를 이용하여 Multi-Account 접근 권한을 중앙 관리할 수 있습니다.

예를 들어:

CloudAdmin
    │
    ├── Management
    ├── Prod
    ├── Dev
    └── Sandbox

Developer
    │
    ├── Dev
    └── Sandbox

Security
    │
    ├── Audit
    └── Log Archive

형태의 권한 구조를 만들 수 있습니다.

각 AWS Account마다 IAM User를 별도로 생성하는 것보다 훨씬 관리하기 쉬운 구조입니다.

---

11. 실제 회사 OU 구조 만들기

기본 Landing Zone 구축이 끝났다면 이제 실제 회사 환경에 맞게 OU를 확장합니다.

예를 들어 다음과 같이 설계할 수 있습니다.

Root
│
├── Management Account
│
├── Security
│   ├── Log Archive
│   └── Audit
│
├── Infrastructure
│   ├── Network
│   └── Shared Services
│
├── Workloads
│   │
│   ├── Prod
│   │   ├── prod-app
│   │   └── prod-data
│   │
│   └── Dev
│       ├── dev-app
│       └── dev-data
│
└── Sandbox

여기서 OU와 Account의 차이를 이해해야 합니다.

OU
=
Account를 묶는 관리 단위

Account
=
실제 AWS Resource가 존재하는 격리 단위

따라서

Prod OU
   │
   ├── prod-app Account
   ├── prod-data Account
   └── prod-batch Account

같은 구조를 만들 수 있습니다.

가능하면 Control Tower에서 관리하는 OU는 Organizations에서 임의 변경하기보다 Control Tower를 통해 관리하는 것이 좋습니다. Organizations에서 직접 변경하면 Control Tower와 구성 불일치, 즉 Drift가 발생할 수 있기 때문입니다.

---

12. Member Account 생성 - Account Factory

이제 새로운 서비스용 AWS Account가 필요하다고 가정해보겠습니다.

일반적인 방법이라면 Organizations에서 계정을 직접 생성할 수도 있습니다.

하지만 Control Tower 환경에서는 Account Factory를 이용할 수 있습니다.

Control Tower
     │
     ▼
Account Factory
     │
     ▼
Account 생성
     │
     ▼
OU 배치
     │
     ▼
Control Tower Governance

예를 들어

Account Name
prod-app

OU
Workloads / Prod

Email
aws-prod-app@example.com

을 지정하여 신규 Account를 프로비저닝합니다.

결과적으로

Workloads
└── Prod
    └── prod-app

이라는 구조가 만들어집니다.

이 Account는 Control Tower Landing Zone의 Governance 아래에서 관리됩니다.

---

13. Terraform을 사용한다면 AFT

여기서 한 단계 더 자동화할 수 있습니다.

DevOps/Platform Engineering 조직에서 Terraform을 사용한다면 **Account Factory for Terraform(AFT)**을 사용할 수 있습니다.

AFT에서는 Account 생성 요청 자체를 Terraform으로 관리할 수 있습니다.

개념적으로는:

Terraform
    │
    ▼
Git Push
    │
    ▼
AFT Pipeline
    │
    ▼
Account Factory
    │
    ▼
Control Tower
    │
    ▼
AWS Account

형태입니다.

예를 들어 Git Repository에서

account-requests/
├── prod-app
├── prod-data
├── dev-app
└── dev-data

형태로 Account 요구사항을 관리할 수 있습니다.

AFT는 단순히 계정만 생성하는 것이 아니라 Account Tag, Account Metadata, Global Customization, Account별 Customization 등을 함께 자동화할 수 있습니다.

AFT를 사용하려면 기존 Control Tower Landing Zone이 필요하며 Control Tower Management Account와 별도의 AFT Management Account를 사용하는 구조입니다.

---

14. CfCT로 공통 환경 자동 배포

계정을 자동으로 만들었다면 다음 문제가 생깁니다.

새 Account마다 회사에서 요구하는 설정을 반복해야 합니다.

예를 들어:

IAM Role
Security 설정
CloudWatch
Config Rule
VPC
DNS
공통 Tag
S3 설정
보안 솔루션

등입니다.

Account가 2~3개라면 직접 할 수도 있습니다.

하지만 Account가 수십 개가 되면 사람이 반복해서 구성하는 방식은 관리하기 어렵습니다.

이때 **Customizations for AWS Control Tower(CfCT)**를 사용할 수 있습니다.

Account Factory
       │
       ▼
New Account
       │
       ▼
Control Tower
Lifecycle Event
       │
       ▼
      CfCT
       │
       ▼
CloudFormation StackSets
       │
       ├── IAM Role
       ├── Security
       ├── Logging
       ├── Network
       └── Company Standard

CfCT는 CloudFormation Template과 정책을 이용하여 특정 Account 또는 OU에 회사 표준 Resource를 자동 배포할 수 있습니다.

중요한 차이는 다음과 같습니다.

Account Factory / AFT
        =
Account를 만드는 자동화

CfCT
        =
Account / OU에
회사 표준 환경을 배포하는 자동화

따라서 둘은 경쟁 관계가 아니라 서로 다른 역할을 담당합니다.

---

15. 최종 자동화 구조

여기까지 구축했다면 전체 흐름은 다음과 같습니다.

[최초 1회]

Management Account 준비
        │
        ▼
Control Tower
        │
        ▼
Landing Zone
        │
        ├── Organizations
        ├── Security OU
        ├── Shared Accounts
        ├── IAM Identity Center
        ├── Logging
        └── Controls


[이후 운영]

Account 생성 요청
        │
        ▼
Account Factory
또는 AFT
        │
        ▼
AWS Account 생성
        │
        ▼
OU 배치
        │
        ▼
Control Tower Governance
        │
        ▼
CfCT / AFT Customization
        │
        ▼
회사 표준 Resource 배포

결국 우리가 만들고 싶은 환경은 AWS 계정을 사람이 하나씩 만들고 설정하는 환경이 아닙니다.

Account 요청
     ↓
Account 자동 생성
     ↓
OU 자동 배치
     ↓
Control 적용
     ↓
IAM 권한 적용
     ↓
공통 Resource 자동 배포
     ↓
운영 시작

이라는 흐름을 만드는 것이 목표입니다.

---

정리

이번 구축의 핵심은 Management Account만 준비하고 나머지는 가능한 한 Control Tower의 Landing Zone 구축 프로세스를 활용하는 것입니다.

처음부터 Organizations, Security OU, Log Archive, Audit Account 등을 각각 별도의 작업으로 구성하기보다 Control Tower를 중심으로 Landing Zone을 구축하면 AWS가 권장하는 Multi-Account 기본 구조를 훨씬 일관성 있게 만들 수 있습니다.

그리고 Landing Zone 구축이 끝나면 자동화의 범위를 단계적으로 확장할 수 있습니다.

Level 1
Control Tower
→ Landing Zone 자동화

Level 2
Account Factory
→ Account 생성 표준화

Level 3
AFT
→ Account 생성 IaC / GitOps

Level 4
CfCT
→ OU / Account 공통 환경 자동화

결국 Control Tower의 목적은 단순히 AWS Account를 여러 개 만드는 것이 아닙니다.

AWS Organizations를 기반으로 Account, 권한, 보안, 로그, 정책을 중앙에서 통제하면서 새로운 AWS 환경을 반복 가능하고 표준화된 방법으로 확장하는 것이 핵심입니다.