AWS Organizations 완벽 가이드

여러 AWS 계정을 체계적으로 관리하고 통합 결제와 보안 정책을 적용하는 방법을 실무 스토리로 쉽게 배워봅니다. 초보 개발자도 바로 이해할 수 있는 친절한 설명과 실전 예제를 제공합니다.

1. Organizations란?

김개발 씨는 스타트업에서 일하는 3년 차 개발자입니다. 회사가 성장하면서 개발, 운영, 테스트용으로 AWS 계정이 하나씩 늘어났습니다.

어느 날 CTO님이 물었습니다. "계정이 10개인데 관리가 너무 복잡하지 않나요?"

AWS Organizations는 한마디로 여러 AWS 계정을 하나의 조직으로 묶어서 중앙에서 관리하는 서비스입니다. 마치 여러 지점을 가진 회사가 본사에서 통합 관리하는 것과 같습니다.

이것을 제대로 이해하면 계정 관리, 비용 절감, 보안 정책 통합을 한 번에 해결할 수 있습니다.

다음 코드를 살펴봅시다.

import boto3

# AWS Organizations 클라이언트 생성
org_client = boto3.client('organizations')

# 새로운 조직 생성
response = org_client.create_organization(
    FeatureSet='ALL'  # 모든 기능 활성화
)

# 조직 정보 확인
org_id = response['Organization']['Id']
master_account = response['Organization']['MasterAccountId']

print(f"조직 ID: {org_id}")
print(f"마스터 계정: {master_account}")
# 이제 조직이 생성되었습니다!

김개발 씨는 요즘 고민이 많았습니다. 회사의 AWS 계정이 개발용, 스테이징용, 프로덕션용으로 나뉘어 있는데 각각 따로 관리하다 보니 여간 번거로운 게 아니었습니다.

매달 청구서도 따로따로 오고, 보안 설정도 계정마다 다시 해야 했습니다. 팀장님께서 이런 고민을 들으시더니 말씀하셨습니다.

"AWS Organizations를 써보는 게 어때요?" 그렇다면 AWS Organizations란 정확히 무엇일까요? 쉽게 비유하자면, AWS Organizations는 마치 대기업의 본사와 지점 구조와 같습니다.

본사에서 전체 지점을 관리하고, 각 지점에 예산을 배정하고, 공통 규칙을 적용하는 것처럼, Organizations도 여러 AWS 계정을 하나의 조직으로 묶어서 중앙에서 관리합니다. Organizations가 없던 시절에는 어땠을까요?

개발자들은 각 AWS 계정에 로그인해서 보안 설정을 일일이 확인해야 했습니다. 계정이 5개만 되어도 같은 작업을 5번 반복해야 했습니다.

더 큰 문제는 비용 관리였습니다. 각 계정의 청구서를 하나하나 확인하고, 엑셀로 정리해서 전체 비용을 계산해야 했습니다.

프로젝트가 커질수록 이런 문제는 눈덩이처럼 불어났습니다. 바로 이런 문제를 해결하기 위해 AWS Organizations가 등장했습니다.

Organizations를 사용하면 통합 결제가 가능해집니다. 모든 계정의 사용량을 합산해서 하나의 청구서로 받을 수 있습니다.

또한 보안 정책을 중앙에서 관리할 수 있습니다. 무엇보다 계정을 논리적으로 그룹화할 수 있어서 조직 구조에 맞게 체계적으로 관리할 수 있다는 큰 이점이 있습니다.

위의 코드를 한 줄씩 살펴보겠습니다. 먼저 boto3 라이브러리로 Organizations 클라이언트를 생성합니다.

이 부분이 핵심입니다. 다음으로 create_organization 메서드를 호출하는데, FeatureSet을 'ALL'로 설정하면 모든 Organizations 기능을 사용할 수 있습니다.

마지막으로 생성된 조직의 ID와 마스터 계정 정보가 반환됩니다. 실제 현업에서는 어떻게 활용할까요?

예를 들어 이커머스 회사를 운영한다고 가정해봅시다. 개발 팀, 데이터 팀, 운영 팀이 각각 별도의 AWS 계정을 사용하는데 Organizations로 묶으면 CTO는 한눈에 전체 계정을 파악할 수 있습니다.

많은 스타트업과 대기업에서 이런 패턴을 적극적으로 사용하고 있습니다. 하지만 주의할 점도 있습니다.

초보 개발자들이 흔히 하는 실수 중 하나는 조직을 생성한 후 마스터 계정을 일반 업무에 사용하는 것입니다. 이렇게 하면 보안 위험이 높아지고 관리가 복잡해질 수 있습니다.

따라서 마스터 계정은 순수하게 조직 관리 용도로만 사용하고, 실제 리소스는 멤버 계정에서 생성해야 합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

팀장님의 조언을 들은 김개발 씨는 AWS Organizations를 공부하기 시작했습니다. "아, 이렇게 편리한 기능이 있었군요!" AWS Organizations를 제대로 이해하면 더 체계적이고 안전하게 다중 계정 환경을 관리할 수 있습니다.

여러분도 오늘 배운 내용을 실제 프로젝트에 적용해 보세요.

실전 팁

💡 - 마스터 계정(현재는 관리 계정이라고 부름)은 순수하게 조직 관리용으로만 사용하세요

조직 생성 시 FeatureSet을 'ALL'로 설정하면 SCP 등 고급 기능을 사용할 수 있습니다
계정 간 이동 시 AWS SSO를 함께 활용하면 로그인 편의성이 크게 향상됩니다

2. 조직 구조 설계

Organizations를 만들었다면 이제 어떻게 구조를 잡아야 할까요? 김개발 씨는 계정이 10개나 되는데 이것을 어떻게 분류해야 할지 막막했습니다.

선배 박시니어 씨가 화이트보드를 꺼내며 말했습니다. "조직 구조를 먼저 설계해야 해요."

조직 구조란 AWS 계정들을 논리적으로 그룹화하는 방법입니다. 마치 회사의 조직도처럼 부서별, 프로젝트별, 환경별로 계정을 분류합니다.

올바른 구조 설계는 향후 관리 효율성과 보안 정책 적용의 핵심입니다.

다음 코드를 살펴봅시다.

import boto3

org_client = boto3.client('organizations')

# 루트 OU 아래에 환경별 OU 생성
production_ou = org_client.create_organizational_unit(
    ParentId='r-xxxx',  # 루트 ID
    Name='Production'
)

development_ou = org_client.create_organizational_unit(
    ParentId='r-xxxx',
    Name='Development'
)

# OU 구조 확인
print(f"프로덕션 OU: {production_ou['OrganizationalUnit']['Id']}")
print(f"개발 OU: {development_ou['OrganizationalUnit']['Id']}")
# 이제 계정을 OU별로 분류할 수 있습니다

김개발 씨는 화이트보드 앞에 섰습니다. 박시니어 씨가 그림을 그리기 시작했습니다.

"보세요, 우리 회사 계정들을 이렇게 나눠볼 수 있어요." 조직 구조를 설계한다는 것은 무슨 의미일까요? 쉽게 비유하자면, 조직 구조는 마치 도서관의 분류 체계와 같습니다.

도서관에서 책을 문학, 과학, 역사로 나누고 다시 세부 카테고리로 나누듯이, AWS 계정도 목적에 따라 계층적으로 분류합니다. 이렇게 하면 필요한 계정을 빠르게 찾고, 비슷한 성격의 계정들에 같은 정책을 적용할 수 있습니다.

조직 구조를 제대로 설계하지 않으면 어떻게 될까요? 계정 수가 늘어날수록 관리가 혼란스러워집니다.

"이 계정이 뭐에 쓰는 계정이었지?"라는 질문을 매번 하게 됩니다. 보안 정책을 적용할 때도 각 계정의 용도를 일일이 확인해야 합니다.

더 큰 문제는 실수로 프로덕션 계정에 개발용 설정을 적용하는 등의 사고가 발생할 수 있다는 점입니다. 바로 이런 문제를 해결하기 위해 조직 구조 설계가 필요합니다.

조직 구조를 잘 설계하면 계정의 용도를 명확히 구분할 수 있습니다. 또한 정책 관리가 쉬워집니다.

무엇보다 신규 계정 추가 시 어디에 배치할지 명확하다는 큰 이점이 있습니다. 일반적으로 많이 사용하는 구조 패턴이 있습니다.

첫 번째는 환경별 분류입니다. Production, Staging, Development처럼 배포 환경에 따라 나눕니다.

두 번째는 부서별 분류입니다. Engineering, Marketing, Data처럼 조직 구조에 따라 나눕니다.

세 번째는 프로젝트별 분류입니다. ProjectA, ProjectB처럼 프로젝트 단위로 나눕니다.

위의 코드를 한 줄씩 살펴보겠습니다. 먼저 create_organizational_unit 메서드로 OU를 생성합니다.

ParentId는 상위 OU의 ID인데, 루트 바로 아래에 만들 때는 루트 ID를 사용합니다. Name으로 OU 이름을 지정하면 계층 구조가 만들어집니다.

이렇게 Production과 Development OU를 분리하면 환경별로 명확하게 구분할 수 있습니다. 실제 현업에서는 어떻게 활용할까요?

예를 들어 금융 서비스 회사라면 규제 준수가 중요합니다. Production OU에는 엄격한 보안 정책을, Development OU에는 좀 더 유연한 정책을 적용할 수 있습니다.

많은 기업에서 환경별 분리를 가장 기본적인 구조로 사용하고 있습니다. 하지만 주의할 점도 있습니다.

초보 개발자들이 흔히 하는 실수 중 하나는 너무 복잡한 계층 구조를 만드는 것입니다. OU를 5단계, 6단계로 깊게 만들면 관리가 오히려 복잡해집니다.

따라서 2~3단계 정도의 간단한 구조로 시작하는 것이 좋습니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

박시니어 씨의 설명을 들은 김개발 씨는 화이트보드의 조직도를 이해했습니다. "아, 이렇게 환경별로 나누면 되겠네요!" 조직 구조를 제대로 설계하면 향후 수백 개의 계정을 관리하더라도 혼란 없이 운영할 수 있습니다.

여러분도 회사의 상황에 맞는 구조를 고민해 보세요.

실전 팁

💡 - 처음에는 간단하게 2~3단계 구조로 시작하고, 필요에 따라 확장하세요

환경별 분류(Prod/Dev/Staging)가 가장 보편적이고 안전한 접근법입니다
OU 이름은 명확하고 일관성 있게 지어야 나중에 혼란이 없습니다

3. OU 생성하기

조직 구조 설계가 끝났다면 이제 실제로 OU를 만들어야 합니다. 김개발 씨는 콘솔을 열고 OU 생성 버튼을 찾았지만, 막상 어떤 순서로 만들어야 할지 고민되었습니다.

"일단 만들고 나중에 옮기면 되지 않을까요?" 박시니어 씨가 고개를 저었습니다.

OU 생성은 계층 구조를 실제로 구현하는 작업입니다. 마치 폴더를 만들듯이 OU를 생성하고, 계정을 그 안에 배치합니다.

처음부터 체계적으로 만들어야 나중에 재작업하는 수고를 덜 수 있습니다.

다음 코드를 살펴봅시다.

import boto3

org_client = boto3.client('organizations')

# 루트 ID 조회
roots = org_client.list_roots()
root_id = roots['Roots'][0]['Id']

# Workloads OU 생성 (1단계)
workloads_ou = org_client.create_organizational_unit(
    ParentId=root_id,
    Name='Workloads'
)
workloads_id = workloads_ou['OrganizationalUnit']['Id']

# Production OU 생성 (2단계 - Workloads 아래)
prod_ou = org_client.create_organizational_unit(
    ParentId=workloads_id,  # 부모를 Workloads로 지정
    Name='Production'
)

print(f"생성 완료: {prod_ou['OrganizationalUnit']['Name']}")

김개발 씨는 실제 작업에 들어가기 전에 한 가지 의문이 들었습니다. "OU를 만드는 건 간단해 보이는데, 왜 미리 계획이 필요하다는 걸까요?" 박시니어 씨가 예전 경험담을 들려주었습니다.

"제가 전 회사에서 OU를 아무 계획 없이 막 만들었다가 나중에 다 엎은 적이 있어요. 계정을 다른 OU로 옮기는 것도 번거롭고, 정책 상속 관계도 꼬여서 고생했죠." OU 생성이란 정확히 무엇일까요?

쉽게 비유하자면, OU 생성은 마치 컴퓨터에서 폴더를 만드는 것과 같습니다. 상위 폴더를 만들고 그 아래 하위 폴더를 만들어서 파일을 분류하듯이, OU도 계층적으로 만들어서 계정을 분류합니다.

다만 일반 폴더와 다른 점은 OU에 정책을 연결하면 그 아래의 모든 계정에 자동으로 적용된다는 점입니다. OU를 체계 없이 만들면 어떻게 될까요?

처음에는 문제가 없어 보입니다. 하지만 시간이 지나면서 계정 수가 늘어나면 "이 계정이 어느 OU에 있었지?"라는 질문을 반복하게 됩니다.

더 큰 문제는 정책 관리입니다. OU 구조가 엉망이면 어떤 정책이 어느 계정에 적용되는지 파악하기 어렵습니다.

잘못된 OU에 엄격한 정책을 적용해서 개발 작업이 막히는 사고도 발생할 수 있습니다. 바로 이런 문제를 해결하기 위해 체계적인 OU 생성이 필요합니다.

OU를 체계적으로 만들면 계정의 위치를 직관적으로 파악할 수 있습니다. 또한 정책 적용 범위가 명확해집니다.

무엇보다 신규 계정 추가 시 어디에 넣을지 고민할 필요가 없다는 큰 이점이 있습니다. 위의 코드를 한 줄씩 살펴보겠습니다.

먼저 list_roots로 조직의 루트 ID를 조회합니다. 모든 OU는 루트 아래에 생성되므로 루트 ID가 필요합니다.

다음으로 Workloads라는 1단계 OU를 루트 아래에 생성합니다. 마지막으로 Production OU를 Workloads의 하위로 생성하는데, ParentId를 Workloads의 ID로 지정하면 계층 관계가 만들어집니다.

실제 현업에서는 어떻게 활용할까요? 예를 들어 글로벌 서비스를 운영하는 회사라면 지역별로 OU를 나눌 수 있습니다.

Asia OU 아래에 Korea, Japan OU를 만들고, 각 국가의 계정을 배치합니다. 이렇게 하면 지역별 규제에 맞는 정책을 효율적으로 적용할 수 있습니다.

많은 다국적 기업에서 이런 지역별 구조를 사용하고 있습니다. 하지만 주의할 점도 있습니다.

초보 개발자들이 흔히 하는 실수 중 하나는 OU 이름을 막연하게 짓는 것입니다. "Test", "Misc", "Others" 같은 이름을 쓰면 나중에 용도를 파악하기 어렵습니다.

따라서 OU 이름은 명확하고 구체적으로 지어야 합니다. "Dev-Frontend", "Prod-Backend"처럼 목적이 드러나는 이름이 좋습니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 조언을 들은 김개발 씨는 화이트보드의 설계도를 보며 하나씩 OU를 만들기 시작했습니다.

"계획대로 차근차근 만드니까 헷갈리지 않네요!" OU 생성은 한 번 제대로 해두면 향후 수년간 안정적으로 사용할 수 있는 기반이 됩니다. 여러분도 서두르지 말고 설계도를 그린 후 체계적으로 만들어 보세요.

실전 팁

💡 - OU 생성 전에 반드시 구조도를 그려보세요 (화이트보드나 문서로)

OU 이름은 회사 전체가 이해할 수 있는 명확한 용어를 사용하세요
처음부터 완벽할 필요는 없습니다. 기본 구조를 만들고 필요에 따라 확장하세요

4. SCP 정책

OU 구조가 완성되자 박시니어 씨가 말했습니다. "이제 보안 정책을 적용해야 해요." 김개발 씨는 IAM 정책을 떠올렸지만, 박시니어 씨가 말하는 것은 SCP라는 다른 개념이었습니다.

"SCP는 IAM보다 상위 레벨의 가드레일이에요."

**SCP(Service Control Policy)**는 조직 내 계정들이 수행할 수 있는 작업의 최대 범위를 제한하는 정책입니다. 마치 아파트 관리규칙처럼 각 세대가 할 수 있는 행동의 경계를 정합니다.

IAM 정책이 허용하더라도 SCP가 거부하면 작업이 차단됩니다.

다음 코드를 살펴봅시다.

import boto3
import json

org_client = boto3.client('organizations')

# 특정 리전만 허용하는 SCP 정책
region_restriction_policy = {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": "*",
            "Resource": "*",
            "Condition": {
                "StringNotEquals": {
                    "aws:RequestedRegion": ["ap-northeast-2", "us-east-1"]
                }
            }
        }
    ]
}

# SCP 정책 생성
response = org_client.create_policy(
    Content=json.dumps(region_restriction_policy),
    Description='Only allow Seoul and Virginia regions',
    Name='RegionRestriction',
    Type='SERVICE_CONTROL_POLICY'
)

print(f"정책 생성 완료: {response['Policy']['PolicySummary']['Id']}")

김개발 씨는 IAM 정책은 익숙했지만 SCP는 처음 들어봤습니다. "IAM 정책으로 권한을 관리하는데 SCP는 왜 필요한 거죠?" 박시니어 씨가 실제 사례를 들려주었습니다.

"예전에 우리 회사에서 개발자 한 명이 실수로 미국 리전에 EC2를 띄웠어요. 비용도 비용이지만 데이터 주권 문제가 생겼죠.

IAM으로는 개발자마다 설정해야 하는데 SCP를 쓰면 조직 전체에 한 번에 적용할 수 있어요." SCP란 정확히 무엇일까요? 쉽게 비유하자면, SCP는 마치 건물의 출입 통제 시스템과 같습니다.

건물 관리자가 "이 건물에서는 밤 10시 이후 출입 금지"라는 규칙을 정하면, 개별 사무실의 열쇠가 있어도 그 시간에는 들어갈 수 없습니다. 마찬가지로 SCP가 특정 작업을 거부하면, IAM 권한이 있어도 그 작업을 수행할 수 없습니다.

SCP 없이 IAM만으로 관리하면 어떻게 될까요? 각 계정의 모든 사용자와 역할에 일일이 정책을 적용해야 합니다.

계정이 10개고 각 계정에 사용자가 10명이면 100번의 설정이 필요합니다. 더 큰 문제는 일관성입니다.

누군가 실수로 정책을 빼먹으면 보안 구멍이 생깁니다. 신규 입사자가 들어올 때마다 정책 적용을 잊지 않아야 하는 부담도 있습니다.

바로 이런 문제를 해결하기 위해 SCP가 등장했습니다. SCP를 사용하면 조직 전체에 일관된 보안 기준을 적용할 수 있습니다.

또한 실수로 인한 보안 사고를 예방할 수 있습니다. 무엇보다 관리 포인트가 줄어들어 운영 효율성이 크게 향상됩니다.

위의 코드를 한 줄씩 살펴보겠습니다. 먼저 정책 문서를 JSON 형태로 작성합니다.

Effect는 Deny, Action은 모든 작업, Resource는 모든 리소스를 의미합니다. 핵심은 Condition 부분인데, aws:RequestedRegion이 서울과 버지니아가 아니면 거부한다는 뜻입니다.

create_policy로 이 정책을 생성하면 OU에 연결할 수 있습니다. Type을 SERVICE_CONTROL_POLICY로 지정하는 것이 중요합니다.

실제 현업에서는 어떻게 활용할까요? 예를 들어 금융권 회사라면 개인정보보호법 준수가 필수입니다.

S3 버킷을 퍼블릭으로 열지 못하게 하는 SCP를 적용하면 개발자가 실수로 데이터를 노출하는 사고를 원천 차단할 수 있습니다. 많은 대기업에서 컴플라이언스 준수를 위해 SCP를 적극 활용하고 있습니다.

하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 너무 엄격한 SCP를 적용해서 정상 업무를 막는 것입니다.

예를 들어 모든 EC2 생성을 차단하면 개발 작업 자체가 불가능해집니다. 따라서 SCP는 꼭 필요한 제약만 걸고, 나머지는 IAM으로 세밀하게 관리하는 것이 좋습니다.

SCP의 또 다른 중요한 특징은 상속입니다. OU에 SCP를 연결하면 그 아래의 모든 하위 OU와 계정에 자동으로 적용됩니다.

이것이 SCP의 가장 강력한 점이자 조심해야 할 점입니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

박시니어 씨의 설명을 들은 김개발 씨는 SCP의 위력을 이해했습니다. "아, 조직 전체를 한 번에 보호할 수 있는 안전장치군요!" SCP를 제대로 활용하면 보안 사고를 사전에 예방하고, 규정 준수를 자동화할 수 있습니다.

여러분도 회사의 보안 요구사항을 SCP로 구현해 보세요.

실전 팁

💡 - SCP는 Deny 정책부터 시작하세요. Allow보다 관리가 쉽습니다

테스트 OU를 만들어서 먼저 적용해보고, 문제 없으면 전체에 적용하세요
FullAWSAccess SCP가 기본으로 연결되어 있으니, 제거 시 주의하세요

5. 통합 결제

OU와 SCP 설정이 끝나자 김개발 씨는 경리팀에서 연락이 왔습니다. "계정 10개의 청구서를 일일이 확인하기 힘들어요." 박시니어 씨가 웃으며 말했습니다.

"Organizations의 가장 큰 장점 중 하나가 바로 통합 결제예요."

통합 결제는 조직 내 모든 계정의 사용량을 합산해서 하나의 청구서로 받는 기능입니다. 마치 가족 요금제처럼 사용량을 모아서 할인도 받고, 관리도 간편해집니다.

Organizations를 만들면 자동으로 활성화됩니다.

다음 코드를 살펴봅시다.

import boto3
from datetime import datetime, timedelta

# Cost Explorer로 통합 결제 정보 조회
ce_client = boto3.client('ce')

# 지난 달 비용 조회
end_date = datetime.now().strftime('%Y-%m-%d')
start_date = (datetime.now() - timedelta(days=30)).strftime('%Y-%m-%d')

response = ce_client.get_cost_and_usage(
    TimePeriod={
        'Start': start_date,
        'End': end_date
    },
    Granularity='MONTHLY',
    Metrics=['UnblendedCost'],
    GroupBy=[
        {'Type': 'DIMENSION', 'Key': 'LINKED_ACCOUNT'}
    ]
)

# 계정별 비용 출력
for result in response['ResultsByTime']:
    for group in result['Groups']:
        account = group['Keys'][0]
        cost = group['Metrics']['UnblendedCost']['Amount']
        print(f"계정 {account}: ${float(cost):.2f}")

김개발 씨는 매달 초면 경리팀에서 요청이 들어왔습니다. "이번 달 AWS 비용 정리 좀 해주세요." 그럴 때마다 10개 계정에 각각 로그인해서 청구서를 다운로드하고, 엑셀로 합산하는 작업이 한나절이 걸렸습니다.

박시니어 씨가 이런 고충을 듣고 말했습니다. "Organizations를 쓰면 그럴 필요가 없어요.

통합 결제가 자동으로 되거든요." 통합 결제란 정확히 무엇일까요? 쉽게 비유하자면, 통합 결제는 마치 가족 휴대폰 요금제와 같습니다.

가족 구성원 각자의 사용량을 합쳐서 한 장의 청구서로 받고, 합산 할인도 받습니다. 마찬가지로 Organizations도 모든 멤버 계정의 AWS 사용량을 합산해서 관리 계정으로 청구서가 옵니다.

통합 결제가 없다면 어떻게 될까요? 각 계정마다 별도의 청구서가 발행됩니다.

경리 담당자는 계정 수만큼 신용카드를 관리해야 하고, 매달 청구서를 하나하나 확인해야 합니다. 더 큰 문제는 할인 혜택을 놓치는 것입니다.

예를 들어 Reserved Instance는 사용량이 많을수록 할인율이 높은데, 계정이 분리되면 이 혜택을 제대로 받을 수 없습니다. 바로 이런 문제를 해결하기 위해 통합 결제가 등장했습니다.

통합 결제를 사용하면 하나의 청구서로 모든 계정을 관리할 수 있습니다. 또한 사용량 합산으로 할인 혜택을 극대화할 수 있습니다.

무엇보다 비용 추적과 분석이 쉬워진다는 큰 이점이 있습니다. 위의 코드를 한 줄씩 살펴보겠습니다.

먼저 Cost Explorer 클라이언트를 생성합니다. get_cost_and_usage 메서드로 지난 30일간의 비용을 조회하는데, GroupBy로 LINKED_ACCOUNT를 지정하면 멤버 계정별로 비용이 구분됩니다.

UnblendedCost는 할인 전 실제 사용 비용을 의미합니다. 이렇게 하면 어느 계정에서 얼마를 썼는지 한눈에 파악할 수 있습니다.

실제 현업에서는 어떻게 활용할까요? 예를 들어 여러 프로젝트를 동시에 진행하는 회사라면 프로젝트별로 계정을 분리합니다.

통합 결제를 사용하면 전체 비용은 한 번에 내되, Cost Explorer로 프로젝트별 비용을 추적할 수 있습니다. 재무팀은 한 장의 청구서만 확인하면 되고, 프로젝트 매니저는 자기 프로젝트 비용을 실시간으로 모니터링할 수 있습니다.

통합 결제의 또 다른 장점은 예약 인스턴스와 Savings Plans의 공유입니다. 한 계정에서 구매한 예약 인스턴스를 다른 계정에서도 사용할 수 있습니다.

이렇게 하면 리소스 활용률을 높이고 비용을 절감할 수 있습니다. 하지만 주의할 점도 있습니다.

초보 개발자들이 흔히 하는 실수 중 하나는 비용 알림을 관리 계정에만 설정하는 것입니다. 각 멤버 계정에서도 비용 알림을 설정해두면 팀별로 예산을 초과하지 않도록 관리할 수 있습니다.

따라서 CloudWatch와 SNS를 활용해서 계정별 비용 알림을 구성하는 것이 좋습니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

통합 결제를 설정한 후 김개발 씨는 경리팀에서 감사 인사를 받았습니다. "이제 청구서 하나만 확인하면 되니 정말 편해졌어요!" 통합 결제를 제대로 활용하면 재무 관리가 단순해지고, 비용 절감 효과도 얻을 수 있습니다.

여러분도 Cost Explorer를 활용해서 비용을 분석해 보세요.

실전 팁

💡 - Cost Explorer에서 태그 기반 비용 분석을 활성화하면 더욱 세밀한 추적이 가능합니다

예산(Budget)을 설정해서 비용이 임계값을 넘으면 자동 알림을 받으세요
Reserved Instance는 조직 전체에서 공유되므로, 구매 전에 전체 사용량을 분석하세요

6. 계정 간 리소스 공유

통합 결제로 비용 문제는 해결되었지만, 김개발 씨는 또 다른 고민이 생겼습니다. "개발 계정과 프로덕션 계정에서 같은 VPC를 써야 하는데 어떻게 하죠?" 박시니어 씨가 답했습니다.

"AWS RAM을 사용하면 리소스를 공유할 수 있어요."

계정 간 리소스 공유는 한 계정의 리소스를 다른 계정에서 사용할 수 있게 하는 기능입니다. 마치 회사 차량을 여러 부서가 공유하듯이, VPC, Subnet, Transit Gateway 같은 리소스를 조직 내에서 공유합니다.

AWS RAM(Resource Access Manager)을 사용합니다.

다음 코드를 살펴봅시다.

import boto3

ram_client = boto3.client('ram')

# Transit Gateway를 조직과 공유
response = ram_client.create_resource_share(
    name='SharedTransitGateway',
    resourceArns=[
        'arn:aws:ec2:ap-northeast-2:123456789012:transit-gateway/tgw-xxxxx'
    ],
    principals=[
        'arn:aws:organizations::123456789012:organization/o-xxxxx'
    ],
    allowExternalPrincipals=False,  # 조직 내부만 공유
    tags=[
        {'key': 'Environment', 'value': 'Shared'}
    ]
)

print(f"리소스 공유 생성: {response['resourceShare']['name']}")
print(f"상태: {response['resourceShare']['status']}")
# 이제 조직 내 모든 계정에서 Transit Gateway 사용 가능

김개발 씨는 네트워크 설계를 하다가 딜레마에 빠졌습니다. 개발 환경과 프로덕션 환경을 완전히 분리해야 하는데, 공통으로 사용해야 하는 네트워크 리소스가 있었습니다.

"각 계정에 똑같은 걸 만들어야 하나요?" 박시니어 씨가 고개를 저었습니다. "그럴 필요 없어요.

한 계정에서 만들고 공유하면 됩니다. AWS RAM이라는 서비스가 있거든요." 계정 간 리소스 공유란 정확히 무엇일까요?

쉽게 비유하자면, 리소스 공유는 마치 사무실 공용 프린터와 같습니다. 각 팀이 프린터를 따로 살 필요 없이 하나를 공유해서 사용하는 것처럼, AWS 리소스도 한 계정에서 생성하고 여러 계정이 공유할 수 있습니다.

소유권은 원래 계정에 있지만, 사용 권한은 다른 계정도 가질 수 있습니다. 리소스 공유 없이 각 계정에 개별 생성하면 어떻게 될까요?

먼저 관리 포인트가 늘어납니다. Transit Gateway를 5개 계정에 만들면 5번 설정하고 5번 관리해야 합니다.

또한 비용 낭비가 발생합니다. 같은 리소스를 중복으로 만들면 그만큼 비용이 배로 듭니다.

더 큰 문제는 일관성입니다. 각 계정의 설정이 조금씩 달라지면 나중에 통합하거나 문제를 해결하기 어렵습니다.

바로 이런 문제를 해결하기 위해 AWS RAM이 등장했습니다. RAM을 사용하면 중복 리소스 생성을 방지할 수 있습니다.

또한 관리가 중앙화되어 효율성이 높아집니다. 무엇보다 비용을 절감할 수 있다는 큰 이점이 있습니다.

공유 가능한 리소스는 다양합니다. VPC Subnet, Transit Gateway, Route53 Resolver Rules, License Manager 설정 등이 대표적입니다.

특히 네트워크 리소스 공유가 가장 많이 활용됩니다. 위의 코드를 한 줄씩 살펴보겠습니다.

먼저 RAM 클라이언트를 생성합니다. create_resource_share로 공유를 만드는데, resourceArns에 공유할 리소스의 ARN을 지정합니다.

principals에는 공유 대상을 지정하는데, 조직 ARN을 넣으면 조직 내 모든 계정이 사용할 수 있습니다. allowExternalPrincipals를 False로 설정하면 조직 외부와는 공유되지 않아 안전합니다.

실제 현업에서는 어떻게 활용할까요? 예를 들어 MSA 아키텍처를 운영하는 회사라면 각 마이크로서비스를 별도 계정으로 분리합니다.

하지만 모든 서비스가 같은 VPC에 있어야 통신이 쉽습니다. 이럴 때 네트워크 계정에서 VPC Subnet을 만들고 RAM으로 공유하면, 각 서비스 계정에서 해당 Subnet에 리소스를 배치할 수 있습니다.

많은 클라우드 네이티브 기업에서 이런 패턴을 사용하고 있습니다. RAM의 또 다른 장점은 권한 관리의 간소화입니다.

리소스를 공유받은 계정은 해당 리소스에 대한 읽기 권한은 자동으로 얻지만, 수정이나 삭제는 할 수 없습니다. 이렇게 하면 실수로 중요한 리소스를 삭제하는 사고를 예방할 수 있습니다.

하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 모든 리소스를 공유하려는 것입니다.

공유는 필요한 경우에만 해야 합니다. 예를 들어 데이터베이스는 보안상 공유하지 않는 것이 좋습니다.

따라서 공유할 리소스를 선택할 때는 보안과 관리 효율성을 모두 고려해야 합니다. 또한 공유 범위를 신중히 설정해야 합니다.

전체 조직과 공유할 것인지, 특정 OU만 공유할 것인지를 명확히 결정하세요. 개발 환경 리소스는 개발 OU에만 공유하고, 프로덕션 리소스는 프로덕션 OU에만 공유하는 식으로 분리하는 것이 안전합니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. RAM으로 Transit Gateway를 공유한 후 김개발 씨는 감탄했습니다.

"이제 각 계정에서 중복으로 만들 필요가 없네요!" 계정 간 리소스 공유를 제대로 활용하면 인프라 관리가 단순해지고, 비용도 절감할 수 있습니다. 여러분도 공유 가능한 리소스를 찾아서 RAM으로 구성해 보세요.

실전 팁

💡 - 네트워크 리소스(Subnet, Transit Gateway)부터 공유를 시작하세요

RAM 공유 시 태그를 잘 활용하면 어떤 리소스가 공유 중인지 쉽게 파악할 수 있습니다
공유받은 계정에서는 리소스를 수정할 수 없으니, 변경이 필요하면 소유 계정에 요청하세요

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

#AWS#Organizations#SCP#OU#ConsolidatedBilling

AWS Organizations 완벽 가이드

# AWS Organizations 완벽 가이드 여러 AWS 계정을 체계적으로 관리하고 통합 결제와 보안 정책을 적용하는 방법을 실무 스토리로 쉽게 배워봅니다. 초보 개발자도 바로 이해할 수 있는 친절한 설명과 실전 예제를 제공합니다. --- ## 목차 1. [Organizations란?](#organizations란?) 2. [조직 구조 설계](#조직-구조-설계) 3. [OU 생성하기](#ou-생성하기) 4. [SCP 정책](#scp-정책) 5. [통합 결제](#통합-결제) 6. [계정 간 리소스 공유](#계정-간-리소스-공유) --- ## 1. Organizations란? 김개발 씨는 스타트업에서 일하는 3년 차 개발자입니다. 회사가 성장하면서 개발, 운영, 테스트용으로 AWS 계정이 하나씩 늘어났습니다. 어느 날 CTO님이 물었습니다. "계정이 10개인데 관리가 너무 복잡하지 않나요?" **AWS Organizations**는 한마디로 여러 AWS 계정을 하나의 조직으로 묶어서 중앙에서 관리하는 서비스입니다. 마치 여러 지점을 가진 회사가 본사에서 통합 관리하는 것과 같습니다. 이것을 제대로 이해하면 계정 관리, 비용 절감, 보안 정책 통합을 한 번에 해결할 수 있습니다. 다음 코드를 살펴봅시다. ```python import boto3 # AWS Organizations 클라이언트 생성 org_client = boto3.client('organizations') # 새로운 조직 생성 response = org_client.create_organization( FeatureSet='ALL' # 모든 기능 활성화 ) # 조직 정보 확인 org_id = response['Organization']['Id'] master_account = response['Organization']['MasterAccountId'] print(f"조직 ID: {org_id}") print(f"마스터 계정: {master_account}") # 이제 조직이 생성되었습니다! ``` 김개발 씨는 요즘 고민이 많았습니다. 회사의 AWS 계정이 개발용, 스테이징용, 프로덕션용으로 나뉘어 있는데 각각 따로 관리하다 보니 여간 번거로운 게 아니었습니다. 매달 청구서도 따로따로 오고, 보안 설정도 계정마다 다시 해야 했습니다. 팀장님께서 이런 고민을 들으시더니 말씀하셨습니다. "AWS Organizations를 써보는 게 어때요?" 그렇다면 **AWS Organizations**란 정확히 무엇일까요? 쉽게 비유하자면, AWS Organizations는 마치 대기업의 본사와 지점 구조와 같습니다. 본사에서 전체 지점을 관리하고, 각 지점에 예산을 배정하고, 공통 규칙을 적용하는 것처럼, Organizations도 여러 AWS 계정을 하나의 조직으로 묶어서 중앙에서 관리합니다. Organizations가 없던 시절에는 어땠을까요? 개발자들은 각 AWS 계정에 로그인해서 보안 설정을 일일이 확인해야 했습니다. 계정이 5개만 되어도 같은 작업을 5번 반복해야 했습니다. 더 큰 문제는 비용 관리였습니다. 각 계정의 청구서를 하나하나 확인하고, 엑셀로 정리해서 전체 비용을 계산해야 했습니다. 프로젝트가 커질수록 이런 문제는 눈덩이처럼 불어났습니다. 바로 이런 문제를 해결하기 위해 **AWS Organizations**가 등장했습니다. Organizations를 사용하면 **통합 결제**가 가능해집니다. 모든 계정의 사용량을 합산해서 하나의 청구서로 받을 수 있습니다. 또한 **보안 정책을 중앙에서 관리**할 수 있습니다. 무엇보다 **계정을 논리적으로 그룹화**할 수 있어서 조직 구조에 맞게 체계적으로 관리할 수 있다는 큰 이점이 있습니다. 위의 코드를 한 줄씩 살펴보겠습니다. 먼저 boto3 라이브러리로 Organizations 클라이언트를 생성합니다. 이 부분이 핵심입니다. 다음으로 create_organization 메서드를 호출하는데, FeatureSet을 'ALL'로 설정하면 모든 Organizations 기능을 사용할 수 있습니다. 마지막으로 생성된 조직의 ID와 마스터 계정 정보가 반환됩니다. 실제 현업에서는 어떻게 활용할까요? 예를 들어 이커머스 회사를 운영한다고 가정해봅시다. 개발 팀, 데이터 팀, 운영 팀이 각각 별도의 AWS 계정을 사용하는데 Organizations로 묶으면 CTO는 한눈에 전체 계정을 파악할 수 있습니다. 많은 스타트업과 대기업에서 이런 패턴을 적극적으로 사용하고 있습니다. 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 조직을 생성한 후 **마스터 계정을 일반 업무에 사용하는 것**입니다. 이렇게 하면 보안 위험이 높아지고 관리가 복잡해질 수 있습니다. 따라서 마스터 계정은 순수하게 조직 관리 용도로만 사용하고, 실제 리소스는 멤버 계정에서 생성해야 합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. 팀장님의 조언을 들은 김개발 씨는 AWS Organizations를 공부하기 시작했습니다. "아, 이렇게 편리한 기능이 있었군요!" AWS Organizations를 제대로 이해하면 더 체계적이고 안전하게 다중 계정 환경을 관리할 수 있습니다. 여러분도 오늘 배운 내용을 실제 프로젝트에 적용해 보세요. **실전 팁** 💡 - 마스터 계정(현재는 관리 계정이라고 부름)은 순수하게 조직 관리용으로만 사용하세요 - 조직 생성 시 FeatureSet을 'ALL'로 설정하면 SCP 등 고급 기능을 사용할 수 있습니다 - 계정 간 이동 시 AWS SSO를 함께 활용하면 로그인 편의성이 크게 향상됩니다 --- ## 2. 조직 구조 설계 Organizations를 만들었다면 이제 어떻게 구조를 잡아야 할까요? 김개발 씨는 계정이 10개나 되는데 이것을 어떻게 분류해야 할지 막막했습니다. 선배 박시니어 씨가 화이트보드를 꺼내며 말했습니다. "조직 구조를 먼저 설계해야 해요." **조직 구조**란 AWS 계정들을 논리적으로 그룹화하는 방법입니다. 마치 회사의 조직도처럼 부서별, 프로젝트별, 환경별로 계정을 분류합니다. 올바른 구조 설계는 향후 관리 효율성과 보안 정책 적용의 핵심입니다. 다음 코드를 살펴봅시다. ```python import boto3 org_client = boto3.client('organizations') # 루트 OU 아래에 환경별 OU 생성 production_ou = org_client.create_organizational_unit( ParentId='r-xxxx', # 루트 ID Name='Production' ) development_ou = org_client.create_organizational_unit( ParentId='r-xxxx', Name='Development' ) # OU 구조 확인 print(f"프로덕션 OU: {production_ou['OrganizationalUnit']['Id']}") print(f"개발 OU: {development_ou['OrganizationalUnit']['Id']}") # 이제 계정을 OU별로 분류할 수 있습니다 ``` 김개발 씨는 화이트보드 앞에 섰습니다. 박시니어 씨가 그림을 그리기 시작했습니다. "보세요, 우리 회사 계정들을 이렇게 나눠볼 수 있어요." 조직 구조를 설계한다는 것은 무슨 의미일까요? 쉽게 비유하자면, 조직 구조는 마치 도서관의 분류 체계와 같습니다. 도서관에서 책을 문학, 과학, 역사로 나누고 다시 세부 카테고리로 나누듯이, AWS 계정도 목적에 따라 계층적으로 분류합니다. 이렇게 하면 필요한 계정을 빠르게 찾고, 비슷한 성격의 계정들에 같은 정책을 적용할 수 있습니다. 조직 구조를 제대로 설계하지 않으면 어떻게 될까요? 계정 수가 늘어날수록 관리가 혼란스러워집니다. "이 계정이 뭐에 쓰는 계정이었지?"라는 질문을 매번 하게 됩니다. 보안 정책을 적용할 때도 각 계정의 용도를 일일이 확인해야 합니다. 더 큰 문제는 실수로 프로덕션 계정에 개발용 설정을 적용하는 등의 사고가 발생할 수 있다는 점입니다. 바로 이런 문제를 해결하기 위해 **조직 구조 설계**가 필요합니다. 조직 구조를 잘 설계하면 **계정의 용도를 명확히 구분**할 수 있습니다. 또한 **정책 관리가 쉬워집니다**. 무엇보다 **신규 계정 추가 시 어디에 배치할지 명확**하다는 큰 이점이 있습니다. 일반적으로 많이 사용하는 구조 패턴이 있습니다. 첫 번째는 **환경별 분류**입니다. Production, Staging, Development처럼 배포 환경에 따라 나눕니다. 두 번째는 **부서별 분류**입니다. Engineering, Marketing, Data처럼 조직 구조에 따라 나눕니다. 세 번째는 **프로젝트별 분류**입니다. ProjectA, ProjectB처럼 프로젝트 단위로 나눕니다. 위의 코드를 한 줄씩 살펴보겠습니다. 먼저 create_organizational_unit 메서드로 OU를 생성합니다. ParentId는 상위 OU의 ID인데, 루트 바로 아래에 만들 때는 루트 ID를 사용합니다. Name으로 OU 이름을 지정하면 계층 구조가 만들어집니다. 이렇게 Production과 Development OU를 분리하면 환경별로 명확하게 구분할 수 있습니다. 실제 현업에서는 어떻게 활용할까요? 예를 들어 금융 서비스 회사라면 규제 준수가 중요합니다. Production OU에는 엄격한 보안 정책을, Development OU에는 좀 더 유연한 정책을 적용할 수 있습니다. 많은 기업에서 환경별 분리를 가장 기본적인 구조로 사용하고 있습니다. 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 **너무 복잡한 계층 구조를 만드는 것**입니다. OU를 5단계, 6단계로 깊게 만들면 관리가 오히려 복잡해집니다. 따라서 2~3단계 정도의 간단한 구조로 시작하는 것이 좋습니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 설명을 들은 김개발 씨는 화이트보드의 조직도를 이해했습니다. "아, 이렇게 환경별로 나누면 되겠네요!" 조직 구조를 제대로 설계하면 향후 수백 개의 계정을 관리하더라도 혼란 없이 운영할 수 있습니다. 여러분도 회사의 상황에 맞는 구조를 고민해 보세요. **실전 팁** 💡 - 처음에는 간단하게 2~3단계 구조로 시작하고, 필요에 따라 확장하세요 - 환경별 분류(Prod/Dev/Staging)가 가장 보편적이고 안전한 접근법입니다 - OU 이름은 명확하고 일관성 있게 지어야 나중에 혼란이 없습니다 --- ## 3. OU 생성하기 조직 구조 설계가 끝났다면 이제 실제로 OU를 만들어야 합니다. 김개발 씨는 콘솔을 열고 OU 생성 버튼을 찾았지만, 막상 어떤 순서로 만들어야 할지 고민되었습니다. "일단 만들고 나중에 옮기면 되지 않을까요?" 박시니어 씨가 고개를 저었습니다. **OU 생성**은 계층 구조를 실제로 구현하는 작업입니다. 마치 폴더를 만들듯이 OU를 생성하고, 계정을 그 안에 배치합니다. 처음부터 체계적으로 만들어야 나중에 재작업하는 수고를 덜 수 있습니다. 다음 코드를 살펴봅시다. ```python import boto3 org_client = boto3.client('organizations') # 루트 ID 조회 roots = org_client.list_roots() root_id = roots['Roots'][0]['Id'] # Workloads OU 생성 (1단계) workloads_ou = org_client.create_organizational_unit( ParentId=root_id, Name='Workloads' ) workloads_id = workloads_ou['OrganizationalUnit']['Id'] # Production OU 생성 (2단계 - Workloads 아래) prod_ou = org_client.create_organizational_unit( ParentId=workloads_id, # 부모를 Workloads로 지정 Name='Production' ) print(f"생성 완료: {prod_ou['OrganizationalUnit']['Name']}") ``` 김개발 씨는 실제 작업에 들어가기 전에 한 가지 의문이 들었습니다. "OU를 만드는 건 간단해 보이는데, 왜 미리 계획이 필요하다는 걸까요?" 박시니어 씨가 예전 경험담을 들려주었습니다. "제가 전 회사에서 OU를 아무 계획 없이 막 만들었다가 나중에 다 엎은 적이 있어요. 계정을 다른 OU로 옮기는 것도 번거롭고, 정책 상속 관계도 꼬여서 고생했죠." **OU 생성**이란 정확히 무엇일까요? 쉽게 비유하자면, OU 생성은 마치 컴퓨터에서 폴더를 만드는 것과 같습니다. 상위 폴더를 만들고 그 아래 하위 폴더를 만들어서 파일을 분류하듯이, OU도 계층적으로 만들어서 계정을 분류합니다. 다만 일반 폴더와 다른 점은 OU에 정책을 연결하면 그 아래의 모든 계정에 자동으로 적용된다는 점입니다. OU를 체계 없이 만들면 어떻게 될까요? 처음에는 문제가 없어 보입니다. 하지만 시간이 지나면서 계정 수가 늘어나면 "이 계정이 어느 OU에 있었지?"라는 질문을 반복하게 됩니다. 더 큰 문제는 정책 관리입니다. OU 구조가 엉망이면 어떤 정책이 어느 계정에 적용되는지 파악하기 어렵습니다. 잘못된 OU에 엄격한 정책을 적용해서 개발 작업이 막히는 사고도 발생할 수 있습니다. 바로 이런 문제를 해결하기 위해 **체계적인 OU 생성**이 필요합니다. OU를 체계적으로 만들면 **계정의 위치를 직관적으로 파악**할 수 있습니다. 또한 **정책 적용 범위가 명확**해집니다. 무엇보다 **신규 계정 추가 시 어디에 넣을지 고민할 필요가 없다**는 큰 이점이 있습니다. 위의 코드를 한 줄씩 살펴보겠습니다. 먼저 list_roots로 조직의 루트 ID를 조회합니다. 모든 OU는 루트 아래에 생성되므로 루트 ID가 필요합니다. 다음으로 Workloads라는 1단계 OU를 루트 아래에 생성합니다. 마지막으로 Production OU를 Workloads의 하위로 생성하는데, ParentId를 Workloads의 ID로 지정하면 계층 관계가 만들어집니다. 실제 현업에서는 어떻게 활용할까요? 예를 들어 글로벌 서비스를 운영하는 회사라면 지역별로 OU를 나눌 수 있습니다. Asia OU 아래에 Korea, Japan OU를 만들고, 각 국가의 계정을 배치합니다. 이렇게 하면 지역별 규제에 맞는 정책을 효율적으로 적용할 수 있습니다. 많은 다국적 기업에서 이런 지역별 구조를 사용하고 있습니다. 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 **OU 이름을 막연하게 짓는 것**입니다. "Test", "Misc", "Others" 같은 이름을 쓰면 나중에 용도를 파악하기 어렵습니다. 따라서 OU 이름은 명확하고 구체적으로 지어야 합니다. "Dev-Frontend", "Prod-Backend"처럼 목적이 드러나는 이름이 좋습니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 조언을 들은 김개발 씨는 화이트보드의 설계도를 보며 하나씩 OU를 만들기 시작했습니다. "계획대로 차근차근 만드니까 헷갈리지 않네요!" OU 생성은 한 번 제대로 해두면 향후 수년간 안정적으로 사용할 수 있는 기반이 됩니다. 여러분도 서두르지 말고 설계도를 그린 후 체계적으로 만들어 보세요. **실전 팁** 💡 - OU 생성 전에 반드시 구조도를 그려보세요 (화이트보드나 문서로) - OU 이름은 회사 전체가 이해할 수 있는 명확한 용어를 사용하세요 - 처음부터 완벽할 필요는 없습니다. 기본 구조를 만들고 필요에 따라 확장하세요 --- ## 4. SCP 정책 OU 구조가 완성되자 박시니어 씨가 말했습니다. "이제 보안 정책을 적용해야 해요." 김개발 씨는 IAM 정책을 떠올렸지만, 박시니어 씨가 말하는 것은 **SCP**라는 다른 개념이었습니다. "SCP는 IAM보다 상위 레벨의 가드레일이에요." **SCP(Service Control Policy)**는 조직 내 계정들이 수행할 수 있는 작업의 최대 범위를 제한하는 정책입니다. 마치 아파트 관리규칙처럼 각 세대가 할 수 있는 행동의 경계를 정합니다. IAM 정책이 허용하더라도 SCP가 거부하면 작업이 차단됩니다. 다음 코드를 살펴봅시다. ```python import boto3 import json org_client = boto3.client('organizations') # 특정 리전만 허용하는 SCP 정책 region_restriction_policy = { "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": "*", "Resource": "*", "Condition": { "StringNotEquals": { "aws:RequestedRegion": ["ap-northeast-2", "us-east-1"] } } } ] } # SCP 정책 생성 response = org_client.create_policy( Content=json.dumps(region_restriction_policy), Description='Only allow Seoul and Virginia regions', Name='RegionRestriction', Type='SERVICE_CONTROL_POLICY' ) print(f"정책 생성 완료: {response['Policy']['PolicySummary']['Id']}") ``` 김개발 씨는 IAM 정책은 익숙했지만 SCP는 처음 들어봤습니다. "IAM 정책으로 권한을 관리하는데 SCP는 왜 필요한 거죠?" 박시니어 씨가 실제 사례를 들려주었습니다. "예전에 우리 회사에서 개발자 한 명이 실수로 미국 리전에 EC2를 띄웠어요. 비용도 비용이지만 데이터 주권 문제가 생겼죠. IAM으로는 개발자마다 설정해야 하는데 SCP를 쓰면 조직 전체에 한 번에 적용할 수 있어요." **SCP**란 정확히 무엇일까요? 쉽게 비유하자면, SCP는 마치 건물의 출입 통제 시스템과 같습니다. 건물 관리자가 "이 건물에서는 밤 10시 이후 출입 금지"라는 규칙을 정하면, 개별 사무실의 열쇠가 있어도 그 시간에는 들어갈 수 없습니다. 마찬가지로 SCP가 특정 작업을 거부하면, IAM 권한이 있어도 그 작업을 수행할 수 없습니다. SCP 없이 IAM만으로 관리하면 어떻게 될까요? 각 계정의 모든 사용자와 역할에 일일이 정책을 적용해야 합니다. 계정이 10개고 각 계정에 사용자가 10명이면 100번의 설정이 필요합니다. 더 큰 문제는 일관성입니다. 누군가 실수로 정책을 빼먹으면 보안 구멍이 생깁니다. 신규 입사자가 들어올 때마다 정책 적용을 잊지 않아야 하는 부담도 있습니다. 바로 이런 문제를 해결하기 위해 **SCP**가 등장했습니다. SCP를 사용하면 **조직 전체에 일관된 보안 기준**을 적용할 수 있습니다. 또한 **실수로 인한 보안 사고를 예방**할 수 있습니다. 무엇보다 **관리 포인트가 줄어들어** 운영 효율성이 크게 향상됩니다. 위의 코드를 한 줄씩 살펴보겠습니다. 먼저 정책 문서를 JSON 형태로 작성합니다. Effect는 Deny, Action은 모든 작업, Resource는 모든 리소스를 의미합니다. 핵심은 Condition 부분인데, aws:RequestedRegion이 서울과 버지니아가 아니면 거부한다는 뜻입니다. create_policy로 이 정책을 생성하면 OU에 연결할 수 있습니다. Type을 SERVICE_CONTROL_POLICY로 지정하는 것이 중요합니다. 실제 현업에서는 어떻게 활용할까요? 예를 들어 금융권 회사라면 개인정보보호법 준수가 필수입니다. S3 버킷을 퍼블릭으로 열지 못하게 하는 SCP를 적용하면 개발자가 실수로 데이터를 노출하는 사고를 원천 차단할 수 있습니다. 많은 대기업에서 컴플라이언스 준수를 위해 SCP를 적극 활용하고 있습니다. 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 **너무 엄격한 SCP를 적용해서 정상 업무를 막는 것**입니다. 예를 들어 모든 EC2 생성을 차단하면 개발 작업 자체가 불가능해집니다. 따라서 SCP는 꼭 필요한 제약만 걸고, 나머지는 IAM으로 세밀하게 관리하는 것이 좋습니다. SCP의 또 다른 중요한 특징은 **상속**입니다. OU에 SCP를 연결하면 그 아래의 모든 하위 OU와 계정에 자동으로 적용됩니다. 이것이 SCP의 가장 강력한 점이자 조심해야 할 점입니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 설명을 들은 김개발 씨는 SCP의 위력을 이해했습니다. "아, 조직 전체를 한 번에 보호할 수 있는 안전장치군요!" SCP를 제대로 활용하면 보안 사고를 사전에 예방하고, 규정 준수를 자동화할 수 있습니다. 여러분도 회사의 보안 요구사항을 SCP로 구현해 보세요. **실전 팁** 💡 - SCP는 Deny 정책부터 시작하세요. Allow보다 관리가 쉽습니다 - 테스트 OU를 만들어서 먼저 적용해보고, 문제 없으면 전체에 적용하세요 - FullAWSAccess SCP가 기본으로 연결되어 있으니, 제거 시 주의하세요 --- ## 5. 통합 결제 OU와 SCP 설정이 끝나자 김개발 씨는 경리팀에서 연락이 왔습니다. "계정 10개의 청구서를 일일이 확인하기 힘들어요." 박시니어 씨가 웃으며 말했습니다. "Organizations의 가장 큰 장점 중 하나가 바로 통합 결제예요." **통합 결제**는 조직 내 모든 계정의 사용량을 합산해서 하나의 청구서로 받는 기능입니다. 마치 가족 요금제처럼 사용량을 모아서 할인도 받고, 관리도 간편해집니다. Organizations를 만들면 자동으로 활성화됩니다. 다음 코드를 살펴봅시다. ```python import boto3 from datetime import datetime, timedelta # Cost Explorer로 통합 결제 정보 조회 ce_client = boto3.client('ce') # 지난 달 비용 조회 end_date = datetime.now().strftime('%Y-%m-%d') start_date = (datetime.now() - timedelta(days=30)).strftime('%Y-%m-%d') response = ce_client.get_cost_and_usage( TimePeriod={ 'Start': start_date, 'End': end_date }, Granularity='MONTHLY', Metrics=['UnblendedCost'], GroupBy=[ {'Type': 'DIMENSION', 'Key': 'LINKED_ACCOUNT'} ] ) # 계정별 비용 출력 for result in response['ResultsByTime']: for group in result['Groups']: account = group['Keys'][0] cost = group['Metrics']['UnblendedCost']['Amount'] print(f"계정 {account}: ${float(cost):.2f}") ``` 김개발 씨는 매달 초면 경리팀에서 요청이 들어왔습니다. "이번 달 AWS 비용 정리 좀 해주세요." 그럴 때마다 10개 계정에 각각 로그인해서 청구서를 다운로드하고, 엑셀로 합산하는 작업이 한나절이 걸렸습니다. 박시니어 씨가 이런 고충을 듣고 말했습니다. "Organizations를 쓰면 그럴 필요가 없어요. 통합 결제가 자동으로 되거든요." **통합 결제**란 정확히 무엇일까요? 쉽게 비유하자면, 통합 결제는 마치 가족 휴대폰 요금제와 같습니다. 가족 구성원 각자의 사용량을 합쳐서 한 장의 청구서로 받고, 합산 할인도 받습니다. 마찬가지로 Organizations도 모든 멤버 계정의 AWS 사용량을 합산해서 관리 계정으로 청구서가 옵니다. 통합 결제가 없다면 어떻게 될까요? 각 계정마다 별도의 청구서가 발행됩니다. 경리 담당자는 계정 수만큼 신용카드를 관리해야 하고, 매달 청구서를 하나하나 확인해야 합니다. 더 큰 문제는 할인 혜택을 놓치는 것입니다. 예를 들어 Reserved Instance는 사용량이 많을수록 할인율이 높은데, 계정이 분리되면 이 혜택을 제대로 받을 수 없습니다. 바로 이런 문제를 해결하기 위해 **통합 결제**가 등장했습니다. 통합 결제를 사용하면 **하나의 청구서로 모든 계정을 관리**할 수 있습니다. 또한 **사용량 합산으로 할인 혜택**을 극대화할 수 있습니다. 무엇보다 **비용 추적과 분석이 쉬워진다**는 큰 이점이 있습니다. 위의 코드를 한 줄씩 살펴보겠습니다. 먼저 Cost Explorer 클라이언트를 생성합니다. get_cost_and_usage 메서드로 지난 30일간의 비용을 조회하는데, GroupBy로 LINKED_ACCOUNT를 지정하면 멤버 계정별로 비용이 구분됩니다. UnblendedCost는 할인 전 실제 사용 비용을 의미합니다. 이렇게 하면 어느 계정에서 얼마를 썼는지 한눈에 파악할 수 있습니다. 실제 현업에서는 어떻게 활용할까요? 예를 들어 여러 프로젝트를 동시에 진행하는 회사라면 프로젝트별로 계정을 분리합니다. 통합 결제를 사용하면 전체 비용은 한 번에 내되, Cost Explorer로 프로젝트별 비용을 추적할 수 있습니다. 재무팀은 한 장의 청구서만 확인하면 되고, 프로젝트 매니저는 자기 프로젝트 비용을 실시간으로 모니터링할 수 있습니다. 통합 결제의 또 다른 장점은 **예약 인스턴스와 Savings Plans의 공유**입니다. 한 계정에서 구매한 예약 인스턴스를 다른 계정에서도 사용할 수 있습니다. 이렇게 하면 리소스 활용률을 높이고 비용을 절감할 수 있습니다. 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 **비용 알림을 관리 계정에만 설정하는 것**입니다. 각 멤버 계정에서도 비용 알림을 설정해두면 팀별로 예산을 초과하지 않도록 관리할 수 있습니다. 따라서 CloudWatch와 SNS를 활용해서 계정별 비용 알림을 구성하는 것이 좋습니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. 통합 결제를 설정한 후 김개발 씨는 경리팀에서 감사 인사를 받았습니다. "이제 청구서 하나만 확인하면 되니 정말 편해졌어요!" 통합 결제를 제대로 활용하면 재무 관리가 단순해지고, 비용 절감 효과도 얻을 수 있습니다. 여러분도 Cost Explorer를 활용해서 비용을 분석해 보세요. **실전 팁** 💡 - Cost Explorer에서 태그 기반 비용 분석을 활성화하면 더욱 세밀한 추적이 가능합니다 - 예산(Budget)을 설정해서 비용이 임계값을 넘으면 자동 알림을 받으세요 - Reserved Instance는 조직 전체에서 공유되므로, 구매 전에 전체 사용량을 분석하세요 --- ## 6. 계정 간 리소스 공유 통합 결제로 비용 문제는 해결되었지만, 김개발 씨는 또 다른 고민이 생겼습니다. "개발 계정과 프로덕션 계정에서 같은 VPC를 써야 하는데 어떻게 하죠?" 박시니어 씨가 답했습니다. "AWS RAM을 사용하면 리소스를 공유할 수 있어요." **계정 간 리소스 공유**는 한 계정의 리소스를 다른 계정에서 사용할 수 있게 하는 기능입니다. 마치 회사 차량을 여러 부서가 공유하듯이, VPC, Subnet, Transit Gateway 같은 리소스를 조직 내에서 공유합니다. AWS RAM(Resource Access Manager)을 사용합니다. 다음 코드를 살펴봅시다. ```python import boto3 ram_client = boto3.client('ram') # Transit Gateway를 조직과 공유 response = ram_client.create_resource_share( name='SharedTransitGateway', resourceArns=[ 'arn:aws:ec2:ap-northeast-2:123456789012:transit-gateway/tgw-xxxxx' ], principals=[ 'arn:aws:organizations::123456789012:organization/o-xxxxx' ], allowExternalPrincipals=False, # 조직 내부만 공유 tags=[ {'key': 'Environment', 'value': 'Shared'} ] ) print(f"리소스 공유 생성: {response['resourceShare']['name']}") print(f"상태: {response['resourceShare']['status']}") # 이제 조직 내 모든 계정에서 Transit Gateway 사용 가능 ``` 김개발 씨는 네트워크 설계를 하다가 딜레마에 빠졌습니다. 개발 환경과 프로덕션 환경을 완전히 분리해야 하는데, 공통으로 사용해야 하는 네트워크 리소스가 있었습니다. "각 계정에 똑같은 걸 만들어야 하나요?" 박시니어 씨가 고개를 저었습니다. "그럴 필요 없어요. 한 계정에서 만들고 공유하면 됩니다. AWS RAM이라는 서비스가 있거든요." **계정 간 리소스 공유**란 정확히 무엇일까요? 쉽게 비유하자면, 리소스 공유는 마치 사무실 공용 프린터와 같습니다. 각 팀이 프린터를 따로 살 필요 없이 하나를 공유해서 사용하는 것처럼, AWS 리소스도 한 계정에서 생성하고 여러 계정이 공유할 수 있습니다. 소유권은 원래 계정에 있지만, 사용 권한은 다른 계정도 가질 수 있습니다. 리소스 공유 없이 각 계정에 개별 생성하면 어떻게 될까요? 먼저 관리 포인트가 늘어납니다. Transit Gateway를 5개 계정에 만들면 5번 설정하고 5번 관리해야 합니다. 또한 비용 낭비가 발생합니다. 같은 리소스를 중복으로 만들면 그만큼 비용이 배로 듭니다. 더 큰 문제는 일관성입니다. 각 계정의 설정이 조금씩 달라지면 나중에 통합하거나 문제를 해결하기 어렵습니다. 바로 이런 문제를 해결하기 위해 **AWS RAM**이 등장했습니다. RAM을 사용하면 **중복 리소스 생성을 방지**할 수 있습니다. 또한 **관리가 중앙화**되어 효율성이 높아집니다. 무엇보다 **비용을 절감**할 수 있다는 큰 이점이 있습니다. 공유 가능한 리소스는 다양합니다. **VPC Subnet**, **Transit Gateway**, **Route53 Resolver Rules**, **License Manager 설정** 등이 대표적입니다. 특히 네트워크 리소스 공유가 가장 많이 활용됩니다. 위의 코드를 한 줄씩 살펴보겠습니다. 먼저 RAM 클라이언트를 생성합니다. create_resource_share로 공유를 만드는데, resourceArns에 공유할 리소스의 ARN을 지정합니다. principals에는 공유 대상을 지정하는데, 조직 ARN을 넣으면 조직 내 모든 계정이 사용할 수 있습니다. allowExternalPrincipals를 False로 설정하면 조직 외부와는 공유되지 않아 안전합니다. 실제 현업에서는 어떻게 활용할까요? 예를 들어 MSA 아키텍처를 운영하는 회사라면 각 마이크로서비스를 별도 계정으로 분리합니다. 하지만 모든 서비스가 같은 VPC에 있어야 통신이 쉽습니다. 이럴 때 네트워크 계정에서 VPC Subnet을 만들고 RAM으로 공유하면, 각 서비스 계정에서 해당 Subnet에 리소스를 배치할 수 있습니다. 많은 클라우드 네이티브 기업에서 이런 패턴을 사용하고 있습니다. RAM의 또 다른 장점은 **권한 관리의 간소화**입니다. 리소스를 공유받은 계정은 해당 리소스에 대한 읽기 권한은 자동으로 얻지만, 수정이나 삭제는 할 수 없습니다. 이렇게 하면 실수로 중요한 리소스를 삭제하는 사고를 예방할 수 있습니다. 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 **모든 리소스를 공유하려는 것**입니다. 공유는 필요한 경우에만 해야 합니다. 예를 들어 데이터베이스는 보안상 공유하지 않는 것이 좋습니다. 따라서 공유할 리소스를 선택할 때는 보안과 관리 효율성을 모두 고려해야 합니다. 또한 **공유 범위를 신중히 설정**해야 합니다. 전체 조직과 공유할 것인지, 특정 OU만 공유할 것인지를 명확히 결정하세요. 개발 환경 리소스는 개발 OU에만 공유하고, 프로덕션 리소스는 프로덕션 OU에만 공유하는 식으로 분리하는 것이 안전합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. RAM으로 Transit Gateway를 공유한 후 김개발 씨는 감탄했습니다. "이제 각 계정에서 중복으로 만들 필요가 없네요!" 계정 간 리소스 공유를 제대로 활용하면 인프라 관리가 단순해지고, 비용도 절감할 수 있습니다. 여러분도 공유 가능한 리소스를 찾아서 RAM으로 구성해 보세요. **실전 팁** 💡 - 네트워크 리소스(Subnet, Transit Gateway)부터 공유를 시작하세요 - RAM 공유 시 태그를 잘 활용하면 어떤 리소스가 공유 중인지 쉽게 파악할 수 있습니다 - 공유받은 계정에서는 리소스를 수정할 수 없으니, 변경이 필요하면 소유 계정에 요청하세요 --- 이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

카테고리: AWS

언어: Python

태그: AWS, Organizations, SCP, OU, ConsolidatedBilling

작성자: AI Generated

프리미엄 콘텐츠 - 3개월 무료 체험 가능

CodeDeck

AWS Organizations 완벽 가이드

목차

1. Organizations란?

2. 조직 구조 설계

3. OU 생성하기

4. SCP 정책

5. 통합 결제

6. 계정 간 리소스 공유

댓글 (0)

함께 보면 좋은 카드 뉴스

Helm 마이크로서비스 패키징 완벽 가이드

보안 아키텍처 구성 완벽 가이드

AWS KMS 암호화 완벽 가이드

AWS Secrets Manager 완벽 가이드

AWS WAF 웹 방화벽 완벽 가이드