AWS Organizations FAQ

AWS Organizations와 같은 AWS 서비스에 구축되는 AWS Control Tower는 새롭고 안전한 다중 계정 AWS 환경을 설정 및 관리할 수 있는 가장 쉬운 방법을 제공합니다. 모범 사례 블루프린트를 기반으로 한 well-architected 다중 계정 환경인 Landing Zone을 설정하며, 선택 가능한 가드레일을 사용하여 거버넌스를 활성화합니다. 가드레일은 보안, 규정 준수, 운영 거버넌스를 구현하는 SCP, RCP, AWS Config 규칙입니다.

AWS Control Tower는 AWS Organizations에서 추상화, 자동화 및 규범적 환경을 제공합니다. AWS Organizations를 자동으로 기본 AWS 서비스로 설정하여 계정을 구성하고 SCP 및 RCP를 사용해 예방 가드레일을 구현합니다. Control Tower와 Organizations는 함께 작동합니다. Control Tower를 사용하여 환경과 가드레일을 설정할 수 있으며, 그런 다음 AWS Organizations를 사용하여 AWS 서비스와 다중 AWS 계정의 리소스 사용을 중앙에서 제어하는 사용자 지정 정책(예: 태그, 백업 또는 SCP)을 추가로 생성할 수 있습니다.

가드레일은 보안, 운영 및 규정 준수에 대해 사전 패키징된 SCP 및 AWS Config 거버넌스 규칙으로, 고객들은 이를 전사적으로 또는 특정 계정 그룹에 대해 선택하고 적용할 수 있습니다. 가드레일은 평이한 영어로 표현되며, 조직 단위(OU) 내에서 활성화될 수 있는 AWS 환경에 대해 특정 거버넌스 정책을 적용합니다.

AWS Control Tower는 기본 모범 사례를 통해 다중 계정 AWS 환경을 생성하거나 관리하고자 하는 고객을 위한 서비스입니다. AWS Control Tower는 규모에 따라 AWS 환경을 관리하기 위한 규범적 지침을 제시하고 AWS가 빌더에게 제공하는 속도와 민첩성을 훼손하지 않으면서 환경을 제어할 수 있게 합니다. 새로운 AWS 환경을 구축하거나, 새로운 클라우드 이니셔티브를 시작하거나, AWS를 완전히 처음 시작하거나, 기존의 다중 계정 AWS 환경을 보유하고 있는 경우 AWS Control Tower의 다양한 이점을 누릴 수 있습니다.

조직이란 계층 구조로 구성하고 중앙에서 관리할 수 있는 AWS 계정 모음입니다.

AWS 계정은 AWS 리소스용 컨테이너입니다. AWS 계정 내에 AWS 리소스를 생성하고 관리할 수 있으며, AWS 계정은 액세스 및 결제에 대한 관리 기능을 제공합니다.

환경을 확장하려는 경우 다중 AWS 계정 환경을 사용하는 것이 가장 좋습니다. 비용에 대해 자연스러운 결제 경계를 제공하고, 보안용 리소스를 분리하며, 개인과 팀에 유연성을 제공할 뿐만 아니라 새로운 비즈니스 프로세스에 대해서도 조정할 수 있기 때문입니다.

관리 계정은 조직을 생성하는 데 사용하는 AWS 계정입니다. 관리 계정에서 조직 내 다른 계정을 생성하고, 다른 계정이 조직에 가입하도록 초대하고 초대를 관리하며, 조직에서 계정을 제거할 수 있습니다. 또한, 조직 내 관리 루트, 조직 단위(OU) 또는 계정과 같은 엔터티에 정책을 연결할 수 있습니다. 관리 계정은 조직의 최고 소유자로, 보안, 인프라 및 금융 정책을 최종적으로 제어합니다. 관리 계정은 지급 계정 역할을 가지며 조직 내 계정에 의해 발생하는 모든 요금의 지급을 담당합니다. 조직의 어느 계정을 관리 계정으로 할지는 변경할 수 없습니다.

멤버 계정은 관리 계정이 아니면서 조직의 일부인 AWS 계정을 말합니다. 조직의 관리자인 경우 조직에 멤버 계정을 만들고, 조직에 가입하도록 기존 계정을 초대할 수 있습니다. 또한, 멤버 계정에 정책을 적용할 수도 있습니다. 멤버 계정은 한 번에 하나의 조직에만 속할 수 있습니다.

관리 루트는 관리 계정에 포함되며 AWS 계정을 구성하는 시작점입니다. 관리 루트는 조직의 계층 구조 중 가장 상위에 있는 컨테이너입니다. 이 루트 아래에 OU를 생성하여 논리적으로 계정을 그룹화하고 이러한 OU를 비즈니스 요구 사항에 가장 잘 맞는 계층 구조로 구성할 수 있습니다.

조직 단위(OU)는 조직 내 AWS 계정 그룹입니다. 또한, OU는 다른 OU를 포함할 수 있으므로 사용자가 계층 구조를 생성할 수 있습니다. 예를 들어, 동일한 부서에 속하는 모든 계정을 부서별 OU로 그룹화할 수 있습니다. 마찬가지로, 보안 서비스를 실행하는 모든 계정을 보안 OU로 그룹화할 수 있습니다. OU는 조직의 계정 하위 집합에 동일한 제어 항목을 적용해야 하는 경우 유용합니다. 중첩 OU를 사용하면 더 작은 관리 단위를 만들 수 있습니다. 예를 들어, 각 워크로드에 대해 OU를 생성한 다음, 각 워크로드 OU에서 중첩된 OU를 2개 생성하여 프로덕션 전 단계에서 프로덕션 워크로드를 분할할 수 있습니다. 이러한 OU는 팀 수준 OU에 직접 지정된 제어 항목뿐만 아니라 상위 OU로부터 정책을 상속받습니다.

정책은 AWS 계정 그룹에 적용하려는 제어 항목을 정의하는 하나 이상의 문으로 된 '문서'입니다. AWS Organizations는 다음 정책을 지원합니다.

• 백업 정책—지정된 케이던스에서 AWS 백업을 요구
• 태그 정책—태그 키 및 허용되는 값을 정의
• AI 서비스 옵트아웃 정책—AI 서비스가 콘텐츠를 저장 또는 사용하는 방식 제어
• 서비스 제어 정책(SCP)—SCP는 조직 내 다른 계정에서 사용할 수 있는 AWS 서비스 작업(예: Amazon EC2 RunInstances)을 정의합니다.

중국에서 관리되는 조직을 제외한 모든 조직 엔터티는 전 세계에서 액세스할 수 있습니다. 이는 현재 AWS Identity and Access Management(IAM)가 작동하는 방식과 유사합니다. 조직을 생성 및 관리할 때 AWS 리전을 지정할 필요는 없지만, 중국에서 사용되는 계정에 대해서는 개별 조직을 생성해야 합니다. AWS 계정의 사용자는 해당 서비스가 제공되는 모든 지리적 리전에서 AWS 서비스를 사용할 수 있습니다.

아니요. 관리 계정을 다른 AWS 계정으로 변경할 수는 없습니다. 따라서 관리 계정은 주의해서 선택해야 합니다.

다음 두 가지 방법 중 하나를 사용하여 AWS 계정을 조직에 추가할 수 있습니다.

방법 1: 조직에 가입하도록 기존 계정 초대

1. 관리 계정의 관리자로 로그인하고 AWS Organizations 콘솔로 이동합니다.

2. Accounts 탭을 선택합니다.

3. Add account를 선택한 다음, Invite account를 선택합니다.

4. 초대하려는 계정의 이메일 주소 또는 계정의 AWS 계정 ID를 입력합니다.

참고: 이메일 주소 또는 AWS 계정 ID 목록을 쉼표로 구분하여 입력하면 두 개 이상의 AWS 계정을 초대할 수 있습니다.

지정한 AWS 계정으로 조직에 가입하도록 초대하는 이메일이 전송됩니다. 초대를 받은 AWS 계정의 관리자는 AWS Organizations 콘솔, AWS CLI 또는 Organizations API를 사용하여 요청을 수락하거나 거절해야 합니다. 관리자가 초대를 수락하면, 조직의 멤버 계정 목록에 해당 계정이 표시됩니다. SCP 등 적용 가능한 정책이 새로 추가된 계정에 자동으로 적용됩니다. 예를 들어 조직의 루트에 SCP가 연결되어 있다면, 새로 생성된 계정에 해당 SCP가 바로 적용됩니다.

방법 2: 조직에 AWS 계정 생성

1. 관리 계정의 관리자로 로그인하고 AWS Organizations 콘솔로 이동합니다.

2. Accounts 탭을 선택합니다.

3. Add account를 선택한 다음 Create account를 선택합니다.

4. 계정의 이름 및 계정의 이메일 주소를 입력합니다.

AWS SDK나 AWS CLI를 사용하여 계정을 생성할 수도 있습니다. 두 가지 방법 모두, 새 계정을 추가한 후에 이를 조직 단위(OU)로 이동할 수 있습니다. 새 계정은 해당 OU에 연결된 정책을 자동으로 상속받습니다.

아니요. 하나의 AWS 계정은 한 번에 하나의 조직 멤버만 될 수 있습니다.

AWS 계정을 생성하는 과정에서 AWS Organizations는 새 계정에 대한 전체 관리 권한이 있는 IAM 역할을 생성합니다. 적절한 권한이 있는 마스터 계정의 IAM 사용자 및 IAM 역할은 이 역할을 맡아 새로 생성된 계정에 액세스할 수 있습니다.

아니요. 이 작업은 현재 지원되지 않습니다.

예. 하지만 먼저 조직에서 해당 계정을 제거하여 독립형 계정으로 만들어야 합니다(아래 참조). 해당 계정을 독립형으로 만든 후에 다른 조직에 합류하도록 초대할 수 있습니다.

예. AWS Organizations 콘솔, API 또는 CLI 명령을 사용하여 조직에 계정을 생성하면, AWS에서 독립형 계정에 필요한 정보를 전혀 수집하지 않습니다. 독립형으로 사용하려는 각 계정에서 이러한 정보를 업데이트해야 합니다. 여기에는 계약 정보 제공, 유효한 결제 수단 제공, Support 플랜 옵션 선택이 포함될 수 있습니다. AWS에서는 이 결제 수단을 사용해 해당 계정이 조직에 연결되어 있지 않을 때 발생하는 모든 청구 가능한 AWS 활동(AWS 프리 티어 이외)에 대해 비용을 청구합니다. 자세한 내용은 조직에서 멤버 계정 제거를 참조하세요.

이는 경우에 따라 다릅니다. 계정을 추가해야 하는 경우 AWS 지원 센터로 이동한 다음 지원 케이스를 열어 증가를 요청하세요.

다음 두 가지 방법 중 하나로 멤버 계정을 제거할 수 있습니다. Organizations를 사용해 생성한 계정을 제거하기 위해서는 추가 정보를 제공해야 할 수도 있습니다. 계정 제거를 시도하였지만 실패하는 경우, AWS 지원 센터로 이동하여 계정 제거에 대한 지원을 요청하세요.

방법 1: 관리 계정으로 로그인하여 초대된 멤버 계정 제거

1. 마스터 계정의 관리자로 로그인하고 AWS Organizations 콘솔로 이동합니다.

2. 왼쪽 창에서 계정을 선택합니다.

3. 제거하려는 계정을 선택한 다음 계정 제거를 선택합니다.

4. 계정에 유효한 결제 방법이 없다면 이를 제공해야 합니다.

방법 2: 멤버 계정으로 로그인하여 초대된 멤버 계정 제거

1. 조직에서 제거하려는 멤버 계정의 관리자로 로그인합니다.

2. AWS Organizations 콘솔로 이동합니다.

3. *[조직 나가기(Leave organization)]*를 선택합니다.

4. 계정에 결제 방법이 없다면 이를 제공해야 합니다.

OU를 생성하려면 다음 단계를 따르십시오.

1. 관리 계정의 관리자로 로그인하고 AWS Organizations 콘솔로 이동합니다.

2. 계정 구성 탭을 선택합니다.

3. OU를 생성하려는 계층 구조로 이동합니다. 루트 바로 아래에 OU를 생성하거나 다른 OU 내에 OU를 생성할 수 있습니다.

4. 조직 단위 생성을 선택하고 OU 이름을 입력합니다. 이 이름은 조직 내에서 고유해야 합니다.

참고: OU 이름은 나중에 바꿀 수 있습니다.

이제 OU에 AWS 계정을 추가할 수 있습니다. AWS CLI 및 AWS API를 사용하여 OU를 생성하고 관리할 수도 있습니다.

다음 단계를 따라 OU에 멤버 계정을 추가합니다.

1. AWS Organizations 콘솔에서 Organize accounts 탭을 선택합니다.

2. AWS 계정을 선택한 다음, Move account를 선택합니다.

3. 대화 상자에서 AWS 계정을 이동하려는 대상 OU를 선택합니다.

아니면 AWS CLI와 AWS API를 사용하여 AWS 계정을 OU에 추가할 수도 있습니다.

아니요. 하나의 AWS 계정은 한 번에 하나의 OU 멤버만 될 수 있습니다.

아니요. OU는 한 번에 하나의 OU 멤버만 될 수 있습니다.

OU를 5개 레벨까지 중첩할 수 있습니다. 계층 구조는 루트와 가장 낮은 OUT에 생성된 AWS 계정을 포함하여 5개의 레벨로 구성될 수 있습니다.

조직의 루트(조직의 모든 계정에 적용), 중첩된 OU를 포함하여 OU의 모든 계정에 적용되는 개별 조직 단위(OU) 또는 개별 계정에 정책을 연결할 수 있습니다.

다음 두 가지 방법 중 하나로 정책을 연결할 수 있습니다.

• AWS Organizations 콘솔에서, 정책을 지정하려는 위치(루트, OU 또는 계정)로 이동한 다음, 정책 연결을 선택합니다.
• Organizations 콘솔에서 정책 탭을 선택하고 다음 중 하나를 수행합니다.
  기존 정책을 선택하고 작업 드롭다운 목록에서 정책 연결을 선택한 다음, 정책을 연결하려는 루트, OU 또는 계정을 선택합니다.
• 정책 생성을 선택한 다음, 정책 생성 워크플로우의 한 부분으로 새로운 정책을 연결하려는 루트, OU 또는 계정을 선택합니다.

자세한 내용은 정책 관리 섹션을 참조하세요.

예. 예를 들어, 애플리케이션 개발 단계(DEV, TEST 및 PROD)에 따라 AWS 계정을 OU에 구성했다고 가정합니다. 정책 P1은 조직의 루트에 연결되고, 정책 P2는 DEV OU에 연결되고, 정책 P3은 DEV OU의 AWS 계정 A1에 연결됩니다. 이러한 설정에서 P1+P2+P3은 모두 계정 A1에 연결됩니다.
자세한 내용은 서비스 제어 정책 정보 섹션을 참조하세요.

현재, AWS Organizations는 다음 정책을 지원합니다.

• 백업 정책—AWS Backup을 사용하여 지정된 케이던스에서 AWS 백업을 요구
• 태그 정책—태그 키 및 허용되는 값을 정의
• AI 서비스 옵트아웃 정책—AI 서비스가 조직에서 콘텐츠를 저장 또는 사용하는 방식 제어
• 서비스 제어 정책(SCP)—SCP가 적용되는 계정의 IAM 사용자, 그룹 및 역할이 수행할 수 있는 작업을 정의하고 적용

서비스 제어 정책(SCP)을 사용하면 조직의 계정 내 보안 주체(계정 루트, IAM 사용자 및 IAM 역할)에 액세스할 수 있는 AWS 서비스 작업을 제어할 수 있습니다. 계정의 보안 주체에 리소스에 대한 액세스 권한을 부여하기 위해서는 SCP가 필요하긴 하지만, 리소스에 액세스할 수 있는 계정의 보안 주체를 결정하는 유일한 제어 항목은 아닙니다. SCP가 연결되어 있는 계정 내 보안 주체의 실질적인 권한은 SCP에서 명시적으로 허용하는 권한과 해당 보안 주체에 연결된 권한에서 명시적으로 허용하는 권한의 교집합입니다. 예를 들어, 계정에 적용된 SCP에서 허용하는 유일한 작업이 Amazon EC2 작업이고, 동일한 AWS 계정 내 보안 주체의 권한이 EC2 작업 및 Amazon S3 작업을 모두 허용하는 경우, 보안 주체는 EC2 작업에만 액세스할 수 있습니다.
멤버 계정의 보안 주체(멤버 계정의 루트 사용자 포함)는 해당 계정에 적용된 SCP를 제거하거나 변경할 수 없습니다.  

SCP는 IAM 정책과 동일한 규칙과 문법을 따릅니다. SCP 구문에 대한 자세한 내용은 SCP 구문을 참조하세요. SCP 예시는 서비스 제어 정책 예시를 참조하세요.  

{ 

 "Version":"2012-10-17", 

 "Statement":[ 

 { 

 "Effect":"Allow", 

 "작업":["EC2:*","S3:*"], 

 "리소스":"*" 

 } 

 ] 

 }

블랙리스트 예제
다음은 S3 작업인 PutObject를 제외한 모든 AWS 서비스 작업에 대한 액세스를 허용하는 SCP입니다. 이 SCP가 적용된 계정에서 적절한 권한이 직접 지정된 모든 보안 주체(계정 루트, IAM 사용자 및 IAM 역할)는 S3 PutObject 작업을 제외한 모든 작업에 액세스할 수 있습니다. 

{ 

 "Version":"2012-10-17", 

 "Statement":[ 

 { 

 "Effect":"Allow", 

 "작업": "*:*", 

 "리소스":"*" 

 }, 

 { 

 "Effect":"Deny", 

 "Action":"S3:PutObject", 

 "리소스":"*" 

 } 

 ] 

 }

자세한 내용은 SCP 사용 전략을 참조하세요.

아니요. SCP는 IAM 정책과 같은 방식으로 작동합니다. 빈 IAM 정책은 기본 거부에 해당합니다. 빈 SCP를 계정에 연결하는 것은 모든 작업을 명시적으로 거부하는 정책을 연결하는 것과 같습니다.

SCP가 적용된 AWS 계정 내 보안 주체(계정 루트, IAM 사용자 및 IAM 역할)에 부여된 실질적인 권한은 SCP에서 허용한 권한과 IAM 권한 정책에서 보안 주체에 부여한 권한의 교집합입니다. 예를 들어 IAM 사용자가 "Allow": "ec2:* " 및 "Allow": "sqs:* " 권한을 가지고 있고 계정에 연결된 SCP가 "Allow": "ec2:* " and "Allow": "s3:* "인 경우, IAM 사용자의 최종 권한은 "Allow": "ec2:* "입니다. 이 보안 주체는 Amazon SQS 작업도 수행할 수 없고(SCP에서 허용하지 않음) S3 작업도 수행할 수 없습니다(IAM 정책에서 허용하지 않음).

예. IAM 정책 시뮬레이터에 SCP의 영향을 포함할 수 있습니다. 조직의 멤버 계정으로 정책 시뮬레이터를 사용하여 해당 계정의 개별 보안 주체에 대한 영향을 파악할 수 있습니다. 적절한 AWS Organizations 권한이 있는 멤버 계정의 관리자는 SCP가 멤버 계정 내 보안 주체(계정 루트, IAM 사용자 및 IAM 역할)의 액세스 권한에 영향을 주는지 확인할 수 있습니다.
자세한 내용은 서비스 제어 정책 섹션을 참조하세요.

예. 적용하려는 정책을 결정하면 됩니다. 예를 들어, 통합 결제 기능의 장점만 활용하는 조직을 생성할 수 있습니다. 즉, 조직의 모든 계정에 대해 단일 지급 계정을 사용함으로써, 기본적인 차등가격제 혜택을 자동으로 받을 수 있습니다.

RCP는 조직의 AWS 리소스에 대한 예방적 제어를 정의하고 적용하는 데 사용할 수 있는 AWS Organizations 정책입니다. RCP를 사용하면 AWS에서 워크로드를 확장할 때 AWS 리소스에 사용 가능한 최대 권한을 중앙에서 설정할 수 있습니다. 예를 들어 RCP는 조직에 속한 ID만 액세스할 수 있도록 하거나 조직 외부 ID가 액세스할 수 있는 조건을 지정하여 리소스에 대한 액세스를 제한하는 데 도움이 될 수 있습니다.

RCP의 예는 설명서 페이지를 참조하세요. RCP의 일반적인 예는 다음과 같습니다.

• 혼동된 대리자 방지 적용
• 리소스에 대한 HTTPS 연결만 허용
• 일관된 Amazon S3 버킷 정책 제어

SCP와 RCP는 서로 독립적입니다. SCP 또는 RCP만 사용하도록 선택하거나 두 정책 유형을 함께 사용할 수 있습니다. SCP는 멤버 계정의 IAM 사용자 및 역할에 사용 가능한 최대 권한을 허용합니다. 조직 내 위탁자에 대한 일관된 액세스 제어를 중앙에서 적용하려는 경우 SCP를 사용할 수 있습니다. 여기에는 사용자 및 역할이 액세스할 수 있는 AWS 서비스, 액세스할 수 있는 리소스 또는 요청을 수행할 수 있는 조건(예: 특정 리전 또는 네트워크에서)을 지정하는 것이 포함될 수 있습니다. RCP를 사용하면 조직의 리소스에서 사용 가능한 최대 권한을 제한할 수 있습니다. 조직 내 리소스에 대한 일관된 액세스 제어를 중앙에서 적용하려는 경우 RCP를 사용할 수 있습니다. 예를 들어 리소스에 액세스할 수 있는 권한을 가진 사용자를 제한하거나 리소스에 액세스할 수 있는 방법에 대한 요구 사항을 적용할 수 있습니다(예: HTTPS를 통한 암호화된 연결을 통해서만 액세스 허용). RCP를 지원하는 AWS 서비스의 리소스(예: 모든 S3 버킷)에 적용되는 제어를 지정할 수 있습니다. 

AWS Organizations는 추가 비용 없이 제공됩니다.

관리 계정의 소유자가 조직의 계정에서 사용하는 모든 사용량, 데이터 및 리소스에 대한 비용을 지불해야 합니다.

아니요. 현재는 조직에 정의한 구조가 비용 청구서에 반영되지 않습니다. 개별 AWS 계정에 비용 할당 태그를 사용하면 AWS 비용을 분류하고 추적할 수 있으며, 조직의 통합 결제에 이러한 할당 내용이 표시됩니다.

AWS 서비스는 AWS Organizations에 통합되어 고객에게 조직의 여러 계정에 걸쳐 중앙화된 관리 및 구성을 제공합니다. 이를 통해 하나의 위치에서 여러 계정에 걸쳐 서비스를 관리할 수 있으므로 배포와 구성을 단순화합니다.

AWS Organizations에 통합된 AWS 서비스 목록은 AWS Organizations와 함께 사용할 수 있는 AWS 서비스를 참조하세요.

AWS Organizations에 통합된 AWS 서비스의 사용을 시작하려면 AWS Management Console에서 해당 서비스로 이동하고 통합을 활성화합니다.