Azure 네트워크는 VNet을 중심으로 주소 공간과 서브넷을 구성하고, NIC를 통해 가상 머신과 리소스를 연결하는 구조이다.
서로 다른 네트워크 연결, 온프레미스 연결, PaaS 사설 접근, 트래픽 통제와 분산은 목적에 따라 별도의 Azure 네트워크 서비스를 사용한다.
- (1) Azure에서 사설 네트워크가 필요한 이유
- (2) VNet과 주소 공간
- (3) Subnet과 NIC
- (4) VNet Peering
- (5) VPN Gateway와 ExpressRoute
- (6) Service Endpoint와 Private Link
- (7) Azure DNS와 Traffic Manager
- (8) NSG, Azure Firewall, WAF
- (9) Azure Bastion과 트래픽 분산
- (10) 온라인 주문 서비스의 3-Tier 네트워크 구성
- (11) 목적별 Azure 네트워크 서비스 선택
- (12) 자료 외 보완
- (13) 핵심 정리
- (14) 핵심 키워드
- (15) 연결되는 개념
- (16) 다음 학습
(1) Azure에서 사설 네트워크가 필요한 이유

클라우드에 생성한 가상 머신과 데이터베이스도 서로 통신하고 외부 사용자 또는 온프레미스 시스템과 연결되어야 한다
. Azure는 이러한 통신을 외부 인터넷과 분리된 논리적 공간에서 구성하기 위해 VNet을 제공한다.
- Azure 리소스를 사설 IP 기반으로 연결한다.
- 웹, 애플리케이션, 데이터 계층을 서로 다른 네트워크 영역으로 분리한다.
- 외부에서 직접 접근할 수 있는 리소스와 내부에서만 사용할 리소스를 구분한다.
- 서브넷과 NIC에 보안 규칙을 적용하여 허용할 트래픽을 제한한다.
- 온프레미스 네트워크나 다른 VNet과 연결할 수 있다.
- PaaS 서비스에 사설 경로 또는 사설 IP로 접근할 수 있다.
개념 09에서 정리한 IP 주소, 서브넷, DNS, 방화벽, 로드 밸런서가 Azure에서는 VNet, Subnet, Azure DNS, NSG, Azure Firewall, Azure Load Balancer 등의 리소스로 구현된다.
(2) VNet과 주소 공간
1) VNet의 정의
Azure Virtual Network(VNet)는 Azure 안에 만드는 격리된 사설 네트워크 공간이다.
VNet은 물리 네트워크의 주소 체계, 서브넷 분리, 라우팅, 보안 정책과 네트워크 연결 기능을 소프트웨어 리소스로 제공한다.
- Azure 리소스가 Private IP를 사용하여 통신하는 기본 공간이다.
- VNet 생성 시 사용할 IP 주소 범위를 CIDR로 지정한다.
- 하나 이상의 Subnet으로 나누어 사용할 수 있다.
- 기본적으로 다른 VNet과 논리적으로 격리된다.
- VNet Peering, VPN Gateway 등을 통해 다른 네트워크와 연결할 수 있다.
2) 주소 공간
주소 공간(Address Space)은 VNet 안에서 사용할 수 있는 사설 IP 주소의 전체 범위이다.
VNet 주소 공간: 10.0.0.0/16
전체 범위
10.0.0.0 ~ 10.0.255.255
이 범위 안에서 Subnet을 분할
10.0.1.0/24
10.0.2.0/24
10.0.3.0/24
- 사설 IP 주소 범위를 사용한다.
- 하나의 VNet에 하나 이상의 주소 범위를 지정할 수 있다.
- Subnet은 반드시 VNet 주소 공간 안에서 생성해야 한다.
- 향후 확장을 고려하여 주소 공간을 설계해야 한다.
온프레미스 네트워크나 다른 VNet과 주소 범위가 겹치면 Peering 또는 VPN 연결 후 목적지 네트워크를 구분할 수 없어 정상적인 라우팅이 어렵다.
3) VNet의 격리
서로 다른 VNet은 기본적으로 직접 통신하지 않는다.
| 통신 대상 | 필요한 구성 |
|---|---|
| 같은 VNet의 Subnet 간 | 기본 시스템 경로로 통신 가능하며 NSG 규칙에 따라 제한할 수 있다. |
| 서로 다른 VNet 간 | VNet Peering 또는 네트워크 게이트웨이 연결이 필요하다. |
| VNet과 온프레미스 간 | VPN Gateway 또는 ExpressRoute가 필요하다. |
(3) Subnet과 NIC
1) Subnet
Subnet은 VNet의 주소 공간을 더 작은 IP 주소 범위로 나눈 논리적 네트워크 구획이다.
리소스를 용도별로 구분하고, 각 영역에 다른 보안 규칙과 라우팅 정책을 적용하는 단위로 사용한다.
- VNet의 CIDR 범위 일부를 할당받는다.
- 웹, 애플리케이션, 데이터 등의 역할별로 리소스를 분리한다.
- NSG를 연결하여 Subnet 단위로 트래픽을 통제할 수 있다.
- Route Table을 연결하여 Subnet의 패킷 경로를 지정할 수 있다.
- 일부 Azure 서비스는 전용 Subnet을 요구한다.
- 주소 할당을 세분화하여 IP 주소를 효율적으로 관리한다.
| Subnet | 주소 범위 | 배치 대상 |
|---|---|---|
| web-subnet | 10.0.1.0/24 | 웹 서버, 외부 요청 처리 계층 |
| app-subnet | 10.0.2.0/24 | API 서버, 애플리케이션 계층 |
| data-subnet | 10.0.3.0/24 | 데이터베이스, 내부 데이터 계층 |
2) Public·Private Subnet의 의미
Public Subnet과 Private Subnet은 Subnet 자체의 이름보다 외부 인터넷과의 연결 방식에 따라 구분되는 개념이다.
| 구분 | 의미 |
|---|---|
| 외부 접근 가능한 영역 | Public IP, Load Balancer 등의 외부 진입점을 통해 인터넷 요청을 받을 수 있게 구성한 Subnet |
| 내부 전용 영역 | 외부 Public IP를 직접 연결하지 않고 내부 네트워크에서만 접근하도록 구성한 Subnet |
3) NIC

NIC(Network Interface)는 가상 머신과 VNet의 Subnet을 연결하는 가상 네트워크 장치이다.
- VM이 다른 VM, 인터넷, 온프레미스 네트워크와 IP 프로토콜로 통신하게 한다.
- NIC는 특정 VNet의 Subnet에 연결된다.
- NIC의 IP Configuration을 통해 Private IP가 할당된다.
- 필요한 경우 Public IP 리소스를 연결할 수 있다.
- 하나의 NIC에 여러 IP 주소 구성을 지정할 수 있다.
- NIC 또는 NIC가 속한 Subnet에 NSG를 연결할 수 있다.
- NIC를 Load Balancer의 백엔드 풀과 연결할 수 있다.
VM 자체가 VNet에 직접 붙는 것이 아니라, VM에 연결된 NIC가 Subnet에 배치되고 Private IP를 할당받는다.
4) VNet·Subnet·NIC의 연결 관계
VNet 10.0.0.0/16
├─ web-subnet 10.0.1.0/24
│ └─ VM-WEB
│ └─ NIC-WEB
│ └─ Private IP 10.0.1.4
│
├─ app-subnet 10.0.2.0/24
│ └─ VM-APP
│ └─ NIC-APP
│ └─ Private IP 10.0.2.4
│
└─ data-subnet 10.0.3.0/24
└─ VM-DB
└─ NIC-DB
└─ Private IP 10.0.3.4
| 구성 요소 | 답하는 질문 |
|---|---|
| VNet | 전체 사설 네트워크 공간은 무엇인가? |
| Subnet | 그 네트워크를 어떤 영역으로 나눌 것인가? |
| NIC | 개별 VM을 어느 Subnet과 IP에 연결할 것인가? |
(4) VNet Peering

VNet Peering은 서로 다른 VNet을 연결하여 각 VNet의 리소스가 사설 IP로 통신하게 하는 기능이다.
- 트래픽은 공용 인터넷이 아니라 Microsoft 백본 네트워크를 사용한다.
- 피어링된 VNet의 리소스는 하나의 연결된 네트워크처럼 통신할 수 있다.
- 게이트웨이 없이 낮은 지연의 VNet 간 연결을 구성할 수 있다.
- 각 VNet의 주소 공간은 유지된다.
1) Regional·Global Peering
| 구분 | 연결 범위 |
|---|---|
| Regional VNet Peering | 같은 Azure Region에 있는 VNet을 연결한다. |
| Global VNet Peering | 서로 다른 Azure Region에 있는 VNet을 연결한다. |
2) 피어링 구성 조건
- 연결할 VNet의 주소 공간이 서로 겹치지 않아야 한다.
- 양쪽 VNet에서 피어링 연결 상태를 확인해야 한다.
- NSG 또는 Route Table이 트래픽을 차단하지 않아야 한다.
- 필요한 경우 게이트웨이 전송 또는 원격 게이트웨이 사용 설정을 구성한다.
3) 사용 구조
Hub VNet
├─ Azure Firewall
├─ VPN Gateway
└─ 공통 DNS·관리 서비스
│
├─ Peering ─ Spoke VNet A
├─ Peering ─ Spoke VNet B
└─ Peering ─ Spoke VNet C
공통 네트워크 서비스를 Hub VNet에 배치하고 여러 업무 VNet이 이를 공유하는 구조에 활용할 수 있다.
(5) VPN Gateway와 ExpressRoute(온프레미스 네트워크 - Vnet 연결)
온프레미스 네트워크와 Azure VNet을 연결하는 대표적인 방식은 인터넷 위의 암호화 터널과 전용 연결이다.
1) VPN Gateway
VPN Gateway는 공용 인터넷 위에 암호화된 터널을 구성하여 VNet과 외부 네트워크를 연결한다.
- 공용 인터넷을 전송 경로로 사용한다.
- IPsec 등의 암호화된 VPN 터널을 사용한다.
- 비교적 낮은 비용으로 하이브리드 연결을 구성할 수 있다.
- 인터넷 상태에 따라 지연 시간과 품질이 달라질 수 있다.
- VNet 안의 전용
GatewaySubnet에 배치된다.
2) VPN 연결 유형
| 연결 유형 | 연결 대상 | 사용 상황 |
|---|---|---|
| Site-to-Site | 온프레미스 네트워크와 VNet | 회사 전체 네트워크를 Azure에 연결 |
| Point-to-Site | 개별 사용자 PC와 VNet | 개발자나 관리자의 원격 접속 |
| VNet-to-VNet | VNet과 VNet | VPN Gateway를 이용한 VNet 간 암호화 연결 |
3) ExpressRoute - OSI 7 Layer 중 layer3에서 동작

ExpressRoute는 통신 사업자 또는 연결 제공자를 통해 온프레미스 네트워크와 Microsoft 클라우드를 전용 연결로 연결하는 서비스이다.
- 일반적인 공용 인터넷 경로를 사용하지 않는다.
- VPN보다 일정한 대역폭과 지연 시간을 구성하기에 유리하다.
- 대규모 데이터 전송과 안정적인 하이브리드 연결에 적합하다.
- VPN Gateway보다 비용과 구성 복잡도가 높다.
- 연결 제공자와 회선 구성이 필요하다.
4) VPN Gateway와 ExpressRoute 비교
| 구분 | VPN Gateway | ExpressRoute |
|---|---|---|
| 전송 경로 | 공용 인터넷 위 암호화 터널 | 전용 연결 |
| 품질 | 인터넷 상태의 영향을 받음 | 일정한 품질 구성에 유리 |
| 비용 | 상대적으로 낮음 | 상대적으로 높음 |
| 적합한 환경 | 소규모, 원격 접속, 비용 우선 | 대규모, 안정성, 일정한 성능 요구 |
(6) Service Endpoint와 Private Link
Azure Storage나 Azure SQL Database 같은 PaaS 서비스는 사용자가 직접 VNet 안에 배치하는 VM이 아니다. 이러한 서비스에 VNet에서 더 안전하게 접근하도록 구성하는 대표적인 방식이 Service Endpoint와 Private Link이다.
1) Service Endpoint
Service Endpoint는 특정 Subnet에서 Azure PaaS 서비스로 가는 트래픽을 Azure 백본 경로로 전환하는 기능이다.
- VNet의 특정 Subnet에서 활성화한다.
- 해당 Subnet의 리소스가 지원되는 PaaS 서비스에 접근할 수 있게 한다.
- 트래픽이 일반 공용 인터넷이 아니라 Azure 백본을 통해 전달된다.
- PaaS 서비스의 주소 자체는 여전히 공용 엔드포인트일 수 있다.
- 서비스 방화벽에서 허용할 VNet과 Subnet을 제한할 수 있다.
- Azure Storage, Azure SQL Database, Key Vault, Event Hubs, Service Bus 등에 사용할 수 있다.
VM in Subnet
↓
Service Endpoint 활성화
↓
Azure 백본 네트워크
↓
PaaS의 공용 엔드포인트
2) Private Link와 Private Endpoint
Private Endpoint는 PaaS 서비스에 접근하기 위한 Private IP를 사용자의 VNet Subnet 안에 생성하는 네트워크 인터페이스이다.
Private Link는 이러한 사설 연결을 제공하는 기술이며, 사용자는 Private Endpoint를 통해 PaaS 서비스를 VNet 내부 리소스처럼 접근한다.
- 선택한 Subnet에서 Private IP를 할당받는다.
- 애플리케이션은 PaaS 서비스의 Private IP로 통신한다.
- 공용 엔드포인트 접근을 차단할 수 있다.
- 트래픽은 Microsoft 네트워크 안에서 처리된다.
- DNS 이름이 Private IP로 해석되도록 DNS 구성이 필요하다.
VM 10.0.2.4
↓
Private Endpoint 10.0.3.5
↓
Private Link
↓
Azure PaaS Service
3) 두 방식 비교
| 구분 | Service Endpoint | Private Endpoint |
|---|---|---|
| 핵심 방식 | PaaS까지의 경로를 Azure 백본으로 전환 | PaaS 연결점에 VNet의 Private IP 부여 |
| 접근 주소 | PaaS의 공용 주소 사용 | VNet 내부 Private IP 사용 |
| 공용 접근 | 공용 엔드포인트가 유지될 수 있음 | 공용 접근을 차단하고 사설 접근만 구성 가능 |
| DNS 구성 | 기존 공용 DNS 사용 | Private DNS 연결이 중요 |
| 격리 수준 | Subnet 기반 접근 제한 | VNet 내부 Private IP 기반 접근 |
4) Private DNS와의 관계
Private Endpoint를 생성해도 애플리케이션이 서비스의 도메인 이름을 공용 IP로 해석하면 사설 연결을 사용하지 못할 수 있다.
- 애플리케이션이 PaaS 서비스의 기존 도메인 이름을 조회한다.
- Private DNS Zone이 해당 이름을 Private Endpoint의 IP로 해석한다.
- 애플리케이션이 VNet 내부 Private IP로 요청을 전송한다.
- Private Link를 통해 PaaS 서비스에 연결된다.
(7) Azure DNS와 Traffic Manager
1) Azure DNS

Azure DNS는 도메인의 DNS Zone과 DNS Record를 Azure에서 호스팅하고 관리하는 서비스이다.
- 도메인 이름과 IP 주소 또는 다른 서비스의 연결 정보를 관리한다.
- A, AAAA, CNAME, MX, TXT 등의 DNS Record를 구성할 수 있다.
- Azure의 글로벌 DNS 인프라를 이용해 이름 질의에 응답한다.
- Azure 리소스와 DNS 구성을 같은 관리 환경에서 운영할 수 있다.
2) Public·Private DNS Zone
| 구분 | 사용 범위 | 주요 용도 |
|---|---|---|
| Public DNS Zone | 인터넷 | 공개 웹사이트와 서비스의 도메인 관리 |
| Private DNS Zone | 연결된 VNet 내부 | 내부 서버 이름, Private Endpoint의 Private IP 해석 |
3) Traffic Manager

Traffic Manager는 DNS 응답을 이용하여 사용자를 여러 지역의 서비스 중 적절한 엔드포인트로 안내하는 글로벌 트래픽 분산 서비스이다.
- DNS 조회 단계에서 사용자에게 반환할 목적지를 선택한다.
- 가장 가까운 지역 또는 우선순위가 높은 지역으로 사용자를 보낼 수 있다.
- 엔드포인트 상태를 확인하고 장애가 있는 지역을 제외할 수 있다.
- 실제 애플리케이션 트래픽을 직접 중계하지 않는다.
- 여러 Azure Region에 배포한 서비스의 장애 조치에 사용할 수 있다.
4) Traffic Manager와 Load Balancer의 차이
| 구분 | Traffic Manager | Load Balancer |
|---|---|---|
| 동작 방식 | DNS 응답으로 목적지 선택 | 실제 네트워크 연결을 백엔드에 분산 |
| 주요 범위 | 여러 Region | 하나의 Region 또는 VNet 내부 |
| 트래픽 중계 | 직접 중계하지 않음 | 클라이언트 연결을 백엔드로 전달 |
(8) NSG, Azure Firewall, WAF
Azure 네트워크 보안 서비스는 적용 위치와 확인하는 트래픽 정보가 서로 다르다.
1) NSG

NSG(Network Security Group)는 Subnet 또는 NIC에 적용하여 트래픽을 허용하거나 차단하는 기본 네트워크 규칙 집합이다.
- Inbound와 Outbound 규칙을 구분한다.
- 출발지와 목적지 IP 또는 Service Tag를 기준으로 판단한다.
- TCP, UDP 등의 프로토콜과 포트 번호를 조건으로 사용한다.
- 규칙에는 우선순위가 있으며 낮은 숫자부터 평가한다.
- 조건과 처음 일치한 규칙의 Allow 또는 Deny 결과를 적용한다.
- Subnet 또는 개별 NIC에 연결할 수 있다.
| 예시 규칙 | 내용 |
|---|---|
| 웹 접근 허용 | 인터넷에서 web-subnet의 TCP 443 포트 허용 |
| App 접근 제한 | web-subnet에서 app-subnet의 애플리케이션 포트만 허용 |
| DB 접근 제한 | app-subnet에서 data-subnet의 DB 포트만 허용 |
2) Azure Firewall

Azure Firewall은 여러 Subnet과 VNet의 네트워크 트래픽을 중앙에서 통제하는 관리형 방화벽 서비스이다.
- Hub VNet에 배치하여 여러 Spoke VNet의 트래픽을 통제할 수 있다.
- 네트워크 규칙으로 IP, 포트, 프로토콜을 제어한다.
- 애플리케이션 규칙으로 도메인 기반 아웃바운드 접근을 제한할 수 있다.
- DNAT를 통해 외부 요청을 내부 리소스로 전달할 수 있다.
- 로그와 정책을 중앙에서 관리할 수 있다.
- 사용하려면 트래픽이 Azure Firewall을 지나도록 Route Table을 구성할 수 있다.
3) WAF

WAF(Web Application Firewall)는 HTTP와 HTTPS 요청 내용을 검사하여 웹 애플리케이션 공격을 차단하는 방화벽이다.
- 웹 요청의 URL, Header, Query String, Body 등을 검사한다.
- SQL Injection과 Cross-Site Scripting 같은 웹 공격 패턴을 차단한다.
- Application Gateway 또는 글로벌 웹 진입 서비스와 결합할 수 있다.
- IP와 포트만 확인하는 일반 네트워크 방화벽보다 애플리케이션 계층을 자세히 검사한다.
4) 세 서비스 비교
| 구분 | NSG | Azure Firewall | WAF |
|---|---|---|---|
| 목적 | 기본 접근 통제 | 네트워크 전체 트래픽 보호 | 웹 애플리케이션 HTTP/HTTPS트래픽 보호 |
| 적용 위치 | Subnet·NIC | 중앙 네트워크 경계 | 웹 애플리케이션 앞단 |
| 적용 계층 | L3~L7 | L7 | |
| 방어 대상 | IP포트, 프로토콜기반 필터링 | SQL 인젝션, XSS등 웹 취약점 공격 | |
| 통합 서비스 | Azure Virtual Network 전체 보호 | Azure Application Gateway, Front Door | |
| 판단 기준 | IP, Port, Protocol, Direction | IP, Port, Protocol, Domain 등 | HTTP 요청 내용과 공격 패턴 |
| 관계 | 서로 대체하는 서비스가 아니라 네트워크 계층별로 함께 사용하는 보안 수단이다. | ||
(9) Azure Bastion과 트래픽 분산
1) Azure Bastion
Azure Bastion은 VM에 Public IP를 직접 연결하지 않고 Azure Portal을 통해 RDP 또는 SSH로 접속하게 하는 관리형 서비스이다.
- 관리 대상 VM을 인터넷에 직접 노출하지 않는다.
- 브라우저와 Azure Portal을 통해 관리 연결을 제공한다.
- VM의 RDP 3389 또는 SSH 22 포트를 인터넷 전체에 열 필요를 줄인다.
- VNet의 전용 Subnet에 배치한다.
- 내부 VM은 Private IP로 유지할 수 있다.
관리자
↓ HTTPS
Azure Portal
↓
Azure Bastion
↓ Private IP
내부 VM
2) Azure Load Balancer
Azure Load Balancer는 전송 계층에서 TCP 또는 UDP 트래픽을 여러 백엔드 VM이나 인스턴스로 분산하는 서비스이다.
- IP 주소와 포트 정보를 기준으로 트래픽을 전달한다.
- Health Probe로 백엔드 상태를 확인한다.
- 비정상 인스턴스에는 새로운 연결을 전달하지 않는다.
- Public Load Balancer와 Internal Load Balancer로 구성할 수 있다.
| 구분 | 용도 |
|---|---|
| Public Load Balancer | 인터넷에서 들어오는 트래픽을 여러 백엔드에 분산 |
| Internal Load Balancer | VNet 내부 서비스 간 트래픽을 여러 백엔드에 분산 |
3) Application Gateway
Application Gateway는 HTTP와 HTTPS 요청을 애플리케이션 계층에서 분석하고 웹 서버로 분산하는 서비스이다.
- URL 경로에 따라 다른 백엔드 풀로 요청을 전달할 수 있다.
- Host Name을 기준으로 여러 웹사이트를 분리할 수 있다.
- TLS 종료를 수행할 수 있다.
- WAF 기능을 결합하여 웹 공격을 차단할 수 있다.
- HTTP 기반 웹 애플리케이션에 적합하다.
https://service.example.com/images/*
→ Image Server Pool
https://service.example.com/api/*
→ API Server Pool
4) Load Balancer와 Application Gateway 비교
| 구분 | Azure Load Balancer | Application Gateway |
|---|---|---|
| 동작 계층 | L4 | L7 |
| 판단 기준 | IP, Port, TCP·UDP | URL, Host, HTTP Header |
| 지원 트래픽 | 다양한 TCP·UDP 서비스 | HTTP·HTTPS 웹 서비스 |
| WAF 결합 | 지원하지 않음 | 지원 가능 |
(10) 온라인 주문 서비스의 3-Tier 네트워크 구성
3-Tier 구조는 웹, 애플리케이션, 데이터 계층을 서로 다른 Subnet으로 분리하고 필요한 인접 계층 간 통신만 허용하는 구성이다.
1) 계층별 Subnet 구성
VNet 10.0.0.0/16
├─ ApplicationGatewaySubnet 10.0.0.0/24
├─ web-subnet 10.0.1.0/24
├─ app-subnet 10.0.2.0/24
├─ data-subnet 10.0.3.0/24
├─ AzureBastionSubnet 10.0.4.0/24
└─ GatewaySubnet 10.0.5.0/24
| 계층 | 역할 | 주요 네트워크 구성 |
|---|---|---|
| Web | 사용자의 웹 요청 처리 | Application Gateway, WAF, NSG |
| App | 비즈니스 로직과 API 처리 | Internal Load Balancer, NSG |
| Data | 데이터 저장과 조회 | NSG, Private Endpoint |
2) 계층별 접근 통제
| 통신 | 정책 |
|---|---|
| Internet → Web | Application Gateway와 WAF를 통해 HTTPS 요청만 허용 |
| Web → App | web-subnet에서 필요한 API 포트만 허용 |
| App → Data | app-subnet에서 데이터베이스 연결만 허용 |
| Internet → App·Data | 직접 접근 차단 |
| 관리자 → VM | Azure Bastion을 통한 관리 접속만 허용 |
3) 요청 흐름
사용자
↓ DNS
공개 도메인과 Public IP 확인
↓ HTTPS
Application Gateway + WAF
↓
web-subnet의 웹 서버
↓ NSG에서 허용된 API 포트
app-subnet의 애플리케이션 서버
↓ NSG에서 허용된 DB 연결
data-subnet 또는 Private Endpoint
↓
데이터베이스
외부 사용자는 웹 계층까지만 접근하고, 웹 계층은 애플리케이션 계층에만, 애플리케이션 계층은 데이터 계층에만 접근하도록 경로를 제한한다.
(11) 목적별 Azure 네트워크 서비스 선택
| 목적 | 사용 서비스 |
|---|---|
| Azure 안에 사설 네트워크 생성 | VNet |
| 네트워크를 역할별 영역으로 분리 | Subnet |
| VM을 Subnet과 IP에 연결 | NIC |
| 두 VNet을 사설로 연결 | VNet Peering |
| 온프레미스와 저비용 암호화 연결 | VPN Gateway |
| 온프레미스와 전용 연결 | ExpressRoute |
| Subnet에서 PaaS까지 Azure 백본 경로 사용 | Service Endpoint |
| PaaS를 VNet의 Private IP로 접근 | Private Endpoint |
| Subnet·NIC 단위의 기본 트래픽 통제 | NSG |
| 네트워크 트래픽의 중앙 통제 | Azure Firewall |
| 웹 공격 차단 | WAF |
| VM을 Public IP 없이 원격 관리 | Azure Bastion |
| TCP·UDP 트래픽 분산 | Azure Load Balancer |
| HTTP·HTTPS 요청의 URL 기반 분산 | Application Gateway |
| 여러 Region 사이에서 사용자 분산 | Traffic Manager |
(12) 자료 외 보완
1) Route Table과 사용자 정의 경로
VNet 안의 트래픽에는 Azure가 제공하는 기본 시스템 경로가 적용된다. Route Table은 특정 Subnet의 트래픽 경로를 사용자가 직접 지정하기 위한 리소스이다.
- Subnet 간 통신, 인터넷 방향 등의 기본 경로가 자동 구성된다.
- 사용자 정의 경로(User Defined Route)를 추가할 수 있다.
- 특정 목적지 트래픽을 Azure Firewall이나 네트워크 가상 어플라이언스로 보낼 수 있다.
- Route Table은 Subnet에 연결한다.
app-subnet의 모든 외부 트래픽
↓ Route Table
Azure Firewall
↓ 검사 및 허용
Internet 또는 다른 VNet
2) VNet Peering의 비전이성
VNet Peering은 기본적으로 전이되지 않는다.
VNet A ↔ VNet B
VNet B ↔ VNet C
위 두 연결만으로
VNet A ↔ VNet C 통신이 자동 허용되지는 않음
A와 C를 직접 Peering하거나, B의 방화벽·라우터·게이트웨이를 경유하도록 별도 경로를 설계해야 한다.
3) 네트워크 계층 분리와 심층 방어
하나의 보안 서비스만으로 전체 네트워크를 보호하기보다 여러 통제 수단을 계층별로 중첩한다.
- VNet과 Subnet으로 네트워크 영역을 구분한다.
- NSG로 계층 사이에서 필요한 IP와 포트만 허용한다.
- Azure Firewall로 중앙 집중 트래픽 정책을 적용한다.
- WAF로 웹 요청 내용을 검사한다.
- Private Endpoint로 데이터 서비스의 공용 접근을 차단한다.
- Azure Bastion으로 관리 포트의 직접 인터넷 노출을 줄인다.
(13) 핵심 정리
- VNet은 Azure의 사설 네트워크 공간이며 주소 공간은 연결할 다른 네트워크와 겹치지 않게 설계해야 한다.
- Subnet은 VNet을 역할별 주소 범위로 나누고, VM은 NIC를 통해 Subnet과 Private IP에 연결된다.
- VNet Peering은 VNet 간 사설 통신을 제공하고, 온프레미스 연결은 VPN Gateway 또는 ExpressRoute로 구성한다.
- Service Endpoint는 PaaS까지의 경로를 Azure 백본으로 전환하고, Private Endpoint는 PaaS 접근점에 VNet의 Private IP를 부여한다.
- NSG는 Subnet·NIC 단위의 접근 통제, Azure Firewall은 중앙 네트워크 통제, WAF는 웹 요청 공격 차단을 담당한다.
- Azure Load Balancer는 L4 트래픽을 분산하고, Application Gateway는 L7 웹 요청을 분산하며 WAF와 결합할 수 있다.
- 3-Tier 구조에서는 Web·App·Data 계층을 분리하고 인접 계층 사이의 필요한 통신만 허용한다.
(14) 핵심 키워드
| 키워드 | 의미 |
|---|---|
| VNet | Azure 안에서 리소스의 사설 통신을 구성하는 논리적 네트워크 |
| Address Space | VNet에서 사용할 수 있는 전체 사설 IP 주소 범위 |
| Subnet | VNet 주소 공간을 역할별로 나눈 작은 네트워크 구획 |
| NIC | VM을 Subnet과 IP 주소에 연결하는 가상 네트워크 장치 |
| VNet Peering | 서로 다른 VNet을 Microsoft 백본으로 사설 연결하는 기능 |
| VPN Gateway | 공용 인터넷 위 암호화 터널로 외부 네트워크와 VNet을 연결하는 서비스 |
| ExpressRoute | 전용 연결을 통해 온프레미스와 Microsoft 클라우드를 연결하는 서비스 |
| Service Endpoint | Subnet에서 PaaS의 공용 엔드포인트까지 Azure 백본 경로를 제공하는 기능 |
| Private Endpoint | PaaS 연결점에 VNet 내부 Private IP를 부여하는 네트워크 인터페이스 |
| Azure DNS | Public·Private DNS Zone과 Record를 Azure에서 관리하는 서비스 |
| Traffic Manager | DNS 수준에서 여러 지역의 엔드포인트 중 목적지를 선택하는 서비스 |
| NSG | Subnet·NIC 단위로 IP, Port, Protocol 기반 트래픽을 허용·차단하는 규칙 집합 |
| Azure Firewall | 여러 네트워크의 트래픽을 중앙에서 통제하는 관리형 방화벽 |
| WAF | HTTP 요청을 검사하여 웹 애플리케이션 공격을 차단하는 방화벽 |
| Azure Bastion | VM의 Public IP 없이 RDP·SSH 관리 접속을 제공하는 서비스 |
| Azure Load Balancer | L4에서 TCP·UDP 연결을 여러 백엔드에 분산하는 서비스 |
| Application Gateway | L7에서 HTTP·HTTPS 요청을 분석하고 웹 백엔드로 분산하는 서비스 |
| Route Table | Subnet 트래픽의 다음 이동 경로를 지정하는 리소스 |
(15) 연결되는 개념
- 상위 개념: Azure 네트워크, 클라우드 인프라
- 선행 개념: 컴퓨터 네트워크의 데이터 전달 원리(개념 09)
- 관련 개념: CIDR, DNS, Routing, Firewall, Load Balancing, Private IP
- 다음 학습: 파일·블록·오브젝트 스토리지와 Azure Storage 서비스
- 대응 실습: VNet 생성, Subnet 분리, NSG 적용, VM 간 사설 통신 확인
(16) 다음 학습
- VNet과 Subnet 구성 실습: 주소 공간을 나누고 VM의 NIC에 Private IP가 할당되는 구조를 확인하기 위해 진행한다.
- NSG와 Private Endpoint 실습: 네트워크 계층별 접근 통제와 PaaS 사설 접근을 실제로 확인하기 위해 학습한다.
- 스토리지 서비스: Azure Blob, Files, Managed Disks가 어떤 네트워크 접근 방식과 결합되는지 이해하기 위해 이어서 학습한다.
'Cloud > Part 3. 핵심 인프라' 카테고리의 다른 글
| 14. Azure Storage 서비스 선택 (0) | 2026.07.28 |
|---|---|
| 11. 컴퓨터 네트워크는 데이터를 어떻게 목적지까지 전달하는가? (0) | 2026.07.27 |
| 10. 클라우드 서버를 위한 Linux 기초 (0) | 2026.07.27 |
| 9. Azure Compute 서비스 선택 (0) | 2026.07.27 |