처음 AWS를 쓰는 회사가 거의 모두 거치는 길이 있다. 시작할 때는 계정 하나다. 개발자 몇 명이 같은 root 계정으로 콘솔에 들어가서 EC2를 만들고 RDS를 띄운다. 점점 사람이 늘면 IAM User를 만들고, IAM Group을 만든다. 그러다 보안팀이 "운영 환경과 개발 환경을 같은 계정에 두면 안 됩니다"라고 말한다. 그래서 개발용 계정과 운영용 계정을 따로 만든다. 시간이 흐르면 그 둘이 다섯이 되고, 마흔이 되고, 백이 된다. 그리고 어느 순간 IAM 정책 충돌, 부서별 비용 분리 불가, 보안 사고가 한 계정에서 다른 계정으로 번지는 문제가 동시에 터진다.
이 모든 일은 2017년 AWS Organizations가 GA되기 전까지는 고객이 직접 풀어야 하는 운영 문제였다. Netflix는 자체 도구 Cloudaco로 100개 이상의 계정을 관리했고, Capital One은 Cloud Custodian을 만들었다. 그러던 2017년, AWS는 "여러 계정을 한 단위로 묶어서 관리하는 API"를 표준으로 제공하기 시작한다. 이게 Organizations다. 그리고 이게 SAP-C02 도메인 1(26%)의 출발점이다.
오늘은 "왜 멀티 계정인가"라는 근본 질문부터 시작해, Organizations의 구조, OU 설계 표준, Management 계정의 위험, 신규 계정 자동화까지 차례로 본다