[클라우드 활용] 11주차

1. AWS 계정(Account)이란?

AWS 계정은 AWS 리소스를 사용할 수 있는 고유한 논리 단위다.

• 계정 ID는 12자리 숫자로 구성됨 (예: 467382719145)
• 계정 생성 시 IAM 루트 유저가 자동 생성되며, 이 루트 유저 하에 다수의 IAM User를 생성할 수 있음
• 한 계정 안에서 수많은 서비스와 리소스를 생성·운영 가능
• 요금·보안·리소스가 계정 단위로 독립적으로 관리됨 → 계정마다 결제, 보안, 리소스 격리가 분리됨

---

2. 다계정(Multi-Account) 환경이 필요한 이유

단일 계정 구조의 문제점

실제 사례로 이해해보자. Engineering Team과 Product Team이 하나의 계정을 공유하는 상황에서 발생할 수 있는 문제들:

• 프로덕션 배포가 예상보다 오래 걸려 영업 데모에 영향을 준다
• 개발 코드에 대한 부하 테스트 시 프로덕션 VPC까지 느려지고 오류가 발생한다
• 재무 팀이 프로덕션 환경과 개발 환경의 비용을 구분할 수 없다
• 새로 고용된 외부 계약업체가 프로덕션 VPC를 통해 고객 데이터에 접근할 수 있다는 보안 우려가 생긴다

이처럼 단일 계정에서는 보안 격리, 비용 구분, 환경 분리가 근본적으로 어렵다.

다계정 환경의 이점

관점 혜택

보안	계정 단위 격리로 침해 범위 최소화
비용	팀·환경별 비용 분리 및 추적 용이
운영	개발/스테이징/프로덕션 환경 완전 분리
규정 준수	업무별 보안 정책 독립 적용 가능

---

3. AWS Organizations 구조

AWS Organizations는 여러 AWS 계정을 하나의 조직처럼 묶어 중앙에서 통합 관리할 수 있게 해주는 서비스다.

계층 구조

Root (조직 루트)
 └── OU (Organizational Unit, 조직 단위)
      ├── OU: Sandbox
      └── OU: Production
           ├── Account A
           └── Account B

• Root: 조직의 최상위 컨테이너
• OU (Organizational Unit): 계정을 그룹핑하는 논리적 컨테이너. 중첩(nested) 구조 가능
• Member Account: 실제 리소스가 운영되는 개별 계정

Organizations에서 지원하는 정책 유형

정책 유형 설명 활용 예시

SCP (Service Control Policies)	계정/OU가 허용·차단할 수 있는 서비스 및 액션 제어	특정 계정에서 EC2 생성 차단
RCP (Resource Control Policies)	리소스 접근을 중앙에서 제한	조직 외부 접근 차단
백업 정책 (Backup Policies)	AWS Backup을 통한 계정별 백업 계획 중앙 관리	공통 백업 주기 및 보존 정책 적용
태그 정책 (Tag Policies)	리소스 태그 일관성 보장	리소스에 CostCenter 태그 강제
관리 정책 (Management Policies)	특정 기능·보안 구성 중앙 통제	S3 퍼블릭 접근 제한 강제

---

4. SCP(Service Control Policy) 심화

SCP란?

SCP는 OU 또는 개별 계정에 대해 **허용할 수 있는 AWS 서비스 작업의 상한선(가드레일)**을 정의하는 정책이다.

• SCP는 IAM 사용자·역할에 권한을 부여하지 않는다
• 허용 가능한 권한의 범위를 **제한(가드레일 설정)**하는 용도로 사용
• OU나 계정에 부여되어, 그 하위의 모든 계정 및 사용자에게 적용됨
• SCP를 사용하면 조직의 액세스 제어 지침에 따라 계정을 유지할 수 있음

SCP 활용 예시

특정 리전만 허용 (Allow-Only-Frankfurt)

{
  "Effect": "Deny",
  "Action": "*",
  "Resource": "*",
  "Condition": {
    "StringNotEquals": {
      "aws:RequestedRegion": "eu-central-1"
    }
  }
}

특정 인스턴스 타입만 허용 (Allow-Only-t3.micro)

{
  "Effect": "Deny",
  "Action": "ec2:RunInstances",
  "Resource": "arn:aws:ec2:*:*:instance/*",
  "Condition": {
    "StringNotEquals": {
      "ec2:InstanceType": "t3.micro"
    }
  }
}

MFA 미사용 시 위험 액션 거부

{
  "Effect": "Deny",
  "Action": [
    "iam:DeleteUser",
    "iam:DeleteRole"
  ],
  "Resource": "*",
  "Condition": {
    "BoolIfExists": {
      "aws:MultiFactorAuthPresent": "false"
    }
  }
}

---

5. SCP vs IAM 정책 비교

SCP와 IAM 정책은 함께 작동하지만 역할이 다르다.

구분 SCP IAM 정책

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

핵심 원칙

SCP에서 허용 AND IAM 정책에서 허용 = 최종 허용

SCP는 전체 허용 범위를 제한하고, IAM은 그 범위 안에서 개별 권한을 부여한다. Deny는 언제나 최우선이다.

---

6. 실습: 조직 생성 및 계정 초대 흐름

AWS Organizations 콘솔에서의 주요 작업 흐름:

1. 조직 생성: Management Account에서 Organizations 서비스로 조직 생성
2. 멤버 계정 초대: 기존 계정을 이메일로 초대하거나 신규 계정 직접 생성
3. OU 구성: Root 아래 목적별 OU 생성 (예: Dev, Staging, Production)
4. SCP 적용: 생성한 OU나 계정에 SCP 연결
5. 태그 정책 적용: 태그 키·값의 대소문자와 형식 규칙 정의

---

7. 학습 정리

• AWS Organizations는 여러 계정을 하나의 조직처럼 묶어 중앙에서 관리할 수 있게 해준다.
• 계정들을 통합하거나 계층 구조로 나누어 관리하면 보안, 결제, 정책 관리가 더 효율적이 된다.
• SCP는 허용 범위 상한선, IAM은 개별 권한 부여라는 역할 분담을 명확히 이해해야 한다.
• Organizations에서는 계정 생성·초대 기능으로 손쉽게 조직을 확장할 수 있으며, 중앙 관리를 통해 대규모 AWS 운영 환경도 체계적으로 유지할 수 있다.

---

다음 주차 예고: 12주차에서는 멀티 AZ 구성과 ELB를 활용한 고가용성(HA) 아키텍처 설계를 학습한다.