Azure Virtual Network

클라우드에 VM 몇 대를 만들면 바로 부딪히는 문제는 이 VM들이 서로 어떻게 통신하고, 외부에서는 어디까지 접근할 수 있느냐입니다. 네트워크 경계가 없으면 모든 리소스가 같은 평면에 놓이고, 데이터베이스가 인터넷에 직접 노출되거나 개발 서버와 프로덕션 서버가 뒤섞일 수 있습니다. 방화벽 규칙만으로 이를 통제하려 해도, 리소스가 어디에 속하는지 구분이 없으면 규칙이 복잡해지고 실수가 생깁니다. 온프레미스 환경에서는 물리 스위치와 VLAN으로 네트워크를 나누었지만, 클라우드에서는 물리 장비가 보이지 않으니 같은 방식을 쓸 수 없습니다. 주소 공간을 정의하고, 서브넷을 나누고, 누가 어디로 갈 수 있는지를 소프트웨어로 설계할 수 있는 가상 네트워크가 필요한 이유입니다.

클라우드 초기에는 VM을 만들면 플랫폼이 알아서 네트워크를 배정했습니다. 서비스 규모가 작을 때는 문제가 없었지만, 리소스가 늘고 팀이 나뉘면서 '이 서버는 저 서버와 통신하면 안 되는데 같은 네트워크에 있다', '개발 환경과 프로덕션이 분리되지 않는다', '온프레미스 데이터센터와 안전하게 연결할 방법이 없다' 같은 운영 문제가 반복됐습니다. 물리 네트워크에서는 스위치, 라우터, VLAN으로 이런 문제를 풀었지만 클라우드에서는 하드웨어를 직접 만질 수 없습니다. 소프트웨어로 정의된 네트워크가 필요했고, 사용자가 주소 공간부터 보안 경계까지 직접 설계할 수 있는 가상 네트워크가 그 응답이었습니다. Azure에서 VNet이 거의 모든 리소스 배포의 전제 조건이 된 것은 이런 배경 때문입니다.

VNet은 사용자가 지정한 CIDR 블록(예: 10.0.0.0/16)을 기반으로 주소 공간을 잡고, 그 안에서 서브넷(예: 10.0.1.0/24, 10.0.2.0/24)을 나누는 것에서 시작합니다. 같은 VNet 안의 서브넷끼리는 기본적으로 통신이 가능하지만, NSG(네트워크 보안 그룹)를 서브넷이나 NIC에 붙이면 포트와 프로토콜 단위로 허용·차단을 제어할 수 있습니다. 외부와의 연결은 방향에 따라 다릅니다. 인터넷에서 들어오는 트래픽은 퍼블릭 IP나 로드 밸런서를 통해 들어오고, 프라이빗 서브넷의 리소스가 외부로 나가야 할 때는 NAT Gateway를 거칩니다. 다른 VNet과는 VNet 피어링으로 Azure 백본을 통해 사설 통신이 가능하고, 온프레미스와는 VPN Gateway나 ExpressRoute로 연결합니다. 이처럼 VNet은 주소 설계, 보안 규칙, 라우팅 경로를 하나의 단위로 묶어서 네트워크의 경계와 흐름을 결정하는 구조입니다.

VNet과 AWS VPC는 둘 다 클라우드 안에 사설 네트워크를 만들고, 서브넷으로 나누고, 보안 규칙과 라우팅을 제어한다는 점에서 거의 같은 문제를 풉니다. 차이는 구현 방식의 세부에 있습니다. AWS VPC는 서브넷이 가용 영역(AZ)에 귀속되고, 보안 그룹은 상태 기반(stateful)이며, 네트워크 ACL은 서브넷 단위 무상태(stateless) 필터입니다. VNet의 서브넷은 특정 AZ에 묶이지 않고 리전 전체에 걸치며, NSG가 상태 기반 필터 역할을 서브넷과 NIC 모두에서 담당합니다. 클라우드를 처음 설계할 때 어떤 플랫폼을 쓰느냐에 따라 하나를 선택하게 되지만, 개념적으로는 '사설 주소 공간 정의 → 서브넷 분할 → 보안 규칙 → 라우팅 제어'라는 흐름이 동일하므로 하나를 이해하면 다른 쪽으로의 전환이 비교적 수월합니다.

VNet은 Azure에서 가상 서버, 컨테이너 워크로드, 관리형 애플리케이션, 데이터 저장소를 사설 주소 공간 안에 배치하는 기본 토대입니다. 새 프로젝트를 시작할 때 가장 먼저 하는 작업이 주소 공간을 정하고 서브넷을 나누는 일이 되는 경우가 많습니다. 웹 계층은 퍼블릭 서브넷에, 데이터 계층은 프라이빗 서브넷에 놓고, NSG로 443 포트만 열어 두는 식의 구성이 가장 기본적인 패턴입니다. 팀이 커지면 환경별(개발/스테이징/프로덕션) 네트워크를 분리하거나, 피어링으로 연결하는 구조로 확장합니다. 반대로 주소 공간을 처음에 너무 좁게 잡으면 나중에 피어링이나 VPN 연결 시 주소가 겹쳐 고치기 어려워지므로, 초기 설계 단계에서 여유를 두는 것이 중요합니다. VNet 자체는 복잡한 애플리케이션 로직을 처리하지 않으므로, 네트워크 토폴로지 설계 도구로 보는 것이 적절합니다.

다음에 볼 개념

함께 보면 좋은 개념