Amazon Web Services 한국 블로그

AWS Organizations – 정책 기반 멀티 계정 조직 관리 서비스 정식 출시

많은 AWS 고객이 여러 개의 AWS 계정을 관리하고 있습니다. 이러한 상황은 여러 가지 이유로 발생할 수 있습니다. 때로는 점진적인 개발 방식의 진화에 따라 서비스 팀과 부서가 분산되어 진화 하는 경우나, 합병 및 인수를 통해 성장하는 경우도 기존 계정을 사용해야 합니다. 표준 규정 준수를 위한 엄격한 가이드 라인을 준수하거나 개발, 테스트 및 정식 서비스을 위해 별개의 계정을 사용하여 애플리케이션 테스트 및 배포를 할 때 이를 격리하기 위해 여러 계정을 정기적으로 생성합니다.

계정이 많아지면 확장성 높은 방식의 관리가 필요합니다. 팀 단위, 부서 단위 또는 애플리케이션 단위의 수 많은 계정을 따로 관리하는 대신 전체 계정, 일부 계정 또는 개별 계정에 쉽게 적용 할 수 있는 접근 제어 정책이 필요하다는 피드백을 많이 받았습니다. 대부분의 경우 이러한 고객은 요금 청구 및 비용 관리에 관심이 있으며, 대량 할인 및 예약 인스턴스와 같은 AWS 가격 책정이 각 계정에 적용되는 관리하고자 합니다.

AWS Organizations 정식 출시
이러한 요구 사항을 지원하기 위해 만든 AWS Organizations 서비스를 미리보기에서 정식으로 출시합니다. 본 서비스를 사용하여 조직 단위(OU)의 계층 구조를 만들고, OU에 각 계정을 할당하고, 정책을 정의한 다음 전체 계층 구조에 적용하고, OU를 선택하거나, 또는 OU를 선택하여 여러 AWS 계정을 중앙에서 관리 할 수 ​​있습니다. 기존 AWS 계정을 조직에 가입하도록 초대 할 수 있으며 새 계정을 만들 수도 있습니다. 이 모든 기능은 AWS 관리 콘솔,  AWS 명령어 모드 (CLI), AWS Organizations API를 사용할 수 있습니다.

다음은 본 서비스를 을 이해하는 데 도움이 되는 몇 가지 중요한 용어 및 개념입니다 (사용자가 AWS 멀티 계정 전체와 마스터 계정을 담당하고 있다고 가정합니다.)

Organization은  여러분이 관리하는 통합 AWS 계정 세트입니다. 새로 생성 된 Organization에서는 서비스 제어 정책과 같은 정교한 계정 제어 기능 구현할 수 있습니다. 이를 통해 조직 관리자는 허용 및 차단 AWS API 함수 목록과 개별 계정에  배치하고, 리소스를 관리 할 수 ​​있습니다. 예를 들어, R&D 팀에 다양한 AWS 서비스에 대한 접근 권한을 부여한 후, 개발 및 테스트 계정에 대해 좀 더 엄격한 접근 제어를 할 수 있습니다. 또는, 정식 서비스에는 (의료 정보만을 다루는 규정을 준수하는) HIPAA 자격이 있는 AWS 서비스에만 액세스 할 수 있습니다.

기존 고객 중 일부는 AWS 통합 결제 (Consolidated Billing) 기능을 사용합니다. 이를 통해 여러 AWS 계정에서 계정 사용량을 하나의 청구서(Invoice)로 모아서  비용을 추적하는 중앙 집중식 방법을 제공하는 최종 지불 계정을 선택할 수 있습니다.

이번 출시와 함께 현재 통합 결제를 사용하는 고객은 모든 기능을 제공하는 가상 조직을 갖게 되었습니다. 그러나, 기본적으로 현재 제공되는 새로운 기능 (예 :서비스 제어 정책)은 없습니다. 이러한 고객은 AWS Organization의 모든 기능을 쉽게 사용할 수 있습니다. 이는 조직의 마스터 계정에서 모든 Organization 기능을 사용하도록 설정 한 다음 각 구성원 계정으로 조직에 대한 변경 사항을 승인하도록 할 수 있습니다. (통합 결제 기능 만 지원하는 새로운 조직을 만드는 것을 계속 지원할 것입니다. 통합 결제 기능만 사용하려는 고객은 마스터 계정 관리자가 조직의 구성원 계정에 대한 고급 정책 제어를 시행하지 않고도 계속해서 그렇게 할 수 있습니다.)

먼저 AWS account는 AWS  자원을 가지고 있습니다. 이 중 Master 계정은 전체 조직의 관리 허브이며, 모든 AWS 계정에 대한 지불 계정이기도 합니다. 마스터 계정은 기존 계정을 가입하도록 초대 할 수 있으며 새 계정을 만들 수도 있습니다.

Member accounts는 조직의 비 마스터 계정입니다. Organizational Unit (OU) 은 AWS 계정 세트의 컨테이너입니다. OU는 최대 5 단계까지 계층 구조로 정렬 할 수 있습니다. OU 계층 구조의 최상위를 Administrative Root라고도 합니다. .

Service Control Policy (SCP)는 조직의 마스터 계정이 조직, 각 OU 또는 계정에 적용 할 수 있는 일련의 제어 방법입니다. OU에 적용되면, OU와 그 하위 계층의 다른 OU에 적용됩니다. 계정에 SCP를 적용하면, 해당 계정의 루트 사용자에게 부여 된 사용 권한을 지정합니다. 계정 내에서 IAM 사용자 및 역할을 평소와 같이 사용할 수 있습니다. 그러나, 사용자 또는 역할의 권한과 관계없이 SCP에 정의 된 것 이상으로 확장되지 않습니다. 이를 사용하여 계정 수준에서 AWS 서비스 및 API 기능에 대한 접근을 세부적으로 제어 할 수 있습니다.

Invitation은 AWS 계정에 가입을 요청하는 데 사용합니다. 15 일 이내에 수락해야 하며 이메일 주소 또는 계정 ID에 대해 연장할 수 있습니다. 최대 20 회의 초대장이 주어진 시간에 미해결 상태가 될 수 있습니다. 초대 기반 모델을 사용하면 마스터 계정에서 시작하여 기존 계정을 접을 수 있습니다. 초대장이 수락되면 계정이 조직에 가입하며 모든 적용 가능한 정책이 효력을 발생합니다. 계정이 조직에 가입하면 적절한 OU로 이동할 수 있습니다.

AWS Organizations 관리하는 AWS 계정간에 강력한 격리 경계를 만들려는 경우에 적합합니다. 그러나 AWS 리소스 (EC2 인스턴스, S3 버킷 등)는 특정 AWS 계정 내에 존재하며 한 계정에서 다른 계정으로 이동할 수 없습니다. VPC 피어링, AMI 공유, EBS 스냅샷 공유, RDS 스냅샷 공유, 멀티 계정 이메일 전송, IAM 역할 별 권한 배정, 멀티 계정 S3 버킷 접근, 멀티 계정 AWS 콘솔 접근 등 여러 가지 교차 계정 AWS 기능에 접근할 수 있습니다.

통합 결제와 마찬가지로 AWS Organizations은 EC2 및 RDS 예약 인스턴스를 사용할 때, 몇 가지 이점을 제공합니다. 과금 청구의 경우, 조직의 모든 계정은 하나의 계정 인 것처럼 취급되며 동일한 조직의 다른 계정으로 구입 한 RI의 시간당 비용 혜택을받을 수 있습니다 (이 혜택이 예상대로 적용될 수 있도록, 가용성 구역 및 RI의 기타 속성은 EC2 또는 RDS 인스턴스의 속성과 일치해야합니다.

Organization 만들기
처음 부터 직접 시작해 보겠습니다. AWS 관리 콘솔에서 신규 조직을 만들고  조직 단위를 만든 다음, 계정을 연결하거나 만듭니다. Create organization를 클릭하여 시작합니다.

그런 다음 ENABLE ALL FEATURES을 선택하고 Create organization를 클릭하십시오.

몇 초 내에 구성을 완료합니다.

Add account를 클릭 한 다음 Create account를 선택하여 새 계정을 만들 수 있습니다.

그런 다음 세부 정보를 제공합니다 (IAM 역할은 새 계정에서 생성되고 계정이 생성 된 후, 맞춤 사용자 정의를 통해 충분한 권한을 부여합니다).

Dev, Test 및 Prod 계정을 만든 후에 콘솔 모습은 다음과 같습니다.

이 시점에서 모든 계정이 계층 구조의 맨 위에 있습니다.

계층 구조를 추가하려면 Organize accounts을 클릭하고 Create organizational unit (OU)을 선택한 다음 이름을 입력하십시오.

두 번째 OU에 대해서도 동일한 작업을 수행합니다.

그런 다음 Prod 계정을 선택하고 Move accounts을 클릭 한 다음, 이동할 해당 조직(Operations OU)를 선택합니다.

다음으로 개발 및 테스트 계정을 개발 OU로 이동합니다.

현재 4개의 계정 (원래 만든 계정과 방금 만든 계정)과 2 개의 OU를 가지고 있습니다. 다음 단계는 Policies을 클릭하고 Create policy을 선택하여 하나 이상의 서비스 제어 정책을 작성하는 것입니다. Policy Generator를 사용하거나 기존 SCP를 복사 한 다음, 설정할 수 있습니다. Policy Generator를 사용하겠습니다. 내 정책에 이름을 지정하고 Allow으로 지정합니다.

그런 다음 Policy Generator를 사용하여 EC2 및 S3에 대한 전체 접근 권한과 Lambda 함수를 실행 (호출) 할 수 있는 정책을 구성합니다.

이 정책은 계정 내에서 허용되는 모든 행위를 정의합니다. 계정 내의 IAM 사용자가 이러한 작업을 사용하려면, 적절한 IAM 정책을 만들어 사용자 (모두 회원 계정 내)에 연결해야 합니다. Create policy을 클릭하면 정책을 만들 수 있습니다.

그런 다음 개발 및 테스트를 위한 두 번째 정책을 만듭니다. AWS CodeCommit, AWS CodeBuild, AWS CodeDeploy, AWS CodePipeline에 접근 할 수 있습니다.

요약하면, AWS 계정을 OU에 넣고 이에 대한 정책을 만들었습다. 이제 정책 사용을 활성화하고 OU에 정책을 첨부해야합니다. 정책을 사용하려면 Organize accounts을 클릭하고 Home 을 선택합니다 (조직이 여러 개의 독립적인 계층 구조를 지원하도록 설계 되었기 때문에 루트를 의미하는 게 아닙니다). 그런 다음 최상위 OU의 확인란을 클릭합니다. 그런 다음 오른쪽에서 Details 섹션을 확장하고 Enable을 클릭합니다.

이제 이를 모두 통합해 보겠습니다! 최상위 OU를 클릭하여 계층 구조로 내린 다음 Operations OU의 확인란을 클릭합니다. 그런 다음 오른쪽의 Control Policies을 확장하고 Attach policy을 클릭하십시오.

그런 다음 OperationsPolicy를 찾아 첨부를 클릭합니다.

마지막으로 FullAWSAccess 정책을 제거합니다.

DevTestPolicy를 Development OU에 연결할 수도 있습니다.

위에서 설명한 모든 작업은 AWS Command Line Interface (CLI)에서 시작하거나  CreateOrganization, CreateAccount, CreateOrganizationalUnit, MoveAccount, CreatePolicy, AttachPolicy, and InviteAccountToOrganization과 같은 함수를 호출하여 시작할 수 있습니다. 실제 CLI를 보려면 Announcing AWS Organizations: Centrally Manage Multiple AWS Accounts를 살펴 보시기 바랍니다.

서비스 활용 시 모범 사례
AWS Organizations 서비스에 대한 몇 가지 모범 사례를 알려드립니다.

  • Master Account 리소스 사용 금지– 한 가지 예외를 제외하고는 마스터 AWS 리소스를 사용하지 않는 것이 좋습니다. 이를 통해 고품질 제어 결정을 보다 쉽게 ​​수행 할 수 있을 뿐만 아니라 AWS 청구서 항목을 더 쉽게 이해할 수 있습니다.
  • CloudTrail 활용 – 마스터 계정에서 (뛰어난 기능을 가진) AWS CloudTrail을 사용하여 회원 계정의 모든 AWS 사용 현황을 추적합니다.
  • 최소 권한 부여 – OU에 대한 정책을 설정할 때 최대한 적은 권한을 할당하십시오..
  • 조직 구성 단위 (OU) 활용 – 계정이 아닌 OU에 정책을 할당합니다. 이렇게 하면 조직 구조와 필요한 AWS 접근 수준 간의 매핑을 잘 유지할 수 있습니다.
  • 테스트 필수 – 규모를 확대하기 전에 단일 계정에서 새 정책과 수정 된 정책을 테스트합니다
  • 자동화 – API와 AWS AWS CloudFormation 템플릿을 사용하여 새로 생성 된 모든 계정이 원하는 대로 구성합니다. 템플릿은 IAM 사용자, 역할 및 정책을 만들 수 있습니다. 또한 로깅을 설정하고 VPC를 만들고 구성 할 수 있습니다.

자세한 정보
아래는 WS Organizations 서비스를 시작하는 데 도움이 되는 정보 모음입니다.

정식 출시
AWS Organizations은 현재 중국 (베이징) 및 AWS GovCloud (US) (미국)를 제외한 모든 AWS 리전에서 무료로 사용할 수 있습니다. (서비스 엔드포인트인 미국 동부 (버지니아 북부) 및 SCP는 모든 관련 리전에 적용됩니다). 모든 AWS 계정은 동일한 회사의 계정이어야 하며, 동일한 조직에서 AWS와 AISPL (인도 AWS 서비스 계정의 리셀러 역할을 하는 현지 법인)을 혼합 할 수 없습니다.

앞으로 Organizations 서비스에 대한 많은 서비스 계획을 가지고 있으며, 현재 다중 지불 지원 추가, 예약 인스턴스 할인 할당, 다중 계층 구조 및 기타 제어 정책 추가를 고려 중입니다. 항상 여버룬의 의견과 제안은 환영합니다.

— Jeff;

이 글은 AWS Organizations – Policy-Based Management for Multiple AWS Accounts의 한국어 번역입니다.