다음을 통해 공유


랜딩 존 지역

이 문서에서는 랜딩 존에서 Azure 지역을 사용하는 방법을 설명합니다. Azure 랜딩 존 아키텍처는 지역에 구애받지 않지만 Azure 랜딩 존 아키텍처를 배포하려면 Azure 지역을 지정해야 합니다. 다음 지침에서는 기존 랜딩 존에 지역을 추가하는 방법을 설명하고 Azure 자산을 다른 지역으로 마이그레이션하는 경우에 대한 고려 사항도 제공합니다.

경우에 따라 고가용성 및 재해 복구 비즈니스 요구 사항을 지원하기 위해 애플리케이션을 여러 Azure 지역에 배포해야 합니다. 다중 지역 애플리케이션에 대한 즉각적인 요구는 없지만, 특히 연결, ID 및 관리 서비스에 대해 여러 지역을 지원하도록 Azure 랜딩 존 플랫폼을 디자인해야 합니다. 다중 지역 애플리케이션 랜딩 존을 신속하게 사용하도록 설정하고 지원할 수 있는지 확인합니다.

자세한 내용은 Azure 지역 선택을 참조 하세요.

랜딩 존 및 Azure 지역

Azure 랜딩 존은 리소스 및 구성 집합으로 구성됩니다. 관리 그룹, 정책 및 역할 할당과 같은 이러한 항목 중 일부는 Azure 랜딩 존 아키텍처 내의 테넌트 또는 관리 그룹 수준에 저장됩니다. 이러한 리소스는 특정 지역에 배포되지 않고 전역적으로 배포됩니다. 그러나 Azure는 지역 메타데이터 저장소의 일부 리소스 메타데이터를 추적하므로 배포 지역을 지정해야 합니다.

다른 리소스는 지역적으로 배포됩니다. 자체 랜딩 존 구성에 따라 다음 지역적으로 배포된 리소스의 일부 또는 전부가 있을 수 있습니다.

  • 선택한 솔루션을 포함하여 Azure Monitor 로그 작업 영역
  • Azure Automation 계정
  • 다른 리소스에 대한 리소스 그룹

네트워킹 토폴로지를 배포하는 경우 네트워킹 리소스를 배포할 Azure 지역도 선택해야 합니다. 이 지역은 이전 목록에 나열된 리소스에 사용하는 지역과 다를 수 있습니다. 선택한 토폴로지에 따라 배포하는 네트워킹 리소스에는 다음이 포함될 수 있습니다.

  • Virtual WAN 허브를 포함한 Azure Virtual WAN
  • Azure 가상 네트워크
  • VPN 게이트웨이
  • Azure ExpressRoute 게이트웨이
  • Azure Firewall
  • Azure DDoS Protection 플랜
  • Azure Private Link에 대한 영역을 포함한 Azure 프라이빗 DNS 영역
  • 이전 리소스를 포함할 리소스 그룹

참고 항목

지역 가동 중단의 영향을 최소화하려면 리소스 그룹과 동일한 지역에 리소스를 배치하는 것이 좋습니다. 자세한 내용은 리소스 그룹 위치 맞춤을 참조 하세요.

기존 랜딩 존에 새 지역 추가

클라우드 경험 시작부터 또는 Azure 랜딩 존 아키텍처의 초기 배포를 완료한 후 더 많은 Azure 지역으로 확장하여 다중 지역 전략을 고려해야 합니다. 예를 들어 Azure Site Recovery를 사용하여 가상 머신에 대한 재해 복구를 사용하도록 설정하는 경우 다른 Azure 지역에 복제할 수 있습니다. Azure 랜딩 존 아키텍처 내에 Azure 지역을 추가하려면 다음 권장 사항을 고려하세요.

영역 추천
관리 그룹 아무런 작업도 수행할 필요가 없습니다. 관리 그룹은 지역에 연결되지 않습니다. 지역에 따라 관리 그룹 구조를 만들면 안 됩니다.
Abunələr 구독은 지역에 연결되지 않습니다.
Azure Policy "허용된" Azure 지역 목록을 지정하여 모든 지역에 리소스 배포를 거부하는 정책을 할당한 경우 Azure Policy를 변경합니다. 사용하도록 설정하려는 새 지역에 리소스 배포를 허용하도록 이러한 할당을 업데이트합니다.
RBAC(역할 기반 액세스 제어) 아무런 작업도 수행할 필요가 없습니다. Azure RBAC는 지역에 연결되지 않습니다.
모니터링 및 로깅 모든 지역에 단일 Azure Monitor 로그 작업 영역을 사용할지 또는 다양한 지리적 지역을 포괄하는 여러 작업 영역을 만들 것인지 결정합니다. 각 접근 방식에는 잠재적인 지역 간 네트워킹 요금을 포함하여 장점과 단점이 있습니다. 자세한 내용은 Log Analytics 작업 영역 아키텍처 디자인를 참조하세요.
네트워킹 네트워킹 토폴로지, Virtual WAN 또는 기존 허브 및 스포크 배포하는 경우 네트워킹을 새 Azure 지역으로 확장합니다. 새 Azure 지역의 기존 연결 구독에 필요한 네트워킹 리소스를 배포하여 다른 네트워킹 허브를 만듭니다. Azure Virtual Network Manager 를 사용하면 여러 지역에서 대규모로 가상 네트워크를 더 쉽게 확장하고 관리할 수 있습니다. DNS(도메인 이름 시스템) 관점에서 전달자를 사용하는 경우 새 Azure 지역에 배포할 수도 있습니다. 해결을 위해 새 지역의 스포크 가상 네트워크에 전달자를 사용합니다. Azure DNS 영역은 전역 리소스이며 단일 Azure 지역에 연결되지 않으므로 아무 작업도 필요하지 않습니다.
ID Active Directory 도메인 Services 또는 Microsoft Entra Domain Services를 ID 구독 또는 스포크에 배포한 경우 서비스를 새 Azure 지역으로 확장합니다.

참고 항목

또한 지역 내의 고가용성을 위해 가용성 영역을 사용해야 합니다. Azure 지역에서 가용성 영역을 지원하는지 여부사용하는 서비스가 가용성 영역을 지원하는 방법을 확인합니다.

Microsoft Cloud for Sovereignty에는 서비스 및 지역을 제한하기 위한 지침이 있습니다. 이러한 지침을 사용하여 고객이 데이터 보존 요구 사항을 달성할 수 있도록 서비스 구성을 적용할 수 있습니다 .

개략적인 접근법

Azure 랜딩 존을 새 지역으로 확장하는 경우 다음 섹션의 단계를 수행하는 것이 좋습니다. 시작하기 전에 확장할 새 Azure 지역 또는 여러 Azure 지역을 결정해야 합니다.

네트워킹

기존 허브 및 스포크 아키텍처
  1. 새 플랫폼 랜딩 존 구독이 필요한지 여부를 결정합니다. 대부분의 고객은 여러 지역을 사용하는 경우에도 기존 연결 구독을 사용하는 것이 좋습니다.

  2. 구독 내에서 새 대상 지역에 새 리소스 그룹을 만듭니다.

  3. 새 대상 지역에 새 허브 가상 네트워크를 만듭니다.

  4. 해당하는 경우 Azure Firewall 또는 NVA(네트워크 가상 어플라이언스)를 새 허브 가상 네트워크에 배포합니다.

  5. 해당하는 경우 VPN 또는 ExpressRoute 연결을 위한 가상 네트워크 게이트웨이를 배포하고 연결을 설정합니다. ExpressRoute 회로 및 온-프레미스 위치가 Microsoft 복원력 권장 사항을 따르는지 확인합니다. 자세한 내용은 ExpressRoute 개인 피어링을 사용하여 재해 복구를 위한 설계를 참조 하세요.

  6. 새 허브 가상 네트워크와 다른 허브 가상 네트워크 간에 가상 네트워크 피어링을 설정합니다.

  7. Azure Route Server 또는 사용자 정의 경로와 같은 필요한 라우팅을 만들고 구성합니다.

  8. 필요한 경우 새 대상 지역에 대한 DNS 전달자를 배포하고 프라이빗 DNS 영역에 연결하여 이름 확인을 사용하도록 설정합니다.

    • 일부 고객은 ID 플랫폼 랜딩 존 구독 내에서 Windows Server Active Directory 도메인 컨트롤러에서 이름 확인을 구성할 수 있습니다.

워크로드를 호스트하려면 가상 네트워크 피어링을 사용하여 애플리케이션 랜딩 존 스포크를 새 지역의 새 허브 가상 네트워크에 연결할 수 있습니다.

Virtual Network Manager 를 사용하면 여러 지역에서 대규모로 가상 네트워크를 더 쉽게 확장하고 관리할 수 있습니다.

Virtual WAN 아키텍처

Virtual WAN 아키텍처참조하세요.

  1. 기존 Virtual WAN 내에서 새 대상 지역에 새 가상 허브를 만듭니다.

  2. Azure Firewall 또는 지원되는 기타 NVA(네트워크 가상 어플라이언스)를 새 가상 허브에 배포합니다. 새 보안 가상 허브를 통해 트래픽을 라우팅하도록 Virtual WAN 라우팅 의도 및 라우팅 정책을 구성합니다.

  3. 해당하는 경우 새 가상 허브에서 VPN 또는 ExpressRoute 연결을 위한 가상 네트워크 게이트웨이를 배포하고 연결을 설정합니다. ExpressRoute 회로 및 온-프레미스 위치가 Microsoft 복원력 권장 사항을 따르는지 확인합니다. 자세한 내용은 ExpressRoute 개인 피어링을 사용하여 재해 복구를 위한 설계를 참조 하세요.

  4. 가상 허브 정적 경로와 같이 필요한 다른 라우팅을 만들고 구성합니다.

  5. 해당하는 경우 새 대상 지역에 대한 DNS 전달자를 배포하고 프라이빗 DNS 영역에 연결하여 해결을 사용하도록 설정합니다.

    • 일부 고객은 ID 플랫폼 랜딩 존 구독 내에서 Active Directory 도메인 컨트롤러에서 이름 확인을 구성할 수 있습니다.

    • Virtual WAN 배포에서는 가상 허브 확장 패턴에 따라 가상 네트워크 연결을 통해 가상 허브에 연결된 스포크 가상 네트워크에 있어야 합니다.

워크로드를 호스트하려면 가상 네트워크 피어링을 사용하여 애플리케이션 랜딩 존 스포크를 새 지역의 새 허브 가상 네트워크에 연결할 수 있습니다.

ID

ID 및 액세스 관리에 대한 Azure 랜딩 존 디자인 영역을 검토합니다.

  1. 새 플랫폼 랜딩 존 구독이 필요한지 여부를 결정합니다. 대부분의 고객은 여러 지역을 사용하는 경우에도 기존 ID 구독을 사용하는 것이 좋습니다.

  2. 새 대상 지역에 새 리소스 그룹을 만듭니다.

  3. 새 대상 지역에 새 가상 네트워크를 만듭니다.

  4. 연결 구독에서 새로 만든 지역 허브 가상 네트워크에 대한 가상 네트워크 피어링을 다시 설정합니다.

  5. Active Directory 도메인 컨트롤러 가상 머신과 같은 ID 워크로드를 새 가상 네트워크에 배포합니다.

    • 프로비전되면 다음 구성 단계와 같이 워크로드를 더 많이 설정해야 할 수 있습니다.

      • Active Directory 도메인 컨트롤러 가상 머신을 기존 Active Directory 도메인으로 승격합니다.

      • 새 Active Directory 사이트 및 서브넷을 만듭니다.

      • 조건부 전달자와 같은 DNS 서버 설정을 구성합니다.

Azure 자산을 새 지역으로 이동

경우에 따라 전체 Azure 자산을 다른 지역으로 이동해야 할 수 있습니다. 예를 들어 인접 국가 또는 지역의 Azure 지역에 랜딩 존 및 워크로드를 배포한 다음, 본국 또는 지역에서 새 Azure 지역이 시작되었다고 가정합니다. 통신 대기 시간을 개선하거나 데이터 보존 요구 사항을 준수하기 위해 모든 워크로드를 새 지역으로 이동하도록 선택할 수 있습니다.

참고 항목

이 문서에서는 자산의 랜딩 존 구성 요소를 마이그레이션하는 방법에 대한 정보를 제공합니다. 자세한 내용은 클라우드 워크로드 재배치를 참조 하세요.

전역 랜딩 존 구성

전역적으로 배포된 대부분의 랜딩 존 구성은 일반적으로 지역을 이동할 때 수정할 필요가 없습니다. 그러나 지역 배포를 제한하는 정책 할당을 확인하고 새 지역에 배포할 수 있도록 정책을 업데이트해야 합니다.

지역 랜딩 존 리소스

지역별 랜딩 존 리소스는 지역 간에 일부 Azure 리소스를 이동할 수 없으므로 더 많은 고려 사항이 필요한 경우가 많습니다. 다음 방법을 고려합니다.

  1. 대상 지역을 랜딩 존에 추가 지역으로 추가합니다. 자세한 내용은 기존 랜딩 존에 새 지역 추가를 참조하세요.

  2. 대상 지역에 중앙 집중식 구성 요소 배포: 예를 들어 워크로드를 마이그레이션한 후 워크로드가 새 구성 요소를 사용하기 시작할 수 있도록 대상 지역에 새 Azure Monitor 로그 작업 영역을 배포합니다.

  3. 원본 지역에서 대상 지역으로 워크로드 마이그레이션: 워크로드 마이그레이션 프로세스 중에 대상 지역의 네트워킹 구성 요소, ID 구성 요소, Azure Monitor 로그 작업 영역 및 기타 지역 리소스를 사용하도록 리소스를 다시 구성합니다.

  4. 마이그레이션을 완료한 후 원본 지역의 리소스를 해제합니다.

지역 간에 랜딩 존 리소스를 마이그레이션할 때 다음 팁을 고려합니다.

  • 코드로 인프라 사용: Bicep, ARM 템플릿(Azure Resource Manager 템플릿), Terraform, 스크립팅 또는 Azure Firewall 규칙과 같은 복잡한 구성을 내보내고 다시 구현하는 유사한 방법을 사용합니다.

  • 자동화: 스크립트를 사용하여 지역 간에 Automation 리소스를 마이그레이션합니다.

  • ExpressRoute: 대상 지역에서 ExpressRoute 로컬 SKU사용할 수 있는지 여부를 고려합니다. 온-프레미스 환경이 Azure 지역과 동일한 대도시 지역 내에 있는 경우 ExpressRoute Local은 다른 ExpressRoute SKU에 비해 저렴한 옵션을 제공할 수 있습니다.

다음 단계