AWS 다중 계정 결제 전략

10 min readDec 20, 2019

[ 고지 사항 (Disclaimer) ]

본 컨텐츠는 고객의 편의를 위하여 AWS 서비스 설명을 위해 제작, 제공된 것입니다. 만약 AWS 사이트와 컨텐츠 상에서 차이나 불일치가 있을 경우 AWS 사이트 (AWS.amazon.com)가 우선합니다. 또한 AWS 사이트 상에서 한글 번역문과 영어 원문에 차이나 불일치가 있을 경우(번역의 지체로 인한 경우 등 포함), 영어 원문이 우선합니다.

본 문서는 AWS Multiple Account Billing Strategy 내용에 기반하여 작성 되었습니다.

이 문서는 정보 제공의 목적으로만 제공됩니다. 본 문서의 발행일 당시 AWS의 현재 제품 오퍼링 및 실행방법 등을 설명하며, 예고 없이 변경될 수 있습니다. 고객은 본 문서에 포함된 정보나 AWS 제품 또는 서비스의 사용을 독립적으로 평가할 책임이 있으며, 각 정보 및 제품은 명시적이든 묵시적이든 어떠한 종류의 보증 없이 “있는 그대로” 제공됩니다. 본 문서는 AWS, 그 자회사, 공급업체 또는 라이선스 제공자로부터 어떠한 보증, 표현, 계약 약속, 조건 또는 보장을 구성하지 않습니다. 고객에 대한 AWS의 책임 및 의무는 AWS 계약에 의해 관리되며 본 문서는 AWS와 고객 사이의 어떠한 계약에도 속하지 않으며 계약을 변경하지도 않습니다.

청구 목적으로 여러 AWS 계정을 관리하려면 어떻게 합니까?

고객은 AWS (Amazon Web Services)를 사용하여 AWS 클라우드로 전환 할 때 생산성, 혁신 및 비용 절감을 크게 향상시킬 수 있습니다. AWS는 클라우드 컴퓨팅 리소스 및 해당 리소스를 관리하는 AWS 계정을 유연하게 제어 할 수 있는 다양한 서비스와 기능을 제공합니다. 이러한 옵션은 적절한 비용 할당, 민첩성 및 보안을 보장하는 데 도움이 되지만 고객은 특히 여러 AWS 계정으로 작업 할 때 계정 전략을 가장 잘 구현하는 방법을 모릅니다. 이 글은 고객에게 계정 수준 고려 사항, 모범 사례 및 높은 수준의 전략적 지침을 제공하여 고객이 AWS Organizations를 사용하여 청구 목적으로 여러 AWS 계정을 구성하고 관리 할 수 있도록 도와줍니다.

다음 섹션에서는 AWS Organizations, AWS 서비스 제한, 리소스 그룹 및 태깅, AWS Identity and Access Management (IAM) 및 예약 인스턴스 (RI)에 대한 기본 지식이 있다고 가정합니다.

일반적인 모범 사례

고객은 AWS를 활용하여 속도와 비즈니스 민첩성을 향상시키므로 회사의 AWS 사용에 따라 AWS 계정 구조가 시간이 지남에 따라 변경되는 것이 일반적입니다. 따라서 여러 계정에 대한 청구 전략을 고려할 때 완벽하고 변경 불가능한 AWS 계정 집합을 만들려고 초기 계정 구조를 과도하게 엔지니어링하지 마십시오. 대신 AWS의 유연성을 활용하고 반복적인 접근 방식을 사용하여 계정을 만들고 구성하십시오. 적응성을 염두에 두고 계정 전략에 대한 다음 모범 사례를 고려하십시오.

계정을 생성하거나 관리하는 개인의 가용성에 관계없이 AWS에서 지속적으로 통신 할 수 있도록 개별 이메일 주소 대신 그룹 별칭을 계정 이메일 주소로 사용하십시오. 이렇게 하면 계정을 보다 쉽게 식별하고 구별 할 수 있습니다. 계정에 구성된 모든 알림 이메일에 대해 이 작업을 수행하십시오.
계정 전체에서 AWS 태깅 표준을 생성 및 구현하여 회사에서 AWS 리소스를 분류, 액세스 및보고하는 방식을 표준화합니다 (추가 지침은 AWS 태깅 전략 솔루션 요약 참조). 콘솔에서 수동으로 또는 자동 스크립트를 사용하여 정기적으로 준수를 확인하십시오.
AWS API 및 스크립트를 활용하여 회사의 기본 구성을 모든 AWS 계정에 자동으로 일관되게 적용하십시오. 규정 준수 모니터링 스크립트를 활용하여 귀사의 AWS 사용에 대해 정의한 정책 및 표준을 계정이 얼마나 잘 준수하는지 파악할 수 있습니다.

구현 고려 사항

다음 섹션에서는 회사의 사용 사례에 적합한 계정 구조를 식별하는 데 도움이되는 조언과 지침을 제공합니다. 반복적인 접근 방식을 염두에 두고 현재 및 미래의 운영 및 비용 모델을 평가하여 AWS 계정의 구조가 회사의 구조를 반영하는지 확인하십시오.

여러 계정을 만드는 시기

특정 고객이 보유해야 하는 AWS 계정 수에 대한 모든 규모의 답변은 없지만 대부분의 회사는 여러 계정이 최고 수준의 리소스 및 청구 격리를 제공하기 때문에 하나 이상의 AWS 계정을 생성하려고 합니다. 다음 질문 중 하나에“예”라고 대답하면 추가 AWS 계정을 만들어야한다는 것을 알 수 있습니다.

비즈니스는 특정 워크로드, 사업부 또는 비용 센터 간에 강력한 재정 및 예산 과금 분리가 필요합니까?
고객이 서로 다른 AWS 리소스 사용을 위해 다른 결제 수단을 사용하려는 경우 또는 특정 AWS 비용의 100%를 특정 애플리케이션 워크로드, 환경, 비용 센터, 사업부(BU) 또는 고객과 연결할 수 있는 기능이 필요한 경우 계정별 청구 격리가 필요합니다.
워크로드 간 관리 분리가 필요합니까?
AWS 리소스에 대해 서로 다른 수준의 관리 제어를 독립 그룹에 부여하는 가장 간단한 방법은 워크로드, 개발 수명 주기, BU 또는 데이터 민감도에 따라 계정을 분리하는 것입니다.
특정 워크로드가 특정 AWS 서비스 제한 내에서 작동해야 하며 다른 워크로드의 제한에 영향을 미치지 않아야 합니까?
고객은 AWS 계정 서비스 제한을 사용하여 특정 사업부, 개발 팀 또는 프로젝트에 제한을 가할 수 있습니다. 예를 들어 특정 프로젝트 그룹에 대한 AWS 계정을 생성하는 경우 시작할 수 있는 Amazon Elastic Compute Cloud(Amazon EC2) 또는 HPC(High Performance Computing) 인스턴스의 수를 제한할 수 있습니다.
비즈니스 워크로드는 HA(고가용성) 또는 재해 복구(DR) 용량 요구사항을 지원하기 위해 특정 인스턴스 예약에 의존합니까?
예약된 인스턴스(RI)는 개별 계정 수준에서 Amazon EC2 및 Amazon RDS(Amazon Relational Database Service)와 같은 서비스에 예약된 인스턴스 및 용량을 보장합니다.

AWS Organizations로 계정을 관리하는시기

AWS Organizations를 사용하면 AWS 계정 그룹을 생성 한 다음 해당 계정에서 정책을 중앙에서 관리 할 수 있습니다. AWS Organizations는 두 기능 세트 모두에 통합 결제를 제공하므로 조직의 마스터 계정에서 단일 결제 방법을 설정하고 각 멤버 계정의 개별 활동에 대한 송장을 받을 수 있습니다. 다음 질문 중 하나라도 “예”라고 대답하면 AWS Organizations를 사용하여 AWS 계정을 구성 할 수 있습니다.

여러 AWS 계정에 대한 결제 도구 (예 : 신용 카드 또는 구매 주문)를 재사용 하시겠습니까?
AWS 리소스 사용량을 집계하고 적용 가능한 할인을 여러 계정에 분산시켜 잠재적 인 볼륨 또는 RI 할인을 극대화 하시겠습니까?

AWS 계정 구조

AWS 계정은 기술적으로 계층적이지 않지만 AWS Organizations와 함께 OU (조직 구성 단위)를 사용하여 계정을보다 효율적으로 관리하기 위해 계층적 및 논리적 그룹을 만들 수 있습니다. 조직 당 20 개 계정의 소프트 제한과 한 수준의 결제 계층 구조에 대한 하드 제한이 있습니다. 예를 들어, 마스터 (지불) 계정은 다른 마스터 (지불) 계정과 같은 조직에 있을 수 없습니다.

다음 계정 구조는 일반적인 AWS 고객 조직, 운영 및 비용 모델을 기반으로 합니다.

사업부 (BU) 계정 구조

이 계정 구조는 AWS 운영 및 청구 관리 기능을 개별 BU에 맞추려는 고객에게 유리할 수 있습니다. 개별 단위 운영 자율성을 제공하면서 그룹, OU 또는 비용 센터로 구분 된 모든 AWS 요금에 대한 통합 청구서 및 통합보기를 회사에 제공합니다. 이 구조는 또한 AWS 리소스의 BU 소비를 기반으로 비용 경보를 트리거하는 기능을 단순화합니다.

이 구조는 일반적으로 각 BU가 자체 IT 관리, 운영 및 비용을 담당하는 분산 IT 환경에서 잘 작동합니다.

환경 수명주기 계정 구조

이 계정 구조는 AWS 운영 및 청구 제어를 애플리케이션 배포 수명주기에 맞추려는 고객에게 유리할 수 있습니다. 개발 수명주기 운영 자율성을 제공하는 동시에 개발 환경으로 구분 된 모든 AWS 요금에 대한 통합 청구서 및 통합보기를 회사에 제공합니다. 이 구조는 또한 각 개발 환경의 AWS 리소스 소비에 따라 비용 경보를 트리거하는 기능을 단순화합니다.

이 구조는 일반적으로 응용 프로그램의 수명주기 단계에 따라 다른 팀이 IT 관리와 작업을 수행하는 응용 프로그램 환경간에 엄격한 업무 분리를 통해 기존 IT 모델에서 잘 작동합니다.

프로젝트 기반 계정 구조

이 계정 구조는 제품, 애플리케이션 워크로드 또는 프로그램별로 AWS 운영 및 청구 제어를 조정하려는 고객에게 유리할 수 있습니다. 프로젝트 또는 워크로드 운영 자율성을 제공하면서 회사에 프로젝트별로 구분 된 모든 청구 내역과 통합 된 청구서를 제공합니다. 이 구조는 또한 프로젝트, 애플리케이션 워크로드 또는 프로그램의 AWS 리소스 소비를 기반으로 비용 경보를 트리거하는 기능을 단순화합니다.

이 구조는 일반적으로 단일 팀이 지정된 응용 프로그램 작업 부하를 개발하고 운영하는 DevOps 환경에서 잘 작동합니다.

하이브리드 AWS 계정 구조

앞에서 설명한 기본 계정 구조는 대부분의 소규모 회사에서 작동하지만 일부 대규모 AWS 고객은 계정을 여러 차원으로 그룹화하는 하이브리드 조합을 만드는 것이 유리하다는 것을 알았습니다. 예를 들어 DevOps 환경은 프로덕션 및 비 프로덕션 시스템간에 강력한 AWS 계정 관리 격리를 생성하여 잠재적인 변경 범위를 제한하려고 할 수 있습니다. 이 경우 회사는 프로젝트 및 응용 프로그램 수명주기별로 계정을 통합 할 수 있습니다. 마찬가지로 BU 기반 회사는 BU마다 또는 BU마다 또는 프로그램마다 다른 AWS 정책을 수용하기 위해 BU별로 여러 제품 또는 프로젝트 기반 계정을 그룹화 할 수 있습니다. 다음 다이어그램은 이러한 하이브리드 모델을 보여줍니다 (각 마스터 계정은 완전히 별개의 조직입니다).