다음을 통해 공유

마이그레이션을 위한 랜딩 존 준비

  • 아티클

이 문서에서는 마이그레이션을 위해 Azure 랜딩 존 을 준비하는 방법을 설명합니다. 또한 마이그레이션 프로젝트에 대한 구성이 준비되었는지 확인하기 위해 수행해야 하는 주요 작업도 나열합니다.

사용한 Azure 랜딩 존 참조 구현에 관계없이 성공적인 마이그레이션 프로젝트를 위해 랜딩 존을 준비하기 위해 몇 가지 작업을 수행해야 합니다.

Azure 랜딩 존 참조 구현을 사용하지 않은 경우에도 이 문서의 단계를 수행해야 합니다. 그러나 먼저 수행해야 하는 필수 구성 요소 작업이 있거나 특정 권장 사항을 디자인에 맞게 조정해야 할 수 있습니다.

이 문서에서는 배포된 후 기존 Azure 랜딩 존에 대해 수행해야 하는 작업에 대해 설명합니다. 일부 작업은 자동화된 배포에 중점을 줍니다. 작업이 수동으로 배포되고 관리되는 환경과 관련이 없는지 확인합니다.

하이브리드 연결 설정

Azure 랜딩 존을 배포하는 동안 허브 가상 네트워크 및 네트워크 게이트웨이(예: Azure VPN Gateway, Azure ExpressRoute 게이트웨이 또는 둘 다)를 사용하여 커넥트ivity 구독을 배포할 수 있습니다. Azure 랜딩 존 배포 후에도 기존 데이터 센터 어플라이언스 또는 ExpressRoute 회로에 연결하도록 이러한 게이트웨이에서 하이브리드 연결을 구성해야 합니다.

준비 단계에서는 Azure에 대한 연결을 계획했습니다. 이 계획을 사용하여 통합해야 하는 연결을 결정합니다. 예를 들어 ExpressRoute를 사용하는 경우 공급자와 협력하여 ExpressRoute 회로를 설정해야 합니다.

특정 시나리오에 대한 기술 지침을 얻으려면 다음을 참조하세요.

참고 항목

추가 지침은 공급자의 특정 설명서도 참조하세요.

가상 네트워크에 배포된 타사 NVA(네트워크 가상 어플라이언스)를 통해 Azure에 하이브리드 연결을 설정하는 경우 해당 특정 지침과 고가용성 NVA에 대한 일반적인 지침을 검토합니다.

ID 준비

Azure 랜딩 존을 배포하는 동안 ID 플랫폼에 대한 지원 아키텍처도 배포해야 합니다. ID에 사용하는 VM(가상 머신)에 대한 전용 ID 구독 또는 리소스 그룹 및 가상 네트워크 또는 서브넷이 있을 수 있습니다. 그러나 Azure 랜딩 존 배포 후에 ID 리소스를 배포해야 합니다.

다음 섹션에서는 Active Directory와 관련된 지침을 제공합니다. 인증 및 권한 부여에 다른 ID 공급자를 사용하는 경우 ID를 Azure로 확장하는 방법에 대한 지침을 따라야 합니다.

이 지침을 구현하기 전에 랜딩 존에 대해 계획할 때 내린 Active Directory 및 하이브리드 ID 결정을 검토합니다.

또한 거버넌스 단계에서 ID 기준을 검토하여 Microsoft Entra ID를 변경해야 하는지 확인해야 합니다.

Active Directory do기본 컨트롤러 확장

대부분의 마이그레이션 시나리오에서 Azure로 마이그레이션하는 워크로드는 이미 기존 Active Directory에 조인되어 있습니다기본. Microsoft Entra ID는 VM 워크로드의 경우에도 ID 관리를 현대화하기 위한 솔루션을 제공하지만 마이그레이션을 방해할 수 있습니다. 워크로드에 대한 ID 사용 다시 설계는 현대화 또는 혁신 이니셔티브 중에 수행되는 경우가 많습니다.

따라서 배포한 ID 네트워크 영역 내에서 do기본 컨트롤러를 Azure에 배포해야 합니다. VM을 배포한 후에는 일반적인 수행기본 컨트롤러 승격 프로세스를 따라 수행에 추가해야 합니다기본. 이 프로세스에는 복제본(replica) 토폴로지를 지원하는 추가 사이트 만들기가 포함될 수 있습니다.

이러한 리소스를 배포하는 일반적인 아키텍처 패턴은 Azure 가상 네트워크에서 AD DS(Active Directory 도메인 Services) 배포를 참조하세요.

소규모 기업을 위한 엔터프라이즈 규모 아키텍처를 구현하는 경우 AD DS 서버는 허브의 서브넷에 있는 경우가 많습니다. 엔터프라이즈 규모 허브 및 스포크 아키텍처 또는 엔터프라이즈 규모 Virtual WAN 아키텍처를 구현하는 경우 서버는 전용 가상 네트워크에 있는 경우가 많습니다.

Microsoft Entra Connect

많은 조직에서 이미 Exchange Online과 같은 Microsoft 365 서비스를 채울 수 있는 Microsoft Entra 커넥트 있습니다. 조직에 Microsoft Entra 커넥트 없는 경우 ID를 복제본(replica) 수 있도록 랜딩 존 배포 후에 설치하고 배포해야 할 수 있습니다.

하이브리드 DNS 사용

대부분의 조직에서는 기존 환경의 일부인 네임스페이스에 대한 DNS(Do기본 Name System) 요청을 해결할 수 있어야 합니다. 이러한 네임스페이스는 종종 Active Directory 서버와 통합해야 합니다. 또한 기존 환경의 리소스는 Azure에서 리소스를 확인할 수 있어야 합니다.

이러한 함수를 사용하도록 설정하려면 일반적인 흐름을 지원하도록 DNS 서비스를 구성해야 합니다. Azure 랜딩 존을 사용하여 필요한 많은 리소스를 배포할 수 있습니다. 검토하고 준비할 추가 작업은 Azure의 DNS 확인을 참조하세요.

사용자 지정 DNS 확인

DNS 확인자에게 Active Directory를 사용하거나 타사 솔루션을 배포하는 경우 VM을 배포해야 합니다. 기본 컨트롤러가 ID 구독 및 네트워크 스포크에 배포된 경우 이러한 VM을 DNS 서버로 사용할 수 있습니다. 그렇지 않으면 이러한 서비스를 보관하도록 VM을 배포하고 구성해야 합니다.

VM을 배포한 후에는 기존 네임스페이스에 대한 조회를 수행할 수 있도록 기존 DNS 플랫폼에 통합해야 합니다. Active Directory DNS 서버의 경우 이 통합은 자동으로 수행됩니다.

Azure DNS Private Resolver를 사용할 수도 있지만 이 서비스는 Azure 랜딩 존 배포의 일부로 배포되지 않습니다.

디자인에서 프라이빗 DNS 영역을 사용하는 경우 그에 따라 계획합니다. 예를 들어 프라이빗 엔드포인트에서 프라이빗 DNS 영역을 사용하는 경우 DNS 서버 지정을 참조하세요. 프라이빗 DNS 영역은 랜딩 존의 일부로 배포됩니다. 또한 프라이빗 엔드포인트를 사용하여 현대화 작업을 수행하는 경우 추가 구성이 있어야 합니다.

Azure Firewall DNS 프록시

Azure Firewall을 DNS 프록시로 구성할 수 있습니다. Azure Firewall은 트래픽을 수신하여 Azure 확인자 또는 DNS 서버로 전달할 수 있습니다. 이 구성을 사용하면 온-프레미스에서 Azure로 조회를 수행할 수 있지만 조건부로 온-프레미스 DNS 서버로 다시 전달할 수는 없습니다.

하이브리드 DNS 확인이 필요한 경우 트래픽을 사용자 지정 DNS 서버(예: do기본 컨트롤러로 전달하도록 Azure Firewall DNS 프록시를 구성할 수 있습니다.

이 단계는 선택 사항이지만 몇 가지 이점이 있습니다. 나중에 DNS 서비스를 변경하고 Azure Firewall에서 FQDN(정규화된 do기본 이름) 규칙을 사용하도록 설정하면 구성 변경 내용이 줄어듭니다.

사용자 지정 가상 네트워크 DNS 서버 구성

이전 작업을 완료한 후 Azure 가상 네트워크에 대한 DNS 서버를 사용하는 사용자 지정 서버로 구성할 수 있습니다.

자세한 내용은 Azure Firewall DNS 설정을 참조 하세요.

허브 방화벽 구성

허브 네트워크에 방화벽을 배포한 경우 워크로드를 마이그레이션할 준비가 되도록 해결해야 하는 몇 가지 고려 사항이 있습니다. 배포 초기에 이러한 고려 사항을 해결하지 않으면 라우팅 및 네트워크 액세스 문제가 발생할 수 있습니다.

이러한 작업을 수행하는 과정의 일환으로 네트워킹 디자인 영역, 특히 네트워크 보안 지침을 검토합니다.

타사 NVA를 방화벽으로 배포하는 경우 공급업체의 지침과 고가용성 NVA에 대한 일반적인 지침을 검토합니다.

표준 규칙 집합 배포

Azure 방화벽을 사용하는 경우 명시적 허용 규칙을 추가할 때까지 모든 방화벽 트래픽이 차단됩니다. 다른 많은 NVA 방화벽도 비슷하게 작동합니다. 허용되는 트래픽을 지정하는 규칙을 정의할 때까지 트래픽이 거부됩니다.

워크로드 요구 사항에 따라 개별 규칙 및 규칙 컬렉션을 추가해야 합니다. 그러나 Active Directory 또는 다른 ID 및 관리 솔루션에 대한 액세스와 같은 표준 규칙도 사용하도록 설정된 모든 워크로드에 적용되도록 계획해야 합니다.

라우팅

Azure는 추가 구성 없이 다음 시나리오에 대한 라우팅을 제공합니다.

  • 동일한 가상 네트워크의 리소스 간 라우팅
  • 피어링된 가상 네트워크의 리소스 간 라우팅
  • 자체 가상 네트워크 또는 게이트웨이를 사용하도록 구성된 피어링된 가상 네트워크에서 리소스와 가상 네트워크 게이트웨이 간의 라우팅

두 가지 일반적인 라우팅 시나리오에는 추가 구성이 필요합니다. 두 시나리오 모두 셰이프 라우팅을 위해 서브넷에 할당된 경로 테이블이 있습니다. Azure 라우팅 및 사용자 지정 경로에 대한 자세한 내용은 가상 네트워크 트래픽 라우팅을 참조 하세요.

스포크 간 라우팅

네트워크 디자인 영역의 경우 많은 조직에서 허브-스포크 네트워크 토폴로지 사용

한 스포크에서 다른 스포크로 트래픽을 전송하는 경로가 필요합니다. 효율성과 단순성을 위해 방화벽에 대한 기본 경로(0.0.0.0/0)를 사용합니다. 이 경로를 사용하면 알 수 없는 위치에 대한 트래픽이 방화벽으로 이동하여 트래픽을 검사하고 방화벽 규칙을 적용합니다.

인터넷 송신을 허용하려면 개인 IP 공간에 대한 다른 경로를 방화벽(예: 10.0.0.0/8방화벽)에 할당할 수도 있습니다. 이 구성은 더 구체적인 경로를 재정의하지 않습니다. 그러나 스포크 간 트래픽이 제대로 라우팅할 수 있도록 간단한 경로로 사용할 수 있습니다.

스포크 간 네트워킹에 대한 자세한 내용은 스포크 간 통신에 대한 패턴 및 토폴로지(topologies)를 참조 하세요.

게이트웨이 서브넷에서 라우팅

허브에 가상 네트워크를 사용하는 경우 게이트웨이에서 오는 트래픽 검사를 처리하는 방법을 계획해야 합니다.

트래픽을 검사하려는 경우 다음 두 가지 구성이 필요합니다.

  • 커넥트 구독에서 경로 테이블을 만들고 게이트웨이 서브넷에 연결해야 합니다. 게이트웨이 서브넷에는 연결하려는 모든 스포크 네트워크에 대한 경로가 필요하며 방화벽 IP 주소의 다음 홉이 필요합니다.

  • 각 랜딩 존 구독에서 경로 테이블을 만들고 각 서브넷에 연결해야 합니다. 경로 테이블에서 BGP(Border Gateway Protocol) 전파를 사용하지 않도록 설정합니다.

사용자 지정 및 Azure 정의 경로에 대한 자세한 내용은 Azure 가상 네트워크 트래픽 라우팅을 참조 하세요.

프라이빗 엔드포인트에 대한 트래픽을 검사하려는 경우 프라이빗 엔드포인트가 호스트되는 서브넷에서 적절한 라우팅 네트워크 정책을 사용하도록 설정합니다. 자세한 내용은 프라이빗 엔드포인트에 대한 네트워크 정책 관리를 참조하세요.

트래픽을 검사하지 않으려는 경우 변경이 필요하지 않습니다. 그러나 스포크 네트워크 서브넷에 경로 테이블을 추가하는 경우 트래픽이 게이트웨이로 다시 라우팅할 수 있도록 BGP 전파를 사용하도록 설정합니다.

모니터링 및 관리 구성

랜딩 존 배포의 일환으로 Azure Monitor 로그에 리소스를 등록하는 정책을 프로비전했습니다. 하지만 랜딩 존 리소스에 대한 경고도 만들어야 합니다.

경고를 구현하기 위해 랜딩 존에 대한 Azure Monitor 기준을 배포할 수 있습니다. 이 배포를 사용하여 연결 리소스 및 서비스 상태와 같은 랜딩 존 관리에 대한 일반적인 시나리오를 기반으로 경고를 가져옵니다.

요구 사항이 기준선에서 벗어나는 경우 리소스에 대한 사용자 지정 경고를 직접 배포할 수도 있습니다.

소버린 워크로드 마이그레이션을 위한 랜딩 존 준비

주권 요구 사항을 해결해야 하는 경우 Microsoft Cloud for Sovereignty가 요구 사항에 맞는지 평가할 수 있습니다. Microsoft Cloud for Sovereignty는 개별 공공 부문 및 정부 고객의 요구를 해결하는 추가적인 정책 및 감사 기능을 제공합니다.

소버린 랜딩 존을 배포하여 이러한 기능을 사용하도록 설정할 수 있습니다. 소버린 랜딩 존의 아키텍처는 권장 되는 Azure 랜딩 존 디자인과 일치합니다.

Microsoft Cloud for Sovereignty 정책 포트폴리오

Azure 정책을 사용하여 Azure 리소스 전체에서 중앙 집중식 제어를 사용하도록 설정하여 특정 구성을 적용할 수 있습니다. Microsoft Cloud for Sovereignty 정책 이니셔티브를 랜딩 존에 할당하여 국가/지역의 로컬 정책 및 규정 요구 사항을 준수하도록 할 수 있습니다.

해당 정책 이니셔티브가 아직 소버린 랜딩 존 배포에 할당되지 않은 경우 규정 요구 사항에 해당하는 이니셔티브를 할당하는 것이 좋습니다.

구독 자동 판매 사용

이 섹션은 구독 프로비저닝 프로세스를 자동화하려는 조직에 적용됩니다. 랜딩 존 및 구독 만들기를 수동으로 관리하는 경우 구독을 만들기 위한 고유한 프로세스를 설정해야 합니다.

마이그레이션을 시작할 때 워크로드에 대한 구독을 만들어야 합니다. 구독 자동 판매 사용하도록 설정하여 이 프로세스를 자동화하고 가속화합니다. 구독 자동 판매 설정되면 신속하게 구독을 만들 수 있어야 합니다.

클라우드용 Microsoft Defender 준비

랜딩 존을 배포할 때 Azure 구독에 클라우드용 Defender 사용하도록 정책을 설정합니다. 클라우드용 Defender Microsoft 보안 기준에 따라 배포된 리소스를 평가하는 보안 상태 권장 사항을 보안 점수에 제공합니다.

추가 기술 구성을 구현할 필요는 없지만 권장 사항을 검토하고 리소스를 마이그레이션할 때 보안 상태를 개선하기 위한 계획을 설계해야 합니다. 리소스를 Azure로 마이그레이션하기 시작하면 마이그레이션 최적화의 일환으로 보안 향상을 구현할 준비가 되어 있어야 합니다.

마이그레이션을 준비하려면 다음 추가 리소스를 고려하세요.

다음 단계

도구 준비 및 초기 마이그레이션 백로그