Overview
기업의 규모가 커지고 클라우드 도입이 가속화됨에 따라, 단일 AWS 계정(Single Account)만으로 수많은 워크로드를 관리하는 것은 보안, 비용 분석, 리소스 격리 측면에서 한계가 명확하다. AWS는 이를 해결하기 위해 멀티 계정 전략(Multi-Account Strategy)을 권장하며, 그 중심에는 모든 계정의 기초 공사 역할을 하는 Landing Zone이라는 핵심 개념이 있다.
과거에는 'AWS Landing Zone'이라는 수동 설치형 솔루션을 직접 구축해야 했으나, 현재는 이를 자동화한 매니지드 서비스인 AWS Control Tower가 표준으로 자리 잡았다. 이번 포스팅에서는 두 방식의 차이점부터 실무에서 필수적인 거버넌스 전략, 그리고 실제 Hands-On까지 심도 있게 정리한다.
서비스 비교: Landing Zone vs Control Tower
많은 사용자가 혼동하는 두 개념의 차이점은 다음과 같다. 결론부터 말하자면, 특수한 커스텀 요구사항이 없는 한 Control Tower를 사용하는 것이 권장된다.
| 항목 | AWS Landing Zone (Solution) | AWS Control Tower (Service) |
| 유형 | CloudFormation 기반 커스텀 구축 솔루션 | AWS 관리형 서비스 (Managed Service) |
| 관리 주체 | 사용자 (직접 코드 및 파이프라인 유지보수) | AWS (자동 업데이트 및 중앙 대시보드 제공) |
| 설치 편의성 | 복잡함 (코드 배포 및 초기 설정 수주 소요) | 매우 쉬움 (콘솔에서 몇 번의 클릭으로 활성화) |
| 커스터마이징 | 매우 자유로움 (직접 코드 수정 가능) | 정해진 프레임워크 내에서 가능 (최근 확장성 대폭 개선) |
| 추천 대상 | 고도로 특화된 환경이 필요한 대기업 | 대부분의 기업 (신속한 구축과 안정적 운영 필요 시) |
AWS Control Tower 핵심 기능
Control Tower는 단순히 계정을 생성하는 도구가 아니라, 전사적 보안 기조(Security Posture)를 유지하는 프레임워크다.
1. 거버넌스를 위한 가드레일 (Guardrails)
가드레일은 조직 내 모든 계정이 지켜야 할 "최소한의 보안 규칙"을 정의한다.
- 예방적 가드레일(Preventive): SCP(Service Control Policy)를 사용해 정책 위반 행위 자체를 차단한다. (예: 특정 리전 외 서비스 실행 금지, Root 사용자 사용 제한)
- 탐지적 가드레일(Detective): AWS Config를 사용하여 위반 사항을 실시간 감지하고 알림을 보낸다. (예: S3 버킷의 퍼블릭 액세스 허용 여부 체크)
- 사전 예방적 가드레일(Proactive): CloudFormation Hook을 통해 리소스 생성 전 정책 준수 여부를 검사한다.
2. 계정 팩토리 (Account Factory)
새로운 AWS 계정을 생성할 때 보안 정책(SCP), 네트워크(VPC), 로깅 설정이 완료된 상태로 자동 배포해 주는 템플릿 공정이다. 이를 통해 계정 생성 시마다 반복되는 수동 작업을 제거할 수 있다.
3. 중앙 집중형 대시보드
조직 내 모든 계정의 가드레일 준수 상태를 한눈에 확인할 수 있으며, 보안 정책에서 벗어난(Drift) 계정을 즉시 파악하여 복구할 수 있다.
멀티 계정 아키텍처 구성 예시 (OU 설계)
효율적인 관리를 위해 조직 단위(OU, Organizational Unit)를 논리적으로 격리하는 것이 중요하다.
| 계정/OU 역할 | 상세 설명 |
| Management Account | 조직 전체 결제(Billing) 및 Control Tower 제어권 관리 |
| Security OU | Log Archive(모든 로그 통합 저장) 및 Audit(보안 감사/감지) 계정 포함 |
| Infrastructure OU | 공유 네트워크(Transit Gateway, Shared VPC) 및 공통 인프라 관리 |
| Workload OU | 실제 서비스 환경 (Dev, Staging, Prod)별로 계정을 나누어 관리 |
| Sandbox OU | 개발자들이 자유롭게 테스트하되, 비용/리전 제한이 엄격히 적용된 환경 |
Control Tower 활성화 시 자동 생성 리소스
Control Tower를 활성화하면 내부적으로 많은 리소스가 자동 생성된다. 이를 미리 파악해야 비용 예측과 운영에 도움이 된다.
| 리소스 | 생성 위치 | 설명 |
| AWS Organizations | Management Account | 조직 생성 및 OU 구조 설정 |
| AWS CloudTrail (Organization Trail) | 전체 계정 | 모든 계정의 API 활동을 Log Archive 계정의 S3로 중앙 집중 수집 |
| AWS Config | 전체 계정 × 활성 리전 | 리소스 변경 이력 기록 및 Config Rules(탐지적 가드레일) 배포 |
| AWS IAM Identity Center (구 SSO) | Management Account | 멀티 계정 중앙 로그인 서비스 |
| S3 Buckets (로그 저장용) | Log Archive Account | CloudTrail, Config 로그 저장 버킷 (자동 암호화, 버전 관리 적용) |
| SNS Topics | Audit Account | 가드레일 위반 알림 전달용 |
| Service Control Policies (SCP) | Organizations | 예방적 가드레일에 해당하는 정책들 |
| IAM Roles | 전체 계정 | AWSControlTowerExecution 등 Control Tower 운영용 역할 |
비용 주의: Control Tower 자체는 무료이지만, 자동으로 배포되는 AWS Config Recorder와 CloudTrail은 계정 수 × 활성 리전 수 만큼 비용이 발생한다. 불필요한 리전의 거버닝은 꺼두거나, Region Deny SCP로 사전에 차단하는 것이 좋다.
Hands-On 1: Control Tower 초기 설정
사전 준비
Control Tower를 활성화하기 전에 다음 사항을 준비한다.
- Management Account: Organizations가 설정되지 않은 깨끗한 계정 (또는 기존 Organization)
- 이메일 주소 2개: Log Archive 계정용, Audit 계정용 (기존 AWS 계정에 사용되지 않은 이메일)
- Home Region 결정: 한 번 설정하면 변경할 수 없으므로 신중하게 선택 (한국 기업이라면 ap-northeast-2)
Step 1. Control Tower 활성화
AWS Console → Control Tower → Set up landing zone- Home Region 선택: Asia Pacific (Seoul) - ap-northeast-2
- Region deny setting: Enabled — 선택한 리전 외 서비스 실행 차단
- 추가 리전 선택: 필요에 따라 us-east-1(글로벌 서비스용) 등 추가
Step 2. OU 구성
Control Tower는 기본적으로 두 개의 OU를 생성한다.
- Security OU (필수): Log Archive, Audit 계정이 포함됨
- Sandbox OU (선택): 초기 설정 시 추가 OU 생성 가능
Foundation OU (Security):
├── Log Archive Account (로그 중앙 저장)
└── Audit Account (보안 감사 및 알림)
Additional OU:
└── Sandbox OU (개발/테스트 환경)
Step 3. 공유 계정 설정
| 설정 | 항목값 |
| Log Archive Account Email | log-archive@example.com |
| Audit Account Email | audit@example.com |
| Log Archive Account Name | Log Archive |
| Audit Account Name | Audit |
Step 4. 활성화 실행
Set up landing zone 버튼을 클릭하면 약 30~60분 정도 소요된다. 진행 상태는 Control Tower 대시보드에서 확인할 수 있다.
Landing Zone 설정 진행 순서:
1. AWS Organizations 설정
2. Security OU 생성
3. Log Archive 계정 생성 및 구성
4. Audit 계정 생성 및 구성
5. CloudTrail Organization Trail 활성화
6. Config 규칙 배포
7. IAM Identity Center 설정
8. 기본 가드레일 적용
Step 5. 설정 완료 확인
활성화가 완료되면 Control Tower 대시보드에서 다음 사항을 확인한다.
Control Tower Dashboard:
├── Landing Zone status: Active ✅
├── Organizational Units: 2 (Security, Sandbox)
├── Accounts: 3 (Management, Log Archive, Audit)
├── Enabled guardrails: ~20 (mandatory guardrails)
└── Region deny: Enabled ✅
Hands-On 2: Account Factory로 신규 계정 생성
시나리오
Workload OU를 생성하고, 그 아래에 Dev 환경 계정을 만든다.
Step 1. OU 생성
Control Tower Console → Organization → Create organizational unit- OU Name: Workload
- Parent OU: Root
Step 2. Account Factory에서 계정 생성
Control Tower Console → Account Factory → Create account| 설정 | 항목값 |
| Account email | workload-dev@example.com |
| Display name | Workload-Dev |
| IAM Identity Center user email | admin@example.com |
| Organizational unit | Workload |
Step 3. 네트워크 설정 (선택사항)
Account Factory는 계정 생성 시 VPC를 자동으로 프로비저닝할 수 있다. 불필요하다면 비활성화도 가능하다.
Account Factory Network Configuration:
├── Internet-accessible subnet: Yes
├── Maximum number of private subnets: 2
├── Address range (CIDR): 10.0.0.0/16
├── Region for VPC: ap-northeast-2
└── VPC creation: Enable (또는 Disable)Tip: 실무에서는 Account Factory의 기본 VPC 생성을 비활성화하고, Terraform이나 CloudFormation으로 네트워크를 별도 관리하는 경우가 많다. 네트워크 설계가 복잡한 경우(Transit Gateway, Shared VPC 등) 이 방법이 더 유연하다.
Step 4. 생성 확인
계정 생성은 약 20~30분 소요된다. 완료 후 다음을 확인한다.
# AWS CLI로 조직 계정 목록 확인 (Management Account에서 실행)
aws organizations list-accounts --query 'Accounts[*].[Name,Id,Status]' --output table
# 결과 예시
-----------------------------------------------------
| ListAccounts |
+------------------+--------------+------------------+
| Management | 111111111111 | ACTIVE |
| Log Archive | 222222222222 | ACTIVE |
| Audit | 333333333333 | ACTIVE |
| Workload-Dev | 444444444444 | ACTIVE |
+------------------+--------------+------------------+# OU 구조 확인
aws organizations list-organizational-units-for-parent \
--parent-id r-xxxx \
--query 'OrganizationalUnits[*].[Name,Id]' --output table
Hands-On 3: SCP 가드레일 — Region Deny 실습
서울(ap-northeast-2)과 버지니아(us-east-1, 글로벌 서비스용)를 제외한 모든 리전에서의 서비스 실행을 차단하는 SCP를 적용한다.
Step 1. SCP 정책 JSON 작성
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyAllOutsideAllowedRegions",
"Effect": "Deny",
"NotAction": [
"a4b:*",
"acm:*",
"aws-marketplace-management:*",
"aws-marketplace:*",
"aws-portal:*",
"budgets:*",
"ce:*",
"chime:*",
"cloudfront:*",
"config:*",
"cur:*",
"directconnect:*",
"ec2:DescribeRegions",
"ec2:DescribeTransitGateways",
"ec2:DescribeVpnGateways",
"fms:*",
"globalaccelerator:*",
"health:*",
"iam:*",
"importexport:*",
"kms:*",
"mobileanalytics:*",
"networkmanager:*",
"organizations:*",
"pricing:*",
"route53:*",
"route53domains:*",
"route53-recovery-cluster:*",
"route53-recovery-control-config:*",
"route53-recovery-readiness:*",
"s3:GetBucketLocation",
"s3:ListAllMyBuckets",
"shield:*",
"sts:*",
"support:*",
"trustedadvisor:*",
"waf-regional:*",
"waf:*",
"wafv2:*",
"wellarchitected:*"
],
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:RequestedRegion": [
"ap-northeast-2",
"us-east-1"
]
}
}
}
]
}NotAction 설명: NotAction에 나열된 서비스들은 리전 제한에서 제외된다. IAM, Route53, CloudFront, S3 버킷 목록 조회 등 글로벌 서비스는 특정 리전에 종속되지 않으므로, 차단 대상에서 빼야 정상적으로 동작한다.
Step 2. SCP를 Organizations에 등록
# SCP 생성
aws organizations create-policy \
--name "RegionDeny-AllowSeoulVirginia" \
--description "Deny all regions except ap-northeast-2 and us-east-1" \
--type SERVICE_CONTROL_POLICY \
--content file://region-deny-scp.json
# 결과에서 PolicyId 확인
# 예: p-xxxxxxxxxxxx
Step 3. 대상 OU에 SCP 연결
# Sandbox OU에 SCP 연결
aws organizations attach-policy \
--policy-id p-xxxxxxxxxxxx \
--target-id ou-xxxx-xxxxxxxx # Sandbox OU ID
Step 4. SCP 동작 테스트
Sandbox OU에 속한 계정으로 로그인한 후, 차단된 리전에서 EC2 인스턴스 생성을 시도한다.
# 도쿄 리전(ap-northeast-1)에서 EC2 생성 시도
aws ec2 run-instances \
--region ap-northeast-1 \
--image-id ami-0abcdef1234567890 \
--instance-type t3.micro \
--count 1
# 예상 결과: AccessDenied
# An error occurred (UnauthorizedOperation): You are not authorized to perform this operation.# 서울 리전(ap-northeast-2)에서 EC2 생성 시도 — 정상 동작
aws ec2 run-instances \
--region ap-northeast-2 \
--image-id ami-0abcdef1234567890 \
--instance-type t3.micro \
--count 1
# 예상 결과: 정상 생성 ✅Control Tower 가드레일 vs 직접 SCP: Control Tower에서 Region deny setting을 활성화하면 유사한 SCP가 자동 적용된다. 하지만 직접 SCP를 작성하면 NotAction 목록을 세밀하게 커스터마이징할 수 있다는 장점이 있다. OU별로 다른 리전 정책이 필요한 경우 직접 SCP를 관리하는 것이 더 유연하다.
Hands-On 4: 기존 계정 Enrollment
이미 운영 중인 AWS 계정을 Control Tower로 가져올(Enroll) 때는 기존 리소스와 충돌이 발생할 수 있다.
사전 점검 체크리스트
| 점검 항목 | 잠재적 문제 | 해결 방법 |
| AWS Config Recorder | 기존 Config Recorder가 있으면 Enrollment 실패 | 기존 Config Recorder를 삭제하거나 비활성화 후 진행 |
| AWS Config Delivery Channel | 기존 Delivery Channel과 충돌 가능 | 기존 Delivery Channel 삭제 후 진행 |
| CloudTrail | 기존 Organization Trail이 있으면 중복 로깅 | 기존 Trail 비활성화 또는 Control Tower Trail과 병합 검토 |
| IAM Role 이름 충돌 | AWSControlTowerExecution 역할이 이미 존재 | 기존 역할 삭제 또는 이름 변경 후 진행 |
| VPC 기본 설정 | Account Factory의 VPC 자동 생성이 기존 VPC와 CIDR 충돌 | Account Factory VPC 생성 비활성화 후 Enrollment |
| SCP 영향 범위 | Enrollment 후 OU의 SCP가 즉시 적용되어 기존 워크로드 중단 가능 | 완화된 SCP가 적용된 OU에 먼저 배치 후 단계적 이동 |
Step 1. 기존 Config 리소스 정리
# 기존 계정의 Config Recorder 확인
aws configservice describe-configuration-recorders --region ap-northeast-2
# Config Recorder 삭제 (필요 시)
aws configservice delete-configuration-recorder \
--configuration-recorder-name default --region ap-northeast-2
# Config Delivery Channel 삭제 (필요 시)
aws configservice delete-delivery-channel \
--delivery-channel-name default --region ap-northeast-2
Step 2. 기존 IAM Role 확인
# AWSControlTowerExecution Role 존재 여부 확인
aws iam get-role --role-name AWSControlTowerExecution 2>/dev/null && \
echo "Role exists - delete or rename before enrollment" || \
echo "Role does not exist - safe to proceed"
Step 3. Enrollment 실행
Control Tower Console → Organization → 대상 계정 선택 → Enroll account- 대상 계정을 배치할 OU를 선택한다. 프로덕션 워크로드가 실행 중인 계정이라면, 먼저 완화된 SCP가 적용된 OU에 배치한 후 검증 완료 후 최종 OU로 이동하는 것이 안전하다.
Step 4. Enrollment 후 검증
# 계정이 정상적으로 등록되었는지 확인
aws organizations list-accounts --query 'Accounts[?Name==`Target-Account`]' --output table
# Control Tower 가드레일 준수 상태 확인
# Control Tower Console → Account details → Guardrail compliance단계적 Enrollment 권장: 프로덕션 계정을 바로 Enroll하지 말고, 먼저 비운영 계정으로 테스트한 후 문제가 없으면 단계적으로 확대하는 것이 안전하다.
Landing Zone 비용 구조
Control Tower 자체는 무료이지만, 자동으로 활성화되는 서비스들은 계정 수와 리전 수에 비례하여 비용이 발생한다.
| 서비스 | 과금 기준 | 비용 추정 (10계정 × 2리전 기준) |
| AWS Config Recorder | 기록된 구성 항목(Configuration Item)당 과금 | ~$20~50/월 (계정당 $1~5) |
| AWS Config Rules | 규칙 평가 횟수당 과금 | ~$10~30/월 |
| AWS CloudTrail | Management Event 무료, Data Event는 유료 | ~$0 (Management Event만 사용 시) |
| S3 (로그 저장) | 저장 용량 + 요청 수 | ~$5~20/월 |
| SNS | 알림 발송 수 | ~$0~1/월 |
| 합계 (추정) | ~$35~100/월 |
비용 최적화 포인트
- 불필요한 리전의 Config Recorder 비활성화 (Region Deny SCP 활용)
- CloudTrail Data Event는 필요한 경우에만 활성화
- S3 로그 버킷에 Lifecycle Policy 적용 (예: 90일 후 Glacier 이동, 365일 후 삭제
고도화 전략: 자동화 및 보안 강화 (Advanced)
기본 기능을 넘어 실무에서 활용하는 고도화 기술이다.
AFT (Account Factory for Terraform)
계정 생성 과정을 테라폼(Terraform)과 GitOps 파이프라인으로 관리하여 IaC 기반의 계정 관리를 실현한다.
Git Push → CodePipeline → Account Factory → 신규 계정 생성 + 커스터마이징# AFT 계정 요청 예시 (aft-account-request)
module "workload_staging" {
source = "./modules/aft-account-request"
control_tower_parameters = {
AccountEmail = "workload-staging@example.com"
AccountName = "Workload-Staging"
ManagedOrganizationalUnit = "Workload"
SSOUserEmail = "admin@example.com"
SSOUserFirstName = "Admin"
SSOUserLastName = "User"
}
account_tags = {
Environment = "staging"
Team = "platform"
}
account_customizations_name = "workload-baseline"
}
CfCT (Customizations for Control Tower)
기본 가드레일 외에 기업 특유의 보안 규칙이나 리소스를 여러 계정에 일괄 배포할 때 사용한다.
# manifest.yaml 예시
resources:
- name: baseline-vpc
resource_file: templates/vpc-baseline.yaml
deployment_targets:
organizational_units:
- Workload
regions:
- ap-northeast-2
- name: security-baseline
resource_file: templates/security-baseline.yaml
deployment_targets:
organizational_units:
- Workload
- Sandbox
regions:
- ap-northeast-2
보안 서비스 통합
GuardDuty(위협 탐지), Security Hub(보안 표준 준수) 데이터를 Audit 계정으로 중앙 집중화하여 통합 모니터링 체계를 구축한다.
# GuardDuty 조직 관리자 위임 (Management Account에서 실행)
aws guardduty enable-organization-admin-account \
--admin-account-id 333333333333 # Audit Account ID
# Security Hub 조직 관리자 위임
aws securityhub enable-organization-admin-account \
--admin-account-id 333333333333
실무 운영 팁 및 주의사항 (Best Practices)
1. SCP 적용의 유연성
모든 OU에 동일하게 엄격한 SCP를 적용하면 개발 속도가 저하될 수 있다. Production OU는 엄격하게 관리하되, Sandbox OU는 비교적 완화된 정책을 적용하여 보안과 자율성의 균형을 맞춰야 한다.
| OU | SCP 강도 | 예시 |
| Security OU | 최고 엄격 | 모든 변경 제한, 삭제 방지, 리전 제한 |
| Production OU | 엄격 | 리전 제한, 특정 서비스만 허용, Root 사용 금지 |
| Staging OU | 보통 | 리전 제한, 고비용 인스턴스 타입 제한 |
| Sandbox OU | 완화 | 리전 제한 + 비용 상한만 적용 |
2. 기존 계정 등록(Enrollment) 시 주의사항
이미 운영 중인 계정을 Control Tower로 가져올 때는 기존에 설정된 AWS Config 규칙이나 IAM Role과 충돌이 발생할 수 있다. 따라서 사전 점검 후 단계적으로 Enrollment를 진행해야 한다.
3. 비용 모니터링 및 리전 제한
계정이 늘어남에 따라 발생하는 NAT Gateway, Config Recorder 비용 등에 주의해야 한다. 또한, 사용하지 않는 리전에서의 활동을 막기 위해 'Region Deny' 가드레일을 반드시 설정하는 것이 좋다.
4. Management Account는 워크로드에 사용하지 않기
Management Account에서 직접 워크로드를 실행하면 보안과 비용 분석에 혼선이 생긴다. Management Account는 오직 조직 관리와 결제 목적으로만 사용하고, 모든 워크로드는 별도 계정에서 운영한다.
마무리
AWS Control Tower는 더 이상 선택이 아닌 필수다. 복잡한 보안 설정을 수동으로 하는 시대는 지났다. 처음 클라우드 도입을 설계할 때 Control Tower를 통해 탄탄한 거버넌스 기반을 다져놓는다면, 나중에 규모가 확장되어도 인프라 관리에 투입되는 리소스를 획기적으로 줄일 수 있다.
특히 대규모 조직일수록 Policy as Code(코드로 관리하는 정책) 관점에서 Control Tower를 활용하는 것이 중요하다.
다음 포스팅에서는 AWS IAM Identity Center(구 SSO)를 Control Tower와 연동하여 중앙 집중형 로그인을 구현하는 방법을 상세히 다뤄본다.
Reference
- AWS Control Tower 공식 문서
- AWS 멀티 계정 프레임워크 가이드
- AWS Account Factory for Terraform (AFT) 소개
- AWS SCP Examples
- AWS Control Tower Guardrail Reference
- CfCT (Customizations for AWS Control Tower)
Somaz | DevOps Engineer | Kubernetes & Cloud Infrastructure Specialist
'AWS' 카테고리의 다른 글
| [EKS] Blue-Green 배포 시 발생하는 ALB 503 에러 해결기 (with Argo Rollouts Canary) (0) | 2026.09.15 |
|---|---|
| EKS 컴퓨팅 모드 비교: Fargate, 관리형 노드 그룹, Karpenter, 그리고 Auto Mode (0) | 2026.09.14 |
| SNS + SQS + EventBridge: AWS 이벤트 기반 아키텍처 설계 가이드 (0) | 2026.09.03 |
| S3와 AWS SSM을 이용한 CI → EFS 키리스 파일 배포 (1) | 2026.08.03 |
| EKS + Karpenter 무중단 업그레이드 — 노드 잔존 문제부터 검증까지 (0) | 2026.07.16 |