Organizations와 SCP, 허용하지 않고 한도만 정하는 정책

AWS 계정이 둘 이상으로 늘면 AWS Organizations로 묶어서 관리하게 된다.
Organizations 콘솔에서 서비스 제어 정책(SCP)⁠을 켜고 정책 목록을 열면, FullAWSAccess라는 정책이 이미 붙어 있다.

내용을 열어 보면 IAM 정책과 거의 같은 모양이다.
모든 서비스의 모든 작업을 허용(Allow)⁠한다고 적혀 있다.
그래서 이 정책이 붙은 계정의 사용자는 무엇이든 할 수 있다고 읽기 쉽다.

그런데 이 정책은 누구에게도 권한을 주지 않는다.
이유는 IAM 정책과 Organizations의 구조를 보면 드러난다.

권한은 IAM 정책에서 나온다

IAM은 AWS의 권한 관리 서비스다.
계정 안에서 사람이나 프로그램이 쓰는 신원을 IAM 사용자와 역할이라고 하고, 여기에 붙이는 IAM 정책이 무엇을 할 수 있는지 정한다.
정책은 어떤 작업을 허용하거나 거부할지 적은 문서다.

IAM 정책이 하나도 붙지 않은 사용자는 기본적으로 아무것도 하지 못한다.
여러 정책이 함께 걸려 있으면 AWS는 모두를 평가하고, 어느 한 정책의 명시적인 거부(Deny)⁠가 다른 정책의 허용을 이긴다.

Organizations는 계정을 나무 구조로 묶는다

조직(organization)⁠은 여러 AWS 계정을 맨 위의 루트(root)⁠와 그 아래 조직 단위(OU)⁠로 이뤄진 나무 구조로 묶어 관리하는 단위다.
OU는 계정 여러 개를 묶은 그룹이고, OU 안에 다시 OU를 둘 수도 있다.

개발용 계정들을 한 OU에, 운영용 계정들을 다른 OU에 두는 식이다.
조직을 만든 계정은 관리 계정, 나머지는 구성원 계정이라고 부른다.

SCP는 루트, OU, 개별 계정에 붙일 수 있고, 붙인 자리 아래에 있는 계정들에 영향을 준다.
조직에서 모든 기능(all features)⁠을 켜야 쓸 수 있고, 통합 결제 기능만 켠 조직에서는 쓸 수 없다.

SCP는 상한만 정한다

SCP는 IAM 권한 정책과 거의 같은 문법을 쓰지만 결코 권한을 주지 않는다.
조직 안의 IAM 사용자와 역할이 가질 수 있는 최대 권한을 정하는 접근 통제다.

실제로 할 수 있는 일은 두 정책이 겹치는 부분이다.
구성원 계정의 사용자가 요청한 작업은 사용자의 정책과 SCP 양쪽에서 모두 허용돼야 실행된다.

그래서 실패는 양쪽에서 나온다.
하나는 SCP가 모든 작업을 허용하니 된다고 보고 IAM 정책을 붙이지 않는 경우다.
권한 정책이 없는 사용자는 SCP가 모든 서비스와 작업을 허용해도 아무 접근 권한이 없다.

다른 하나는 반대 방향이다.
SCP가 막은 작업은, 구성원 계정의 관리자가 사용자에게 모든 작업을 허용하는 AdministratorAccess 정책을 붙여도 할 수 없다.
계정을 만들 때 쓴 이메일로 로그인하는 구성원 계정의 루트 사용자도 SCP의 제한을 받는다.

이 SCP는 CloudTrail 기록 중지만 거부하고 나머지 작업은 열어 둔다. 권한 정책과 실행 계정에 따라 결과가 달라진다.

작업	SCP	⁠권한 정책	결과
S3 객체 읽기	허용	없음	불가
EC2 인스턴스 시작	허용	없음	불가
CloudTrail 기록 중지	거부	없음	불가

SCP가 열어 둔 작업도 권한 정책이 허용해야 할 수 있다. 권한 정책이 모두 허용해도 SCP가 거부한 작업은 막히고, 관리 계정에는 SCP가 적용되지 않는다.

SCP 하나와 권한 정책 하나만 두고 단순화한 예시다. 실제 요청은 리소스 기반 정책, 권한 경계, 세션 정책 같은 다른 정책과 함께 평가된다.

SCP를 여러 단계에 붙이면 어떻게 되는가

SCP를 루트와 OU와 계정에 겹겹이 붙이면 허용과 거부가 다르게 움직인다.
어떤 작업이 허용되려면 루트에서 그 계정까지 내려오는 모든 단계에 허용 문장이 있어야 한다.
한 단계라도 허용이 빠지면 그 아래 계정에서는 막힌다.

SCP를 켤 때 루트와 모든 OU, 계정에 FullAWSAccess가 자동으로 붙는 것도 이 때문이다.
모든 단계에 허용이 미리 깔려 있으니, 이 정책만 붙어 있는 동안에는 SCP를 켜도 막히는 작업이 없다.

거부는 한 단계만으로 충분하다.
루트부터 그 계정까지 어느 단계의 SCP든 거부하면 그 작업은 막히고, 아래 단계에서 다시 허용해도 소용없다.

처음 다룰 때 하기 쉬운 실수가 여기서 나온다.
루트에 FullAWSAccess 없이 거부 문장만 담은 SCP를 두면, 모든 구성원 계정이 어떤 서비스도 쓰지 못하게 된다.
허용이 빠진 단계가 생겼기 때문이다.

SCP가 닿지 않는 곳

SCP는 관리 계정의 사용자와 역할에는 아무 영향을 주지 않는다.
그래서 관리 계정에서 SCP를 시험해 보고 막히지 않는다고 결론 내리면 정반대로 이해하게 된다.
시험은 구성원 계정에서 한다.

서비스 연결 역할도 SCP의 제한을 받지 않는다.
AWS 서비스가 사용자 대신 작업하려고 계정 안에 만들어 두는 역할이다.
그래서 SCP가 막는 범위는 조직 전체라기보다 구성원 계정의 사용자와 역할이라고 적는 편이 정확하다.

AWS는 관리 계정을 그 계정에서만 할 수 있는 일에만 쓰고, 서비스 자원은 다른 계정에 두라고 권한다.
SCP가 관리 계정의 사용자와 역할을 제한하지 못한다는 점이 그 이유 가운데 하나다.

설정	실제 의미	확인할 점
SCP가 허용	그 작업의 상한을 열어 둔다	실제 권한은 별도 정책에서 받아야 한다
권한 정책이 허용	해당 정책이 작업을 허용한다	SCP와 다른 거부 조건도 함께 평가된다
관리 계정에서 실행	SCP의 제한 대상이 아니다	적용 범위는 구성원 계정에서 확인한다

실무에서 SCP로 막아 두는 작업

AWS의 SCP 예제는 FullAWSAccess를 그대로 두고, 막을 작업만 거부 문장으로 더하는 거부 목록 방식을 쓴다.
반대로 FullAWSAccess를 쓸 서비스만 허용하는 정책으로 바꾸는 허용 목록 방식도 있는데, 그러면 새로 나온 서비스는 목록에 넣기 전까지 막힌다.

막아 둘 작업으로는 평소 업무에서 쓸 일이 거의 없고, 한번 일어나면 되돌리기 어려운 것들이 잘 맞는다.

AWS는 구성원 계정이 조직을 떠나거나 스스로 계정을 닫는 작업을 루트의 SCP로 거부해 두라고 권한다.
2026년 7월 10일 이후 콘솔에서 만든 조직에는 이 SCP가 루트에 자동으로 붙는다.

감사 기록을 끄는 작업도 후보다.
CloudTrail 글에서 다룬 것처럼 꺼져 있던 동안의 기록은 나중에 만들 수 없다.
위에서 막아 두면 구성원 계정의 관리자도 계정 안에서 풀지 못한다.

새 SCP는 루트에 바로 붙이지 않는다.
AWS의 SCP 문서도 충분히 시험하지 않은 SCP를 루트에 붙이지 말고, OU를 하나 만들어 계정을 한두 개씩 옮겨 가며 영향을 확인하라고 권한다.
루트에서 필요한 작업까지 막으면 그 아래 모든 계정이 한꺼번에 멈춘다.