Organizations, SCP 와 Control Tower (다중 계정 랜딩 존)

왜 다중 계정인가

AWS 계정은 가장 강한 격리 경계입니다. 권한, 할당량, 청구, 장애 영향 범위가 모두 계정 단위로 나뉩니다. 그래서 운영과 개발을 한 계정에 섞지 않고, 워크로드와 환경별로 계정을 나누는 것이 표준입니다. AWS Organizations 는 이 계정들을 묶어서 통합 결제, 정책, 중앙 서비스(CloudTrail, GuardDuty, Security Hub, Identity Center)를 한 번에 관리하게 해 줍니다.

OU 설계

OU 는 조직도가 아니라 정책 단위로 나눕니다. "마케팅 팀 OU" 보다 "운영 워크로드 OU" 가 정책을 걸기 쉽습니다. 관리 계정에는 워크로드를 두지 않습니다. 관리 계정의 주체에는 SCP 가 적용되지 않기 때문입니다.

SCP (서비스 제어 정책)

SCP 는 계정 안의 IAM 주체(사용자, 역할)가 받을 수 있는 권한의 상한선입니다. 권한을 주지는 않습니다. 기본으로 붙어 있는 FullAWSAccess 를 떼면 그 아래 계정은 아무것도 못 하게 되니 조심합니다.

2025-09 부터 SCP 가 IAM 정책 문법을 모두 지원합니다. 예전에는 Allow 문에 조건을 못 쓰고 Resource 는 * 만 됐지만, 이제 Allow 에도 조건과 개별 리소스 ARN, NotResource 를 쓸 수 있습니다.

리전 제한 SCP 예

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyOutsideSeoulTokyo",
    "Effect": "Deny",
    "NotAction": [
      "iam:*", "organizations:*", "sts:*", "support:*", "account:*",
      "cloudfront:*", "route53:*", "route53domains:*", "waf:*", "wafv2:*",
      "budgets:*", "ce:*", "health:*", "trustedadvisor:*", "sso:*", "identitystore:*"
    ],
    "Resource": "*",
    "Condition": {
      "StringNotEquals": { "aws:RequestedRegion": ["ap-northeast-2", "ap-northeast-1"] },
      "ArnNotLike": { "aws:PrincipalARN": "arn:aws:iam::*:role/OrgBreakGlass" }
    }
  }]
}

전역 서비스(IAM, Organizations, CloudFront, Route 53 등)는 us-east-1 로 호출되므로 NotAction 으로 빼 둬야 합니다. 빠진 서비스가 있으면 콘솔 일부가 이유 없이 깨집니다. 실제로 걸기 전에 Sandbox OU 에서 먼저 시험합니다.

흔히 쓰는 SCP

• 조직 탈퇴 금지: organizations:LeaveOrganization Deny
• CloudTrail, Config, GuardDuty 끄기 금지: cloudtrail:StopLogging, cloudtrail:DeleteTrail, guardduty:DeleteDetector 등 Deny
• 루트 사용자 사용 금지: aws:PrincipalArn 이 arn:aws:iam::*:root 이면 Deny
• 비싼 인스턴스 금지(Sandbox): ec2:RunInstances 에서 ec2:InstanceType 이 p*, trn* 이면 Deny
• 퍼블릭 S3 설정 변경 금지: s3:PutAccountPublicAccessBlock Deny

RCP (리소스 제어 정책)

RCP 는 2024-11 에 나온 정책으로, 계정 안 리소스에 허용될 수 있는 상한선을 정합니다. SCP 가 "우리 사람이 할 수 있는 최대치" 라면, RCP 는 "우리 리소스에 누가 와도 넘을 수 없는 선" 입니다. 대표적인 쓰임은 데이터 경계(data perimeter) 입니다.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "EnforceOrgIdentities",
    "Effect": "Deny",
    "Principal": "*",
    "Action": ["s3:*", "sqs:*", "kms:*", "secretsmanager:*", "sts:AssumeRole"],
    "Resource": "*",
    "Condition": {
      "StringNotEqualsIfExists": { "aws:PrincipalOrgID": "o-abc123example" },
      "BoolIfExists": { "aws:PrincipalIsAWSService": "false" }
    }
  }]
}

이렇게 걸면 누군가 버킷 정책을 실수로 "Principal": "*" 로 열어도 조직 밖 주체는 들어오지 못합니다. RCP 를 지원하는 서비스는 처음에 S3, STS, KMS, SQS, Secrets Manager 로 시작해 늘고 있으니, 걸기 전에 RCP 문서에서 지원 서비스를 확인합니다. CloudFront OAC 처럼 AWS 서비스가 대신 접근하는 경우를 막지 않도록 예외 조건을 꼭 시험합니다.

선언적 정책과 기타 정책

• 선언적 정책(declarative policies): 2024-12 에 나온 정책으로, EC2 같은 서비스의 기본 설정(예: 퍼블릭 AMI 공유 차단, IMDSv2 강제, VPC 퍼블릭 액세스 차단)을 API 단에서 조직 전체에 고정합니다. SCP 와 달리 새로 나온 API 가 우회하지 못하고, 막혔을 때 사용자에게 보일 안내 문구도 정할 수 있습니다.
• 태그 정책, 백업 정책, AI 서비스 옵트아웃 정책도 Organizations 에서 함께 관리합니다.

Control Tower

AWS Control Tower 는 위 내용을 모범 사례대로 한 번에 깔아 주는 서비스입니다.

2025-11 에는 컨트롤 전용 경험이 나왔습니다. 전체 랜딩 존을 깔지 않고도 이미 운영 중인 Organizations 에 Control Tower 의 관리형 컨트롤 750 개 이상을 바로 적용할 수 있고, Control Tower 가 정해진 OU 구조를 강제하지 않습니다. 이미 자체 랜딩 존이 있는 회사가 컨트롤만 가져다 쓰기 좋아졌습니다.

운영 팁

• SCP 변경은 코드로: Terraform, CloudFormation StackSets, Control Tower 의 컨트롤 API 로 관리하고 PR 리뷰를 거칩니다.
• 정책 크기 한도: SCP 문서 하나는 5,120 자까지이고, 한 대상에 붙일 수 있는 SCP 는 5 개까지입니다. 문장을 잘게 쪼개면 금방 찹니다.
• 위임 관리자: GuardDuty, Security Hub, Config 집계, Identity Center 같은 서비스는 관리 계정이 아닌 Audit 계정이나 보안 계정에 위임합니다.
• 통합 결제: Savings Plans 와 예약 인스턴스 할인은 기본적으로 조직 안 계정끼리 나눠 씁니다. 나누지 않으려면 결제 설정에서 할인 공유를 끕니다. 자세한 내용은 비용 최적화 문서에 있습니다.

자주 하는 실수

• FullAWSAccess 를 떼고 허용 목록 SCP 만 붙임: 빠뜨린 서비스가 모두 막힙니다. 처음에는 Deny 목록 방식이 안전합니다.
• SCP 로 막았는데 관리 계정에서는 됨: 관리 계정은 SCP 의 적용을 받지 않습니다.
• RCP 를 걸었더니 AWS 서비스 연동이 깨짐: aws:PrincipalIsAWSService, aws:SourceOrgID 같은 예외가 빠졌는지 봅니다.
• Control Tower 가 만든 리소스를 직접 수정: 드리프트가 나서 랜딩 존 업데이트가 막힙니다.