가상 네트워크 및 서브넷

Azure 가상 네트워크(VNet)는 Azure 클라우드에서 사용자가 정의하고 제어하는 논리적으로 격리된 네트워크입니다. Azure 네트워킹의 기본 구성 요소로서 가상 머신, 데이터베이스 및 앱 서비스와 같은 Azure 리소스가 서로, 인터넷 및 온-프레미스 네트워크와 안전하게 통신할 수 있도록 합니다. VNet은 단일 Azure 지역과 사용자가 만들 때 정의하는 특정 IPv4(선택적으로 IPv6) CIDR 주소 공간에 속합니다.

VNet을 만들 때 CIDR 표기법을 사용하여 주소 공간을 할당합니다. CIDR(Classless Inter-Domain Routing) 표기법은 네트워크 주소와 네트워크 접두사에 사용되는 비트 수를 함께 지정합니다. 예를 들어 10.0.0.0/16은 65,536개의 IP 주소(10.0.0.0~10.0.255.255)를 제공합니다. 주소 공간은 RFC 1918에 따른 프라이빗 IP 범위(10.0.0.0/8, 172.16.0.0/12 또는 192.168.0.0/16)여야 합니다. 계획된 모든 서브넷을 수용하고 확장할 여유가 있을 만큼 큰 주소 공간을 선택하되, 하이브리드 연결을 계획하고 있다면 온-프레미스 네트워크와 주소가 겹치지 않도록 하세요.

서브넷은 VNet 주소 공간을 더 작은 네트워크 세그먼트로 나눕니다. 각 서브넷에는 자체 IP 범위(VNet 주소 공간의 하위 집합)가 있으며 서로 다른 유형의 리소스를 포함할 수 있습니다. 서브넷의 목적은 두 가지입니다. 관련 리소스를 그룹화하는 구성과 서로 다른 리소스 그룹에 각기 다른 보안 규칙을 적용하는 격리입니다. 예를 들어 웹 서버용 웹 계층 서브넷(10.0.1.0/24), 애플리케이션 서버용 앱 계층 서브넷(10.0.2.0/24), 데이터베이스용 데이터 계층 서브넷(10.0.3.0/24)을 사용할 수 있습니다.

Azure는 각 서브넷에서 처음 네 개의 IP 주소와 마지막 IP 주소를 자체 용도로 예약합니다. 10.0.1.0/24 서브넷의 경우 다음과 같습니다. 10.0.1.0(네트워크 주소), 10.0.1.1(defaultRoute 게이트웨이), 10.0.1.2 및 10.0.1.3(Azure DNS용으로 예약), 10.0.1.255(브로드캐스트 주소)입니다. 따라서 /24 서브넷에서 사용할 수 있는 IP는 251개입니다. 서브넷 크기를 정할 때 이 예약을 고려하세요. /28 서브넷에서는 16개 중 5개가 예약되므로 사용할 수 있는 주소가 11개뿐입니다.

기본적으로 동일한 VNet 내의 리소스는 서로 다른 서브넷에 있더라도 프라이빗 IP 주소를 사용하여 서로 통신할 수 있습니다. VNet 내부 통신에는 추가 구성이 필요하지 않습니다. 서로 다른 VNet의 리소스는 기본적으로 통신할 수 없으며, VNet 피어링을 사용하여 명시적으로 연결해야 합니다. 동일한 서브넷의 리소스는 같은 네트워크 세그먼트를 공유하므로 Azure의 소프트웨어 정의 네트워킹 계층에서 서로 통신할 때 가장 직접적인 경로를 사용합니다.

VNet의 VM은 기본적으로 인터넷으로 아웃바운드 연결을 시작할 수 있습니다. Azure는 관리되는 NAT 서비스를 통해 아웃바운드 인터넷 액세스를 자동으로 제공합니다. 인바운드 인터넷 액세스를 사용하려면 리소스의 네트워크 인터페이스 또는 부하 분산 장치에 공용 IP 주소를 할당해야 합니다. 그런 다음 네트워크 보안 그룹(NSG) 규칙을 사용하여 허용할 포트와 프로토콜을 정확하게 지정하면서 인바운드 액세스를 제어합니다. 일반적인 아키텍처에서는 공용 IP가 있는 웹 서버를 공용 서브넷에 배치하고, 웹 계층에서만 액세스할 수 있는 애플리케이션 서버를 프라이빗 서브넷에 배치합니다.

기본적으로 Azure가 라우팅을 자동으로 처리합니다. 서브넷 간 트래픽은 VNet 내부에 유지되고, 아웃바운드 인터넷 트래픽은 NAT 처리되며, Azure 서비스로 향하는 트래픽은 Azure 백본을 사용합니다. 사용자 정의 경로(UDR)를 경로 테이블에서 사용하여 이 동작을 재정의할 수 있습니다. 일반적인 사용 사례는 중앙 집중식 검사를 위해 허브 VNet의 네트워크 가상 어플라이언스(NVA) 또는 Azure Firewall을 통해 모든 아웃바운드 인터넷 트래픽을 강제로 전송하는 것입니다. 경로 테이블을 만들고 경로 항목을 추가한 다음 하나 이상의 서브넷에 테이블을 연결하여 적용합니다.

Azure App Service(VNet 통합), Azure Kubernetes 서비스, Azure SQL 관리형 인스턴스, Azure Databricks와 같은 일부 Azure 서비스에는 해당 서비스에 위임된 전용 서브넷이 필요합니다. 위임된 서브넷이란 Azure가 사용자를 대신하여 서비스별 리소스(네트워크 인터페이스, 내부 IP 주소)를 해당 서브넷에 삽입할 수 있다는 의미입니다. 위임된 서브넷에는 다른 유형의 리소스를 배포할 수 없으며, 해당 Azure 서비스 전용으로 예약됩니다. 위임이 필요한 서비스를 사용할 계획이라면 항상 충분한 IP 공간을 갖춘 전용 서브넷을 할당하시기 바랍니다.

VNet 설계를 위한 주요 모범 사례는 다음과 같습니다. VNet을 만들기 전에 주소 공간을 계획하십시오. 리소스를 다시 만들지 않고는 주소 공간을 변경할 수 없습니다. 각 애플리케이션 계층에 별도의 서브넷을 사용하십시오. 이렇게 하면 서로 다른 보안 정책을 적용할 수 있습니다. VPN 또는 ExpressRoute를 통해 연결할 계획이라면 온프레미스 네트워크와 주소 공간이 겹치지 않도록 하십시오. 확장이 필요한 서비스에는 더 큰 서브넷을 예약하십시오(예: AKS 노드 풀). 대규모 환경을 효율적으로 관리할 수 있도록 리소스 이름을 명확하게 지정하십시오(예: vnet-prod-eastus-001). 잘 설계된 VNet은 임시로 구축된 VNet보다 보안 유지와 문제 해결이 훨씬 쉽습니다.

Azure VNet은 두 가지 방식으로 온프레미스 네트워크에 연결할 수 있습니다. VPN 게이트웨이 — 공용 인터넷을 통해 암호화된 IPsec/IKE 터널을 사용하며, 중간 수준의 대역폭이 필요한 경우 비용 효율적입니다. Azure ExpressRoute — 네트워크 공급자 파트너를 통한 비공개 전용 광섬유 연결로, VPN보다 더 높은 대역폭, 더 짧은 지연 시간, 더 예측 가능한 성능을 제공합니다. 민감한 워크로드나 보장된 대역폭이 필요한 시나리오에는 ExpressRoute가 선호되지만, 비용이 훨씬 높고 프로비저닝에 더 오랜 시간이 걸립니다.

VNet의 주소 공간 크기를 정할 때는 현재와 미래의 요구 사항을 모두 계획해야 합니다. 일반적인 엔터프라이즈 패턴은 다음과 같습니다. VNet 주소 공간: /16(주소 65,536개). 서브넷: 워크로드 계층마다 /24(각각 사용 가능한 주소 251개). /16 VNet에는 /24 서브넷을 256개 포함할 수 있으므로 대부분의 환경에 충분합니다. 매우 큰 환경에서는 /8을 사용하거나 서로 겹치지 않는 범위를 여러 개 요청하십시오. 항상 확장 여유 공간을 남겨 두십시오. 오늘 /24를 할당했지만 내년에 /22가 필요해지면 나중에 주소를 다시 지정하는 작업이 매우 번거로워집니다.

이 단원에서 다룬 Microsoft Azure 기초(AZ-900) 개념을 얼마나 이해했는지 확인해 보십시오.

이 단원에서는 다음을 배웠습니다. Azure VNet은 정의된 CIDR 주소 공간을 갖고 단일 지역으로 범위가 지정된 논리적으로 격리된 네트워크입니다. 또한 서브넷은 VNet을 여러 세그먼트로 나누어 구성과 보안 정책을 격리합니다. 그리고 Azure는 서브넷마다 IP 주소 5개를 예약하며, 동일한 VNet 내부의 리소스는 추가 구성 없이 기본적으로 비공개 방식으로 통신합니다. 다음 단원에서는 트래픽 필터링을 위한 Network Security Group과 Application Security Group을 살펴보겠습니다.