AWS Organizations
더 많은 작업
- AWS Organizations
- 여러 AWS 계정을 하나의 조직으로 묶어 계정 생성, 정책 기반 통제(SCP 등), 통합 결제를 중앙에서 관리하는 서비스
규모가 있는 회사는 AWS 계정을 하나만 쓰지 않는다. 운영·개발·테스트를 계정으로 나누고, 팀이나 규제 범위(예: 결제 카드 데이터)별로도 나눈다. 계정은 권한, 요금, 장애 영향 범위를 가르는 가장 확실한 경계이기 때문이다. 대신 계정이 수십 개가 되면 보안 기준을 똑같이 지키고 비용을 모아 보는 일이 어려워진다. Organizations는 이 계정들을 트리 구조로 묶고, 상위에서 내린 정책이 아래 계정 전체에 일관되게 적용되게 한다.
| 항목 | 설명 |
|---|---|
| 조직 | 중앙에서 관리하는 AWS 계정의 모음 |
| 관리 계정 | 조직을 만든 계정. 계정 생성·초대, 정책 관리, 모든 멤버 계정의 요금 지불을 맡는다. 관리 계정에는 SCP가 적용되지 않으므로 워크로드를 두지 않는 것이 모범 사례다. |
| 멤버 계정 | 조직에 속한 나머지 계정. 한 번에 한 조직에만 속한다. |
| 루트 | 조직 계층 맨 위의 컨테이너. 여기에 붙인 정책은 모든 OU와 계정에 내려간다. |
| 조직 단위(OU) | 계정을 묶는 폴더. OU 안에 OU를 중첩할 수 있다. |
| 위임된 관리자 | GuardDuty, Security Hub 같은 서비스의 조직 차원 관리를 특정 멤버 계정에 맡기는 기능 |
- 기능 세트
- 모든 기능(권장): 통합 결제에 더해 SCP 등 정책과 AWS 서비스 통합을 모두 쓴다.
- 통합 결제만: 결제만 합치고 정책은 쓰지 못한다. 나중에 모든 기능으로 바꾸려면 멤버 계정들이 변경을 승인해야 한다.
서비스 제어 정책(SCP)은 조직 안의 IAM 사용자와 역할이 쓸 수 있는 최대 권한(가드레일)을 정한다. 가장 많이 헷갈리는 점은 SCP 자체는 아무 권한도 주지 않는다는 것이다. 실제 권한은 여전히 AWS IAM 정책이 줘야 하고, SCP는 그 위에 상한을 씌운다.
- 루트, OU, 계정에 붙일 수 있다. 계정은 위쪽 모든 단계의 SCP가 허용하는 작업만 할 수 있다.
- 멤버 계정의 루트 사용자도 SCP의 제한을 받는다. 계정 관리자가
AdministratorAccess를 붙여도 SCP가 막은 작업은 할 수 없다. - 관리 계정의 사용자·역할과 서비스 연결 역할에는 SCP가 적용되지 않는다.
- SCP는 리소스 기반 정책에 직접 영향을 주지 않으며, 조직 밖 계정의 주체에도 적용되지 않는다.
- 기본으로 모든 작업을 허용하는
FullAWSAccess가 붙어 있고, 그 위에 Deny 문을 더하는 거부 목록 방식을 많이 쓴다.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyOutsideSeoul",
"Effect": "Deny",
"NotAction": ["iam:*", "organizations:*", "sts:*", "support:*"],
"Resource": "*",
"Condition": {
"StringNotEquals": {"aws:RequestedRegion": "ap-northeast-2"}
}
}
]
}
위 SCP는 서울 리전 밖에서 자원을 만들거나 쓰는 요청을 막는다. 글로벌 서비스(IAM, Organizations 등)는 예외로 둬야 계정 관리가 깨지지 않는다.
리소스 제어 정책(RCP)은 SCP와 짝을 이루는 정책으로, 주체가 아니라 리소스 쪽에 상한을 둔다. 지원되는 서비스의 리소스에 대해, 요청자가 조직 안이든 밖이든 RCP를 벗어나는 접근은 거부된다. 예를 들어 "우리 조직의 S3 버킷은 조직 밖 주체가 절대 접근할 수 없게" 같은 데이터 경계를 만들 때 쓴다. RCP도 권한을 주지 않고, 관리 계정의 리소스에는 적용되지 않는다.
백업 정책(조직 전체 백업 계획), 태그 정책(태그 표준화), AI 서비스 옵트아웃 정책, 선언적 정책 등 관리용 정책 유형도 있다.
조직의 모든 멤버 계정 요금은 관리 계정이 한 장의 청구서로 지불한다. 추가 비용은 없다.
- 사용량 합산: 여러 계정의 사용량을 합쳐 S3 등 구간 요금의 볼륨 할인을 더 빨리 받는다.
- 약정 할인 공유: 예약 인스턴스와 절감형 플랜(Savings Plans) 할인을 조직 안 다른 계정의 사용량에도 적용할 수 있다(공유 설정은 끌 수 있다).
- 계정별 비용은 관리 계정에서 따로 볼 수 있다. 자세한 비용 분석은 AWS 비용 관리 도구 참조.
AWS Control Tower는 Organizations, IAM Identity Center, Service Catalog 등을 조합해 모범 사례에 맞는 다중 계정 환경(랜딩 존)을 자동으로 구축하고 관리하는 서비스다. Organizations가 "부품"이라면 Control Tower는 그 부품으로 미리 조립한 표준 환경이다.
| 기능 | 설명 |
|---|---|
| 랜딩 존 | 보안 OU와 공유 계정(기본 이름: 로그 아카이브 계정, 감사 계정)을 포함한 다중 계정 기본 구조 |
| 예방 제어 | 작업이 일어나지 않게 막는다. SCP·RCP로 구현된다. |
| 탐지 제어 | 규정 위반 리소스를 찾아낸다. AWS Config 규칙으로 구현된다. |
| 사전 제어(proactive) | 리소스가 프로비저닝되기 전에 정책 준수를 검사한다. CloudFormation 후크로 구현된다. |
| Account Factory | 미리 승인된 구성으로 새 계정을 표준화해 발급한다. |
| 대시보드 | 계정, 적용 중인 제어, 규정 미준수 리소스를 한눈에 본다. |
제어(가드레일)는 필수, 적극 권장, 선택 세 범주로 제공된다.
AWS Resource Access Manager(AWS RAM)는 한 계정에서 만든 리소스를 다른 계정, 조직 전체, 특정 OU, 일부 리소스는 특정 IAM 역할·사용자와 공유하게 한다. 리소스를 계정마다 중복으로 만들지 않아도 된다.
- 대표 예: VPC 서브넷 공유(네트워크 계정이 VPC를 만들고 다른 계정이 그 서브넷에 EC2를 띄움), AWS Transit Gateway 공유, Route 53 Resolver 규칙, 접두사 목록, License Manager 구성 등.
- 조직 안 공유를 활성화하면 초대 수락 없이 바로 공유되고, 조직 밖 계정과 공유하면 상대가 초대를 수락해야 한다.
- 리소스 기반 정책으로 공유할 수 있는 리소스도 있지만, RAM을 쓰면 계정 ID를 일일이 나열하지 않고 조직·OU 단위로 공유할 수 있다.
- 워크로드는 환경(운영·개발)과 규제 범위별로 계정을 나누고, OU로 묶어 OU 단위로 SCP를 붙인다.
- 로그는 별도 로그 아카이브 계정에 모으고, 보안 도구는 감사(보안) 계정을 위임된 관리자로 지정해 운영한다.
- 관리 계정은 조직 관리와 결제에만 쓴다.
- 사람의 접근은 AWS IAM Identity Center로 중앙화하고, 네트워크는 RAM으로 공유된 VPC나 Transit Gateway로 통합한다.
- "모든 계정에서 특정 서비스·리전 사용을 금지", "누구도(계정 관리자 포함) CloudTrail을 끄지 못하게" → SCP. IAM 정책은 계정 관리자가 바꿀 수 있으므로 답이 아니다.
- SCP는 권한을 주지 않는다. SCP가 허용해도 IAM 정책이 없으면 접근할 수 없다. 관리 계정에는 SCP가 적용되지 않는다.
- 여러 계정의 요금을 합쳐 볼륨 할인과 RI·Savings Plans 공유를 받으려면 통합 결제.
- 다중 계정 환경을 모범 사례대로 빠르게 세우고 가드레일을 자동 적용하려면 Control Tower가 운영 부담이 가장 적다.
- 다른 계정과 서브넷, Transit Gateway 등을 공유하라는 요구는 AWS RAM이다.
- 서비스 제어 정책(SCP) – AWS
- 리소스 제어 정책(RCP) – AWS
- AWS Organizations에 대한 결제 통합 – AWS
- AWS Control Tower란? – AWS
- AWS Resource Access Manager란 무엇인가요? – AWS