11주차 - AWS Organizations

- AWS 계정 개념
AWS 계정(Account)은 AWS 서비스를 사용할 수 있는 고유한 논리 단위
일반적으로 "계정"이라는 단어를 유저 ID 개념으로 쓰는 경우가 많은데 AWS에서 계정과 유저는 다른 개념
계정은 하나의 독립된 공간이고, 그 안에 IAM 유저들이 존재하는 구조

계정 ID는 12자리 숫자로 구성됨 (예: 467382719145)
계정을 생성하면 IAM 루트 유저가 자동으로 만들어지며, 루트 유저는 계정 내 모든 권한을 가짐
루트 유저는 일상 업무에 사용하지 않는 것이 권장되며, 계정 내에 IAM 유저를 별도로 만들어 관리하는 것이 보안상 안전함
계정 단위로 결제·보안·리소스 격리가 독립적으로 관리됨

- 다계정 아키텍처 운영 장점
팀별·프로젝트별로 AWS 계정을 따로 만들어서 분리 운영하는 전략

· 비즈니스 목적이나 소유권 기준으로 리소스를 깔끔하게 나눌 수 있음
· 환경별로 다른 보안 제어를 적용할 수 있음
· 민감한 데이터에 대한 접근을 엄격하게 통제할 수 있음
· 문제가 생겨도 해당 계정에만 국한되어 다른 계정으로 전파되지 않음
· 계정 단위로 청구서가 나와서 팀별·환경별 비용 분석이 쉬움
· 계정별 AWS 서비스 할당량이 적용되어 개발 계정이 한도를 다 써도 운영 계정에 영향이 없음

- AWS Organizations
수십~수백 개의 계정을 편리하게 중앙 관리하기 위한 서비스
계정을 계층 구조로 묶어서 정책·결제·보안을 한 곳에서 관리할 수 있게 해 준다

- 주요 기능
① 통합 결제 — 여러 계정의 요금을 관리 계정 하나에서 통합 결제
② 조직 계층 구조 — Root → OU → Account 트리 구조로 계정을 논리적으로 분류
③ 정책 일괄 적용 — OU에 정책을 한 번 적용하면 하위 모든 계정에 자동 적용
④ 하위 OU 지원 — OU 안에 또 다른 OU를 두어 더 세분화된 구조로 관리 가능


- 통합 결제
여러 계정의 비용을 관리 계정 하나에서 모아서 결제하는 기능

볼륨 할인 적용이 가장 큰 장점임
예를 들어 계정 A에서 S3를 20TB, 계정 B에서 10TB 쓰고 있다면 개별 결제 시에는 각각의 사용량으로 계산되지만 통합 결제를 쓰면 30TB 기준으로 더 낮은 단가가 적용

청구서가 하나로 나와 결제 관리가 단순해지고 Cost Explorer나 AWS Budgets로 계정별 사용량을 한눈에 파악할 수 있음
리소스에 태깅을 해두면 팀별·프로젝트별 비용도 세밀하게 분류할 수 있음

- Organizations 계층 구조

Root
Organizations의 최상위 노드로, 모든 OU와 계정을 포함하는 컨테이너임
루트에 SCP를 적용하면 하위의 모든 OU와 멤버 계정에 자동으로 적용됨
단, 관리 계정에는 SCP가 적용되지 않음

OU (Organizational Unit)
계정을 그룹화하는 단위
OU 안에는 계정 또는 하위 OU가 들어갈 수 있음
OU별로 SCP를 별도로 적용할 수 있어 팀·환경 단위로 정책을 세분화할 수 있음
예) 개발 OU에는 저사양 인스턴스만 허용하는 정책을 걸고, 운영 OU에는 고성능 리소스를 허용하되 보안 정책을 강화하는 식으로 구성 가능

Account (계정)
실제 AWS 리소스를 사용하는 실행 단위
OU에 소속될 수도 있고, 루트에 직접 속할 수도 있음
관리 계정(Management Account)과 멤버 계정(Member Account)으로 구분

구분	관리 계정 (Management Account)	멤버 계정 (Member Account)
역할	Organizations을 생성하는 계정 (마스터)	관리 계정이 초대하거나 생성한 계정
권한	보안·인프라·재무 정책 최종 제어권	OU 정책(SCP)의 영향을 받음
결제	조직 전체 요금 지불 책임	개별 리소스 사용, 비용은 관리 계정으로 통합
SCP 적용	적용되지 않음	적용됨

- 조직 정책 종류

정책 유형	역할	활용 예시
SCP (Service Control Policies)	계정·OU가 사용할 수 있는 서비스와 액션의 상한선 정의	특정 계정에서 EC2 생성 차단
RCP (Resource Control Policies)	리소스 접근을 중앙에서 제한	조직 외부에서 S3 버킷 접근 차단
백업 정책 (Backup Policies)	AWS Backup을 통한 계정별 백업 계획 중앙 관리	전 계정 매일 새벽 3시 백업, 30일 보관 정책 일괄 적용
태그 정책 (Tag Policies)	리소스 태그 일관성 보장	모든 리소스에 CostCenter 태그 강제 부착
관리 정책 (Management Policies)	특정 기능이나 보안 구성을 중앙에서 강제	S3 퍼블릭 접근 차단 강제

- SCP (Service Control Policy)  vss IAM
OU 또는 계정에 대해 허용할 수 있는 AWS 서비스 작업의 상한선을 정의하는 정책임
IAM 정책처럼 권한을 부여하는 것이 아니라, 권한의 가드레일(경계선)을 치는 역할을 함

구분	SCP	IAM 정책
적용 범위	OU, 계정 전체	특정 사용자, 그룹, 역할
역할	허용 가능한 권한의 상한선 정의	세부 작업 권한 부여
기본값	FullAWSAccess (모든 서비스 허용)	없음 (명시적으로 부여해야 함)
평가 시점	API 요청이 AWS 서비스로 전달되기 전	API 요청이 서비스에 도달했을 때
평가 방식	Deny 우선, 허용 권한 범위를 제한	Allow/Deny로 구체적 액세스 제어

중요 포인트: SCP가 차단한 권한은 IAM 정책으로도 복구 불가능함
정책 적용 순서는 ① SCP 허용 여부 확인 → ② IAM 정책 허용 여부 확인 → 두 조건 모두 허용일 때만 실행 가능


- SCP 평가 방식
SCP는 기본 거부(Default Deny) 모델을 따름
명시적으로 허용하지 않은 권한은 거부됨
단, 기본적으로 모든 계정에 FullAWSAccess라는 SCP가 디폴트로 적용되어 있어 처음에는 전부 허용 상태임

계층 구조에서는 상위 SCP에서 허용한 것만 하위에서도 허용됨

- SCP 코드 예시
프랑크푸르트(eu-central-1) 리전만 허용하는 SCP:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Deny",
    "Action": "*",
    "Resource": "*",
    "Condition": {
      "StringNotLike": {
        "aws:RequestedRegion": "eu-central-1"
      }
    }
  }]
}

- SCP 설계 시 유의할 점
· 반드시 테스트 환경에서 먼저 실험한 후 적용할 것 — 잘못 걸면 계정 전체 작업이 중단될 수 있음
· OU 이름·계정 이름·정책 이름의 명명 규칙을 일관되게 관리해야 나중에 헷갈리지 않음

학교 계정을 사용하고 있어 (=이미 조직 구성원으로 들어가 있어) 실습은 따로 진행할 수 없었다...