AWS 계정을 여러 개 쓸 때 SCP로 막을 수 있는 것과 막을 수 없는 것
서비스가 커지면 AWS 계정 하나로 모든 것을 운영하기 어려워집니다. 개발용과 운영용을 나누고, 팀별로 계정을 따로 두면 비용도 구분하기 쉽고 한쪽 실수가 다른 쪽에 번지지 않습니다. 문제는 계정이 늘어날수록 "어느 계정에서도 이것만은 하면 안 된다"는 규칙을 계정마다 따로 지키게 하기가 어렵다는 점입니다.
AWS Organizations는 여러 계정을 하나의 조직으로 묶어 관리하는 서비스이고, 서비스 제어 정책(SCP)은 그 조직 안의 계정들에 공통 규칙을 거는 기능입니다. 예를 들어 "서울과 버지니아 리전 외에는 리소스를 만들 수 없다", "CloudTrail 기록을 끌 수 없다" 같은 규칙을 조직 단위로 걸 수 있습니다.
다만 SCP는 IAM 정책과 문법이 비슷해서 같은 방식으로 동작한다고 오해하기 쉽습니다. 이 글에서는 SCP가 권한을 계산하는 방식, 붙이는 위치에 따른 상속, SCP가 미치지 않는 영역, 자주 쓰는 예시와 안전하게 적용하는 순서를 정리합니다.
SCP는 권한을 주지 않고 상한선만 정합니다
SCP를 이해하는 핵심은 한 문장입니다. SCP는 어떤 권한도 부여하지 않습니다. 계정 안의 IAM 사용자와 역할이 쓸 수 있는 권한의 최대 범위를 정할 뿐이고, 실제 권한은 여전히 IAM 정책이나 리소스 기반 정책으로 줘야 합니다. 최종 권한은 SCP가 허용하는 범위와 IAM 정책이 허용하는 범위가 겹치는 부분입니다.
| SCP | IAM 정책 | 결과 |
|---|---|---|
| 허용 | 허용 | 가능 |
| 허용 | 허용 없음 | 불가(IAM 권한이 없음) |
| 허용 없음 또는 거부 | 허용(AdministratorAccess 포함) | 불가(SCP가 막음) |
세 번째 줄이 SCP의 쓸모입니다. 멤버 계정의 관리자가 자기 계정에서 AdministratorAccess를 가지고 있어도, SCP가 막은 작업은 할 수 없습니다. 이 제한은 멤버 계정의 루트 사용자에게도 적용됩니다.
어디에 붙이고, 어떻게 내려가나
SCP는 조직의 루트, 조직 단위(OU), 개별 계정에 붙일 수 있습니다. 계정은 자기 위에 있는 모든 단계에서 허용된 권한만 쓸 수 있습니다. 어느 한 단계에서라도 허용 목록에 빠지거나 명시적으로 거부되면, 그 아래 계정에서는 그 작업을 할 수 없습니다.
조직에서 SCP를 켜면 모든 단계에 FullAWSAccess라는 기본 정책이 붙어 있습니다. 모든 작업을 허용하는 정책이라, 이것을 그대로 두고 필요한 거부 규칙만 따로 붙이는 방식이 가장 단순합니다. AWS 문서는 FullAWSAccess를 대체 정책 없이 떼어 내면 멤버 계정의 모든 작업이 실패한다고 경고합니다.
예시로 따라가 보는 SCP 평가
조직 구조가 루트 → 운영 OU → 운영 계정 A로 되어 있다고 해 보겠습니다. 루트에는 기본 FullAWSAccess와 함께 CloudTrail 추적을 끄지 못하게 하는 거부 정책이 붙어 있고, 운영 OU에는 서울 리전(ap-northeast-2) 밖의 작업을 거부하는 정책이 붙어 있습니다. 계정 A의 개발자는 IAM에서 AdministratorAccess를 받았습니다.
| 계정 A에서 시도한 작업 | 루트 단계 | 운영 OU 단계 | 결과 |
|---|---|---|---|
| 서울 리전에 EC2 인스턴스 생성 | 허용 | 허용 | 가능 |
| 오레곤 리전에 EC2 인스턴스 생성 | 허용 | 거부(리전 밖) | 불가 |
| CloudTrail 추적 중지 | 거부 | - | 불가 |
| IAM 사용자 생성 | 허용 | 예외로 허용(전역 서비스) | 가능 |
마지막 줄처럼 리전 제한 정책을 만들 때는 IAM처럼 특정 리전에 묶이지 않는 전역 서비스를 예외로 빼 두어야 합니다. 그렇지 않으면 계정 관리에 필요한 작업까지 함께 막힙니다. 이처럼 SCP는 단계별로 하나라도 막히면 결과가 거부가 되므로, 새 정책을 붙이기 전에 표처럼 대표 작업 몇 가지를 직접 따라가 보면 실수를 줄일 수 있습니다.
거부 목록과 허용 목록, 두 가지 전략
SCP를 쓰는 방식은 크게 두 가지입니다. 거부 목록 방식은 FullAWSAccess를 그대로 두고, 막고 싶은 작업만 Deny로 추가합니다. 허용 목록 방식은 FullAWSAccess를 떼어 내고, 쓸 수 있는 서비스와 작업만 Allow로 나열합니다.
| 구분 | 거부 목록 | 허용 목록 |
|---|---|---|
| 기본 상태 | 모든 작업 허용 | 나열한 작업만 허용 |
| 새 AWS 서비스가 나오면 | 자동으로 쓸 수 있음 | 목록에 추가해야 쓸 수 있음 |
| 관리 부담 | 적음 | 큼 |
| 어울리는 곳 | 대부분의 조직 | 규제가 엄격한 환경 |
처음 SCP를 도입한다면 거부 목록 방식으로 꼭 막아야 할 몇 가지부터 시작하는 것이 현실적입니다. 허용 목록 방식은 강력하지만, 필요한 작업을 빠뜨리면 운영 중인 서비스가 갑자기 멈출 수 있습니다.
SCP가 미치지 않는 곳
SCP를 걸었는데도 막히지 않는 작업이 있어 혼란스러운 경우가 많습니다. 대부분 아래 범위에 해당합니다.
- 관리 계정 — SCP는 멤버 계정에만 적용되고, 조직을 만든 관리 계정의 사용자와 역할에는 영향을 주지 않습니다.
- 서비스 연결 역할 — AWS 서비스가 대신 작업하도록 만든 서비스 연결 역할은 SCP로 제한되지 않습니다.
- 조직 밖의 사용자 — 버킷 정책 같은 리소스 기반 정책으로 다른 계정 사용자에게 준 접근은 SCP가 직접 막지 않습니다.
그래서 관리 계정에서는 실제 워크로드를 돌리지 않고, 조직 관리와 결제 같은 최소한의 일만 하는 것이 권장됩니다. 관리 계정에서 하는 작업은 어떤 SCP로도 막을 수 없기 때문입니다.
자주 쓰는 SCP 예시 세 가지
| 목적 | 막는 작업 | 주의할 점 |
|---|---|---|
| 기록 보호 | cloudtrail:StopLogging, cloudtrail:DeleteTrail | 추적 이름을 바꾸는 운영 작업이 있다면 예외 역할 지정 |
| 리전 제한 | 허용 리전 밖의 작업(aws:RequestedRegion 조건) | IAM처럼 전역으로 동작하는 서비스는 예외로 두어야 함 |
| 루트 사용 제한 | 멤버 계정 루트 사용자의 작업 | 루트가 꼭 필요한 일부 작업은 SCP로도 막히지 않음 |
첫 번째 예시는 정책 문장이 짧아 시작하기 좋습니다. Effect를 Deny로, Action에 cloudtrail:StopLogging과 cloudtrail:DeleteTrail을, Resource를 *로 두면 멤버 계정에서 누구도 추적을 끄거나 지울 수 없습니다. 감사 기록을 지키는 가장 기본적인 안전장치입니다.
안전하게 적용하는 순서
- 조직 루트에 바로 붙이지 않고, 테스트용 OU를 하나 만듭니다.
- IAM의 서비스 마지막 접근 정보나 CloudTrail 기록으로, 대상 계정이 실제로 어떤 서비스를 쓰는지 확인합니다.
- 테스트 OU에 SCP를 붙이고 계정을 한두 개씩 옮겨 영향을 확인합니다.
- 문제가 없으면 운영 OU로 넓히고, 예외가 필요한 역할은 조건으로 따로 허용합니다.
AWS 문서도 충분히 시험하지 않은 SCP를 조직 루트에 붙이지 말고, 계정을 조금씩 옮겨 가며 확인하라고 권합니다. 잘못된 SCP 하나로 모든 계정의 핵심 서비스가 한꺼번에 막힐 수 있기 때문입니다.
SCP를 적용하면서 자주 묻는 것
계정이 하나뿐인데 SCP를 쓸 수 있나요?
SCP는 Organizations 조직의 멤버 계정에 적용되는 기능입니다. 계정 하나만 운영한다면 IAM 정책과 권한 경계로 권한을 관리하고, 계정을 나눌 때 조직과 SCP를 함께 설계하는 것이 자연스럽습니다.
SCP와 권한 경계는 무엇이 다른가요?
둘 다 최대 범위를 정한다는 점은 같지만, 권한 경계는 IAM 사용자나 역할 하나에 붙이고 SCP는 계정이나 OU 전체에 붙입니다. 둘이 함께 있으면 SCP, 권한 경계, 자격 증명 기반 정책 모두가 허용해야 작업이 가능합니다.
SCP를 잘못 걸어서 계정들이 막혔어요.
SCP는 관리 계정에는 적용되지 않으므로, 관리 계정에서 문제의 SCP를 떼어 내거나 수정하면 됩니다. 이런 상황에 대비해서라도 관리 계정의 접근 권한과 MFA는 따로 잘 지켜 두어야 합니다.
통합 결제만 켠 조직에서도 SCP를 쓸 수 있나요?
아닙니다. SCP는 조직의 모든 기능을 켠 경우에만 사용할 수 있습니다. 통합 결제 기능만 켠 조직이라면 모든 기능 사용으로 전환해야 합니다.
OU 세 개로 시작하는 조직 — 어디에 어떤 SCP를 붙이나
SCP는 개념보다 조직 단위(OU) 설계가 먼저입니다. 계정이 서너 개뿐인 조직이 처음 잡는 구조를 표로 정리했습니다. SCP 자체는 무료이고, 조직 단위를 나누는 데도 요금이 들지 않습니다.
| OU | 들어가는 계정 | 붙이는 SCP | 이유 |
| Root (조직 전체) | 모든 계정 | 조직 탈퇴 금지, CloudTrail·Config 끄기 금지 | 어느 계정에서도 감사 기록을 못 지우게 |
| Infrastructure | 로그 수집 계정, 네트워크 계정 | 리전 제한(서울·버지니아만), 루트 사용자 작업 거부 | 공용 자원은 변경 범위를 좁게 |
| Workloads/Prod | 운영 서비스 계정 | 리전 제한, 대형 인스턴스 유형 거부, 퍼블릭 AMI 공유 거부 | 요금 폭탄과 실수 노출 차단 |
| Sandbox | 개발자 실습 계정 | 리전 제한, 허용 서비스 목록(EC2·S3·Lambda 등)만 | 실습 중 비싼 서비스 사용 방지 |
Prod OU에 붙인 SCP는 그 안의 모든 계정에 내려가고, 계정 안의 관리자라도 넘을 수 없습니다. 반대로 Sandbox처럼 허용 목록 방식으로 좁힌 OU는 새 서비스를 쓸 때마다 SCP를 고쳐야 하므로, 처음에는 거부 목록 방식으로 시작해 사고가 날 만한 것만 막는 편이 운영이 쉽습니다.
적용 전에 네 가지만 확인
- 관리 계정(조직을 만든 계정)에는 SCP가 적용되지 않으므로, 그 계정에는 운영 자원을 두지 않습니다.
- SCP는 권한을 주지 않습니다. SCP가 허용해도 IAM 정책이 없으면 여전히 거부입니다.
- 리전 제한 SCP에는 글로벌 서비스(IAM·CloudFront·Route 53·STS)를 예외로 넣어야 콘솔 로그인부터 막히는 사고를 피합니다.
- Sandbox 계정 하나에 먼저 붙여 하루 돌려 본 뒤 OU로 올립니다. 잘못 붙이면 조직 전체가 한 번에 막힙니다.
정리
- SCP는 권한을 주지 않고, 멤버 계정의 IAM 사용자·역할(루트 포함)이 쓸 수 있는 최대 범위만 정합니다.
- 루트·OU·계정 중 어느 단계에서든 막히면 그 아래 계정에서는 그 작업을 할 수 없습니다.
- 관리 계정과 서비스 연결 역할에는 SCP가 적용되지 않으므로, 관리 계정에서는 워크로드를 돌리지 않습니다.
- 새 SCP는 테스트 OU에서 계정을 조금씩 옮기며 확인한 뒤 넓힙니다.
함께 읽으면 좋은 글: 루트 계정 MFA와 IAM 권한 분리 / AWS Budgets 예산 알림 설정
참고 자료: 서비스 제어 정책(SCP), SCP 예시, 관리 계정 모범 사례
※ 본 글은 2026년 10월 기준 AWS Organizations 사용 설명서를 참고해 작성했으며, 기능과 제한 사항은 변경될 수 있으니 최신 내용은 AWS 공식 문서에서 확인해 주세요.