1. AWS Organization
탄생 배경 및 사용하면 좋은 점 (Why & What for?)
기업의 규모가 커지면서, 단일 AWS 계정으로 모든 워크로드를 관리하는 것은 보안, 비용 관리, 거버넌스 측면에서 매우 비효율적이고 위험해졌다. 예를 들어, 개발 환경에서 발생한 실수가 운영 환경에 영향을 주거나, 여러 부서의 비용이 뒤섞여 책임 소재를 파악하기 어려워지는 문제가 발생했다. 이 때문에 기업들은 '개발팀 계정', '운영팀 계정', '재무팀 계정'처럼 목적에 따라 여러 개의 AWS 계정을 분리하여 사용하는 '멀티 어카운트' 전략을 채택하게 되었다.
AWS Organizations는 이러한 멀티 어카운트 환경을 중앙에서 효율적으로 관리하고 통제하기 위해 탄생했다. 흩어져 있는 여러 AWS 계정을 하나의 '조직(Organization)'으로 묶어, 통합된 정책과 비용 관리를 적용할 수 있게 해주는 중앙 거버넌스 서비스다.
- 중앙 집중식 거버넌스 및 제어 🏛️
수십, 수백 개의 계정에 대해 공통된 보안 정책(예: "특정 리전 사용 금지")을 한 번에 강제하고, 모든 계정의 활동을 중앙에서 감사할 수 있다. - 비용 관리 및 절감 💵
모든 멤버 계정의 비용을 관리 계정으로 통합하여 하나의 청구서로 관리할 수 있다(통합 결제). 또한, 여러 계정의 사용량을 합산하여 예약 인스턴스(RI)나 Savings Plans의 볼륨 할인을 더 크게 받을 수 있어 비용 절감에 유리하다. - 계정 관리 자동화 ⚙️
새로운 AWS 계정을 API 호출 한 번으로 몇 분 만에 생성하고, 미리 정의된 보안 기준과 네트워크 설정을 자동으로 적용하여 프로비저닝 과정을 자동화할 수 있다.
개인화 및 설정 범위 (How to Customize?)
Organizations는 기업의 조직 구조와 정책에 맞춰 계정들을 유연하게 구성하고 제어할 수 있다.
- 조직 단위 (Organizational Units, OUs)
회사의 부서 구조처럼, 관련된 AWS 계정들을 그룹으로 묶는 폴더 역할을 한다. '개발 OU', '운영 OU', '보안 OU' 등으로 나누어, 각 OU에 속한 계정들에 서로 다른 정책을 적용할 수 있다. OUs는 계층 구조(최대 5단계)로 만들 수 있다. - 서비스 제어 정책 (Service Control Policies, SCPs)
Organizations의 가장 강력한 기능. 특정 OU나 개별 계정의 IAM 사용자 및 역할(루트 사용자 포함)이 사용할 수 있는 AWS 서비스와 액션의 최대 허용 범위를 정의하는 가드레일 역할을 한다.- 화이트리스트 방식: 허용된 작업만 명시한다.
- 블랙리스트 방식: 금지할 작업만 명시한다. (예:
iam:DeleteRole액션 거부)
SCPs는 권한을 직접 부여하지 않으며, 각 계정 내 IAM 정책과 교집합으로 적용된다. 즉, SCP에서 허용되지 않은 작업은 계정 내 관리자(Administrator)라도 절대 수행할 수 없다.
- 기타 정책 유형
백업 정책, 태그 정책 등을 조직 전체에 적용하여 데이터 보호 및 리소스 분류 기준을 표준화할 수 있다.
비용 최적화 방안 (How to Save?)
Organizations 서비스 자체는 무료이며, 비용 최적화에 매우 중요한 역할을 한다.
- 통합 결제 (Consolidated Billing)
모든 멤버 계정의 사용량이 관리 계정으로 합산 청구된다. 이 과정에서 AWS의 볼륨 할인 혜택을 극대화할 수 있다. 예를 들어, A 계정의 S3 사용량과 B 계정의 S3 사용량을 합쳐서 더 높은 할인율이 적용되는 구간에 도달할 수 있다. - RI 및 Savings Plans 공유
한 계정에서 구매한 예약 인스턴스(RI)나 Savings Plans의 할인 혜택이, 다른 계정의 온디맨드 인스턴스에도 자동으로 공유되어 적용된다. 이를 통해 조직 전체의 EC2, RDS 등의 컴퓨팅 비용을 최적화하고, 특정 계정에서 RI가 낭비되는 것을 방지할 수 있다. - 비용 데이터 중앙화
관리 계정에서 모든 멤버 계정의 상세 비용 데이터를 한눈에 파악하고 분석할 수 있어, 비용이 급증하는 부서나 프로젝트를 쉽게 찾아내고 조치할 수 있다.
서비스 간 연동 및 통합 (Service Interconnections)
Organizations는 다른 AWS 관리 및 거버넌스 서비스와 통합될 때 진정한 힘을 발휘한다.
- AWS Control Tower & Landing Zone: Organizations를 기반으로, 모범 사례에 따라 안전하고 확장 가능한 멀티 어카운트 환경(Landing Zone)을 몇 번의 클릭만으로 자동으로 구축해주는 서비스다.
- AWS CloudFormation StackSets: 단일 CloudFormation 템플릿을 사용하여 조직 내 모든 계정 또는 특정 OU에 속한 계정 전체에 걸쳐 리소스를 한 번에 배포, 업데이트, 삭제할 수 있다.
- AWS Config & Security Hub: 조직의 모든 계정에 Config 규칙과 Security Hub 표준을 중앙에서 배포하고, 모든 계정의 규정 준수 및 보안 상태를 관리 계정의 중앙 대시보드에서 통합 모니터링할 수 있다.
- AWS CloudTrail: 조직 트레일(Organization Trail)을 생성하여, 모든 멤버 계정의 API 활동 로그를 중앙의 단일 S3 버킷으로 수집하여 전사적인 감사를 용이하게 한다.
보안 (Security)
Organizations는 멀티 어카운트 환경의 보안을 중앙에서 강제하는 핵심 도구다.
- 서비스 제어 정책 (SCPs)을 통한 가드레일: "서울 리전 외에는 어떤 리소스도 생성할 수 없다", "루트 계정은 절대 사용할 수 없다", "승인되지 않은 서비스는 사용할 수 없다" 와 같은 강력한 보안 경계선을 설정하여, 멤버 계정이 보안 정책을 우회하는 것을 원천적으로 차단한다.
- 중앙 집중식 보안 서비스 관리: 위에서 언급한 것처럼 Security Hub, GuardDuty, IAM Access Analyzer 등의 보안 서비스를 조직의 모든 계정에 중앙에서 활성화하고 관리할 수 있다.
- 계정 격리를 통한 영향 범위 축소 (Blast Radius Reduction): 워크로드나 환경을 여러 계정으로 분리함으로써, 하나의 계정이 침해되더라도 다른 계정으로의 피해 확산을 막는 보안의 기본 원칙을 구현한다.
모니터링 및 로깅 (Monitoring & Logging)
- 중앙 집중식 로깅: CloudTrail 조직 트레일을 통해 모든 계정의 API 로그를, Config 어그리게이터를 통해 모든 계정의 리소스 변경 로그를 중앙 S3 버킷이나 관리 계정에서 통합 관리하고 분석할 수 있다.
- 교차 계정 접근: 관리 계정의 감사 담당자나 보안팀이, 멤버 계정의 리소스(CloudWatch 로그, S3 버킷 등)에 접근하여 모니터링할 수 있도록 교차 계정 IAM 역할(Cross-Account Role)을 표준화하여 배포할 수 있다.
장애 복구 및 고가용성 (DR & HA)
- 서비스 자체의 HA: Organizations는 AWS가 완전 관리하는 글로벌 서비스로, 고가용성이 내장되어 있다.
- DR 전략 지원:
- 계정 수준의 격리: DR 환경을 운영 환경과 별개의 AWS 계정으로 분리하여, 운영 환경의 장애나 보안 침해가 DR 환경에 영향을 주지 않도록 격리 수준을 높일 수 있다.
- 정책의 일관성: 주 리전과 DR 리전 양쪽에 동일한 SCP를 적용하여, DR 환경에서도 보안 및 거버넌스 정책이 일관되게 유지되도록 보장할 수 있다.
트러블슈팅 및 문제 해결 (Troubleshooting)
- 권한 거부 (Permission Denied): 멤버 계정의 관리자(Administrator)가 특정 작업을 수행하려는데 권한 거부 오류가 발생한다면, 가장 먼저 상위 OU나 루트에 연결된 SCP가 해당 작업을 금지하고 있는지 확인해야 한다. IAM 권한이 있더라도 SCP에서 막혀있으면 절대 실행할 수 없다.
- 새 계정 프로비저닝 문제: AWS Control Tower 등을 통해 계정을 생성할 때 실패한다면, 이메일 주소가 이미 사용 중이거나 조직의 계정 수 한도(기본 1000개)에 도달했는지 등을 확인해야 한다.
- 통합 결제 문제: 특정 계정의 RI나 Savings Plans 할인이 다른 계정에 적용되지 않는다면, Organizations 설정에서 할인 공유 기능이 활성화되어 있는지 확인해야 한다.
사용 사례 및 아키텍처 패턴 (Use Cases & Patterns)
- 표준 랜딩 존 (Landing Zone) 구축
모든 기업이 AWS를 도입할 때 가장 먼저 수행하는 패턴. Organizations를 사용하여 '인프라', '로깅', '보안', '네트워크' 등 공용 서비스를 관리하는 중앙 계정들을 만들고, '개발', '운영' 등 워크로드를 배포할 계정들을 OU로 묶어 관리하는 표준화된 멀티 어카운트 환경을 구축한다. - 보안 및 규정 준수 환경 분리
개인정보(PII)를 다루거나 PCI-DSS 같은 엄격한 규정을 준수해야 하는 워크로드는, 일반 워크로드와는 완전히 격리된 별도의 OU와 계정 그룹에 배포하여 강력한 SCP와 감사 정책을 적용한다. - 비용 분리 및 책임 추적
각 부서나 프로젝트별로 별도의 AWS 계정을 할당하여, 어떤 팀이 얼마의 비용을 사용하는지 명확하게 분리하고 추적(Chargeback/Showback)한다. - 샌드박스 환경 제공
개발자들이 자유롭게 기술을 실험해볼 수 있도록, SCP를 통해 비용이 많이 들거나 보안에 위험한 서비스(예: 고사양 GPU 인스턴스) 사용을 제한한 '샌드박스' 계정을 대량으로 생성하고 배포한다.
2. Governanace
## AWS Control Tower: '잘 지어진 집'을 분양해주는 서비스 🏡
AWS Control Tower는 AWS의 모범 사례에 따라, 안전하고 잘 설계된 멀티 어카운트 환경(랜딩 존)을 버튼 몇 번으로 자동 구축해주는 서비스다.
AWS Organizations가 멀티 어카운트 환경을 만들 수 있는 '건축 자재(OU, SCP 등)'를 제공한다면, Control Tower는 그 자재들을 이용해 검증된 '설계도'에 따라 로깅 및 감사용 중앙 계정, 보안 정책, 네트워크 설정까지 완벽하게 갖춰진 집들을 자동으로 지어주는 '건축 회사'와 같다.
- 핵심 기능:
- 랜딩 존 (Landing Zone): 모범 사례에 따른 멀티 어카운트 환경을 자동으로 설정한다.
- 가드레일 (Guardrails): "특정 리전 사용 금지"와 같은 보안 및 규정 준수 정책(SCP)을 미리 구성하여 조직 전체에 적용한다.
- 계정 팩토리 (Account Factory): 이 가드레일이 적용된 새로운 AWS 계정을 표준화된 템플릿을 통해 신속하게 생성하고 프로비저닝한다.
## AWS Service Catalog: 승인된 제품만 파는 '사내 자판기' vending_machine
Service Catalog는 회사의 관리자가 미리 승인하고 표준화한 AWS 리소스 템플릿을 '제품(Product)'으로 만들어 목록(Catalog)으로 제공하면, 일반 개발자들은 필요한 제품을 쇼핑하듯이 골라 직접 배포할 수 있게 해주는 서비스다.
개발자에게 EC2, RDS 등을 만들 수 있는 모든 권한(IAM)을 직접 주는 것은 보안이나 비용 측면에서 위험할 수 있다. 대신, 관리자가 보안과 비용 설정이 완료된 CloudFormation 템플릿을 '2Core-4GB-WebApp-Server' 같은 제품으로 만들어 카탈로그에 등록해두면, 개발자는 이 '제품'을 구매(실행)할 권한만 받아 안전하게 리소스를 생성할 수 있다.
- 핵심 기능:
- 제품(Products): 관리자가 승인한 CloudFormation 템플릿.
- 포트폴리오(Portfolios): 제품, 사용자, 권한을 그룹으로 묶어 관리하는 컬렉션.
- 거버넌스 및 셀프 서비스: 개발자에게는 셀프 서비스의 편리함을 제공하고, 회사는 중앙에서 IT 거버넌스를 유지할 수 있게 한다.
## AWS Health Dashboard: AWS가 보내주는 '공식 건강검진표' 🏥
AWS Health Dashboard는 AWS 서비스 자체의 상태나, 내 계정에 영향을 미칠 수 있는 예정된 이벤트에 대한 정보를 제공하는 공식적인 창구다. '내' 리소스의 상태를 보는 CloudWatch와는 달리, 'AWS'의 상태를 보는 것이다.
-
CloudWatch와의 차이 (아파트 비유):
- CloudWatch: 우리 집 '내부'의 전기 사용량, 누수 여부 등을 감시하는 계량기나 센서.
- Health Dashboard: 아파트 '관리사무소'에서 보내주는 공지. "오늘 오후 2시부터 전체 전기 점검이 있습니다" 또는 "3동 엘리베이터가 현재 고장입니다" 와 같은 AWS 인프라 자체의 이슈를 알려준다.
-
두 가지 뷰:
- 서비스 상태 대시보드: 모든 AWS 서비스의 리전별 현재 상태를 보여주는 공개적인 상태 페이지.
- 개인 상태 대시보드: 내 계정이 사용 중인 리소스에 영향을 미칠 수 있는 이벤트(예정된 유지보수, 특정 EC2 인스턴트가 위치한 하드웨어의 성능 저하 등)에 대한 맞춤형 알림을 제공한다.
3. Cost
## Cost Allocation Tags: 가계부에 '항목' 적기 🏷️
Cost Allocation Tags는 AWS 리소스(EC2, S3 등)에 '이름표'를 붙이는 기능이다. Project: A, Team: DevOps, Environment: Production 과 같은 태그를 붙여두면, 나중에 "A 프로젝트에서 비용이 얼마나 나왔지?" 또는 "DevOps 팀이 사용한 리소스 비용은?" 과 같은 질문에 답할 수 있게 된다.
이것은 가계부를 쓸 때, 모든 지출에 대해 '식비', '교통비', '문화생활'처럼 항목을 꼼꼼히 적어두는 것과 같다. 태그 자체는 비용을 줄여주지 않지만, 비용을 분석하고 추적하기 위한 가장 기본적이고 중요한 첫 단계다.
## Cost Explorer: 카드사 지출 분석 리포트 📊
Cost Explorer는 AWS 비용이 어디에 얼마나 발생했는지 시각적으로 분석하고 탐색할 수 있는 도구다. 과거의 비용 데이터를 다양한 필터(서비스별, 리전별, 그리고 위에서 설정한 태그별)로 조회하고, 그래프로 확인하며, 미래의 비용을 예측해볼 수도 있다.
이것은 카드사 앱에 로그인해서 "지난 6개월간 나의 식비 지출 추이"를 그래프로 보거나, "이번 달 교통비는 지난달보다 얼마나 늘었지?"를 비교 분석하는 것과 같다. 비용의 패턴과 원인을 파악하는 데 사용되는 분석 도구다.
## AWS Budgets: 월별 '예산' 설정 및 경고 💸
AWS Budgets는 앞으로 사용할 비용이나 사용량에 대해 사전에 '예산'을 설정하고, 그 예산을 초과했거나 초과할 것으로 '예측'될 때 알림을 받는 서비스다.
이것은 "이번 달 식비 예산은 30만원, 교통비는 10만원으로 잡아야지"라고 계획을 세우는 것과 같다. 그리고 "식비가 예산의 80%(24만원)를 넘으면 알려줘" 또는 "이런 추세라면 월말에 총 예산을 초과할 것 같아" 와 같은 예측 기반의 경고를 설정할 수 있다. 비용이 초과되기 전에 선제적으로 대응할 수 있게 해주는 계획 및 경고 도구다.
## AWS Billing Alarms: 최후의 비상 경보 🚨
Billing Alarms는 AWS Budgets보다 훨씬 단순한 기능이다. CloudWatch를 사용하여 계정의 총 예상 청구액이라는 단일 지표를 감시하다가, 설정해 둔 금액(예: $500)을 넘으면 즉시 알림을 보내는 기능이다.
이것은 "이유를 불문하고, 이번 달 내 통장에서 총 100만원 이상 빠져나가면 무조건 비상 연락해줘!" 라고 설정해두는 최후의 안전장치와 같다. Budgets처럼 세부적인 항목별 예산이나 예측 기능은 없지만, 계정 전체의 비용이 예상치 못하게 폭증하는 것을 막기 위한 간단하고 확실한 경보 장치다.
