AWS Organizations로 멀티 계정 거버넌스 구축

AWS Organizations를 활용하여 여러 AWS 계정을 효율적으로 관리하고 보안 정책을 일관성 있게 적용하는 방법을 알아봅니다. 초급 개발자도 쉽게 이해할 수 있도록 실무 사례와 함께 설명합니다.

---

목차

1. 멀티_계정_전략의_필요성
2. Organizations_OU_구조_설계
3. 통합_결제_Consolidated_Billing
4. Service_Control_Policies_SCP
5. 계정_간_리소스_공유_RAM
6. Control_Tower로_Landing_Zone_구성

---

1. 멀티 계정 전략의 필요성

스타트업에서 일하는 김개발 씨는 어느 날 팀장님으로부터 뜻밖의 이야기를 들었습니다. "우리 회사 AWS 계정이 하나인데, 개발 환경이랑 운영 환경이 섞여서 큰일 날 뻔했어요." 실제로 개발자가 실수로 운영 데이터베이스를 삭제할 뻔한 아찔한 상황이 있었다고 합니다.

멀티 계정 전략은 하나의 AWS 계정에 모든 리소스를 넣는 대신, 목적별로 여러 계정을 분리하여 운영하는 방식입니다. 마치 아파트에서 각 세대가 독립된 공간을 가지는 것처럼, 각 계정은 완전히 격리된 환경을 제공합니다.

이를 통해 보안 사고의 영향 범위를 최소화하고, 비용을 명확하게 추적할 수 있습니다.

다음 코드를 살펴봅시다.

// AWS Organizations 계정 구조 예시 (TypeScript CDK)
import * as organizations from 'aws-cdk-lib/aws-organizations';

// 관리 계정에서 새 계정 생성
const devAccount = new organizations.CfnAccount(this, 'DevAccount', {
  accountName: 'company-development',
  email: 'aws-dev@company.com',
  // 개발 환경 OU에 배치
  parentIds: ['ou-xxxx-development'],
});

const prodAccount = new organizations.CfnAccount(this, 'ProdAccount', {
  accountName: 'company-production',
  email: 'aws-prod@company.com',
  // 운영 환경 OU에 배치 - 더 엄격한 정책 적용
  parentIds: ['ou-xxxx-production'],
});

김개발 씨가 다니는 회사는 급성장 중인 스타트업입니다. 처음에는 AWS 계정 하나로 모든 것을 해결했습니다.

EC2 인스턴스도 만들고, RDS 데이터베이스도 생성하고, S3 버킷도 만들었습니다. 개발자 다섯 명이 모두 같은 계정에서 작업했습니다.

그런데 어느 날 신입 개발자가 테스트를 하다가 실수로 운영 환경의 Lambda 함수를 삭제해버렸습니다. 다행히 백업이 있어서 복구했지만, 팀장님은 등골이 서늘해졌습니다.

"이러다가 진짜 큰일 나겠다." 이것이 바로 멀티 계정 전략이 필요한 이유입니다. 쉽게 비유하자면, 하나의 AWS 계정에 모든 것을 넣는 것은 마치 집에 방 구분 없이 모든 가족이 한 공간에서 생활하는 것과 같습니다.

부모님의 중요한 서류와 아이들의 장난감이 뒤섞이고, 누군가 실수로 중요한 것을 망가뜨릴 수 있습니다. 반면에 각자 방이 있으면 물건을 정리하기도 쉽고, 다른 사람의 물건을 건드릴 일도 없습니다.

AWS에서도 마찬가지입니다. 개발 계정, 스테이징 계정, 운영 계정을 분리하면 개발자가 아무리 실험적인 작업을 해도 운영 환경에는 영향을 주지 않습니다.

각 계정은 완전히 독립된 공간이기 때문입니다. 멀티 계정 전략의 장점은 여러 가지가 있습니다.

첫째, 보안 경계가 명확해집니다. 개발 계정이 해킹당해도 운영 계정은 안전합니다.

둘째, 비용 추적이 쉬워집니다. 각 프로젝트나 팀별로 계정을 분리하면 누가 얼마나 비용을 사용하는지 한눈에 파악할 수 있습니다.

셋째, 권한 관리가 단순해집니다. 개발 계정에는 개발자에게 넓은 권한을 주고, 운영 계정에는 최소한의 권한만 부여할 수 있습니다.

넷째, 규정 준수가 용이합니다. 금융이나 의료 분야에서 요구하는 컴플라이언스를 특정 계정에만 적용할 수 있습니다.

실제로 대부분의 기업에서는 최소한 네 개 이상의 계정을 운영합니다. 관리용 계정, 로그 보관용 계정, 개발 계정, 운영 계정이 기본입니다.

여기에 보안 계정, 네트워크 계정 등을 추가하기도 합니다. 물론 계정이 많아지면 관리가 복잡해질 수 있습니다.

그래서 AWS에서는 AWS Organizations라는 서비스를 제공합니다. 이 서비스를 사용하면 여러 계정을 하나의 조직으로 묶어서 중앙에서 관리할 수 있습니다.

김개발 씨의 회사도 결국 멀티 계정 전략을 도입하기로 했습니다. 처음에는 복잡해 보였지만, 막상 적용해보니 오히려 관리가 편해졌습니다.

무엇보다 "실수로 운영 환경을 건드리면 어쩌지"라는 불안감에서 해방된 것이 가장 큰 수확이었습니다.

실전 팁

💡 - 최소한 개발, 스테이징, 운영 세 개의 계정은 분리하세요

• 보안과 로깅을 위한 전용 계정을 별도로 만드는 것을 권장합니다
• 계정 이메일은 그룹 메일이나 별칭을 사용하여 담당자가 바뀌어도 접근 가능하게 하세요

---

2. Organizations OU 구조 설계

멀티 계정 전략을 도입하기로 한 김개발 씨 회사. 그런데 계정이 점점 늘어나면서 새로운 고민이 생겼습니다.

"계정이 열 개가 넘어가니까 어떤 계정이 어떤 용도인지 헷갈려요." 박시니어 씨가 화이트보드에 그림을 그리며 말했습니다. "OU 구조를 잘 설계하면 해결됩니다."

**OU(Organizational Unit)**는 AWS Organizations에서 계정들을 논리적으로 그룹화하는 폴더와 같습니다. 마치 회사의 조직도처럼 계층 구조로 계정들을 정리할 수 있습니다.

OU를 잘 설계하면 정책을 한 번에 여러 계정에 적용할 수 있어 관리 효율이 크게 높아집니다.

다음 코드를 살펴봅시다.

// AWS Organizations OU 구조 설계 예시
const ouStructure = {
  root: {
    name: 'Root',
    children: [
      {
        name: 'Security',
        // 보안 관련 계정들
        accounts: ['log-archive', 'security-tooling', 'audit'],
      },
      {
        name: 'Infrastructure',
        // 공통 인프라 계정
        accounts: ['network-hub', 'shared-services'],
      },
      {
        name: 'Workloads',
        children: [
          { name: 'Development', accounts: ['dev-team-a', 'dev-team-b'] },
          { name: 'Staging', accounts: ['staging-main'] },
          { name: 'Production', accounts: ['prod-main', 'prod-dr'] },
        ],
      },
      {
        name: 'Sandbox',
        // 실험용 계정 - 느슨한 정책
        accounts: ['sandbox-experiments'],
      },
    ],
  },
};

박시니어 씨가 화이트보드에 그림을 그리기 시작했습니다. 맨 위에 'Root'라고 쓰고, 그 아래에 여러 개의 상자를 그렸습니다.

"이게 바로 OU 구조예요." **OU(Organizational Unit)**를 이해하려면 회사의 조직도를 떠올리면 됩니다. 회사에는 개발팀, 마케팅팀, 재무팀 등 여러 부서가 있고, 각 부서 안에는 또 다른 하위 팀이 있습니다.

AWS Organizations의 OU도 이와 같습니다. 계정들을 목적에 따라 폴더처럼 묶어서 관리하는 것입니다.

"근데 왜 굳이 이렇게 복잡하게 나눠야 해요?" 김개발 씨가 물었습니다. 박시니어 씨가 설명을 이어갔습니다.

"OU의 진짜 힘은 정책 상속에 있어요. 상위 OU에 정책을 적용하면 그 아래 모든 계정에 자동으로 적용됩니다." 예를 들어, Production OU에 "특정 리전에서만 리소스를 생성할 수 있다"는 정책을 적용하면, 그 안에 있는 모든 운영 계정에 해당 정책이 적용됩니다.

계정이 백 개여도 한 번에 관리할 수 있는 것입니다. AWS에서 권장하는 기본 OU 구조가 있습니다.

먼저 Security OU에는 로그를 모아두는 계정과 보안 도구를 관리하는 계정을 배치합니다. 이 계정들은 가장 엄격한 보안 정책이 적용됩니다.

Infrastructure OU에는 여러 계정이 공유하는 네트워크나 서비스를 관리하는 계정을 둡니다. VPN 연결이나 Transit Gateway 같은 것들이 여기에 해당합니다.

Workloads OU가 실제 애플리케이션이 동작하는 곳입니다. 이 OU 아래에 Development, Staging, Production 같은 하위 OU를 만들어서 환경별로 다른 정책을 적용합니다.

개발 환경에서는 자유롭게 실험할 수 있지만, 운영 환경에서는 제한적인 작업만 허용하는 식입니다. Sandbox OU는 개발자들이 마음껏 실험할 수 있는 공간입니다.

다만 비용이 과도하게 발생하지 않도록 예산 제한을 걸어두는 것이 좋습니다. OU 구조를 설계할 때 주의할 점이 있습니다.

너무 깊게 계층을 만들면 오히려 관리가 복잡해집니다. AWS에서는 최대 5단계까지 OU를 중첩할 수 있지만, 보통 2~3단계 정도가 적당합니다.

또한 OU 구조는 한 번 정하면 바꾸기 어렵습니다. 계정을 다른 OU로 옮길 수는 있지만, 적용되는 정책이 바뀌면서 예상치 못한 문제가 생길 수 있습니다.

그래서 처음에 신중하게 설계하는 것이 중요합니다. 김개발 씨가 고개를 끄덕였습니다.

"아, 그래서 처음에 잘 설계해야 하는 거군요. 회사 조직도처럼 생각하니까 이해가 되네요."

실전 팁

💡 - OU 계층은 2~3단계를 넘지 않도록 단순하게 유지하세요

• 정책 적용 관점에서 OU를 설계하세요. 같은 정책이 적용될 계정들을 묶으면 됩니다
• Sandbox OU를 만들어 개발자들이 안전하게 실험할 수 있는 공간을 제공하세요

---

3. 통합 결제 Consolidated Billing

월말이 다가오자 김개발 씨 회사의 재무팀에서 연락이 왔습니다. "AWS 비용 청구서가 계정별로 다 따로 오는데, 이거 하나로 합칠 수 없나요?

그리고 계정이 많아지면 볼륨 할인 같은 건 못 받나요?" 좋은 질문이었습니다. AWS Organizations는 이런 고민을 해결하는 기능도 제공합니다.

**통합 결제(Consolidated Billing)**는 조직 내 모든 계정의 비용을 관리 계정 하나로 합쳐서 청구받는 기능입니다. 마치 가족 통신비를 한 명 앞으로 합쳐서 할인받는 것처럼, AWS 사용량을 합산하여 볼륨 할인 혜택을 받을 수 있습니다.

또한 각 계정별 비용을 상세하게 추적할 수 있어 부서별 비용 배분도 쉬워집니다.

다음 코드를 살펴봅시다.

// AWS Cost Explorer API를 활용한 계정별 비용 조회 예시
import { CostExplorerClient, GetCostAndUsageCommand } from '@aws-sdk/client-cost-explorer';

const client = new CostExplorerClient({ region: 'us-east-1' });

// 계정별 비용 조회
const getCostByAccount = async (startDate: string, endDate: string) => {
  const command = new GetCostAndUsageCommand({
    TimePeriod: { Start: startDate, End: endDate },
    Granularity: 'MONTHLY',
    Metrics: ['UnblendedCost'],
    // 계정별로 그룹화
    GroupBy: [{ Type: 'DIMENSION', Key: 'LINKED_ACCOUNT' }],
  });

  const response = await client.send(command);
  return response.ResultsByTime;
};

// 서비스별 비용도 함께 조회 가능
// GroupBy에 SERVICE를 추가하면 됩니다

재무팀의 이 대리가 AWS 청구서를 들고 한숨을 쉬었습니다. "계정이 다섯 개인데 청구서도 다섯 개예요.

매달 이걸 하나하나 확인하고 합산하려니 머리가 아파요." 이 대리의 고민은 **통합 결제(Consolidated Billing)**로 한 번에 해결됩니다. AWS Organizations를 사용하면 모든 멤버 계정의 비용이 관리 계정(Management Account) 하나로 합쳐서 청구됩니다.

재무팀은 청구서 하나만 확인하면 됩니다. 물론 각 계정별로 얼마를 썼는지 상세 내역도 확인할 수 있습니다.

통합 결제의 진짜 매력은 볼륨 할인입니다. AWS의 많은 서비스는 사용량이 많을수록 단가가 낮아지는 구조입니다.

예를 들어 S3 스토리지는 처음 50TB까지는 GB당 0.023달러이지만, 그 다음 450TB는 0.022달러로 조금 싸집니다. 계정이 분리되어 있으면 각 계정의 사용량이 따로 계산되어 할인을 못 받을 수 있습니다.

하지만 통합 결제를 사용하면 모든 계정의 S3 사용량이 합산됩니다. 개발 계정에서 30TB, 운영 계정에서 40TB를 사용하면 합쳐서 70TB로 계산되어 할인 구간에 진입하는 것입니다.

**Reserved Instance(RI)**와 Savings Plans도 조직 내에서 공유됩니다. 운영 계정에서 구매한 EC2 예약 인스턴스를 개발 계정에서도 활용할 수 있습니다.

물론 이 기능은 설정에서 끌 수도 있습니다. 부서별로 예약 인스턴스를 따로 관리하고 싶다면 공유를 비활성화하면 됩니다.

비용 배분도 쉬워집니다. AWS Cost Explorer에서 계정별, 서비스별, 태그별로 비용을 분석할 수 있습니다.

"마케팅팀 계정에서 이번 달 Lambda 비용이 급증했네요. 무슨 일이 있었나 확인해봐야겠어요." 이런 식으로 문제를 빠르게 파악할 수 있습니다.

AWS Budgets를 활용하면 계정별로 예산을 설정하고 초과 시 알림을 받을 수 있습니다. Sandbox 계정에 월 100달러 예산을 설정해두면, 80% 도달 시 이메일 알림을 보내고, 100% 초과 시 자동으로 리소스를 중지시킬 수도 있습니다.

주의할 점도 있습니다. 통합 결제를 사용하면 관리 계정에서 모든 비용을 지불합니다.

만약 멤버 계정 중 하나가 비용을 지불하지 않으면 관리 계정에서 책임져야 합니다. 따라서 외부 파트너나 고객에게 계정을 제공할 때는 별도의 조직으로 분리하는 것이 안전합니다.

이 대리가 환하게 웃었습니다. "이거 진작 알았으면 좋았을 텐데!

청구서도 하나로 오고, 할인도 받고, 일석이조네요."

실전 팁

💡 - Cost Explorer와 AWS Budgets를 활용하여 계정별 비용을 체계적으로 관리하세요

• 태그 정책을 수립하여 프로젝트별, 환경별 비용을 추적할 수 있게 하세요
• RI와 Savings Plans 공유 설정을 조직 상황에 맞게 조정하세요

---

4. Service Control Policies SCP

어느 날 보안팀에서 긴급 연락이 왔습니다. "누가 서울 리전에만 리소스 만들기로 했는데, 버지니아 리전에 EC2를 만들어놨어요!" 정책을 정해도 지키지 않으면 소용없습니다.

김개발 씨는 생각했습니다. "사람이 실수하지 않도록 시스템에서 막을 수는 없을까?"

**SCP(Service Control Policy)**는 조직 내 계정에서 사용할 수 있는 AWS 서비스와 작업을 제한하는 정책입니다. 마치 건물의 출입 통제 시스템처럼, 아무리 권한이 있는 사람도 SCP가 막으면 그 작업을 할 수 없습니다.

IAM 정책보다 상위에서 작동하여 조직 전체의 보안 경계를 설정합니다.

다음 코드를 살펴봅시다.

// SCP 예시: 특정 리전에서만 리소스 생성 허용
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAllOutsideAllowedRegions",
      "Effect": "Deny",
      "NotAction": [
        "iam:*",
        "organizations:*",
        "support:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": [
            "ap-northeast-2",  // 서울
            "us-east-1"        // 버지니아 (글로벌 서비스용)
          ]
        }
      }
    },
    {
      "Sid": "DenyLeavingOrganization",
      "Effect": "Deny",
      "Action": "organizations:LeaveOrganization",
      "Resource": "*"
    }
  ]
}

보안팀의 최보안 씨가 회의실에서 설명을 시작했습니다. "IAM 정책으로 권한을 관리하고 있는데, 왜 자꾸 정책을 어기는 일이 생길까요?" 김개발 씨가 조심스럽게 대답했습니다.

"IAM 정책은 '할 수 있는 것'을 정의하는 거잖아요. 관리자 권한이 있으면 뭐든 할 수 있으니까요." "맞아요.

그래서 SCP가 필요합니다." **SCP(Service Control Policy)**는 IAM과 다른 차원에서 작동합니다. IAM이 "이 사용자가 무엇을 할 수 있는가"를 정의한다면, SCP는 "이 계정에서 절대 할 수 없는 것"을 정의합니다.

비유하자면, IAM은 회사에서 각 직원에게 부여하는 출입증입니다. 개발자는 개발실에, 인사팀은 인사실에 들어갈 수 있습니다.

반면 SCP는 건물 자체의 출입 통제 시스템입니다. 아무리 사장님이라도 새벽 2시에는 건물에 들어올 수 없다면, 그건 개인 권한과 상관없이 적용되는 규칙입니다.

SCP의 핵심 원리는 교집합입니다. 어떤 작업을 수행하려면 IAM 정책에서도 허용하고, SCP에서도 허용해야 합니다.

둘 중 하나라도 거부하면 작업이 실패합니다. 따라서 SCP는 조직 전체의 보안 가드레일 역할을 합니다.

가장 흔히 사용하는 SCP 패턴이 있습니다. 첫째, 리전 제한입니다.

회사가 서울 리전만 사용하기로 했다면, SCP로 다른 리전에서 리소스 생성을 원천 차단합니다. 개발자가 실수로 다른 리전을 선택해도 에러가 발생합니다.

둘째, 위험한 서비스 차단입니다. 예를 들어 비용이 많이 드는 서비스나, 보안상 위험한 서비스를 아예 사용하지 못하게 막을 수 있습니다.

셋째, 조직 이탈 방지입니다. 멤버 계정이 조직을 떠나면 통합 결제도 끊기고, 공유 리소스 접근도 불가능해집니다.

SCP로 organizations:LeaveOrganization 액션을 차단하면 계정이 무단으로 조직을 떠나는 것을 방지할 수 있습니다. SCP를 적용할 때 주의할 점이 있습니다.

SCP는 OU 단위로 적용되며, 상위 OU의 SCP가 하위로 상속됩니다. 또한 SCP는 관리 계정에는 적용되지 않습니다.

그래서 관리 계정에서는 직접 리소스를 생성하지 않는 것이 보안 모범 사례입니다. 처음 SCP를 도입할 때는 Deny 목록보다 Allow 목록 방식을 권장합니다.

모든 것을 허용하되 위험한 것만 거부하는 방식이 더 안전합니다. 너무 제한적으로 시작하면 개발자들이 정상적인 업무도 못 하게 될 수 있습니다.

최보안 씨가 정리했습니다. "SCP는 우리 조직의 보안 울타리예요.

실수든 고의든, 울타리를 넘어가는 건 시스템에서 막아줍니다."

실전 팁

💡 - SCP는 관리 계정에는 적용되지 않으므로, 관리 계정에서 직접 리소스를 생성하지 마세요

• 처음에는 느슨하게 시작하고, 점진적으로 제한을 강화하세요
• SCP 변경 전에 반드시 테스트 계정에서 먼저 검증하세요

---

5. 계정 간 리소스 공유 RAM

멀티 계정을 도입한 후 새로운 고민이 생겼습니다. "개발 계정에서 만든 AMI를 운영 계정에서도 쓰고 싶은데, 매번 복사해야 하나요?" 계정을 분리하니 리소스 공유가 불편해진 것입니다.

박시니어 씨가 말했습니다. "AWS RAM을 쓰면 됩니다."

**AWS RAM(Resource Access Manager)**은 조직 내 여러 계정 간에 AWS 리소스를 안전하게 공유할 수 있게 해주는 서비스입니다. 마치 공동 주택의 공용 시설처럼, 한 곳에서 만든 리소스를 여러 계정에서 함께 사용할 수 있습니다.

VPC 서브넷, Transit Gateway, AMI 등 다양한 리소스를 복제 없이 공유할 수 있어 비용과 관리 부담을 줄여줍니다.

다음 코드를 살펴봅시다.

// AWS RAM을 사용한 서브넷 공유 예시 (CDK)
import * as ram from 'aws-cdk-lib/aws-ram';

// 공유 VPC의 서브넷을 다른 계정과 공유
const subnetShare = new ram.CfnResourceShare(this, 'SharedSubnets', {
  name: 'shared-network-subnets',
  // 공유할 리소스의 ARN
  resourceArns: [
    'arn:aws:ec2:ap-northeast-2:111111111111:subnet/subnet-abc123',
    'arn:aws:ec2:ap-northeast-2:111111111111:subnet/subnet-def456',
  ],
  // Organizations 조직 전체와 공유
  principals: ['arn:aws:organizations::111111111111:organization/o-example'],
  // 또는 특정 OU와만 공유
  // principals: ['arn:aws:organizations::111111111111:ou/o-example/ou-xxxx-workloads'],
  allowExternalPrincipals: false,  // 조직 외부 공유 차단
});

김개발 씨가 곤란한 표정을 지었습니다. "VPC를 계정마다 따로 만들어야 하나요?

네트워크 설계도 다 따로 해야 하고, IP 대역도 겹치지 않게 조정해야 하고... 이건 너무 복잡해요." 박시니어 씨가 고개를 저었습니다.

"그럴 필요 없어요. AWS RAM을 쓰면 됩니다." **AWS RAM(Resource Access Manager)**은 한 계정에서 만든 리소스를 다른 계정과 공유할 수 있게 해주는 서비스입니다.

리소스를 복제하는 게 아니라 접근 권한을 부여하는 방식입니다. 가장 대표적인 사용 사례가 VPC 서브넷 공유입니다.

네트워크 전담 계정에서 VPC를 설계하고, 그 서브넷을 개발 계정, 운영 계정과 공유합니다. 각 계정은 공유받은 서브넷에 EC2나 RDS를 배포할 수 있습니다.

비유하자면, 아파트 단지를 생각해보세요. 각 세대가 개별 계정이라면, 공용 주차장이나 커뮤니티 시설은 RAM으로 공유하는 리소스입니다.

각 세대가 따로 주차장을 만들 필요 없이, 단지 전체가 하나의 주차장을 함께 사용하는 것입니다. RAM으로 공유할 수 있는 리소스는 다양합니다.

VPC 서브넷은 가장 흔하게 공유됩니다. Transit Gateway를 공유하면 여러 계정의 VPC를 중앙에서 연결할 수 있습니다.

Route 53 Resolver 규칙을 공유하면 DNS 설정을 통합 관리할 수 있습니다. AMI(Amazon Machine Image) 공유도 유용합니다.

개발 계정에서 애플리케이션 AMI를 만들고 테스트한 후, 운영 계정과 공유합니다. 운영 계정에서는 해당 AMI로 EC2를 바로 실행할 수 있습니다.

매번 AMI를 복사할 필요가 없습니다. AWS Organizations와 통합하면 공유가 더 쉬워집니다.

조직 전체 또는 특정 OU에 리소스를 공유할 수 있습니다. 새 계정이 OU에 추가되면 자동으로 공유 리소스에 접근할 수 있게 됩니다.

보안 관점에서도 RAM은 장점이 있습니다. 공유받은 계정은 해당 리소스를 사용할 수만 있고, 수정하거나 삭제할 수는 없습니다.

서브넷을 공유받은 계정이 그 서브넷을 삭제할 수는 없다는 뜻입니다. 리소스의 소유권은 여전히 원본 계정에 있습니다.

주의할 점도 있습니다. 모든 AWS 리소스가 RAM을 지원하는 것은 아닙니다.

S3 버킷이나 Lambda 함수는 RAM 대신 리소스 기반 정책을 사용해야 합니다. 또한 RAM으로 공유해도 비용은 리소스를 생성한 계정에서 발생합니다.

다만 공유받은 계정에서 그 위에 만든 리소스(예: 공유 서브넷에 배포한 EC2)의 비용은 해당 계정에서 발생합니다. 김개발 씨가 안도의 한숨을 쉬었습니다.

"다행이다. 네트워크를 계정마다 다 따로 설계할 뻔했네요.

RAM 덕분에 중앙에서 관리하고 공유하면 되겠군요."

실전 팁

💡 - VPC는 Network 전담 계정에서 생성하고 RAM으로 공유하는 패턴을 권장합니다

• Organizations와 통합하면 OU 단위로 자동 공유가 가능합니다
• 공유 리소스의 비용 발생 위치를 미리 파악하고 비용 배분 계획을 세우세요

---

6. Control Tower로 Landing Zone 구성

여기까지 배운 김개발 씨. Organizations, OU, SCP, RAM까지 이해는 했는데, 막상 처음부터 설정하려니 막막합니다.

"이거 하나하나 다 수동으로 해야 하나요? 실수하면 어쩌죠?" 박시니어 씨가 웃으며 말했습니다.

"AWS Control Tower가 다 해줍니다."

AWS Control Tower는 멀티 계정 환경을 자동으로 설정하고 지속적으로 거버넌스를 관리해주는 서비스입니다. 마치 새 아파트 단지를 분양받으면 기본 인테리어가 되어 있는 것처럼, Control Tower는 보안, 로깅, 네트워킹 등이 모범 사례에 맞게 구성된 Landing Zone을 자동으로 만들어줍니다.

복잡한 초기 설정 없이 안전한 멀티 계정 환경을 시작할 수 있습니다.

다음 코드를 살펴봅시다.

// Control Tower Account Factory로 새 계정 생성 (Service Catalog 활용)
// AWS 콘솔에서 주로 사용하지만, CLI/SDK로도 가능합니다

// 새 계정 요청 파라미터
const newAccountRequest = {
  AccountName: 'project-alpha-dev',
  AccountEmail: 'aws-alpha-dev@company.com',
  // 배치할 OU 선택
  ManagedOrganizationalUnit: 'Development',
  // SSO 사용자 설정
  SSOUserEmail: 'dev-admin@company.com',
  SSOUserFirstName: 'Dev',
  SSOUserLastName: 'Admin',
};

// Control Tower가 자동으로 수행하는 작업:
// 1. 계정 생성 및 OU 배치
// 2. 필수 가드레일(SCP) 적용
// 3. CloudTrail, Config 자동 설정
// 4. SSO 접근 권한 부여
// 5. 로그 아카이브 계정으로 로그 전송 설정

박시니어 씨가 AWS 콘솔을 열었습니다. "지금까지 배운 것들, 하나하나 수동으로 설정하면 며칠은 걸릴 거예요.

그런데 Control Tower를 쓰면 몇 시간이면 끝납니다." AWS Control Tower는 멀티 계정 환경의 자동 설정 도구입니다. AWS가 수년간 축적한 모범 사례를 바탕으로, 보안, 로깅, 계정 관리가 잘 갖춰진 환경을 자동으로 구성해줍니다.

Control Tower를 활성화하면 가장 먼저 Landing Zone이 만들어집니다. Landing Zone은 비행기가 착륙하는 활주로처럼, 새로운 계정이 안전하게 "착륙"할 수 있는 기반 환경입니다.

Landing Zone에는 기본적으로 몇 가지 계정이 자동으로 생성됩니다. Log Archive 계정은 모든 계정의 CloudTrail 로그와 Config 로그를 중앙에서 보관합니다.

Audit 계정은 보안팀이 전체 조직의 보안 상태를 모니터링하는 데 사용합니다. **가드레일(Guardrails)**은 Control Tower의 핵심 기능입니다.

가드레일은 두 가지로 나뉩니다. 예방 가드레일은 SCP를 사용하여 특정 작업을 원천 차단합니다.

탐지 가드레일은 AWS Config 규칙을 사용하여 정책 위반을 발견하고 알려줍니다. Control Tower는 기본적으로 20개 이상의 필수 가드레일을 제공합니다.

예를 들어 "로그 아카이브 버킷 삭제 금지", "CloudTrail 비활성화 금지", "루트 사용자 액세스 키 생성 금지" 같은 것들입니다. 이런 가드레일 덕분에 실수로 중요한 보안 설정을 해제하는 것을 방지할 수 있습니다.

Account Factory는 새 계정을 쉽게 생성해주는 기능입니다. 콘솔에서 몇 가지 정보만 입력하면 계정이 자동으로 생성되고, 지정한 OU에 배치되며, 필요한 가드레일이 적용됩니다.

SSO 접근 권한까지 자동으로 설정됩니다. 기존에 AWS 계정이 있다면 Control Tower에 **등록(Enroll)**할 수도 있습니다.

기존 계정을 조직으로 가져온 후 Control Tower에 등록하면, 가드레일이 적용되고 거버넌스 관리 대상에 포함됩니다. Control Tower의 대시보드에서는 조직 전체의 상태를 한눈에 볼 수 있습니다.

몇 개의 계정이 있는지, 가드레일 준수 상태는 어떤지, 최근에 생성된 계정은 무엇인지 등을 확인할 수 있습니다. 물론 Control Tower가 모든 것을 해결해주지는 않습니다.

기본 제공되는 OU 구조(Security, Sandbox)가 회사 상황에 맞지 않을 수 있고, 추가적인 커스터마이징이 필요할 수 있습니다. 하지만 시작점으로서는 훌륭합니다.

일단 Control Tower로 시작하고, 필요에 따라 조금씩 수정해나가면 됩니다. 김개발 씨가 고개를 끄덕였습니다.

"처음부터 완벽하게 설계하려고 고민만 하고 있었는데, 일단 Control Tower로 시작해보는 게 좋겠네요. 모범 사례가 이미 적용되어 있으니 안심이 되고요."

실전 팁

💡 - 신규 프로젝트라면 처음부터 Control Tower로 시작하는 것을 강력히 권장합니다

• 기존 Organizations가 있다면 Control Tower 도입 전에 호환성을 꼭 확인하세요
• 가드레일을 한꺼번에 많이 활성화하지 말고, 점진적으로 추가하세요

---

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