Azure NSG와 ASG 차이: 네트워크 트래픽 제어와 그룹 기반 보안 설계

NSG와 ASG는 "둘 중 하나를 고르는" 관계가 아닙니다. NSG는 트래픽을 허용/차단하는 규칙이고, ASG는 그 규칙의 출발지·목적지를 IP 대신 역할 그룹으로 표현하는 도구입니다. ASG는 NSG 규칙 안에서만 동작합니다.

핵심 요약

• NSG(Network Security Group): 인바운드/아웃바운드 트래픽을 5-튜플(출발지, 출발지 포트, 목적지, 목적지 포트, 프로토콜)로 필터링하는 방화벽 규칙 집합입니다.
• ASG(Application Security Group): VM의 NIC를 역할별로 묶는 논리적 그룹입니다. NSG 규칙에서 IP/CIDR 대신 그룹 이름을 출발지·목적지로 지정할 수 있게 해줍니다.
• 둘은 대체재가 아닙니다. ASG는 단독으로 트래픽을 막지 못하며, 반드시 NSG 규칙 안에서 참조되어야 동작합니다.
• VM이 자주 늘고 줄거나 역할 기반으로 트래픽을 제어해야 한다면 ASG가 규칙 유지보수를 크게 줄여줍니다.
• 고정 IP, 외부 대역, Azure 서비스 IP 범위를 다룰 때는 IP/CIDR이나 Service Tag를 그대로 쓰는 편이 낫습니다.

1. 왜 이 비교가 필요한가

Azure에서 3-Tier 웹 서비스를 NSG로 보호한다고 가정해 봅니다. 웹 서버 3대가 앱 서버로만 8080 포트를 열어야 한다면, NSG 규칙에 웹 서버 IP 3개를 출발지로 적어야 합니다.

여기서 오토스케일로 웹 서버가 5대로 늘어나면 어떻게 될까요. 새 VM의 IP를 NSG 규칙에 다시 추가해야 합니다. VM이 줄면 또 삭제해야 합니다. 규모가 커질수록 IP를 손으로 관리하는 일은 실수와 누락의 원인이 됩니다.

ASG는 이 문제를 푸는 도구입니다. "AsgWeb"이라는 그룹을 만들어 두고 NSG 규칙에 AsgWeb → AsgApp : 8080 Allow라고 적으면, 웹 서버가 몇 대로 늘든 NIC를 AsgWeb 그룹에 넣기만 하면 됩니다. 규칙은 건드리지 않습니다.

그래서 "NSG와 ASG 중 뭘 써야 하나요"라는 질문은 출발부터 어긋나 있습니다. 정확한 질문은 "NSG 규칙의 출발지/목적지를 IP로 적을까, ASG로 적을까"입니다.

2. 비교 대상 개요

2.1 NSG란

NSG(Network Security Group)는 Azure 리소스로 들어오고 나가는 트래픽을 필터링하는 규칙의 모음입니다. Subnet 또는 NIC(네트워크 인터페이스) 단위로 연결합니다.

각 규칙은 다음 요소로 구성됩니다.

요소	설명
Priority	100~4096. 낮을수록 먼저 평가
Direction	Inbound 또는 Outbound
Source / Destination	IP, CIDR, Service Tag, ASG, Any
Protocol	TCP, UDP, ICMP, Any
Port Range	단일 포트 또는 범위
Action	Allow 또는 Deny

NSG는 상태 추적(Stateful) 방화벽입니다. 인바운드를 허용하면 그에 대한 응답 아웃바운드는 규칙 없이 자동 허용됩니다.

2.2 ASG란

ASG(Application Security Group)는 VM의 NIC를 애플리케이션 역할별로 묶는 논리적 그룹입니다. 예를 들어 웹 서버들의 NIC를 AsgWeb, 앱 서버들의 NIC를 AsgApp으로 묶습니다.

ASG 자체에는 허용/차단 규칙이 없습니다. ASG는 NSG 규칙에서 출발지나 목적지를 가리키는 "이름표" 역할만 합니다. 즉 ASG는 NSG와 짝을 이뤄야 의미가 있습니다.

Tip
ASG를 "트래픽을 막는 그룹"으로 오해하기 쉽습니다. ASG는 트래픽을 막지 않습니다. 막는 주체는 언제나 NSG 규칙이고, ASG는 그 규칙이 적용될 대상을 묶어주는 라벨입니다.

3. 핵심 차이 표

기준	NSG	ASG
역할	트래픽 허용/차단 규칙 정의	NIC를 역할별로 묶는 논리 그룹
규칙 보유 여부	규칙을 가짐	규칙 없음 (NSG 규칙에서 참조됨)
적용 대상	Subnet 또는 NIC	NIC (VM 단위)
단독 동작	가능 (IP/CIDR로 규칙 작성)	불가능 (NSG 규칙 안에서만 동작)
출발지/목적지 표현	IP, CIDR, Service Tag, ASG	해당 없음 (자신이 출발지/목적지가 됨)
주 사용 목적	트래픽 필터링	규칙의 IP 관리 부담 제거
비용	무료	무료

핵심은 마지막에서 두 번째 행입니다. NSG는 ASG 없이도 동작하지만, ASG는 NSG 없이는 아무 일도 하지 않습니다. 둘은 상하 관계나 대체 관계가 아니라, 규칙(NSG)과 규칙이 가리키는 그룹(ASG)의 관계입니다.

4. 구조 차이

azure-nsg-asg-structure

위 구조에서 NSG는 Subnet에 한 번 연결되어 있고, 규칙은 IP가 아니라 ASG 이름으로 작성되어 있습니다.

• Internet → AsgWeb : 443 Allow — 외부에서 웹 계층으로만 HTTPS 허용
• AsgWeb → AsgApp : 8080 Allow — 웹 계층에서 앱 계층으로만 통신
• AsgApp → AsgDb : 1433 Allow — 앱 계층에서 DB 계층으로만 통신
• 그 외는 기본 규칙(DenyAll)으로 차단

여기서 웹 VM을 한 대 추가하면, 그 VM의 NIC를 AsgWeb에 넣기만 하면 위 규칙이 그대로 적용됩니다. NSG 규칙은 손대지 않습니다.

IP 기반 규칙과 ASG 기반 규칙의 차이

azure-nsg-asg-ip-vs-asg

같은 보안 의도를 두 방식으로 표현해 비교하면 차이가 분명합니다.

IP/CIDR 기반:

Priority 100 | Inbound | Source: 10.0.2.10, 10.0.2.11, 10.0.2.12
             | Destination: 10.0.3.0/24 | Port: 1433 | Allow

VM이 추가되면 Source 목록에 IP를 더해야 합니다.

ASG 기반:

Priority 100 | Inbound | Source: AsgApp
             | Destination: AsgDb | Port: 1433 | Allow

VM이 추가되면 NIC를 AsgApp에 넣기만 합니다. 규칙 텍스트는 그대로입니다.

5. 동작 방식 차이

5.1 NSG 규칙 평가 순서

Azure는 트래픽 방향에 따라 NSG를 평가하는 순서가 다릅니다. 공식 문서 기준으로 정리하면 다음과 같습니다.

• 인바운드: Subnet NSG → NIC NSG 순서로 평가
• 아웃바운드: NIC NSG → Subnet NSG 순서로 평가

각 NSG 안에서는 Priority 숫자가 낮은 규칙부터 평가하고, 일치하는 규칙을 만나면 즉시 적용하고 평가를 멈춥니다. 어느 단계에서든 Deny를 만나면 트래픽은 차단됩니다.

5.2 ASG 멤버십 동작

ASG는 NIC를 멤버로 가집니다. NIC를 ASG에 추가하면, 그 NIC를 가진 VM이 ASG 기반 규칙의 적용 대상이 됩니다.

# ASG 생성
az network asg create \
  --resource-group myResourceGroup \
  --name AsgWeb \
  --location koreacentral

# NIC를 ASG에 연결
az network nic ip-config update \
  --resource-group myResourceGroup \
  --nic-name web-vm1-nic \
  --name ipconfig1 \
  --application-security-groups AsgWeb

ASG를 출발지/목적지로 쓰는 NSG 규칙은 다음과 같이 작성합니다.

az network nsg rule create \
  --resource-group myResourceGroup \
  --nsg-name myNSG \
  --name Allow-App-To-Db \
  --priority 100 \
  --direction Inbound \
  --access Allow \
  --protocol Tcp \
  --destination-port-ranges 1433 \
  --source-asgs AsgApp \
  --destination-asgs AsgDb

6. 제약 조건 차이

ASG는 편리하지만 제약이 있습니다. 설계 전에 알아둬야 합니다.

제약	내용
같은 VNet 제한	하나의 ASG에 속한 모든 NIC는 동일한 VNet 안에 있어야 합니다. 첫 NIC가 속한 VNet이 기준이 됩니다.
NIC 다중 소속	하나의 NIC는 여러 ASG에 동시에 속할 수 있습니다(Azure 한도 내).
규칙 내 ASG 지정	출발지와 목적지에 ASG를 쓸 때, 두 ASG가 같은 VNet에 있어야 합니다.
구독 한도	ASG 수, NSG 규칙에서 참조 가능한 ASG 수 등에는 구독/리전 단위 한도가 있습니다.

검증 필요
구독별 한도(예: 리전당 ASG 개수, 단일 NSG의 모든 규칙에서 참조 가능한 ASG 수, NSG 개수, NSG당 규칙 수)는 변경될 수 있습니다. 설계 단계에서 Azure 공식 "subscription and service limits" 문서로 최신 값을 확인하는 것이 좋습니다.

특히 같은 VNet 제한은 Hub-Spoke 구조에서 주의해야 합니다. 서로 다른 Spoke VNet에 걸친 VM들을 하나의 ASG로 묶을 수 없습니다. VNet을 넘나드는 트래픽 제어는 Subnet/IP 기반 NSG 규칙이나 Azure Firewall로 설계해야 합니다.

7. 보안 차이

NSG와 ASG는 보안 "강도"가 다른 게 아니라, 보안 규칙을 표현하는 "방식"이 다릅니다. 다만 ASG를 쓰면 보안 설계 측면에서 얻는 이점이 있습니다.

• 마이크로 세그멘테이션 표현이 쉬움: 같은 Subnet 안에 여러 역할의 VM이 섞여 있어도, ASG로 역할을 구분해 역할 간 트래픽만 허용할 수 있습니다. Subnet을 역할 수만큼 나누지 않아도 됩니다.
• 규칙 의도가 드러남: AsgWeb → AsgApp은 IP 나열보다 의도가 명확합니다. 감사나 리뷰 시 규칙의 목적을 빠르게 파악할 수 있습니다.
• 휴먼 에러 감소: VM 증감 시 IP를 손으로 고치지 않으므로, "규칙에 IP를 빠뜨려 통신이 끊기거나, 삭제된 VM의 IP가 규칙에 남아 과도하게 열려 있는" 실수를 줄입니다.

Security Note
ASG는 Zero Trust의 마이크로 세그멘테이션을 NIC 단위로 구현하는 데 유용합니다. 다만 ASG를 쓴다고 자동으로 안전해지지는 않습니다. 보안을 결정하는 것은 여전히 NSG 규칙의 내용입니다. 기본 아웃바운드 허용 규칙을 좁히고, 필요한 통신만 명시적으로 Allow 하는 원칙은 IP 방식이든 ASG 방식이든 동일하게 적용해야 합니다.

8. 선택 기준

다시 강조하면, 이것은 "NSG vs ASG" 선택이 아니라 "NSG 규칙을 IP로 쓸까, ASG로 쓸까"의 선택입니다.

azure-nsg-asg-decision

상황	권장 방식
역할별 VM 그룹 간 통신 제어 (웹/앱/DB)	ASG 기반 규칙
오토스케일 등 VM이 자주 늘고 주는 환경	ASG 기반 규칙
같은 Subnet에 여러 역할이 섞인 구조	ASG 기반 규칙
고정된 온프레미스 대역, 파트너사 IP	IP/CIDR 직접 지정
Azure Storage, SQL 등 PaaS 서비스 대역	Service Tag
서로 다른 VNet에 걸친 트래픽	IP/CIDR 또는 Azure Firewall
외부 인터넷 전체	Service Tag(Internet)

ASG와 IP/Service Tag는 한 NSG 안에서 함께 쓸 수 있습니다. 예를 들어 "출발지는 Internet(Service Tag), 목적지는 AsgWeb"처럼 혼합 규칙을 작성하는 것이 일반적입니다.

9. 실무 예시

사례 1: 같은 Subnet 안의 3-Tier 분리

스타트업에서 비용을 아끼려고 웹·앱·DB VM을 하나의 Subnet에 함께 배치한 상황입니다. Subnet이 하나뿐이라 Subnet 단위 NSG만으로는 계층 간 트래픽을 구분하기 어렵습니다.

이때 ASG를 쓰면 Subnet을 쪼개지 않고도 계층을 분리할 수 있습니다.

• 웹 VM NIC → AsgWeb, 앱 VM NIC → AsgApp, DB VM NIC → AsgDb
• NSG 규칙: Internet → AsgWeb:443, AsgWeb → AsgApp:8080, AsgApp → AsgDb:1433, 그 외 계층 간 통신 Deny

이 구조를 선택한 이유는 명확합니다. Subnet을 3개로 나누면 주소 계획과 라우팅이 복잡해지지만, ASG는 NIC 라벨만으로 같은 효과를 냅니다. 다만 Subnet 분리는 NSG 외에 라우팅(UDR) 경계도 제공하므로, 규제가 엄격한 환경에서는 Subnet 분리와 ASG를 함께 쓰기도 합니다.

사례 2: 오토스케일 웹 계층

VM Scale Set으로 웹 서버가 트래픽에 따라 2~10대 사이에서 변하는 환경입니다.

IP 기반 규칙이라면 스케일 이벤트마다 NSG 규칙의 IP 목록이 바뀌어야 합니다. ASG를 쓰면 Scale Set 인스턴스의 NIC가 자동으로 AsgWeb에 들어가도록 구성하고, NSG 규칙은 AsgWeb만 참조하게 둡니다. 스케일 이벤트가 NSG 규칙을 건드리지 않으므로 변경 위험이 줄어듭니다.

10. 자주 하는 실수

1. ASG만 만들고 NSG 규칙을 안 만드는 것: ASG에 NIC를 넣어도 NSG 규칙에서 참조하지 않으면 아무 효과가 없습니다. ASG는 규칙이 아닙니다.
2. 서로 다른 VNet의 NIC를 한 ASG에 넣으려는 것: 하나의 ASG는 단일 VNet으로 제한됩니다. VNet을 넘는 제어는 IP/CIDR이나 Azure Firewall로 설계해야 합니다.
3. ASG가 IP 기반 규칙을 완전히 대체한다고 보는 것: 외부 대역, 온프레미스, PaaS 서비스는 ASG로 묶을 수 없습니다. 이 경우 IP/CIDR과 Service Tag를 그대로 써야 합니다.
4. NSG 평가 순서를 무시하는 것: Subnet NSG와 NIC NSG가 모두 있으면 양쪽을 모두 통과해야 통신이 됩니다. 한쪽에서 Deny면 다른 쪽에서 Allow여도 차단됩니다.
5. 기본 아웃바운드 규칙을 방치하는 것: NSG 기본 규칙은 아웃바운드 인터넷을 허용합니다. ASG로 계층을 잘 나눠도 아웃바운드를 좁히지 않으면 데이터 유출 경로가 열려 있을 수 있습니다.

11. 정리

• NSG는 트래픽을 허용/차단하는 규칙이고, ASG는 그 규칙의 출발지·목적지를 역할 그룹으로 표현하는 도구입니다.
• ASG는 NSG 없이 단독으로 동작하지 않습니다. 둘은 대체 관계가 아니라 협력 관계입니다.
• 역할 기반 제어, 오토스케일, 같은 Subnet 내 계층 분리에는 ASG 기반 규칙이 유지보수에 유리합니다.
• 고정 IP, 외부 대역, PaaS 서비스 대역, VNet을 넘는 트래픽에는 IP/CIDR이나 Service Tag, Azure Firewall이 적합합니다.
• ASG는 같은 VNet으로 제한되며, 구독별 한도가 있으므로 설계 전 공식 문서로 확인하는 것이 좋습니다.

관련 글

• Azure VNet이란 무엇인가: Subnet, NSG, Route Table 개념 정리

참고 문서

• Azure 공식 문서: Application Security Groups 개요
• Azure 공식 문서: Network Security Groups 개요
• Azure 공식 문서: NSG가 트래픽을 필터링하는 방식
• Azure 공식 문서: NSG 트래픽 차단 문제 해결
• Azure 공식 문서: 구독 및 서비스 제한, 할당량