환경 구축 - AWS Organizations로 계정 구조화와 SCP연결

Sb_chi·2025년 7월 26일

AWS 계정 운용과 정책 관리

목록 보기

3/4

🔍 Intro

이전 글에서는 Assume Role을 이용해 다중 계정 간 리소스를 안전하게 공유하고 권한을 위임하는 방법을 정리했다.
하지만 계정 수가 많아지고 팀/조직 단위로 운영이 복잡해질수록, 단순한 역할 위임만으로는 통합적인 관리가 어려워진다.
이번 시간에는 AWS Organizations라는 계정 중앙 관리 시스템을 이용해
효율적인 계정 통합과 정책 관리를 어떻게 하는지에 대해 정리해보았다.

🔗 관련링크

AWS 계정의 기초 관리

AWS 다중 계정 구조에서 Assume Role로 권한 위임해보기

TroubleShooting-AWS Organizations로 잘못 만든 계정 Closeaccount로 삭제하기

AWS Organizations 개념

AWS Organizations란?

여러 개의 AWS 계정을 중앙에서 통합 관리할 수 있는 서비스
계정 생성 및 관리, 정책 적용, 액세스 제어 등을 중앙에서 수행 가능
하나의 Organization은 하나의 관리 계정과 0개 이상의 멤버 계정으로 구성됨
AWS계정은 단 하나의 Organization 소속만 가능하다.
Organizations로 생성된 계정은 계정 닫기를 통해 비활성화 후 제거할 수 있다.

계정 닫기(Close Account)란?

AWS Organizations 환경에서 계정 닫기(Close Account)는 다중 계정 운영 시 불필요해진 계정을 안전하게 종료하고 관리 비용을 줄이기 위한 절차

📕 써야 하는 이유

OU 단위 조직 관리
계정을 조직 단위(OU)로 그룹화해서 정책을 적용하고 제어 가능
비용 통합 관리
모든 계정의 리소스 사용 비용을 하나의 관리 계정으로 통합 청구
보안 정책 일괄 적용
모든 계정에 대해 SCP(서비스 제어 정책)을 일괄 적용 가능
계정 생성 자동화 및 초대
새 계정을 Organizations에서 간편하게 생성할 수 있고, 새 계정은 OU에 자동 분류가 가능한 서비스가 있다.
기존 계정도 OU에 배치 가능
실수 방지
프로덕션 과 개발 계정을 분리하여 실수로 리소스를 삭제하는 사고 예방 가능

조직에서의 팀 단위 계정 설계 예시

Infra Team, Dev Team , Prod Team으로 분리해서 관리
Team 별 역할 :
- Infra Team: 공통 인프라 리소스를 별도 계정에서 관리하여, 운영 환경과의 권한 분리를 실현
- Dev Team: 개발 전용 계정에서 자유롭게 테스트 및 개발을 수행하면서 운영 계정과 격리
- Prod Team: 운영 서비스가 배포되는 계정으로, 보안 및 안정성이 중요한 리소스만 존재

팀 구분	계정 이름	주요 역할 설명
Infra Team	`shared-network`	VPC, Subnet, IGW, NAT 등 네트워크 리소스를 중앙 관리
	`central-logging`	각 팀 계정에서 발생하는 로그 수집 (CloudTrail, S3, Config 등)
	`security-tooling`	GuardDuty, Security Hub 등 통합 보안 도구 운영
Dev Team	`dev-backend`	개발 중인 백엔드 애플리케이션 테스트 및 배포 환경 운영
	`dev-frontend`	프론트엔드 정적 리소스 배포(S3 + CloudFront 등)
	`dev-tools`	CodePipeline, CodeBuild 등 CI/CD 도구 계정
Prod Team	`prod-app`	실제 서비스가 운영되는 운영 환경 애플리케이션 배포
	`prod-monitoring`	운영 중인 서비스의 모니터링 전용 계정 (CloudWatch, X-Ray 등)
	`prod-backup`	백업 전용 계정, DR(재해복구) 전략 적용

AWS Organizations 사용해보기

🧾 준비

AWS Organizations를 쓰려면 계정이 두 개 이상 필요하다.
이때, Gmail의 +기능을 써서 하나의 Gmail 주소로 여러 AWS 계정을 만들어서 이용하는 게 가능하다.

예시 :
test@gmail.com ➡️ test+dev@gmail.com 또는 test+prod@gmail.com

AWS는 이걸 각각 다른 이메일로 보고 계정을 만드는게 인정이 된다.
메일은 전부 원래 Gmail 계정으로 온다.

🧪 구성 목표

⚠️ 관리 계정 + 인프라 OU 및 하위 계정 생성

AWS Organizations에서 관리 계정(Management Account)을 기준으로 조직을 구성한다.
OU(조직 단위, Organizational Unit)를 생성하여 팀 또는 기능 단위로 계정을 분리한다.
인프라 OU를 생성하고, 여기에 로그 관리 전용 계정을 하나 생성하여 소속시킨다.
큰 단위의 인프라팀 OU 와 로그 확인 용도의 계정에 각각 SCP(Service Control Policy)를 적용하여, 어떻게 동작되는지 확인한다.

항목	설명
관리 계정	Organizations 생성 및 제어를 담당하는 루트 계정
OU 이름	OU-Infra
하위 계정	LogAccount
적용 정책	`cloudtrail:*` ➡️ CloudTrail 생성, 수정, 시작, 중지 `s3:PutObject`, `s3:ListBucket`, `s3:GetObject` ➡️ 로그 저장용 S3 접근

구성하기

관리 계정 접속 ➡️ AWS 콘솔 ➡️ AWS Organizations ➡️ 조직 생성

OU 생성

Root 체크 ➡️ 작업 클릭 ➡️ 새로 생성

OU 이름 : OU-Infra

계정 추가

상단에 있는 AWS 계정 추가 클릭
AWS 계정 생성에서 정보 입력
기존 계정이 있으면 기존 AWS 계정 초대에서 초대할 수 있다.

Gmail의 Alias 기능을 이용해 자신계정+infra@gmail.com 이런식으로 계정을 생성할 수 있다. 이메일 인증은 자신의 원래 계정으로 오게 된다.

정책 생성

AWS Organizations ➡️ 정책 ➡️ 서비스 제어 정책 ➡️ 서비스 제어 정책 활성화 ➡️ 정책 생성

대상	계정 역할	권한 설정
OU-Infra	인프라 운영 계정 그룹	인프라 서비스 대부분 허용, 위험 작업 제한
logAccount	로그 수집, 분석 전용	로그 및 Athena 서비스만 허용, 그 외 제한, S3 삭제 차단

SCP-OU-Infra

구분	권한 및 영향
허용	인프라 운영에 필요한 거의 모든 EC2, 네트워크, 스토리지, DB, 로그, 알림, 보안 키 작업 가능
제한	IAM 사용자/역할/정책 삭제, S3 버킷 및 객체 삭제 불가 (실수 방지 목적)
기본 동작	명시하지 않은 권한은 SCP 기준으로 제한됨

📕 OU-Infra Json Code


  
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowBasicInfraServices",
      "Effect": "Allow",
      "Action": [
        "ec2:*",
        "s3:*",
        "iam:Get*",
        "iam:List*",
        "logs:*",
        "cloudwatch:*",
        "elasticloadbalancing:*",
        "autoscaling:*",
        "rds:*",
        "sns:*",
        "sqs:*",
        "cloudtrail:*",
        "kms:*"
      ],
      "Resource": "*"
    },
    {
      "Sid": "DenyHighRiskDeleteActions",
      "Effect": "Deny",
      "Action": [
        "iam:DeleteUser",
        "iam:DeleteRole",
        "iam:DeletePolicy",
        "s3:DeleteBucket",
        "s3:DeleteObject"
      ],
      "Resource": "*"
    }
  ]
}

SCP-Log-Account

구분	권한 및 영향
허용	로그 수집 및 분석 관련 서비스(CoudTrail, S3, Athena, Glue, Config, GuardDuty 등) 사용 가능
제한	명시된 서비스 외 모든 AWS 서비스 사용 불가 S3 버킷 및 객체 삭제 차단
기본 동작	허용된 서비스만 사용 가능하며, 그 외는 모두 차단됨

📕 SCP-Log-Account Json Code


  

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowOnlyLoggingAndAnalysis",
      "Effect": "Allow",
      "Action": [
        "cloudtrail:*",
        "s3:*",
        "glue:*",
        "athena:*",
        "logs:*",
        "config:*",
        "guardduty:*"
      ],
      "Resource": "*"
    },
    {
      "Sid": "DenyAllOtherServices",
      "Effect": "Deny",
      "NotAction": [
        "cloudtrail:*",
        "s3:*",
        "glue:*",
        "athena:*",
        "logs:*",
        "config:*",
        "guardduty:*"
      ],
      "Resource": "*"
    },
    {
      "Sid": "DenyS3DeleteActions",
      "Effect": "Deny",
      "Action": [
        "s3:DeleteObject",
        "s3:DeleteBucket"
      ],
      "Resource": "*"
    }
  ]
}

정책연결

만들어진 SCP 정책 또는 OU나 계정에서 정책 연결을 하면된다.

정책 작동 확인

OU-Infra에 속해있는 로그 관리 계정에 접속해 ec2 생성을 하려고 했지만, OU-Infra에는 ec2*(ec2에 관한 모든 행위 허용) SCP가 있어도 로그 관리 계정의 ec2 생성 및 보기 권한이 차단되어있어 접근할 수 없는 것을 확인할 수 있다.

💡 계정에 FullAWSAccess와 사용자 정의 SCP가 모두 연결되어 있더라도, 두 정책의 교집합만 허용되기 때문에 FullAccess 정책의 모든 권한을 사용할 수는 없다.

📓 정리

AWS Organizations는 여러 AWS 계정을 중앙에서 통합 관리할 수 있게 해주는 서비스로, 대규모 팀 운영에 필수적이다.
OU(Organizational Unit)를 사용하면 팀, 기능 또는 목적에 따라 계정을 그룹화하고, 각 그룹별로 다른 정책(SCP)을 적용할 수 있다.
SCP(Service Control Policy)를 통해 각 계정의 권한을 루트 레벨에서 제어할 수 있다. (IAM보다 상위 개념)
계정에 두 개 이상의 정책이 모두 연결되어 있더라도, 두 정책의 교집합만 허용되기 때문에 그 중 하나가 FullAccess 정책이라도 모든 권한을 사용할 수는 없다.

Gmail의 +Alias 기능을 이용하면 하나의 메일 주소로 여러 AWS 계정을 만들어 테스트할 수 있어 비용 없이 학습과 실습이 가능하다.
조직 내 각 팀(Infrastructure, Dev, Prod)은 역할과 책임을 분리해 실수 방지와 보안 강화를 도모할 수 있다.