단일 워크로드 플랫 네트워크 토폴로지

플랫 네트워크는 단일 워크로드를 호스트하는 여러 서브넷이 있는 하나의 가상 네트워크인 가장 간단한 Azure 네트워크 토폴로지입니다. 이 문서에서는 이 패턴을 사용하는 시기와 이를 구현하는 방법을 설명합니다.

이 문서에서 다루는 내용

이 문서에서는 가장 간단한 Azure 네트워크 토폴로지, 즉 하나의 워크로드를 호스팅하는 여러 서브넷이 있는 단일 가상 네트워크에 대해 설명합니다. 한 팀에서 관리하는 단일 애플리케이션이 있고 중앙 방화벽 또는 VPN 게이트웨이와 같은 공유 서비스가 필요하지 않은 경우 이 패턴을 사용합니다.

이 문서가 필요한 사람

다음 경우 이 문서를 읽어보세요.

  • Azure 첫 번째 워크로드를 배포하고 있습니다.
  • 단일 팀이 모든 리소스를 소유하고 운영합니다.
  • 여러 워크로드에서 공유 네트워크 서비스(방화벽, Bastion, 게이트웨이)가 필요하지 않습니다.
  • 서브넷 수준 격리 및 보안을 제공하는 가장 간단한 네트워크를 원합니다.

리프트 앤 시프트 포커스: 구성 요소당 서브넷이 있는 단일 플랫 VNet은 한 지역에서 하나의 워크로드를 다시 호스팅하는 데 적합한 첫 번째 단계인 경우가 많습니다.

현대화 중점 사항: 초기 PaaS 파일럿 또는 현대화할 단일 워크로드에는 플랫 네트워크를 사용하고, 공유 서비스나 두 번째 리전을 추가할 때 허브-스포크 아키텍처로 무리 없이 전환할 수 있도록 서브넷을 설계합니다.

클라우드 간 포커스: 클라우드 간 마이그레이션 중에 단일 Azure 발판으로 플랫 VNet을 사용합니다. 워크로드를 먼저 배치한 다음, 디자인이 완성됨에 따라 허브 또는 Virtual WAN 조인할 수 있도록 주소 공간 및 분할을 계획합니다.

Azure 서비스 및 기능

플랫 네트워크 토폴로지에서는 다음과 같은 핵심 Azure 서비스를 사용합니다.

서비스 이 토폴로지의 역할
Azure Virtual Network 워크로드에 대한 격리된 프라이빗 주소 공간을 제공합니다. 가상 네트워크의 범위는 단일 Azure 지역으로 지정됩니다.
서브넷 + NSG(네트워크 보안 그룹) 서브넷은 애플리케이션 계층을 구분합니다. NSG는 각 서브넷 경계에서 인바운드 및 아웃바운드 트래픽을 필터링합니다. NSG는 상태 저장 방식입니다. 허용된 연결의 응답 트래픽은 자동으로 허용됩니다.
Azure 프라이빗 DNS 영역 가상 네트워크 내의 리소스에 대한 내부 이름 확인을 제공합니다. VM이 DNS 레코드에 자동으로 등록되도록 자동 등록이 사용하도록 설정된 영역을 연결합니다.
게이트웨이 서브넷(선택 사항) 온-프레미스 네트워크에 대한 단일 연결이 필요한 경우 VPN 또는 ExpressRoute 게이트웨이를 호스트합니다.

선택 방법: 플랫을 유지할 것인가, 허브-스포크로 전환할 것인가?

다음 의사 결정 테이블을 사용하여 플랫 토폴로지를 사용자 환경에 적합한지 또는 허브 및 스포크 토폴로지를 대신 채택해야 하는지 여부를 결정합니다.

상태 권장 사항
단일 워크로드, 단일 팀, 공유 서비스 없음 평평하게 유지: 이 문서가 해당됩니다.
두 번째 독립 워크로드에는 자체 네트워크 격리가 필요합니다. 허브-앤-스포크 토폴로지로 전환
워크로드 간에 공유 방화벽, VPN 게이트웨이 또는 Azure Bastion 필요합니다. 허브-앤-스포크 토폴로지로 전환
보안 정책은 여러 워크로드에서 중앙에서 관리해야 합니다. 허브-스포크 토폴로지로 전환

팁 (조언)

6~12개월 내에 두 번째 워크로드를 추가할 것으로 예상되는 경우 첫날부터 허브 및 스포크로 시작하는 것이 좋습니다. 가상 네트워크와 피어링 연결을 하나만 추가하면 오버헤드가 최소화됩니다. 이 접근 방식은 나중에 서비스 중단을 초래하는 마이그레이션을 피할 수 있습니다.

디자인 고려 사항

리프트 앤 시프트를 위한 플랫 네트워크 설계 중점

  • 각 애플리케이션 구성 요소(웹, 앱, 데이터)에 대한 서브넷과 함께 하나의 VNet을 사용하여 최소한의 재설계로 일반적인 온-프레미스 3계층 레이아웃을 미러링합니다.
  • 서브넷 간에 NSG를 적용하여 기존 구분을 다시 만들고 주소 공간을 온-프레미스 범위와 정렬하여 겹치지 않도록 합니다.
  • 단일 팀이 워크로드를 소유하고 있으며 공유 방화벽, 게이트웨이 또는 Bastion 서비스가 필요하지 않은 동안에는 평평하게 유지합니다.
  • 두 번째 워크로드를 추가하기 전에 허브 및 스포크로의 이동을 계획하여 공유 서비스가 개조되는 대신 허브에 배치되도록 합니다.

플랫 네트워크 디자인 포커스 현대화

  • 초기 PaaS 파일럿 또는 단일 현대화된 워크로드에 대해 플랫 네트워크를 사용합니다. 앱 계층을 서브넷에 배치하고 전용 서브넷의 프라이빗 엔드포인트를 통해 Azure PaaS에 연결합니다.
  • Application Gateway 및 프라이빗 엔드포인트와 같이 추가할 플랫폼 서비스를 위해 전용 서브넷을 미리 예약하여 네트워크가 읽기 전용 없이 확장되도록 합니다.
  • 나중에 워크로드가 허브-앤-스포크 설계의 스포크가 되더라도 세분화가 이미 마련되도록 계층별로 NSG와 애플리케이션 보안 그룹을 적용하세요.
  • 나중에 주소를 재할당하지 않고도 다른 리전 및 VNet과 피어링하거나 허브로 전환할 수 있도록 주소 공간이 서로 겹치지 않게 유지하세요.

클라우드 간 플랫 네트워크 디자인 포커스

  • 클라우드 간 마이그레이션 중에 단일 Azure 발판으로 플랫 VNet을 사용합니다. 워크로드를 먼저 착륙한 다음 디자인이 완성되면 허브에서 연결을 연결합니다.
  • 나중에 변환 없이 IPsec 또는 상호 연결 라우팅을 조인할 수 있도록 AWS VPC 및 Google Cloud 네트워크와 겹치지 않도록 플랫 VNet의 주소 공간을 계획합니다.
  • NSG를 사용해 계층 분리를 유지하여 워크로드가 보안된 Virtual WAN 허브 뒤의 스포크가 되더라도 해당 워크로드의 보안 태세가 그대로 유지되도록 합니다.
  • 다른 클라우드와 일치하도록 서브넷 명명 및 태그 지정을 표준화하여 마이그레이션 중과 마이그레이션 후에 워크로드의 상관 관계를 쉽게 유지할 수 있습니다.

사전 요구 사항

이 토폴로지 구현 전에 다음을 수행합니다.

  • 가상 네트워크 및 NSG를 만들 수 있는 권한이 있는 Azure 구독입니다.
  • 계획된 IP 주소 공간입니다. /16 주소 공간은 단일 워크로드의 일반적인 시작점인 65,536개의 주소를 제공합니다. Azure 내부 사용을 위해 서브넷당 5개의 주소를 예약합니다. 자세한 지침은 계획 IP 주소 지정을 참조하세요.
  • 애플리케이션 계층(예: 웹, 애플리케이션 및 데이터)을 이해하여 서브넷에 매핑할 수 있습니다. 서브넷 디자인 지침은 가상 네트워크 및 서브넷 디자인을 참조하세요.

네트워크 레이아웃

단일 가상 네트워크 내에서 각각 NSG로 보호되는 웹, 애플리케이션 및 데이터 계층 서브넷이 있는 플랫 네트워크 토폴로지 다이어그램

플랫 네트워크 토폴로지에서는 다음 구조를 따릅니다.

  • 단일 주소 공간이 있는 하나의 가상 네트워크(예: 10.0.0.0/16).
  • 여러 서브넷: 애플리케이션 계층 또는 구성 요소당 하나씩:
    • 웹 계층 서브넷(예: 10.0.1.0/24).
    • 애플리케이션 계층 서브넷(예: 10.0.2.0/24).
    • 데이터 계층 서브넷(예: 10.0.3.0/24).
    • 게이트웨이 서브넷(선택 사항( 예: 10.0.255.0/27).
  • 각 서브넷에 연결된 NSG, 즉 각 계층에 필요한 트래픽만 허용하는 규칙이 적용된 NSG
  • 자동 등록을 사용하도록 설정된 가상 네트워크에 연결된 하나의 프라이빗 DNS 영역입니다.

메모

IP 주소 범위를 신중하게 계획합니다. 나중에 허브 및 스포크 토폴로지로 마이그레이션하는 경우 스포크 가상 네트워크에는 허브와 겹치지 않는 CIDR 범위가 있어야 합니다. 이제 잘 구성된 주소 체계를 선택하면 마이그레이션 중에 충돌이 방지됩니다.

보안 고려 사항

플랫 네트워크에 다음 보안 사례를 적용합니다.

  • 모든 서브넷에서 NSGs. 거부-모든 인바운드 기준부터 시작하여 계층 간의 합법적인 트래픽에 대한 특정 허용 규칙을 추가합니다. 예를 들어 웹 계층에서 애플리케이션 계층으로 HTTPS를 허용하고 애플리케이션 계층에서 데이터 계층으로 SQL을 허용합니다.
  • VM에서 직접 공용 IP가 없습니다. 부하 분산 장치 또는 Application Gateway를 통해 서비스를 노출합니다. 관리 액세스에 Azure Bastion 사용합니다.
  • 내부 확인을 위한 프라이빗 DNS. 프라이빗 DNS 영역은 공용 DNS 쿼리를 통해 내부 호스트 이름이 노출되지 않도록 방지합니다.
  • 게이트웨이 서브넷 격리. VPN 또는 ExpressRoute 게이트웨이를 추가하는 경우 전용 서브넷(이름) GatewaySubnet에 배치합니다. 게이트웨이 서브넷의 NSG는 지원되지 않습니다. NSG를 이 서브넷에 연결하면 가상 네트워크 게이트웨이가 예상대로 작동하지 않을 수 있습니다.

Important

연결을 허용하는 NSG 규칙을 제거하면 기존 활성 연결이 중단 없이 계속됩니다. 제거된 규칙과 일치하는 새 연결만 차단됩니다.

다음 문서에서는 관련 항목에 대한 자세한 지침을 제공합니다.

자세히 알아보기

이 토폴로지에서 사용되는 Azure 서비스에 대한 자세한 내용은 다음을 참조하세요.

다음 단계

팁 (조언)

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

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

허브 및 스포크 토폴로지 디자인: 대부분의 리프트 앤 시프트 마이그레이션은 플랫 네트워크를 빠르게 능가합니다. 처음부터 중앙 집중식 공유 서비스를 계획합니다.

현대화 과정의 다음 단계:

허브 및 스포크 토폴로지 디자인: 여러 서비스, 보안 제어 및 팀이 있는 현대화된 워크로드에는 첫날부터 허브 및 스포크가 필요합니다.

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

클라우드 간 연결 아키텍처를 계획하세요: 멀티클라우드 환경에는 평면 네트워크가 아니라 트랜짓 아키텍처가 필요합니다. 다중 클라우드 연결 모델을 디자인합니다.

  • Last updated on