허브 및 스포크 네트워크 토폴로지

이 문서에서는 Azure 허브 및 스포크 네트워크를 디자인하는 방법을 설명합니다. 중앙 허브 가상 네트워크는 공유 서비스를 호스트하고 격리된 스포크 가상 네트워크는 개별 워크로드를 호스트합니다.

이 문서에서 다루는 내용

이 문서에서는 허브 가상 네트워크 공유 서비스, 스포크 격리 및 라우팅 패턴(표준, 직접 피어링 및 스탬프 기반)을 다룹니다. 또한 하이브리드 연결 및 Azure Virtual Network Manager 사용하여 허브-스포크 토폴로지 크기 조정을 위한 게이트웨이 전송을 다룹니다.

이 문서가 필요한 사람

다음 조건 중 하나 이상이 적용되는 경우 이 문서를 참조하세요.

  • 여러 워크로드에 대해 방화벽, DNS, Bastion, VPN Gateway 또는 ExpressRoute와 같은 공유 네트워크 서비스가 필요합니다.
  • 모든 VNet에서 해당 서비스를 반복하는 대신 트래픽 검사, 라우팅 제어 또는 관리를 중앙 집중화하려고 합니다.
  • 공유 플랫폼 서비스를 워크로드 VNet과 분리하려면 반복 가능한 토폴로지가 필요합니다.
  • 토폴로지 표준화 전에 허브 및 스포크 모델을 다른 전송 모델과 비교하려고 합니다.

공유 서비스 요구 사항이 없는 단일 워크로드가 있는 경우 대신 플랫 네트워크 토폴로지 로 시작합니다.

팁 (조언)

시나리오 경로를 따라가시겠습니까? 페이지 맨 위에서 시나리오를 선택하여 맞춤형 지침을 확인합니다. 다음 핵심 지침은 모든 판독기에게 적용됩니다.

리프트 앤 시프트 포커스: 온-프레미스 워크로드를 Azure로 이전하려고 하며 여러 스포크 VNet 전반에서 중앙 집중식 공유 서비스(DNS, 방화벽, VPN 게이트웨이)가 필요한 경우 이 문서를 읽어보세요. 허브 및 스포크는 단일 허브에서 공유 인프라가 필요한 다중 워크로드 리프트 앤 시프트 마이그레이션의 기본 토폴로지입니다.

현대화 포커스: 여러 지역에 PaaS 서비스를 배포하고 IT 소유 허브 및 앱 팀 소유 스포크로 이중 허브 토폴로지가 필요한 경우 이 문서를 읽어보세요. 허브 및 스포크 모델은 플랫폼 서비스 및 애플리케이션 워크로드에 대한 별도의 구독 경계를 지원하도록 확장됩니다.

클라우드 간 포커스: 클라우드 간 전송에 대한 허브 및 스포크 및 Virtual WAN 평가하는 경우 이 문서를 읽어보세요. 멀티클라우드 환경의 규모가 Virtual WAN을 도입할 정도는 아니라면, 다른 클라우드에 VPN Gateway로 연결되는 기존의 허브 앤 스포크 아키텍처가 더 단순한 출발점이 됩니다.

Azure 서비스 및 기능

다음 표에서는 허브 및 스포크 토폴로지 지원 Azure 서비스 및 기능을 나열합니다.

서비스 또는 기능 허브-스포크 내에서의 역할 자세히 알아보기
Azure 가상 네트워크 허브 및 스포크 가상 네트워크를 제공합니다 가상 네트워크 개요
VNet 피어링 각 스포크를 허브에 연결합니다 가상 네트워크 피어링
Azure Firewall 허브에서 중앙 트래픽 검사 및 필터링 Azure Firewall 개요
VPN Gateway 또는 ExpressRoute 게이트웨이 모든 스포크 전반에 걸쳐 공유되는 하이브리드 연결 VPN Gateway 개요
Azure Bastion 피어링된 스포크 전반에서 VM에 대한 원격 액세스 보안 Azure Bastion 개요
Azure 프라이빗 DNS 해결 프로그램 Azure와 온-프레미스 간 DNS 전달 프라이빗 DNS 해결 프로그램 개요
Azure DDoS Protection(애저 디도스 보호) 스포크 공용 IP를 포함하는 공유 DDoS 계획 DDoS Protection 개요
AZURE VIRTUAL NETWORK MANAGER(AVNM) 대규모 환경에서의 자동화된 스포크 피어링, UDR 관리 및 네트워크 그룹 AVNM 개요

작동 방식

서로 다른 워크로드를 실행하는 3개의 스포크 VNet에 피어링된 게이트웨이, Azure Firewall 및 Azure Bastion 서브넷이 포함된 허브 VNet에 ExpressRoute 및 사이트 간 VPN을 통해 연결된 온-프레미스 네트워크가 있는 허브 및 스포크 토폴로지를 보여 주는 다이어그램.

허브-스포크 토폴로지에서:

  1. 허브 가상 네트워크는 연결의 중심 지점 역할을 합니다. 방화벽, 게이트웨이 및 Bastion 호스트와 같은 공유 네트워크 서비스를 포함합니다.
  2. 스포크 가상 네트워크는 허브와 피어링됩니다. 각 스포크는 애플리케이션, 팀 환경 또는 격리된 서비스 등의 워크로드를 호스트합니다.
  3. VNet 피어링이 전이적이지 않습니다. 스포크는 허브에 연결할 수 있지만, 스포크는 라우팅 또는 직접 피어링을 구성하지 않는 한 허브를 통해 직접 서로 연결할 수 없습니다.

허브 가상 네트워크에 표시되는 내용

다음 표를 사용하여 허브에 배치할 서비스를 결정합니다.

서비스 포함할까요? Notes
Azure Firewall 권장 모든 동서 및 남북 트래픽에 대한 중앙 집중식 교통 검사를 제공합니다. 정확히 AzureFirewallSubnet이름이 지정된 서브넷이 필요합니다.
VPN 또는 ExpressRoute 게이트웨이 하이브리드 연결이 필요한 경우 모든 스포크는 게이트웨이 트랜짓을 통해 단일 게이트웨이를 공유합니다. 정확히 GatewaySubnet 명명된 서브넷이 필요합니다(최소 /27).
Azure Bastion 권장 허브에 있는 하나의 Bastion 호스트는 피어링된 모든 스포크 가상 네트워크의 VM에 액세스할 수 있습니다. 기본 SKU 이상이 필요합니다. 개발자 SKU는 VNet 간 피어링 액세스를 지원하지 않습니다.
프라이빗 DNS 리졸버 사용자 지정 DNS가 필요한 경우 Azure 호스팅 프라이빗 DNS 영역과 온-프레미스 DNS 서버 간에 DNS 쿼리를 전달합니다.
Azure DDoS Protection 플랜 DDoS 보호를 사용하는 경우 단일 플랜은 허브 구독에 연결된 모든 스포크 가상 네트워크에서 공용 IP 주소를 보호할 수 있습니다.

Important

허브에 애플리케이션 워크로드를 두지 마세요. 허브는 방화벽, 게이트웨이, Bastion 및 DNS와 같은 공유 인프라 서비스만 호스팅합니다. 애플리케이션 VM, 컨테이너 및 PaaS 리소스는 스포크 가상 네트워크에 속합니다. 이렇게 분리하면 허브가 정리되고, 피어링이 간소화되며, 플랫폼 팀이 애플리케이션 팀과 독립적으로 공유 서비스를 관리할 수 있습니다.

허브 서브넷 레이아웃

잘 설계된 허브 가상 네트워크에는 일반적으로 다음 서브넷이 포함됩니다.

서브넷 이름 Purpose 최소 크기
AzureFirewallSubnet Azure Firewall 배포 /26
AzureFirewallManagementSubnet 강제 터널링에 대한 관리 NIC(표준/프리미엄에만 해당) /26
GatewaySubnet VPN 및 ExpressRoute 게이트웨이 /27
AzureBastionSubnet Azure Bastion /26
DNS 리졸버 인바운드 서브넷 프라이빗 DNS 해석기 인바운드 엔드포인트 /28
DNS 리졸버 아웃바운드 서브넷 프라이빗 DNS Resolver 아웃바운드 엔드포인트 /28

자세한 서브넷 크기 조정 지침은 VNet 및 서브넷을 참조하세요.

변형을 선택하는 방법

허브 및 스포크에는 세 가지 일반적인 변형이 있습니다. 격리 및 통신 요구 사항에 따라 선택합니다.

격리된 스탬프, 직접 피어링을 사용하는 허브-스포크, 방화벽을 통한 표준 허브-스포크 등 세 가지 토폴로지 변형을 보여 주는 다이어그램

Variant 트래픽 경로 사용 시기
표준 허브-앤드-스포크 모든 스포크 간 트래픽은 허브 방화벽을 통해 라우팅됩니다 중앙 집중식 트래픽 검사가 필요합니다. 스포크는 직접적인 P2P 통신이 필요하지 않습니다.
직접 피어링이 있는 허브 앤 스포크 특정 스포크 쌍도 서로 직접 피어링합니다. 긴밀하게 결합된 워크로드에는 방화벽을 트래버스하지 않고 대기 시간이 짧은 스포크-스포크 통신이 필요합니다.
스탬프(완전히 격리됨) 허브가 없습니다. 각 가상 네트워크는 완전히 독립적입니다. 엄격한 영향 범위 격리, 규정 준수 기반 분리 또는 독립 스택을 갖춘 멀티테넌트 SaaS.

표준 허브 앤 스포크

이 변형이 가장 일반적입니다. 모든 스포크 간 트래픽은 검사를 거치기 위해 허브 방화벽을 통과합니다. 스포크는 허브를 통해서만 통신하며 직접 통신하지 않습니다.

라우팅 패턴: 허브 방화벽의 개인 IP 주소를 가리키는 기본 경로()를 사용하여 각 스포크 서브넷에 UDR(0.0.0.0/0사용자 정의 경로)을 적용합니다. 이렇게 하면 로깅 및 필터링을 위해 스포크 간 트래픽을 포함한 모든 아웃바운드 트래픽이 방화벽을 거치도록 강제합니다.

피어링 제한: 단일 허브 가상 네트워크는 최대 500개의 피어링 연결(표준 플랫폼 제한)을 지원합니다. 허브-스포크 연결 구성에서 AVNM(Azure Virtual Network Manager)을 사용하는 경우 제한은 1,000개의 스포크로 증가합니다.

직접 피어링이 있는 허브 앤 스포크

일부 아키텍처에서 특정 스포크 쌍은 허브 방화벽을 트래버스하지 않고 대기 시간이 짧은 통신이 필요합니다. 이러한 경우 스포크 쌍 간에 직접 VNet 피어링을 추가하거나 AVNM 연결된 그룹을 사용합니다.

다음과 같은 경우 직접 스포크 피어링을 사용합니다.

  • 두 워크로드가 높은 처리량 데이터(예: 스포크 간 데이터베이스 복제)를 교환합니다.
  • 방화벽 홉의 대기 시간은 특정 데이터 경로에 대해 허용되지 않습니다.
  • 직접 피어된 트래픽이 중앙 방화벽 검사를 우회하는 것을 허용합니다.

메모

스포크 간 피어링으로 허브의 필요성이 제거되지는 않습니다. 허브 바인딩된 트래픽(송신, 하이브리드 연결, 공유 서비스)은 여전히 허브 방화벽을 통해 라우팅됩니다.

스탬프 패턴(완전히 격리됨)

스탬프 패턴은 엄격한 폭발 반경 격리가 필요한 시나리오의 대안입니다. 각 워크로드는 허브가 없고 다른 워크로드에 대한 피어링 없이 완전히 독립적인 가상 네트워크에 배포됩니다.

스탬프를 사용하는 경우:

  • 규정 준수에는 워크로드 간의 네트워크 경로가 필요하지 않습니다.
  • 각 테넌트에 독립적인 스택이 있는 다중 테넌트 SaaS.
  • 최대 오류 격리: 한 스탬프의 오류는 다른 스탬프에 전파할 수 없습니다.

예시: 멀티테넌트 SaaS 격리

SaaS 공급자는 각 엔터프라이즈 고객을 전용 스탬프로 호스트합니다. 각 스탬프에는 자체 VNet(10.x.0.0/16), 애플리케이션 게이트웨이, 컴퓨팅 계층 및 데이터베이스가 포함됩니다. 스탬프 사이에 VNet 피어링이 없으므로 테넌트 A의 스탬프에서 잘못 구성된 NSG 또는 손상된 워크로드는 네트워크를 통해 테넌트 B의 리소스에 연결할 수 없습니다. 공급자는 Azure Resource Manager 템플릿을 통해 스탬프를 관리하고 대규모 테넌트에 대한 별도의 리소스 그룹 또는 별도의 구독에 배포합니다. 필요한 경우 테넌트 간 데이터 교환은 공유 Azure Service Bus 네임스페이스를 사용합니다. 각 스탬프는 프라이빗 엔드포인트를 통해 이 네임스페이스에 액세스합니다.

상충 관계:

  • 공유 서비스가 없습니다. 각 스탬프에는 자체 방화벽, 게이트웨이 및 Bastion 호스트(필요한 경우)가 필요하므로 비용이 증가합니다.
  • 프라이빗 네트워킹을 통한 워크로드 간 통신이 없습니다.
  • 중앙 집중식 인프라 대신 독립 네트워크를 관리하기 때문에 운영 오버헤드가 증가합니다.
  • 공유 서비스 절감은 적용되지 않으므로 스탬프 수에 따라 비용이 선형적으로 증가합니다.

워크로드에 공유 서비스 또는 워크로드 간 통신이 필요한 경우 표준 허브 및 스포크 변형을 대신 사용합니다.

스포크 간 통신 패턴

VNet 피어링이 전이적이지 않으므로 스포크-스포크 통신에는 명시적 라우팅이 필요합니다. 이 섹션에서는 허브 방화벽을 사용하여 스포크 간에 트래픽이 흐르는 방법을 안내합니다.

트래픽 흐름: 허브 방화벽을 통해 스포크 A에서 스포크 B로

다음 시퀀스는 스포크 A()의 VM에서 스포크 B10.1.0.4(10.2.0.4)의 VM으로 패킷이 이동하는 방법을 설명합니다.

  1. 스포크 A VM이 10.2.0.4로 향하는 패킷을 보냅니다. VM의 유효 경로 테이블에는 (Azure Firewall 개인 IP)가 있는 UDR 0.0.0.0/0 → 10.0.1.4 이 포함되어 있습니다.
  2. 패킷은 스포크 A에서 허브 VNet으로 VNet 피어링 링크를 교차합니다. 피어링을 사용하면 트래픽이 방화벽의 서브넷에 도달할 수 있습니다.
  3. Azure Firewall 내부 인터페이스에서 패킷을 받습니다. 네트워크 규칙 및 애플리케이션 규칙에 대해 패킷을 우선 순위순으로 평가합니다.
  4. 규칙이 흐름을 허용하는 경우 방화벽은 패킷 10.2.0.4을 전달합니다. 패킷은 허브와 Spoke-B 간 피어링 링크를 통과합니다.
  5. 스포크 B VM이 패킷을 받습니다. 반환 트래픽은 동일한 경로를 역방향으로 따릅니다. 스포크 B의 UDR은 방화벽을 통해 응답을 다시 보냅니다.

경로 테이블 구성

위의 패턴을 사용하도록 설정하려면 다음 경로 테이블을 적용합니다.

  1. 스포크 서브넷에 대한 경로 테이블을 만듭니다. 온-프레미스 경로가 UDR보다 우선 적용되지 않도록 하려면 BGP 경로 전파를 끄세요.
  2. 기본 경로(0.0.0.0/0)를 추가하고, 다음 홉 유형은 VirtualAppliance로, 다음 홉 주소는 Azure Firewall 프라이빗 IP로 설정합니다.
  3. 경로 테이블을 다른 스포크 또는 인터넷에 연결해야 하는 각 스포크 서브넷과 연결합니다.
  4. 특정 스포크 간 트래픽을 허용하는 방화벽 네트워크 규칙을 생성합니다. 예를 들어 포트 443 및 1433에서 10.1.0.0/16 → 10.2.0.0/16을 허용합니다.

팁 (조언)

Azure Firewall IP 그룹을 사용하여 스포크 주소 범위를 구성합니다. 이렇게 하면 스포크 추가 시 규칙 관리가 간소화됩니다.

대안: 스포크 간 직접 연결을 위한 AVNM 연결된 그룹

특정 스포크 간에 방화벽 검사가 필요하지 않은 경우 AVNM 연결 그룹은 메시 연결 모델을 제공합니다. 동일한 연결된 그룹의 스포크는 허브를 트래버스하지 않고 직접 통신합니다. 이렇게 하면 대기 시간 및 방화벽 처리량 요구 사항이 감소하지만 중앙 집중식 검사를 무시합니다.

Important

인터넷 바인딩된 트래픽을 온-프레미스 어플라이언스로 라우팅하기 위해 Azure Firewall 강제 터널링을 사용하도록 설정하는 경우 표준 또는 프리미엄 계층이 필요합니다. 강제 터널링에는 관리 서브넷(AzureFirewallManagementSubnet)도 필요하며 DNAT 규칙을 해제합니다.

게이트웨이 경유

게이트웨이 전송을 통해 모든 스포크는 허브에 배포된 단일 VPN 또는 ExpressRoute 게이트웨이를 공유할 수 있습니다. 게이트웨이 전송이 없으면 각 스포크에 자체 게이트웨이가 있어야 온-프레미스 네트워크에 연결할 수 있습니다.

구성 단계

  1. 허브의 GatewaySubnet에 VPN 또는 ExpressRoute 게이트웨이를 배포합니다.
  2. 허브 쪽 피어링 연결 (허브 → 스포크)에서 게이트웨이 전송 허용을 사용하도록 설정합니다.
  3. 스포크 쪽 피어링 연결 (스포크 → 허브)에서 원격 게이트웨이 사용을 사용하도록 설정합니다.
  4. 경로 전파를 확인합니다. 구성 후 스포크 VM NIC에서 유효 경로를 확인합니다. 경로 테이블에는 허브 게이트웨이를 통해 학습되었으며 다음 홉 유형이 VNetGlobalPeering 또는 VNetPeering인 온-프레미스 접두사가 표시됩니다.

구성된 경우 허브 게이트웨이에서 학습한 경로(예: ExpressRoute의 온-프레미스 접두사)가 스포크 라우팅 테이블에 자동으로 전파됩니다.

게이트웨이 전송 제한 사항

  • 게이트웨이 전송은 기본 계층을 제외한 모든 VPN Gateway 계층에서 작동합니다. 기본 VPN Gateway 사용하는 경우 피어된 가상 네트워크와 공유할 수 없습니다.
  • 스포크 가상 네트워크는 하나의 원격 게이트웨이만 사용할 수 있습니다. 여러 허브와 피어링하는 스포크에서는 Use remote gateways을(를) 활성화할 수 없습니다.
  • UDR을 사용하여 트래픽이 방화벽을 통과하도록 강제하는 경우, UDR이 게이트웨이에서 전파된 온-프레미스 경로를 의도치 않게 재정의하지 않도록 하세요. 필요한 경우 온-프레미스 접두사에 대한 보다 구체적인 경로를 설정합니다.

메모

게이트웨이 전송과 함께 ExpressRoute를 사용하는 경우 스포크 피어링을 설정하기 전에 게이트웨이 전송 허용 을 사용하도록 설정합니다. 게이트웨이가 존재하고 먼저 프로비전되어야 합니다.

대규모 환경에서의 Azure Virtual Network Manager

환경이 소수의 스포크 이상으로 커지면 피어링 연결 및 경로 테이블을 수동으로 관리하는 것이 복잡해집니다. AVNM은 허브-스포크 토폴로지의 자동화를 제공합니다.

AVNM 기능 용도
허브-스포크 연결 구성 네트워크 그룹의 허브와 모든 스포크 간에 피어링을 자동으로 만들고 유지 관리합니다. 허브당 최대 1,000개의 스포크 지원
연결된 그룹 수동 피어링 없이 직접 스포크 간 연결을 사용하도록 설정합니다. 기본 제한: 그룹당 250개의 가상 네트워크(요청에 따라 1,000개까지 확장 가능).
동적 멤버 자격을 가진 네트워크 그룹 Azure Policy 조건을 사용하여 태그, 이름 지정 또는 구독에 따라 그룹에 가상 네트워크를 자동으로 추가합니다.
UDR 관리 여러 허브-스포크 토폴로지에서 경로 테이블 배포를 자동화합니다.

AVNM은 여러 지역에 걸쳐 허브-스포크 토폴로지를 관리하거나 새 스포크 가상 네트워크가 새로 추가될 때 동적 멤버십이 필요한 경우에 특히 유용합니다.

규모 조정 고려 사항

허브-스포크 토폴로지의 증가에 따라 다음 플랫폼 제한 및 조직 패턴을 계획합니다.

피어링 및 연결 제한

차원 표준 제한 AVNM을 사용하여 Notes
가상 네트워크당 VNet 피어링 500 1,000(허브 및 스포크 간 구성) 각 스포크-허브 피어링은 양쪽에서 슬롯 하나를 차지합니다.
AVNM 연결 그룹당 가상 네트워크 250(기본값) 최대 1,000개(요청별) Azure 지원 통해 요청 증가
AVNM 범위별 구독 수 N/A 1,000 범위는 관리 그룹의 여러 구독에 걸쳐 있습니다.

구독 조직

  • 스포크가 10개를 초과하는 환경의 경우, 스포크를 워크로드별 구독으로 분리합니다. 이렇게 하면 워크로드 팀별로 청구, RBAC, 할당량 한도가 분리됩니다.
  • 허브 VNet, 게이트웨이 및 방화벽에 대한 전용 연결 구독을 사용합니다. 이는 Azure 랜딩 존(플랫폼 구독)에서 권장하는 패턴입니다.
  • AVNM이 Azure Policy 조건을 사용하여 구독 전체에서 스포크 VNet을 동적으로 검색하고 관리할 수 있도록 관리 그룹에서 구독을 그룹화합니다.

Azure Policy 사용하여 토폴로지 적용

Azure Policy 사용하여 구성 드리프트를 방지합니다.

  • 비 허브 VNet에 대한 피어링을 거부합니다. 대상이 지정된 허브 VNet이 아니면 VNet 피어링 생성을 차단하는 관리 그룹 수준에서 정책을 할당합니다.
  • UDR 연결이 필요합니다. 0.0.0.0/0 → Firewall 경로를 포함하는 경로 테이블이 없는 스포크 서브넷을 감사하거나(또는 거부하는) 정책을 할당합니다.
  • AVNM 그룹 멤버 자격을 적용합니다. 태그(예 NetworkRole:Spoke: )에 따라 AVNM에서 동적 멤버 자격 규칙을 사용하므로 새 VNet이 자동으로 등록됩니다.

플랫에서 허브-스포크로 마이그레이션 경로

플랫 네트워크 토폴로지로 시작했고 사용자 환경이 공유 서비스 또는 워크로드 간 분할을 요구하도록 성장한 경우 다음 마이그레이션 경로를 따릅니다.

1단계: 허브 VNet 계획

  1. 기존 플랫 VNet과 겹치지 않는 허브(예 10.0.0.0/16: )에 대한 새 주소 공간을 할당합니다.
  2. 배포할 공유 서비스(방화벽, 게이트웨이, Bastion, DNS 확인자)를 결정합니다.
  3. 허브 서브넷 레이아웃 테이블당 허브 서브넷 크기 지정

2단계: 허브에 공유 서비스 배포

  1. 허브 VNet을 만들고 Azure Firewall(또는 선택한 NVA)를 배포합니다.
  2. 하이브리드 연결이 필요한 경우 VPN/ExpressRoute 게이트웨이를 배포합니다.
  3. 보안 VM 액세스를 위한 Azure Bastion 배포합니다.
  4. 사용자 지정 DNS를 사용하는 경우 프라이빗 DNS Resolver를 구성합니다.

3단계: 워크로드를 스포크로 마이그레이션

  1. 각 워크로드에 대한 새 주소 공간이 있는 스포크 VNet을 만듭니다. IP 주소를 다시 할당할 수 없는 경우, 기존 IP 범위가 허브와 겹치지 않는 한 그대로 유지할 수 있습니다.
  2. 각 스포크를 허브와 피어링합니다. 허브 쪽에서 게이트웨이 전송을 사용하도록 설정하고 스포크 쪽에서 원격 게이트웨이를 사용합니다.
  3. 허브 방화벽을 가리키는 기본 경로를 사용하여 스포크 서브넷에 UDR을 적용합니다.
  4. 플랫 VNet에서 적절한 스포크로 VM 및 서비스를 이동하거나 다시 배포합니다. 워크로드 복잡성에 따라 Azure Resource Mover 또는 재배포를 사용합니다.
  5. 이전에 플랫 VNet 내에서 허용한 스포크 간 트래픽 및 스포크에서 인터넷으로의 트래픽 패턴을 허용하도록 방화벽 규칙을 만듭니다.

4단계: 플랫 VNet 서비스 해제

  1. 새 허브-스포크 토폴로지를 통해 모든 워크로드에 접근할 수 있는지 확인합니다.
  2. 개인 IP 주소가 변경된 경우 DNS 레코드를 업데이트합니다.
  3. 모든 트래픽을 마이그레이션하고 유효성을 검사한 후 이전 플랫 VNet을 제거합니다.

팁 (조언)

워크로드를 단계적으로 마이그레이션합니다. 중요하지 않은 워크로드로 시작하여 라우팅 및 방화벽 규칙의 유효성을 검사한 다음 프로덕션 워크로드를 계속 진행합니다.

대신 Virtual WAN 고려해야 하는 경우

허브-스포크 토폴로지의 복잡성이 증가하는 경우 Azure Virtual WAN 더 적합한지 평가합니다.

요인 허브 앤 스포크(전통적) Azure 가상 WAN
Management 고객 관리형 허브 인프라 Microsoft 관리형 허브 라우팅 및 연결
적합한 대상 30개 미만의 VPN 분기 연결, 모든 권한 필요 30개 이상의 VPN 지점, 여러 Azure 지역
Routing 고객이 수동으로 UDR을 구성합니다. 허브에서 자동 라우팅
SD-WAN 통합 수동 NVA 배포 네이티브 SD-WAN 파트너 통합
글로벌 전송 고객 관리형 허브 간 라우팅 필요 기본 제공: 모든 허브가 자동으로 상호 연결

자세한 비교는 Azure Virtual WAN 토폴로지를 참조하세요.

디자인 고려 사항

리프트 앤 시프트 마이그레이션의 경우 모든 마이그레이션 워크로드에서 사용하는 공유 서비스를 사용하여 단일 허브를 배포합니다.

  • VPN Gateway 있는 단일 허브입니다. 허브의 GatewaySubnet에 VPN Gateway(또는 ExpressRoute 게이트웨이)를 배포합니다. 모든 스포크 워크로드는 마이그레이션 도중 및 후에 온-프레미스 연결을 위해 게이트웨이 전송을 통해 이 게이트웨이를 공유합니다.
  • 허브의 Azure Bastion. 허브의 단일 Bastion 배포는 마이그레이션된 서버에서 공용 IP를 노출하지 않고 피어링된 모든 스포크에서 VM에 대한 보안 RDP/SSH 액세스를 제공합니다.
  • 아웃바운드 트래픽에 대한 중앙 집중식 방화벽입니다. 허브에 Azure Firewall 배포합니다. 방화벽을 가리키는 기본 경로를 사용하여 모든 스포크 서브넷에서 UDR을 구성합니다. 모든 아웃바운드 및 스포크 간 트래픽은 이 단일 검사 지점을 통해 흐릅니다.
  • 하나의 허브로 시작한 다음 스포크를 점진적으로 추가합니다. 각 워크로드를 마이그레이션할 때 해당 스포크 VNet을 허브와 피어링합니다. 단일 허브는 최대 500개의 피어링 연결(AVNM을 사용하는 1,000개)을 지원합니다.

마이그레이션 및 현대화 시나리오의 경우 플랫폼 인프라와 애플리케이션 워크로드를 구분하는 이중 허브 토폴로지 계획을 세워야 합니다.

  • 이중 허브 배포. 주 지역에 허브를 배포하고 백업 지역에 두 번째 허브를 배포합니다. 각 허브에는 자체 방화벽, 게이트웨이 및 Bastion이 포함됩니다. PaaS 워크로드에 대한 활성-활성 아키텍처를 지원합니다.
  • IT가 소유하는 허브, 앱팀이 소유하는 스포크. 플랫폼 팀은 허브 구독(연결 구독 패턴, 워크로드 구독과는 별도로 공유 허브 네트워킹 리소스에 대한 전용 Azure 구독)을 관리합니다. 애플리케이션 팀은 Private Link 서브넷과 워크로드 리소스에 대한 제어 권한을 위임받아 자신들의 스포크 구독을 관리합니다.
  • 스포크별 Private Link 서브넷. 각 스포크 VNet에는 프라이빗 엔드포인트용 전용 서브넷이 포함되어 있습니다. 애플리케이션 팀은 자신의 스포크 내에서 PaaS 서비스(Azure SQL, Storage, Key Vault)에 대한 Private Link 연결을 만듭니다.
  • SNAT/DNAT로 허브 방화벽. 각 허브의 중앙 방화벽은 아웃바운드 트래픽에 대한 원본 NAT 및 인바운드 트래픽 패턴에 대한 대상 NAT를 제공합니다. 애플리케이션 팀은 중앙 집중식 검사를 무시할 수 없습니다.

클라우드 간 연결의 경우 기존 허브-스포크 또는 Virtual WAN 올바른 전송 모델을 제공하는지 여부를 평가합니다.

  • 허브-스포크와 Virtual WAN 중 선택 분기 연결이 30개 미만이고 클라우드 간 VPN 터널 수가 적고 하나 또는 두 개의 Azure 지역에서 작동하는 경우 VPN Gateway 사용하는 기존 허브 스포크는 더 간단합니다. VPC, 지사, 리전 또는 클라우드 에지가 많은 경우 Virtual WAN은 확장성이 더 뛰어난 자동화된 라우팅을 제공합니다.
  • 클라우드 간 터널에 대한 VPN Gateway. 허브-스포크 모델에서 허브에 VPN Gateway 배포하고 AWS Virtual Private Gateway 및 Google Cloud VPN 엔드포인트에 대한 사이트 간 연결을 만듭니다. 각 연결은 IPSec/IKE 암호화를 사용합니다.
  • 복잡성 증가를 평가합니다. 클라우드 간 자산이 증가하는 경우(더 많은 AWS 계정, Google Cloud 프로젝트 또는 Azure 지역), 허브-스포크 및 Virtual WAN 결정을 다시 검토합니다. Virtual WAN 대규모로 많은 터널을 관리할 때 비용 효율적입니다.

전체 비교를 보려면 Azure Virtual WAN topology를 참조하세요.

사전 요구 사항

허브 및 스포크 네트워크를 디자인하기 전에 다음을 수행합니다.

  • 가상 네트워크 및 서브넷 계획을 완료합니다. 필요한 스포크 수와 각 스포크에 필요한 서브넷을 파악합니다.
  • IP 주소 체계를 정의합니다. 허브 및 스포크 주소 공간은 겹쳐서는 안됩니다.
  • VNet 피어링이 전이적이지 않음을 이해합니다. 스포크는 허브를 통해 다른 스포크에 대한 연결을 상속하지 않습니다.

보안 고려 사항

허브 및 스포크 토폴로지에서는 허브의 보안 적용을 중앙 집중화합니다. 다음 원칙을 적용합니다.

  • 허브 방화벽을 통해 모든 스포크 트래픽을 라우팅합니다. 방화벽을 가리키는 기본 경로와 함께 UDR을 사용합니다. 이 구성은 방화벽이 모든 스포크 간 및 스포크에서 인터넷으로의 트래픽을 검사하고 로그를 기록하도록 합니다.
  • 스포크 서브넷에서 NSG를 심층 방어로 사용합니다. 중앙 방화벽이 있더라도 스포크 서브넷의 네트워크 보안 그룹은 추가적인 분할 계층을 제공합니다. 서브넷 수준에서 예기치 않은 횡적 트래픽을 거부합니다. NSG 디자인 지침은 네트워크 보안 그룹 및 애플리케이션 보안 그룹을 참조하세요.
  • 신중하게 게이트웨이 트랜짓을 사용하도록 설정하세요. 게이트웨이 트랜짓은 온-프레미스 경로를 모든 스포크에 공개합니다. 방화벽 규칙이 확장된 연결성을 반영하는지 확인하세요.
  • 스포크 VM에서 공용 IP를 제거합니다. 허브의 Azure Bastion VM을 인터넷에 노출하지 않고도 보안 관리 액세스를 제공합니다.
  • 각 스포크는 보안 경계로 처리합니다. 다른 스포크에 있는 워크로드는 기본적으로 격리된 상태로 유지됩니다. 스포크 간 연결에는 명시적 라우팅 및 방화벽 규칙이 필요합니다.

자세히 알아보기

다음 단계

팁 (조언)

직접 탐색하시겠습니까? 개요 탐색기로 돌아가서 기능별로 다음 문서를 찾습니다.

리프트 앤 시프트 과정의 다음 단계:

온-프레미스 네트워크에 연결: 허브 VNet에서 VPN Gateway 또는 ExpressRoute를 설정하여 중요한 마이그레이션 종속성을 설정합니다.

현대화 과정의 다음 단계:

다중 리전 배포를 계획하세요: 고객 대상 애플리케이션을 주 리전과 백업 리전에 걸쳐 활성-활성으로 배포합니다.

멀티클라우드 여정의 다음 단계:

Azure Virtual WAN을 트랜짓 모델로 평가: 여러 VPC, 지사 및 지역이 포함된 멀티클라우드 환경에 Virtual WAN과 허브-스포크 아키텍처 중 어느 것이 가장 적합한지 평가합니다.

  • Last updated on