AWS Control Tower 랜딩 존에 대한 AWS 다중 계정 전략 - AWS Control Tower
AWS 다중 계정 지침에 따라 조정Well-Architected 환경 설정 지침완전한 다중 계정 OU 구조를 갖춘 AWS Control Tower의 예루트 정보

AWS Control Tower 랜딩 존에 대한 AWS 다중 계정 전략

AWS Control Tower 고객은 종종 최상의 결과를 위해 AWS 환경 및 계정을 설정하는 방법에 대한 지침을 찾습니다. AWS에서는 다중 계정 전략이라고 하는 통합 권장 사항 세트를 통해 AWS Control Tower 랜딩 존을 비롯한 AWS 리소스를 최대한 활용할 수 있도록 지원합니다.

기본적으로 AWS Control Tower는 AWS 계정 및 AWS Organizations에 대한 AWS 다중 계정 권장 사항을 구현하는 데 도움이 되는 다른 AWS 서비스와 함께 작동하는 오케스트레이션 계층 역할을 합니다. 랜딩 존이 설정되면 AWS Control Tower는 여러 계정 및 워크로드에서 기업 정책 및 보안 관행을 유지하도록 계속 지원합니다.

대부분의 랜딩 존은 시간 경과에 따라 고도화됩니다. AWS Control Tower 랜딩 존의 조직 단위(OU) 및 계정 수가 증가하면 워크로드를 효과적으로 구성하는 데 도움이 되는 방식으로 AWS Control Tower 배포를 확장할 수 있습니다. 이 장에서는 AWS 다중 계정 전략에 따라 AWS Control Tower 랜딩 존을 계획 및 설정하고 시간 경과에 따라 확장하는 방법에 대한 규범적 지침을 제공합니다.

조직 단위의 모범 사례에 대한 일반적인 설명은 Best Practices for Organizational Units with AWS Organizations를 참조하세요.

AWS 다중 계정 전략: 모범 사례 지침

Well-Architected 환경의 AWS 모범 사례에서는 리소스와 워크로드를 여러 AWS 계정으로 분리할 것을 권장합니다. AWS 계정을 격리된 리소스 컨테이너로 생각할 수 있습니다. 이는 워크로드 분류뿐만 아니라 문제가 발생했을 때 폭발 반경을 줄여줍니다.

AWS 계정의 정의

AWS 계정은 리소스 컨테이너 및 리소스 격리 경계 역할을 합니다.

참고

AWS 계정은 페더레이션 또는 AWS Identity and Access Management(IAM)를 통해 설정된 사용자 계정과 동일하지 않습니다.

AWS 계정에 대한 자세한 정보

AWS 계정은 리소스를 격리하고 AWS 워크로드에 대한 보안 위협을 억제하는 기능을 제공합니다. 또한 이 계정은 워크로드 환경의 결제 및 거버넌스를 위한 메커니즘을 제공합니다.

AWS 계정은 워크로드에 리소스 컨테이너를 제공하기 위한 기본 구현 메커니즘입니다. Well-Architected 환경인 경우 여러 AWS 계정을 효과적으로 관리할 수 있으므로 여러 워크로드와 환경을 관리할 수 있습니다.

AWS Control Tower는 Well-Architected 환경을 설정합니다. 이는 여러 계정에 걸쳐 확장할 수 있는 환경의 변경 사항을 관리하는 데 도움이 되는 AWS Organizations와 AWS 계정에 의존합니다.

Well-Architected 환경의 정의

AWS는 Well-Architected 환경을 랜딩 존으로 시작되는 환경으로 정의합니다.

AWS Control Tower는 자동으로 설정된 랜딩 존을 제공합니다. 이는 환경의 여러 계정에서 기업 지침을 준수하도록 제어 기능을 적용합니다.

랜딩 존의 정의

랜딩 존은 기본 계정, 계정 구조, 네트워크 및 보안 레이아웃 등을 포함하여 권장 시작 지점을 제공하는 클라우드 환경입니다. 랜딩 존에서 솔루션과 애플리케이션을 활용하는 워크로드를 배포할 수 있습니다.

Well-Architected 환경 설정 지침

다음 섹션에서는 Well-Architected 환경의 세 가지 주요 구성 요소를 다음과 같이 설명합니다.

  • 여러 AWS 계정

  • 여러 조직 단위(OU)

  • 잘 계획된 구조

여러 AWS 계정 사용

하나의 계정만으로는 Well-Architected 환경을 설정할 수 없습니다. 여러 계정을 사용하면 보안 목표와 비즈니스 프로세스를 효과적으로 지원할 수 있습니다. 다중 계정 접근 방식을 사용하면 다음과 같은 몇 가지 이점이 있습니다.

  • 보안 제어 - 애플리케이션마다 보안 프로필이 다르기 때문에 서로 다른 제어 정책과 메커니즘이 필요합니다. 예를 들면 감사자와 상담하여 결제 카드 산업(PCI) 워크로드를 호스팅하는 단일 계정을 추천하는 것이 더 쉽습니다.

  • 격리 – 계정은 보안 보호의 한 단위입니다. 다른 계정이 영향받지 않도록 잠재적 위험과 보안 위협을 특정 계정 내에서 억제할 수 있습니다. 따라서 보안 요구에 따라 계정을 서로 격리해야 할 수 있습니다. 예를 들어 보안 프로필이 다른 팀이 있을 수 있습니다.

  • 다양한 팀 - 팀마다 책임과 리소스 요구 사항이 다릅니다. 여러 개의 계정을 설정하면 같은 계정을 사용할 때처럼 팀에서 서로 간섭할 수 없습니다.

  • 데이터 격리 – 데이터 저장소를 하나의 계정으로 격리하면 데이터에 액세스하고 데이터 저장소를 관리할 수 있는 사람의 수가 제한됩니다. 이러한 격리는 민감한 데이터의 무단 노출을 방지하는 데 도움이 됩니다. 예를 들어 데이터 격리는 일반 데이터 보호 규정(GDPR) 준수를 지원하는 데 도움이 됩니다.

  • 비즈니스 프로세스 – 사업부 또는 제품마다 목적 및 프로세스가 완전히 다를 수 있습니다. 개별 계정을 설정하여 비즈니스별 요구 사항을 충족할 수 있습니다.

  • 청구 – 송금 수수료 등을 포함하여 청구 수준에서 항목을 구분할 수 있는 유일한 방법은 계정입니다. 여러 계정을 사용하면 사업부, 직무 팀 또는 개별 사용자 간에 별도의 청구 가능한 항목을 만들 수 있습니다.

  • 할당량 할당 - AWS 할당량은 계정별로 설정됩니다. 워크로드를 서로 다른 계정으로 분리하면 각 계정(예: 프로젝트)에 잘 정의된 개별 할당량이 부여됩니다.

여러 조직 단위 사용

AWS Control Tower 및 기타 계정 오케스트레이션 프레임워크는 계정 경계를 넘어 변경할 수 있습니다. 따라서 AWS 모범 사례에서는 잠재적으로 환경을 손상시키거나 보안을 약화시킬 수 있는 교차 계정 변경을 해결합니다. 경우에 따라 변경 사항이 정책을 넘어 전체 환경에 영향을 미칠 수 있습니다. 따라서 프로덕션 및 스테이징이라는 두 개 이상의 필수 계정을 설정하는 것이 좋습니다.

또한 AWS 계정은 거버넌스 및 제어를 위해 조직 단위(OU)로 그룹화되는 경우가 많습니다. OU는 여러 계정에서 정책 적용을 처리하도록 설계되었습니다.

최소한 프로덕션 환경과는 다른 사전 프로덕션(또는 스테이징) 환경을 생성하고, 별도의 제어 및 정책을 적용하는 것이 좋습니다. 프로덕션 환경과 스테이징 환경은 별도의 OU로 생성 및 관리할 수 있으며 별도의 계정으로 청구할 수 있습니다. 또한 코드 테스트를 위해 샌드박스 OU를 설정할 수도 있습니다.

랜딩 존의 OU에 대해 잘 계획된 구조 사용

AWS Control Tower는 자동으로 몇 개의 OU를 설정합니다. 시간 경과에 따라 워크로드와 요구 사항이 확장되면 필요에 맞게 원래의 랜딩 존 구성을 확장할 수 있습니다.

참고

예제에 제공된 이름은 다중 계정 AWS 환경을 설정하기 위해 제안된 AWS 이름 지정 규칙을 따릅니다. OU 세부 정보 페이지에서 편집을 선택하여 랜딩 존을 설정한 후 OU의 이름을 바꿀 수 있습니다.

권장 사항

AWS Control Tower를 통해 첫 번째 필수 OU인 보안 OU가 자동으로 설정되면 랜딩 존에 몇 가지 추가 OU를 생성하는 것을 권장합니다.

AWS Control Tower에서 샌드박스 OU라고 하는 추가 OU를 하나 이상 생성하도록 허용하는 것이 좋습니다. 이 OU는 소프트웨어 개발 환경을 위한 것입니다. 랜딩 존 생성 중에 샌드박스 OU를 선택하면 AWS Control Tower가 이를 설정할 수 있습니다.

직접 설정할 수 있는 다른 권장 OU에는 공유 서비스 및 네트워킹 계정을 포함하는 인프라 OU와 프로덕션 워크로드를 포함하는 워크로드 OU의 두 가지가 있습니다. 조직 단위 페이지의 AWS Control Tower 콘솔을 통해 랜딩 존에 OU를 추가할 수 있습니다.

자동으로 설정되는 OU 이외의 권장 OU

  • 인프라 OU - 공유 서비스 및 네트워킹 계정을 포함합니다.

    참고

    AWS Control Tower는 인프라 OU를 자동으로 설정하지 않습니다.

  • 샌드박스 OU - 소프트웨어 개발 OU입니다. 예를 들어, 이 OU는 지출 한도가 고정되어 있거나 프로덕션 네트워크에 연결되어 있지 않을 수 있습니다.

    참고

    AWS Control Tower에서는 샌드박스 OU를 설정할 것을 권장하지만 선택 사항입니다. 랜딩 존 구성의 일부로 자동으로 설정할 수 있습니다.

  • 워크로드 OU - 워크로드를 실행하는 계정이 포함되어 있습니다.

    참고

    AWS Control Tower는 워크로드 OU를 자동으로 설정하지 않습니다.

자세한 내용은 Production starter organization with AWS Control Tower를 참조하세요.

완전한 다중 계정 OU 구조를 갖춘 AWS Control Tower의 예

AWS Control Tower는 중첩된 OU 계층 구조를 지원합니다. 즉, 조직의 요구 사항을 충족하는 계층적 OU 구조를 생성할 수 있습니다. AWS 다중 계정 전략 지침에 맞게 AWS Control Tower 환경을 구축할 수 있습니다.

또한 성능이 우수하고 AWS 다중 계정 지침에 부합하는 더 단순하고 평면적인 OU 구조를 구축할 수 있습니다. 계층적 OU 구조를 구축할 수 있다고 해서 반드시 구축해야 하는 것은 아닙니다.

연결된 페이지의 다이어그램은 더 많은 기본 OU와 더 많은 추가 OU가 생성되었음을 보여줍니다. 이러한 OU는 대규모 배포의 추가 요구 사항을 충족합니다.

기본 OU 열에서 기본 구조에 두 개의 OU가 추가되었습니다.

  • Security_Prod OU – 보안 정책에 대한 읽기 전용 영역과 비상 접근 보안 감사 영역을 제공합니다.

  • 인프라 OU - 이전에 권장한 인프라 OU를 Infrastructure_Test(사전 프로덕션 인프라용)와 Infrastructure_Prod(프로덕션 인프라용)의 두 가지 OU로 분리할 수 있습니다.

추가 OU 영역에서 기본 구조에 몇 개의 OU가 더 추가되었습니다. 다음은 환경의 성장에 따라 생성할 다음 권장 OU입니다.

  • 워크로드 OU - 이전에 권장되었지만 선택 사항인 워크로드 OU는 Workloads_Test(사전 프로덕션 워크로드용)와 Workloads_Prod(프로덕션 워크로드용)의 두 OU로 분리되었습니다.

  • PolicyStaging OU - 시스템 관리자가 제어 및 정책을 완전히 적용하기 전에 변경 사항을 테스트할 수 있습니다.

  • 일시 중지된 OU - 일시적으로 비활성화되었을 수 있는 계정의 위치를 제공합니다.

루트 정보

루트는 OU가 아닙니다. 루트는 관리 계정과 조직의 모든 OU 및 계정의 컨테이너입니다. 개념적으로 루트에는 모든 OU가 포함됩니다. 삭제할 수는 없습니다. AWS Control Tower 내의 루트 수준에서는 등록된 계정을 관리할 수 없습니다. 대신 OU 내에서 등록된 계정을 관리합니다. 유용한 다이어그램은 AWS Organizations 설명서를 참조하세요.