AWS 지역별로 AWS Control Tower를 활용하는 방법 - AWS Control Tower

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

AWS 지역별로 AWS Control Tower를 활용하는 방법

현재 AWS Control Tower는 다음 AWS 지역에서 지원됩니다.

  • 미국 동부(버지니아 북부)

  • 미국 동부(오하이오)

  • 미국 서부(오리건)

  • 캐나다(중부)

  • 아시아 태평양(시드니)

  • 아시아 태평양(싱가포르)

  • 유럽(프랑크푸르트)

  • 유럽(아일랜드)

  • Europe (London)

  • 유럽(스톡홀름)

  • 아시아 태평양(뭄바이)

  • 아시아 태평양(서울)

  • 아시아 태평양(도쿄)

  • 유럽(파리)

  • 남아메리카(상파울루)

  • 미국 서부(캘리포니아 북부)

  • 아시아 태평양(홍콩)

  • 아시아 태평양(자카르타)

  • 아시아 태평양(오사카)

  • 유럽(밀라노)

  • 아프리카(케이프타운)

  • 중동(바레인)

  • 이스라엘(텔아비브)

  • 중동(UAE)

  • 유럽(스페인)

  • 아시아 태평양(하이데라바드)

  • 유럽(취리히)

  • 아시아 태평양(멜버른)

거주 지역 정보

랜딩 존을 생성하면 AWS 관리 콘솔에 액세스하는 데 사용하는 리전이 AWS Control Tower의 홈 AWS 리전이 됩니다. 생성 프로세스 중에 일부 리소스가 홈 리전에 프로비저닝됩니다. OU 및 AWS 계정과 같은 기타 리소스는 전 세계에 있습니다.

홈 지역을 선택한 후에는 변경할 수 없습니다.

제어 및 지역

현재 모든 예방 통제는 전 세계적으로 시행되고 있습니다. 그러나 탐지 및 사전 예방적 제어는 AWS Control Tower가 지원되는 지역에서만 작동합니다. 새 지역에서 AWS Control Tower를 활성화할 때의 제어 동작에 대한 자세한 내용은 을 참조하십시오AWS Control Tower 지역 구성.

AWS Control Tower 지역 구성

이 섹션에서는 AWS Control Tower 랜딩 존을 새 AWS 리전으로 확장하거나 랜딩 존 구성에서 리전을 제거할 때 예상되는 동작을 설명합니다. 일반적으로 이 작업은 AWS Control Tower 콘솔의 업데이트 기능을 통해 수행됩니다.

참고

AWS Control Tower 랜딩 존을 워크로드를 실행할 필요가 없는 AWS 지역으로 확장하지 않는 것이 좋습니다. 리전에서 옵트아웃해도 해당 리전에 리소스를 배포할 수 있는 것은 아니지만, 해당 리소스는 AWS Control Tower 거버넌스의 범위를 벗어나게 됩니다.

새 지역을 구성하는 동안 AWS Control Tower는 랜딩 존을 업데이트합니다. 즉, 랜딩 존의 기준이 됩니다.

  • 새로 선택된 모든 지역에서 활발하게 운영되고,

  • 선택되지 않은 지역의 자원 관리를 중단합니다.

AWS Control Tower에서 관리하는 조직 단위 (OU) 내의 개별 계정은 이 랜딩 존 업데이트 프로세스의 일부로 업데이트되지 않습니다. 따라서 OU를 다시 등록하여 계정을 업데이트해야 합니다.

AWS Control Tower 지역을 구성할 때는 다음 권장 사항 및 제한 사항을 숙지하십시오.

  • AWS 리소스 또는 워크로드를 호스팅할 계획이 있는 지역을 선택하십시오.

  • 리전에서 옵트아웃해도 해당 리전에 리소스를 배포할 수 있는 것은 아니지만, 해당 리소스는 AWS Control Tower 거버넌스의 범위를 벗어나게 됩니다.

새 지역에 대한 랜딩 존을 구성할 때 AWS Control Tower 탐지 컨트롤은 다음 규칙을 준수합니다.

  • 기존 요소의 가드레일 동작은 동일하게 유지. 기존 계정, 기존 OU 및 기존 리전의 감지 및 방지 가드레일 동작은 변경되지 않습니다.

  • 업데이트되지 않은 계정을 포함하는 기존 OU에는 새로운 탐지 제어를 적용할 수 없습니다. AWS Control Tower 랜딩 존을 새 리전으로 구성한 경우 (랜딩 존 업데이트), 기존 OU의 기존 계정을 업데이트해야 해당 OU 및 계정에서 새로운 탐지 제어를 활성화할 수 있습니다.

  • 계정을 업데이트하는 즉시 기존 탐지 컨트롤이 새로 구성된 지역에서 작동하기 시작합니다. 새 지역을 구성하도록 AWS Control Tower 랜딩 존을 업데이트한 다음 계정을 업데이트하면 OU에 이미 활성화되어 있는 탐지 컨트롤이 새로 구성된 지역의 해당 계정에서 작동하기 시작합니다.

AWS Control 타워 지역 구성
  1. 다음 주소에서 AWS Control Tower 콘솔에 로그인하십시오. https://console.aws.amazon.com/controltower

  2. 왼쪽 창 탐색 메뉴에서 랜딩 존 설정을 선택합니다.

  3. 랜딩 존 설정 페이지의 세부 정보 섹션에서 오른쪽 상단의 설정 수정 버튼을 선택합니다. 새 지역을 관리하거나 지역을 거버넌스에서 제거하려면 최신 랜딩 존 버전으로 업데이트해야 하기 때문에 랜딩 존 업데이트 워크플로로 이동합니다.

  4. 거버넌스를 위한 추가 AWS 지역에서 관리하려는 (또는 관리를 중단하려는) 지역을 검색하십시오. 열에는 현재 관할하는 지역과 관리하지 않는 지역이 표시됩니다.

  5. 관리할 각 추가 지역의 확인란을 선택합니다. 거버넌스를 제거하려는 각 지역의 체크박스를 선택 해제하십시오.

    참고

    지역을 관리하지 않기로 선택한 경우에도 해당 지역에 리소스를 배포할 수 있지만 해당 리소스는 AWS Control Tower 거버넌스의 범위를 벗어납니다.

  6. 나머지 워크플로를 완료한 다음, Update landding Zone을 선택합니다.

  7. Landing Zone 설정이 완료되면 OU를 다시 등록하여 새 지역의 계정을 업데이트하십시오. 자세한 설명은 AWS 컨트롤 타워 OU 및 계정 업데이트 시기 섹션을 참조하세요.

새 지역을 구성한 후 개별 계정을 프로비저닝하거나 업데이트하는 또 다른 방법은 Service Catalog의 API 프레임워크를 사용하고 일괄 프로세스로 계정을 AWS CLI업데이트하는 것입니다. 자세한 설명은 자동화를 사용하여 계정을 제공하고 업데이트하십시오. 섹션을 참조하세요.

지역을 구성할 때 복합 거버넌스를 피하세요.

AWS Control Tower 거버넌스를 새 것으로 확장한 후 AWS 리전, 그리고 AWS Control Tower 거버넌스를 지역에서 제거한 후에는 OU의 모든 계정을 업데이트하는 것이 중요합니다.

복합 거버넌스는 OU를 관리하는 제어 항목이 OU 내 각 계정을 관리하는 제어 항목과 완전히 일치하지 않는 경우 발생할 수 있는 바람직하지 않은 상황입니다. AWS Control Tower가 거버넌스를 새로운 AWS 리전것으로 확장하거나 거버넌스를 제거한 후 계정이 업데이트되지 않으면 OU에서 혼합 거버넌스가 발생합니다.

이 경우 OU 내의 특정 계정은 OU의 다른 계정과 비교할 때 또는 랜딩 영역의 전반적인 거버넌스 상태와 비교할 때 지역마다 다른 통제가 적용될 수 있습니다.

복합 거버넌스가 있는 OU에서 새 계정을 프로비저닝하면 새 계정이 랜딩 영역과 동일한 (업데이트된) 지역 및 OU 거버넌스 상태를 받게 됩니다. 하지만 아직 업데이트되지 않은 기존 계정에는 업데이트된 지역 거버넌스 상태가 적용되지 않습니다.

일반적으로 복합 거버넌스는 AWS Control Tower 콘솔에서 모순되거나 부정확한 상태 지표를 생성할 수 있습니다. 예를 들어 복합 거버넌스 중에는 아직 업데이트되지 않은 계정에 대해 등록된 OU에 옵트인 지역이 비규제 상태로 표시됩니다.

참고

AWS Control Tower는 복합 거버넌스 상태에서는 제어 기능을 활성화하는 것을 허용하지 않습니다.

복합 거버넌스 기간 동안의 규제 행동
  • 복합 거버넌스 중에는 OU의 일부 계정이 업데이트되지 않았기 때문에 OU에 이미 규제 대상으로 표시된 지역에 AWS Config 규칙 (즉, 탐지 제어) 을 기반으로 하는 제어 항목을 일관되게 배포할 수 없습니다. FAILED_TO_ENABLE오류 메시지가 표시될 수 있습니다.

  • 복합 거버넌스 중에 OU의 계정이 아직 업데이트되지 않은 상태에서 랜딩 영역의 거버넌스를 옵트인 지역으로 확장하면 OU의 EnableControl API 작업이 탐지 및 사전 제어에 실패합니다. OU 내에서 업데이트되지 않은 구성원 계정이 아직 해당 지역에서 옵트인되지 않았으므로 FAILED_TO_ENABLE 오류 메시지가 표시됩니다.

  • 복합 거버넌스 중에는 Security Hub Service 관리형 표준: AWS Control Tower에 속하는 규제 항목이 랜딩 존 구성과 업데이트되지 않은 계정 간에 불일치가 있는 지역의 규정 준수를 정확하게 보고할 수 없습니다.

  • 복합 거버넌스는 모든 관리 지역의 OU 내 모든 계정에 균일하게 적용되는 SCP 기반 제어 (예방 제어) 의 동작을 변경하지 않습니다.

참고

복합 거버넌스는 드리프트와 동일하지 않으며 드리프트로 보고되지도 않습니다.

복합 거버넌스를 복구하기 위해
  • 콘솔의 Organizations 페이지에 업데이트 가능 상태가 표시된 OU의 각 계정에 대해 계정 업데이트를 선택합니다.

  • 계정이 300개 미만인 OU의 경우 OU의 모든 계정을 자동으로 업데이트하는 Organizations 페이지에서 OU 재등록을 선택합니다.

OU 수준 지역 거부 제어에 대한 고려사항

OU 수준 지역 거부 제어에 대한 주요 고려 사항은 두 가지가 모두 활성화된 경우 착륙 영역 거부 제어와 상호 작용하는 방식을 결정하는 것입니다. 자세한 내용은 OU에 적용된 지역 거부 제어을(를) 참조하세요.