회사가 성장할수록 AWS 계정도 늘어납니다. 개발팀 계정, 운영팀 계정, 보안팀 계정, 데이터 분석 계정... 이 모든 계정을 어떻게 체계적으로 관리하고, 어떻게 안전하게 리소스를 공유할까요? 이 글에서는 멀티 계정 환경의 핵심 개념들을 쉽게 설명합니다.
AWS Organizations — 여러 계정을 하나로 묶기
AWS Organizations는 회사의 조직도와 같습니다. 대기업을 상상해보세요. 본사 아래 마케팅 부서, 엔지니어링 부서, 재무 부서가 있고, 각 부서 아래 여러 팀이 있습니다. AWS Organizations도 같은 구조입니다.
관리 계정(Management Account)은 조직의 본사입니다. 모든 멤버 계정을 생성하고 관리합니다. 결제도 이 계정으로 통합됩니다. 관리 계정은 하나뿐이며, 이 계정에는 SCP가 적용되지 않습니다.
조직 단위(OU, Organizational Unit)는 부서입니다. 개발 OU, 운영 OU, 보안 OU처럼 계정을 논리적으로 묶는 단위입니다. OU 안에 또 다른 OU를 만들 수도 있습니다.
멤버 계정(Member Account)은 각 팀입니다. 실제 AWS 리소스가 생성되는 개별 계정입니다.
통합 결제(Consolidated Billing)는 Organizations의 큰 장점 중 하나입니다. 모든 멤버 계정의 비용이 관리 계정 하나로 청구됩니다. 더 중요한 것은 볼륨 할인입니다. 여러 계정의 사용량이 합산되어 더 높은 할인 구간이 적용됩니다. 예약 인스턴스(Reserved Instances)도 조직 내 다른 계정들과 공유할 수 있어서 비용 절감 효과가 커집니다.
시험 핵심: "여러 계정의 청구서를 하나로 통합하고 볼륨 할인을 받으려면?" 하면 Organizations 통합 결제가 정답입니다.
SCP — 조직 전체에 규칙 강제 적용하기
SCP(Service Control Policy)는 건물의 출입 통제 시스템과 같습니다. "이 층에 있는 모든 사람은 이 구역에 들어갈 수 없다"는 규칙을 설정합니다. AWS 서비스 수준에서 보안 경계를 설정하는 강력한 도구입니다.
SCP의 특성을 정확히 이해하는 것이 중요합니다. SCP는 허용을 추가하지 않습니다. SCP는 IAM 정책이 이미 허용한 권한 중에서 일부를 제한하는 역할만 합니다. 예를 들어 개발팀 계정의 IAM 사용자에게 모든 권한을 부여했더라도, SCP에서 특정 서비스를 차단하면 그 서비스는 사용할 수 없습니다.
관리 계정에는 SCP가 적용되지 않습니다. OU에 SCP를 적용하면 그 OU 안의 모든 멤버 계정과 하위 OU에 자동으로 상속됩니다.
SCP 전략은 두 가지가 있습니다. 허용 목록(Allow list) 전략은 "명시적으로 허용한 서비스만 사용 가능"으로, 엄격한 보안이 필요한 환경에 사용합니다. 거부 목록(Deny list) 전략은 "특정 서비스나 리전만 차단"으로, 유연하게 운영하면서 일부만 제한할 때 사용합니다.
실제 사용 예를 살펴봅시다. 회사 규정상 us-east-1과 us-west-2 리전만 사용해야 한다면, SCP에서 다른 모든 리전을 차단합니다. 모든 계정에서 특정 서비스(예: 비트코인 채굴 서비스)를 차단하고 싶다면, SCP에서 그 서비스의 모든 액션을 거부합니다.
시험 핵심: "조직 전체에서 특정 리전 또는 서비스 사용을 제한하려면?" 하면 SCP가 정답입니다.
AWS RAM — 리소스를 안전하게 공유하기
여러 계정이 같은 네트워크 인프라를 공유해야 하는 상황을 생각해봅시다. 각 계정마다 VPC를 만들면 관리가 복잡해지고 비용도 증가합니다. AWS RAM(Resource Access Manager)은 리소스를 여러 계정과 안전하게 공유하는 서비스입니다.
공용 회의실을 생각해보세요. 회의실 자체는 회사 소유이지만, 여러 팀이 예약해서 사용할 수 있습니다. AWS RAM도 비슷합니다. 리소스 소유 계정이 특정 리소스를 다른 계정들과 공유하면, 공유받은 계정들이 그 리소스를 사용할 수 있습니다.
가장 자주 출제되는 공유 리소스는 VPC 서브넷입니다. 네트워크 계정이 VPC와 서브넷을 소유하고, RAM으로 개발 계정, 운영 계정, 데이터 분석 계정과 공유합니다. 각 계정은 공유받은 서브넷에 자신의 EC2 인스턴스, RDS 데이터베이스 등을 만들 수 있습니다.
중요한 제한사항이 있습니다. 공유받은 계정은 서브넷에 리소스를 배포할 수 있지만, VPC 자체를 수정하거나 서브넷 설정을 변경할 수는 없습니다. 네트워크 관리 권한은 소유 계정에만 있습니다.
RAM으로 공유 가능한 대표적인 리소스들입니다. VPC 서브넷, Transit Gateway, Route 53 Resolver 규칙, Aurora DB 클러스터, AWS License Manager 구성, AWS CodeBuild 프로젝트 등입니다.
시험 핵심: "여러 계정이 같은 서브넷에 리소스를 배포하려면?" 하면 AWS RAM으로 서브넷 공유가 정답입니다.
Cross-Account IAM Role — 다른 계정 리소스에 안전하게 접근하기
개발 계정의 애플리케이션이 운영 계정의 S3 버킷에 있는 파일을 읽어야 한다고 해봅시다. 어떻게 해야 할까요? 운영 계정의 IAM 사용자를 만들어서 자격 증명을 공유하는 것은 매우 위험합니다. Cross-Account IAM Role이 올바른 해결책입니다.
호텔 카드키를 생각해보세요. 다른 층에 있는 손님이 내 방에 잠시 접근해야 할 때, 내 방 카드키를 복사해주는 대신 프런트에서 임시 카드키를 발급합니다. 임시 카드키는 정해진 시간 동안만 유효합니다.
Cross-Account IAM Role은 이와 같습니다. 동작 방식은 세 단계로 이루어집니다. 먼저 운영 계정(B)에서 IAM 역할을 만들고, 신뢰 정책(Trust Policy)에 개발 계정(A)을 지정합니다. 다음으로 개발 계정(A)의 애플리케이션이 AWS STS의 AssumeRole API를 호출하면 임시 자격 증명이 발급됩니다. 마지막으로 그 임시 자격 증명으로 운영 계정(B)의 S3 버킷에 접근합니다. 임시 자격 증명은 보통 1시간에서 12시간 사이에 만료됩니다.
외부 ID(External ID)는 제3자에게 역할을 위임할 때 사용하는 추가 보안 장치입니다. 예를 들어 외부 보안 감사 회사에게 여러분의 계정을 분석할 수 있는 역할을 위임할 때, 그 회사가 다른 고객의 계정에 실수로 접근하는 "대리인 혼동 문제(Confused Deputy Problem)"를 방지합니다. 역할의 신뢰 정책에 External ID 조건을 추가하면, 역할을 맡을 때 반드시 올바른 External ID를 제공해야 합니다.
시험 핵심: "제3자 서비스에 안전하게 역할을 위임하면서 다른 고객의 리소스에 실수로 접근하는 것을 방지하려면?" 하면 External ID가 정답입니다.
AWS Control Tower — 멀티 계정 환경 자동 설정
새로운 회사가 AWS를 처음 도입하면서 멀티 계정 환경을 처음부터 올바르게 구성하고 싶습니다. AWS의 모범 사례를 따르는 계정 구조, 기본 보안 설정, 로깅 설정을 모두 수동으로 하나씩 설정하는 것은 시간이 많이 걸리고 실수하기도 쉽습니다. Control Tower가 이것을 자동화합니다.
Control Tower는 세 가지 핵심 개념으로 이루어집니다.
랜딩 존(Landing Zone)은 AWS 모범 사례를 따르는 멀티 계정 환경을 자동으로 구성합니다. 로그 아카이브 계정, 감사 계정, 샌드박스 계정 등 권장 계정 구조를 자동으로 만들어줍니다.
가드레일(Guardrails)은 조직 전체에 적용되는 자동화된 거버넌스 규칙입니다. 예방적 가드레일은 SCP를 기반으로 아예 특정 행동을 막습니다. 탐지적 가드레일은 AWS Config 규칙을 기반으로 위반 사항을 감지하고 알려줍니다.
Account Factory는 새 계정을 표준화된 설정으로 자동 생성하는 기능입니다. 새 팀이 생기면 Account Factory에서 몇 번의 클릭으로 미리 정해진 설정이 모두 적용된 계정을 만들 수 있습니다.
시험 핵심: "새로운 멀티 계정 환경을 AWS 모범 사례에 따라 빠르게 구성하려면?" 하면 Control Tower가 정답입니다.
멀티 계정 전략
어떤 기준으로 계정을 분리하면 좋을까요?
| 분리 기준 | 목적 | 예시 | |-----------|------|------| | 환경별 | 개발과 운영을 완전히 격리 | dev OU, staging OU, prod OU | | 부서별 | 비용 추적과 권한 분리 | 마케팅 OU, 엔지니어링 OU | | 규제별 | 컴플라이언스 요구사항 충족 | HIPAA 계정, PCI 계정 | | 기능별 | 특수 목적 계정 운영 | 로그 집중 계정, 보안 계정, 네트워크 계정 |
계정 수가 많아질수록 관리가 복잡해지지만, 분리가 잘 되어 있으면 보안 사고가 발생했을 때 피해 범위를 한 계정으로 한정할 수 있습니다.
!계정 간 공유 도구 4가지
Trusted Access — 서비스가 조직 전체에서 동작하게 하기
CloudFormation StackSets, AWS Config, CloudTrail 같은 AWS 서비스를 조직의 모든 계정에서 동작하게 하려면 Trusted Access를 활성화해야 합니다. 이 설정은 해당 서비스가 Organizations API를 사용해서 멤버 계정에 자동으로 접근할 수 있게 합니다.
예를 들어 조직 전체에 CloudTrail을 적용하려면, CloudTrail의 Trusted Access를 활성화하면 관리 계정에서 모든 멤버 계정의 로그를 중앙으로 수집할 수 있습니다.
시험 핵심 정리
"여러 계정 비용을 하나로 통합하고 볼륨 할인 적용" -- Organizations 통합 결제
"특정 리전에서만 서비스 사용 허용 또는 특정 서비스 조직 전체 차단" -- SCP
"여러 계정이 같은 VPC 서브넷을 공유해서 사용" -- AWS RAM 서브넷 공유
"다른 계정 리소스에 자격 증명 공유 없이 안전하게 접근" -- Cross-Account IAM Role (AssumeRole)
"제3자가 내 계정에 역할을 맡을 때 보안 강화" -- External ID
"새 멀티 계정 환경을 모범 사례로 자동 구성" -- Control Tower 랜딩 존
SCP는 관리 계정에 적용되지 않습니다
RAM으로 서브넷을 공유받아도 VPC 자체를 수정할 수 없습니다
예약 인스턴스는 Organizations 내 계정 간 공유가 가능합니다