AZ-104 네트워킹 도메인은 전체 시험의 15~20%를 차지합니다. VNet 구성, 보안, DNS, 부하 분산이 핵심 주제입니다. 처음에는 용어가 낯설게 느껴질 수 있지만, 현실 세계의 비유를 통해 하나씩 이해하면 생각보다 훨씬 쉽습니다.
VNet과 서브넷
VNet이란 무엇인가요?
VNet(Virtual Network)은 Azure 안에서 여러분만의 프라이빗 네트워크를 만드는 것입니다. 쉽게 말해, 거대한 Azure 클라우드 안에 여러분 회사만을 위한 전용 사무실 건물을 짓는 것과 같습니다. 이 건물 안에서는 내부 직원들끼리 자유롭게 통신할 수 있지만, 외부에서는 마음대로 들어올 수 없습니다.
VNet을 만들 때는 주소 공간(CIDR)을 정의합니다. 예를 들어 이라고 하면, 이 건물이 사용할 수 있는 내부 주소 범위를 지정하는 것입니다. 마치 건물의 호실 번호 체계를 정하는 것과 같습니다.
서브넷은 이 건물을 층별로 나누는 개념입니다. 1층은 웹 서버, 2층은 데이터베이스, 3층은 관리 시스템처럼 용도별로 구역을 나눌 수 있습니다. 이렇게 나누면 보안 규칙을 층별로 다르게 적용하고, 문제가 생겼을 때 특정 구역만 격리할 수 있어 훨씬 관리하기 편리합니다.
VNet Peering: 두 건물을 연결하는 전용 통로
사업이 성장하면 서울에도 건물이 있고 부산에도 건물이 생길 수 있습니다. 이 두 건물이 서로 통신해야 할 때 어떻게 할까요? 일반 인터넷을 통하면 속도도 느리고 보안에도 취약합니다. VNet Peering은 두 VNet 사이에 Azure 내부 백본 네트워크를 통한 전용 통로를 만들어 주는 것입니다. 인터넷을 거치지 않으니 빠르고 안전합니다.
VNet Peering에는 두 가지 종류가 있습니다:
로컬 Peering: 같은 Azure 리전(예: 한국 중부) 안에 있는 두 VNet을 연결합니다. 같은 도시 안의 두 사무실을 전용 회선으로 연결하는 것과 같습니다. 글로벌 Peering: 서로 다른 리전(예: 한국 중부와 미국 동부)에 있는 VNet을 연결합니다. 서울 본사와 뉴욕 지사를 국제 전용 회선으로 연결하는 것입니다.
중요한 특성: 비전이성(Non-transitivity)
VNet Peering에서 반드시 기억해야 할 규칙이 있습니다. 바로 '비전이적'이라는 특성입니다. 이게 무슨 뜻인지 예를 들어 설명해 드리겠습니다.
A 건물과 B 건물이 전용 통로로 연결되어 있고, B 건물과 C 건물도 전용 통로로 연결되어 있다고 해봅시다. 그렇다면 A 건물에서 B 건물을 통해 C 건물로 갈 수 있을까요? 안 됩니다. VNet Peering은 두 VNet 사이의 직접 연결만을 의미하기 때문입니다. A와 C가 통신하려면 A↔C 사이의 Peering을 별도로 설정해야 합니다. 이 규칙을 시험에서 자주 물어봅니다.
UDR (사용자 정의 경로): 트래픽의 길을 내가 결정한다
일반적으로 Azure는 트래픽이 목적지까지 가는 최적의 경로를 자동으로 결정합니다. 그런데 때로는 보안상의 이유로 모든 트래픽이 반드시 특정 검문소를 거치도록 강제해야 할 수 있습니다. 예를 들어, 모든 외부 트래픽이 방화벽 역할을 하는 NVA(네트워크 가상 어플라이언스)를 반드시 통과하도록 하고 싶을 때 UDR을 사용합니다.
UDR(User Defined Route)은 Azure의 기본 라우팅 규칙을 덮어쓰고, 트래픽이 지나가야 할 경로를 직접 지정하는 것입니다. 고속도로에서 특정 구간을 통과할 때 반드시 톨게이트(NVA)를 거치도록 강제하는 것과 같습니다. 이를 통해 모든 트래픽을 검사하고, 의심스러운 패킷은 차단할 수 있습니다.
네트워크 보안
NSG (Network Security Group): 건물의 경비원
NSG는 네트워크의 경비원과 같습니다. 누가 들어오고(인바운드) 누가 나갈 수(아웃바운드) 있는지를 규칙으로 정의합니다. 이 규칙들은 서브넷 전체 또는 개별 VM의 네트워크 인터페이스(NIC)에 적용할 수 있습니다.
예를 들어, 웹 서버가 있는 서브넷에 "80번 포트(HTTP)와 443번 포트(HTTPS) 트래픽만 외부에서 허용하고, 나머지는 모두 차단"하는 규칙을 만들 수 있습니다.
우선순위 규칙 이해하기
NSG 규칙에는 우선순위 번호가 있습니다. 번호가 낮을수록 먼저 평가됩니다. 예를 들어 우선순위 100번 규칙과 1000번 규칙이 충돌한다면, 100번 규칙이 먼저 적용됩니다.
경비원이 근무 지침서를 보는데, 지침서 1번 항목이 10번 항목보다 먼저 확인되는 것과 같습니다. 그래서 허용 규칙을 높은 우선순위(낮은 번호)에, 차단 규칙을 낮은 우선순위(높은 번호)에 두거나, 그 반대로 설정하여 정교하게 트래픽을 제어할 수 있습니다.
기본 규칙 (변경 불가)
Azure는 모든 NSG에 기본 규칙을 자동으로 포함시킵니다: VNet 내부 통신은 허용 인터넷으로 나가는 트래픽(아웃바운드)은 허용 그 외 모든 인바운드 트래픽은 차단
이 기본 규칙은 삭제할 수 없지만, 더 낮은 번호(높은 우선순위)의 규칙을 추가하여 덮어쓸 수 있습니다.
ASG (Application Security Group): IP가 아닌 역할로 관리하기
서버가 10대, 20대로 늘어나면 어떻게 될까요? NSG 규칙에서 각 서버의 IP를 일일이 지정하다 보면 관리가 매우 복잡해집니다. 서버 IP가 바뀌면 규칙도 모두 수정해야 하죠.
ASG(Application Security Group)는 이 문제를 해결합니다. VM들을 역할별로 논리적인 그룹으로 묶어서, NSG 규칙에서 IP 주소 대신 그룹 이름을 참조하는 것입니다.
예를 들어, 웹 서버 10대를 'WebServers'라는 ASG로, 데이터베이스 서버 5대를 'DatabaseServers'라는 ASG로 묶습니다. 그리고 NSG 규칙에서 "WebServers에서 DatabaseServers로 1433 포트 허용"이라고 정의합니다. 이렇게 하면 서버가 추가되거나 IP가 바뀌어도 해당 서버를 ASG에 추가하기만 하면 되고, NSG 규칙 자체는 수정할 필요가 없습니다. 마치 직원 명단 대신 '영업팀', '개발팀' 같은 부서명으로 출입 권한을 관리하는 것과 같습니다.
!NSG vs ASG
Azure Bastion: 공용 IP 없이 안전하게 VM 접속하기
일반적으로 원격으로 서버에 접속하려면 해당 서버에 공용 IP가 필요하고, RDP(3389 포트) 또는 SSH(22 포트)를 인터넷에 개방해야 합니다. 그런데 이렇게 하면 해커들이 이 포트를 노리고 지속적으로 공격을 시도합니다.
Azure Bastion은 이 문제를 완전히 해결하는 서비스입니다. VM에 공용 IP를 부여하지 않아도, Azure 포털의 웹 브라우저를 통해 안전하게 VM에 접속할 수 있습니다. RDP나 SSH 포트를 인터넷에 노출할 필요가 없습니다.
비유하자면, 건물 정문에 공개적으로 여러분의 사무실 번호를 알려주는 대신, 보안이 철저한 리셉션 데스크(Bastion)를 통해서만 방문객이 내부로 안내되는 것과 같습니다. 외부에서는 특정 방 번호를 알 수 없고, 무조건 리셉션을 거쳐야만 합니다.
서비스 엔드포인트 vs 프라이빗 엔드포인트: 두 가지 프라이빗 연결 방식
Azure Storage나 SQL Database 같은 Azure 서비스에 접근할 때, VNet 안의 리소스가 더 안전하고 효율적으로 연결하는 두 가지 방법이 있습니다.
서비스 엔드포인트는 VNet에서 Azure 서비스로 가는 경로를 최적화해 주는 것입니다. 트래픽이 인터넷을 거치지 않고 Azure 내부 네트워크를 통해 이동합니다. 단, Azure 서비스는 여전히 공용 IP 주소를 가지고 있습니다. 비유하자면, 공항 가는 길에 일반 도로 대신 전용 고속도로를 이용하는 것과 같습니다. 더 빠르고 덜 복잡하지만, 공항 자체는 여전히 공개된 장소입니다.
프라이빗 엔드포인트는 한 단계 더 나아갑니다. Azure 서비스에 VNet 안의 프라이빗 IP 주소를 직접 할당하는 것입니다. 이제 그 서비스는 마치 VNet 안에 존재하는 리소스처럼 작동합니다. 인터넷에서는 이 서비스에 접근할 수 없고, VNet 안에서만 접근 가능합니다. 비유하자면, 공항의 특정 VIP 라운지가 아예 여러분 회사 건물 안으로 이사 온 것과 같습니다. 완전히 내부에서만 접근 가능합니다.
정리하면: 서비스 엔드포인트: 공용 IP 주소를 사용하지만 경로가 최적화됨 (빠르고 간단) 프라이빗 엔드포인트: 프라이빗 IP를 할당, 완전한 격리 (더 안전, 더 복잡)
!Service Endpoint vs Private Endpoint
DNS
DNS가 왜 필요한가요?
DNS(Domain Name System)는 인터넷의 전화번호부와 같습니다. 우리가 이라는 주소를 입력하면, 실제로는 같은 숫자 IP 주소로 변환되어 통신합니다. DNS가 이 변환 작업을 담당합니다.
Azure Public DNS: 내 도메인을 Azure에서 관리하기
Azure Public DNS를 사용하면 회사가 보유한 도메인(예: )의 DNS 레코드를 Azure에서 관리할 수 있습니다. A 레코드(도메인 → IP 주소), CNAME 레코드(도메인 별칭), MX 레코드(이메일 서버), TXT 레코드(도메인 소유 인증) 등 다양한 DNS 레코드 유형을 지원합니다.
예를 들어, 을 특정 Azure VM의 공용 IP로 연결하고 싶다면 A 레코드를 만들고, 을 으로 연결하고 싶다면 CNAME 레코드를 만들면 됩니다.
Azure Private DNS: VNet 안에서만 쓰는 내부 전화번호부
VNet 안의 VM들은 내부 IP로 통신합니다. 그런데 IP 주소를 외우는 것은 불편하고, VM이 추가되거나 IP가 바뀌면 관리도 어렵습니다. Azure Private DNS Zone은 VNet 안에서만 사용하는 내부 DNS 시스템입니다.
예를 들어, Private DNS Zone 을 만들고 VNet에 연결하면, 이 VNet 안의 VM들은 같은 이름으로 서로를 찾을 수 있습니다. 외부 인터넷에서는 이 DNS 이름으로 아무것도 찾을 수 없고, VNet 안에서만 작동합니다.
자동 등록 기능이 특히 편리합니다. VNet에 VM이 생성되면 자동으로 해당 VM의 이름과 IP가 Private DNS에 등록됩니다. 수동으로 DNS 레코드를 만들 필요가 없습니다. 마치 회사에 새 직원이 입사하면 자동으로 사내 전화번호부에 등록되는 것과 같습니다.
여러 VNet을 하나의 Private DNS Zone에 연결할 수도 있어, 여러 VNet에 걸쳐 일관된 내부 DNS 이름 체계를 유지할 수 있습니다.
Azure Load Balancer: 일을 골고루 나눠주는 교통 정리원
서비스가 성장하면 VM 한 대로는 모든 요청을 처리할 수 없습니다. 여러 대의 VM을 준비해두고 요청을 골고루 분산시켜야 합니다. 이게 바로 Load Balancer의 역할입니다. 바쁜 교차로에서 교통 경찰관이 차량을 여러 차선으로 안내하는 것과 같습니다.
Load Balancer의 두 가지 유형
| 유형 | 설명 | 사용 예시 | |------|------|----------| | 공용 Load Balancer | 인터넷에서 들어오는 트래픽을 여러 VM에 분산 | 웹사이트 방문자 트래픽 분산 | | 내부 Load Balancer | VNet 내부 트래픽을 여러 VM에 분산 | 내부 API 서버나 데이터베이스 앞단에 배치 |
공용 Load Balancer는 외부 사용자들의 요청을 받아 여러 웹 서버로 나눠줍니다. 내부 Load Balancer는 VNet 안에서만 사용하며, 예를 들어 웹 서버에서 내부 API 서버로 요청할 때 여러 API 서버로 분산시켜 줍니다.