처음엔 계정 하나로 충분합니다. 그러다 개발과 운영 리소스가 한 계정에 섞이고, 누군가 운영 DB를 실수로 지울 뻔하고, 비용이 어느 팀 것인지 알 수 없게 되면 한계가 옵니다. 해법은 계정을 경계로 쓰는 것 — AWS Organizations로 여러 계정을 묶고 정책으로 통제합니다.
멀티계정을 가르는 기준
계정은 가장 강력한 격리 단위입니다. 권한, 비용, 장애가 계정 경계에서 멈춥니다.
| 분리 축 | 예시 계정 | 이유 |
|---|---|---|
| 환경 | dev / staging / prod | prod 사고가 dev로 안 번짐 |
| 팀·서비스 | team-a / team-b | 비용·권한 책임 분리 |
| 공유 | shared-network, log-archive | 공통 리소스 중앙화 |
| 보안 | security, audit | 감사 로그를 별도 계정에 격리 |
이 계정들을 **OU(조직 단위)**로 묶습니다. 예를 들어 Workloads/Prod, Workloads/Dev, Infrastructure, Security 같은 트리를 만들고, 정책을 OU 단위로 겁니다.
SCP — 가드레일이지 권한이 아니다
가장 흔한 오해는 SCP(Service Control Policy)가 권한을 "부여"한다는 생각입니다. SCP는 상한선만 정하는 가드레일입니다. 실제 허용은 IAM이 하고, SCP는 그 위에서 "여기까진 절대 안 됨"을 막습니다. 둘 다 허용해야 동작합니다.
예를 들어 모든 계정에서 특정 리전 밖 사용을 막는 SCP입니다.
JSON
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"StringNotEquals": { "aws:RequestedRegion": "ap-northeast-2" }
}
}]
}
관리(management) 계정에는 SCP가 적용되지 않으니, 워크로드를 절대 두지 말고 결제와 조직 관리 전용으로만 씁니다.
도입 순서
- management 계정 생성 — 결제·조직 관리 전용. 여기에 리소스를 만들지 않는다.
- OU 트리 설계 — 환경/팀 기준으로
Prod,Dev,Security,Infrastructure. - 로그·보안 계정 분리 — CloudTrail 로그를
log-archive계정에 모아 변조를 막는다. - SCP를 단계적으로 — 먼저 루트에 넓은 Deny(예: 루트 사용자 차단), OU별로 좁혀간다.
- SSO로 접근 통합 — 계정마다 IAM 유저를 만들지 말고 IAM Identity Center로 단일 로그인.
요점 정리
- 계정은 권한·비용·장애를 가르는 가장 강한 경계다.
- SCP는 권한 부여가 아니라 상한선(가드레일) — IAM과 함께 동작한다.
- management 계정엔 워크로드를 두지 않고, 로그는 별도 계정에 격리한다.
OU 설계와 SCP를 직접 걸어보며 거버넌스를 실습하는 과정은 클라우드 트랙에서 회원가입 없이 무료로 할 수 있습니다.