TestForge Blog
← 전체 포스트
#cloud #aws #landing-zone #security #network

AWS 멀티 계정 랜딩존 설계 가이드 - Organizations, IAM Identity Center, 네트워크 분리까지

AWS를 한 계정으로만 운영하다 보면 권한, 비용, 네트워크, 감사 대응이 빠르게 복잡해집니다. 이 글에서는 Organizations, OU 구조, IAM Identity Center, 계정 분리 원칙, 공유 네트워크, 보안 감사 체계를 포함한 실무형 멀티 계정 랜딩존 설계를 정리합니다.

TestForge Team ·

왜 멀티 계정이 필요한가

초기에는 AWS 계정 하나로도 충분해 보입니다. 하지만 서비스가 늘어나면 아래 문제가 빠르게 드러납니다.

  • 운영/개발 리소스가 한 계정에 섞임
  • IAM 권한 경계가 불분명해짐
  • 비용 배분이 어려워짐
  • 보안 사고 시 영향 범위가 너무 커짐
  • 감사 로그와 보안 설정 기준을 통일하기 어려움

그래서 실무에서는 멀티 계정 구조를 일찍 잡는 편이 훨씬 유리합니다.

랜딩존에서 먼저 정해야 할 원칙

  • 환경 기준 분리: prod, staging, dev
  • 기능 기준 분리: shared, security, logging, network
  • 권한 기준 분리: 관리자와 개발자 역할 분리
  • 비용 기준 분리: 팀 또는 서비스별 계정 할당
  • 감사 기준 분리: 로그 계정과 보안 계정은 별도 운영

핵심은 “AWS 계정을 하나의 강한 보안 경계”로 본다는 점입니다.

추천 OU 구조

보통 아래와 같은 구조가 많이 쓰입니다.

Root
 ├─ Security
 │   ├─ audit
 │   └─ log-archive
 ├─ Infrastructure
 │   ├─ network
 │   └─ shared-services
 ├─ Workloads
 │   ├─ prod
 │   ├─ staging
 │   └─ dev
 └─ Sandbox
     └─ experiments

이 구조의 장점은 정책을 OU 단위로 통제하기 쉽다는 점입니다.

계정별 역할 분리 예시

1. log-archive

  • CloudTrail 중앙 수집
  • Config 스냅샷 백업
  • 장기 보관 로그 저장

2. audit

  • Security Hub
  • GuardDuty 집계
  • IAM Access Analyzer
  • 감사 인력용 읽기 전용 접근

3. network

  • Transit Gateway
  • 중앙 egress VPC
  • 공유 DNS
  • VPC IP 대역 관리

4. shared-services

  • 공통 CI/CD
  • Bastion 또는 SSM 기반 운영 접근
  • 공통 이미지 저장소
  • 내부 공통 API 또는 인증 시스템

5. prod, staging, dev

  • 실제 애플리케이션 워크로드 배치
  • 팀별 또는 서비스별로 추가 세분화 가능

IAM Identity Center를 중심으로 권한 설계하기

이제는 개별 IAM User를 직접 만드는 방식보다 IAM Identity Center 기반 접근이 더 낫습니다.

추천 방식:

  • 사내 IdP 연동
  • 그룹 기반 접근 제어
  • 계정별 Permission Set 정의
  • 운영 계정은 승인된 관리자만 접근

예를 들면:

  • Platform-Admin: 모든 인프라 계정 관리자
  • Security-Audit: audit/log 계정 읽기 전용
  • Developer-ReadOnly-Prod: 운영계정 조회 전용
  • Developer-PowerUser-Dev: 개발계정 개발 권한

이렇게 해야 인력 이동과 권한 회수가 쉬워집니다.

SCP는 최소한의 강한 가드레일로 써야 한다

SCP는 IAM 정책보다 상위에서 동작하므로 아주 신중하게 써야 합니다.

보통 아래와 같은 제한이 유효합니다.

  • 특정 리전 외 사용 금지
  • CloudTrail 중지 금지
  • GuardDuty/Config 비활성화 금지
  • 루트 계정 사용 최소화
  • 승인되지 않은 서비스 사용 제한

SCP를 너무 촘촘하게 걸면 운영이 마비될 수 있으므로, “절대 금지해야 하는 것”만 막는 편이 좋습니다.

네트워크는 중앙집중형과 완전분리형 사이에서 선택한다

멀티 계정 설계에서 가장 자주 부딪히는 문제가 네트워크입니다.

중앙집중형

  • Transit Gateway 중심 연결
  • 중앙 egress 관리
  • 방화벽과 DNS를 공통 운영

장점:

  • 일관된 보안 정책
  • 관찰성과 통제가 쉬움

단점:

  • 네트워크 계정 의존도가 높음
  • 설계가 복잡해짐

완전분리형

  • 계정별 독립 VPC
  • 필요한 연결만 최소 허용

장점:

  • 장애 격리가 강함
  • 팀 자율성이 높음

단점:

  • 공통 운영이 어렵고 중복 비용이 생김

초기에는 공유 네트워크 계정 + 워크로드 계정 독립 VPC 정도가 실무적으로 균형이 좋습니다.

로그와 보안은 반드시 중앙 수집한다

랜딩존이 제대로 동작하려면 아래는 초기에 반드시 넣는 편이 좋습니다.

  • Organization Trail 기반 CloudTrail
  • AWS Config 집계
  • GuardDuty 조직 단위 활성화
  • Security Hub 집계
  • S3 로그 버킷 중앙화

이 구조가 있어야 사고가 났을 때 계정별로 흩어진 로그를 찾지 않아도 됩니다.

비용 구조도 랜딩존 단계에서 정리해야 한다

멀티 계정을 쓰는 이유 중 하나가 비용 추적입니다.

실무 팁:

  • 계정 이름에 팀/환경 목적을 명확히 반영
  • 태그 정책 강제
  • 계정 단위 예산 설정
  • 공유 계정 비용은 별도 기준으로 배분

계정 분리는 보안만이 아니라 비용 책임 분리에도 매우 효과적입니다.

시작할 때 흔한 실수

  • prod와 dev를 같은 계정에서 계속 운영
  • IAM User를 사람별로 계속 발급
  • 로그 계정 없이 각 계정에 로그를 흩어 놓음
  • 네트워크 IP 계획 없이 VPC를 먼저 계속 생성
  • SCP를 과도하게 걸어 운영 장애를 만듦

추천하는 초기 구축 순서

  1. Organizations 생성
  2. OU 구조 설계
  3. audit, log-archive, network, shared-services 계정 생성
  4. IAM Identity Center와 IdP 연동
  5. SCP 최소 가드레일 적용
  6. 중앙 로그/보안 수집 구성
  7. 워크로드 계정 생성 후 환경 이관

마무리

AWS 멀티 계정 랜딩존은 단순한 계정 분할이 아닙니다.
권한, 보안, 네트워크, 비용, 감사 체계를 장기적으로 감당 가능한 구조로 만드는 작업입니다.

초기에는 다소 번거로워 보이지만, 서비스가 커질수록 랜딩존이 없는 비용이 훨씬 커집니다.
특히 운영 계정 보호, 감사 대응, 비용 책임 분리를 생각한다면 멀티 계정 구조는 선택이 아니라 기반 설계에 가깝습니다.