AWS 다중 계정 전략 AWS Control Tower 랜딩 존 - AWS Control Tower

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

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

AWS Control Tower 고객은 AWS 환경을 설정하고 최상의 결과를 설명하는 방법에 대한 지침을 종종 구합니다. AWS는 멀티 어카운트 전략를 사용하여 AWS Control Tower 랜딩 존.

기본적으로 AWS Control Tower 는 다른 AWS 서비스와 함께 작동하는 오케스트레이션 레이어로 기능하여 AWS 계정 및 AWS 조직에 대한 AWS 다중 계정 권장 사항을 구현하는 데 도움을 줍니다. 랜딩 존을 설정한 후 AWS Control Tower 는 여러 계정 및 워크로드에 걸쳐 기업 정책 및 보안 관행을 유지하는 데 도움을 줍니다.

대부분의 랜딩 존은 시간이 지나면서 발생합니다. 의 조직 및 계정 수 AWS Control Tower 랜딩 존이 증가하면 AWS Control Tower 워크로드를 효과적으로 구성할 수 있는 방식으로 구축됩니다.

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

이 장에서는 AWS Control Tower AWS 다중 계정 전략에 맞게 랜딩 존을 설정합니다. 이 장에서는 초기 구성 단계와 이후 성장이 발생한 후의 랜딩 존의 예를 제공합니다.

잘 설계된 AWS 환경으로 랜딩 존 생성

잘 설계된 환경에 대한 AWS 모범 사례는 리소스와 워크로드를 여러 AWS 계정으로 분리하도록 권장합니다. AWS 계정을 격리된 리소스 컨테이너로 생각할 수 있습니다. 워크로드를 분류하고 문제가 발생했을 때 폭발 반경을 줄일 수 있습니다.

AWS 계정의 정의

AWS 계정은 리소스 컨테이너 및 리소스 격리 경계로 작동합니다.

참고

AWS 계정이 사용자 계정과 같지 않습니다. 사용자 계정은 Federation 또는 AWS Identity and Access Management(IAM)를 통해 설정됩니다.

AWS 계정에 대한 추가 정보

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

AWS 계정은 워크로드를 위한 리소스 컨테이너를 제공하는 기본 구현 메커니즘입니다. 환경의 아키텍처가 우수하면 여러 AWS 계정을 효과적으로 관리하여 여러 워크로드와 환경을 관리할 수 있습니다.

AWS Control Tower 은 잘 설계된 환경을 설정합니다. 여러 계정으로 확장될 수 있는 환경 변화를 관리하는 데 도움을 주는 AWS 계정과 AWS Organizations를 사용합니다.

잘 설계된 환경의 정의

AWS는 잘 설계된 환경을 랜딩 존으로 시작하는 환경으로 정의합니다.

AWS Control Tower 에서는 자동으로 설정된 랜딩 존을 제공합니다. 이 툴은 사용자 환경의 여러 계정에 걸쳐 기업 지침을 준수하기 위해 가드레일을 적용합니다.

랜딩 존의 정의

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

잘 설계된 환경을 구축하기 위한 지침

다음 섹션에서 설명하는 잘 설계된 환경의 세 가지 주요 구성 요소는 다음과 같습니다.

  • 여러 AWS 계정

  • 여러 조직 단위(OU)

  • 잘 계획된 구조

여러 AWS 계정 사용

하나의 계정은 잘 설계된 환경을 설정하기에 충분하지 않습니다. 여러 계정을 사용함으로써 보안 목표 및 비즈니스 프로세스를 가장 잘 지원할 수 있습니다. 다중 계정 접근 방식을 사용하면 다음과 같은 이점이 있습니다.

  • 보안 통제 – 애플리케이션은 서로 다른 보안 프로필을 가지고 있으므로 서로 다른 제어 정책 및 메커니즘이 필요합니다. 예를 들어, 감사자와 이야기하고 지불 카드 산업(PCI) 워크로드를 호스팅하는 단일 계정을 가리키는 것이 훨씬 더 쉽습니다.

  • 격리 – 계정은 보안 보호의 단위입니다. 잠재적 위험 및 보안 위협은 다른 사람에게 영향을 주지 않고 계정 내에 포함될 수 있습니다. 따라서 보안 요구 사항으로 인해 계정을 서로 분리해야 할 수 있습니다. 예를 들어, 보안 프로필이 다른 팀이 있을 수 있습니다.

  • 많은 팀 – 팀에는 다양한 책임과 자원이 필요합니다. 여러 개의 계정을 설정함으로써 팀은 동일한 계정을 사용할 때처럼 서로 간섭할 수 없습니다.

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

  • 비즈니스 프로세스 – 사업부 또는 제품은 종종 완전히 다른 목적과 프로세스를 갖습니다. 비즈니스별 요구 사항을 충족하기 위해 개별 계좌를 개설할 수 있습니다.

  • 청구 – 계정은 이체 요금 등을 포함하여 청구 수준에서 항목을 구분하는 유일한 방법입니다. 다중 계정 전략은 사업부, 기능 팀 또는 개별 사용자 간에 별도의 청구 가능한 항목을 생성하는 데 도움이 됩니다.

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

여러 조직 단위 사용

AWS Control Tower 및 기타 계정 오케스트레이션 프레임워크는 계정 경계를 넘는 변화를 가져올 수 있습니다. 따라서 AWS Best Practice는 계정 간 변경을 해결하여 환경을 파괴하거나 보안을 약화시킬 수 있습니다. 경우에 따라 정책 이외의 변경 사항이 전체 환경에 영향을 줄 수 있습니다. 따라서 최소한 두 개의 필수 계정인 생산 및 단계화 를 설정하는 것이 좋습니다.

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

최소한 운영 환경과 다른 사전 운영(또는 스테이징) 환경을 만드는 것이 좋습니다.—명확한 가드레일 및 정책 적용. 프로덕션 및 스테이징 환경은 별도의 OU로 생성 및 관리될 수 있으며, 별도의 계정으로 청구될 수 있습니다. 또한 코드 테스트를 위해 Sandbox OU를 설정할 수도 있습니다.

랜딩 존에서 OU에 대해 잘 계획된 구조를 사용합니다.

다중 계정 전략을 AWS Control Tower 다음 다이어그램은 랜딩 존에서 OU를 설정하는 방법에 대한 기본 스타터 구조를 보여줍니다. AWS Control Tower 에서는 자동으로 이러한 OU 중 일부를 설정합니다. 워크로드와 요구 사항이 시간이 지남에 따라 확장됨에 따라 이 랜딩 존 구성을 필요에 맞게 확장할 수 있습니다.

참고

예제에서 지정된 이름은 잘 설계된 AWS 환경을 설정하기 위해 제안된 AWS 명명 규칙을 따릅니다.


                첫 번째 그림은 여기에 위치

잘 설계된 AWS 환경을 만들려면 이전 다이어그램에 두 개의 기초 OU를 AWS Control Tower 랜딩 존:

  • 코어 OU – 세 개의 공유 계정, 즉 마스터(기본) 계정, 로그 아카이브 계정 및 보안 감사 계정(감사 계정이라고도 함)을 포함합니다.

    참고

    AWS Control Tower 은(는) 사용자를 위한 핵심 OU를 설정합니다.

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

    참고

    AWS Control Tower 에서 귀하를 위한 인프라 OU를 설정하지 않았습니다.

다이어그램에 표시된 것처럼 추가 운영 워크로드 및 소프트웨어 개발 워크로드를 포함하는 OU

  • OU 샌드박스 – 초기 단계 소프트웨어 개발 OU. 예를 들어, 고정 지출 한도가 있거나 생산 네트워크에 연결되지 않았을 수 있습니다.

  • 워크로드 OU – 워크로드를 실행하는 계정을 포함합니다.

    참고

    AWS Control Tower 은 Sandbox OU 또는 워크로드 OU를 설정하지 않습니다. 사용자 지정 OU라는 단일 OU를 설정합니다. 이 두 OU는 사용자 지정 OU 옆이나 대신 생성할 수 있습니다.

  • 사용자 지정 OU – 이 OU 내에서 워크로드 및 개발 환경에 대한 AWS 계정을 설정할 수 있습니다. 사용자 지정 OU의 이름을 워크로드 OU(원하는 경우)를 선택합니다.

    참고

    AWS Control Tower 는 사용자 지정 OU를 설정합니다.

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

AWS 여정을 계속 진행하면서 환경을 체계화하고 효율적으로 유지하기 위해 완전한 다중 계정 OU 구조가 점점 더 중요해지고 있습니다. 다중 계정 구조는 개별 비즈니스 사용자, 다중 배포, 여러 팀, 강력한 소프트웨어 개발 및 테스트 프로세스 등을 지원합니다.

AWS Control Tower는 현재 평면 OU 계층을 지원하므로 중첩된 OU를 사용할 수 없습니다. 그러나 여전히 AWS Control Tower AWS 다중 계정 전략 지침과 일치하는 환경 다음 다이어그램은 성숙도가 높은 AWS Control Tower AWS 다중 계정 지침을 따르는 환경


                    두 번째 그림은 여기에 있습니다.

이전 다이어그램에서는 스타터 구조에서 생성된 것보다 더 많은 기본 OU와 더 많은 추가 OU가 생성되었음을 보여 줍니다. 이러한 OU는 대규모 구축에 대한 추가적인 요구 사항을 충족시킵니다.

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

  • 보안_제품 OU – 보안 정책을 위한 읽기 전용 영역과 보안 감사 영역 을 제공합니다.

  • 인프라 OU – 인프라 OU는 인프라_SDLC(사전 운영 인프라용)와 인프라_Prod(운영 인프라용)의 두 OU로 구분되었습니다.

Additional OUs(추가 OU) 열에서 다음 OU가 기본 구조에 추가되었습니다.

  • 워크로드 OU – OU 워크로드는 2개의 OU, 즉 사전 운영 워크로드의 경우 Workloads_SDLC와 운영 워크로드의 경우 Workloads_Prod로 구분되었습니다.

  • 정책스테이징 OU – 시스템 관리자가 가드레일 및 정책을 완전히 적용하기 전에 변경 사항을 테스트할 수 있습니다.

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