Azure DDoS IP Protection과 Network Protection 비교: 범위·운영·비용으로 선택하기

DDoS IP Protection은 DDoS Network Protection의 단순한 “소형 버전”이 아니다. 반대로 Network Protection이라고 해서 모든 기업에 자동으로 정답이 되는 것도 아니다. 두 계층 모두 지원되는 Azure Public IP의 트래픽을 감시하고 Layer 3·Layer 4 공격을 완화하는 핵심 기능을 제공한다. 실제로 비교해야 할 차이는 보호를 어디에 연결하는지, 아키텍처를 얼마나 넓게 포괄하는지, 비용을 어떤 단위로 지불하는지, 어떤 사고 대응 및 비용 혜택이 필요한지다.

입문자에게는 건물 보험으로 비유하면 이해하기 쉽다. IP Protection은 이름을 지정한 상점 하나에 보험을 드는 방식과 비슷하다. Network Protection은 관리되는 단지 안의 지원 대상 상점들을 하나의 계획 아래 두는 방식과 비슷하다. 각 상점에서 작동하는 경보와 긴급 통제는 비슷할 수 있지만 계약 범위, 포함된 지원, 비용 구조가 다르다. 상점 수만 세어서는 부족하다. 어떤 상점이 중요한지, 단지가 얼마나 성장할지, 심각한 사고 때 누구의 지원이 필요한지도 함께 물어야 한다.

이 글은 Coursera Azure Cybersecurity Solutions and Microsoft Defender 강좌 Module 1을 12개 주제로 나눈 학습 계획의 세 번째 상세 노트다. Module 1 복습 글은 전체 보안 지도를 제공한다. 바로 앞의 DDoS 인프라 보호 범위 글은 Azure가 자동 제공하는 사업자 기준선과 고객별 DDoS 준비 상태가 왜 다른지 설명했다. 이번 글은 그 공백 평가가 끝난 시점에서 시작해 어떤 강화 보호 계층이 워크로드에 적합한지 판단한다.

이 글은 강의 녹취록, 평가 답안, 구매 권고, 실제 배포 기록 또는 공격 테스트 보고서가 아닌 독립 학습 노트다. 제품 기능, 제약 및 현재 가격 안내는 2026년 8월 11일 공식 Microsoft 자료를 기준으로 검토했다. 가격과 상업 조건은 바뀔 수 있으므로 실제 결정에서는 해당 지역, 통화, 계약 및 검토일을 기준으로 다시 계산해야 한다.

1. 이 글이 해결할 질문

워크로드에 강화된 Azure DDoS Protection이 필요하다고 판단했다면, 선택한 Public IP를 하나씩 보호해야 할까, 아니면 워크로드의 Virtual Network를 DDoS Protection Plan에 연결해야 할까?

이 글을 읽은 뒤에는 다음을 설명할 수 있어야 한다.

Public IP, Virtual Network, DDoS Protection Plan의 차이를 설명한다.
가격 비교 전에 엔드포인트가 지원 대상인지 확인한다.
두 계층이 공통 제공하는 핵심 보호 및 관측 데이터 기능을 설명한다.
IP Protection을 “약한 제품”이라고 부르지 않으면서 Network Protection 전용 혜택을 구분한다.
Virtual Machine 수가 아니라 실제 리소스 자산 목록으로 비용을 추정한다.
반복 가능한 의사결정 절차로 계층을 선택한다.
보호 공백 없이 계층을 전환하는 순서를 계획한다.
선택이 증명하는 것과 증명하지 못하는 것, 재검토 조건을 기록한다.

이 글에서는 기본 Infrastructure Protection의 세부 경계를 반복하지 않는다. Portal, CLI, PowerShell, Bicep 또는 Terraform 배포 절차도 다루지 않는다. DDoS Protection과 네트워크 보안 그룹(Network Security Group, NSG), Azure Firewall, 웹 애플리케이션 방화벽(Web Application Firewall, WAF)의 전체 비교 역시 뒤의 Module 1 주제로 남겨 둔다.

의사결정은 다음 순서로 진행한다.

강화 보호 필요성 확인
→ 엔드포인트 지원 여부 확인
→ 보호 범위 자산 목록 작성
→ 운영 혜택 분류
→ 현재 및 미래 비용 추정
→ 계층 선택과 근거 기록
→ 관측 데이터와 대응 체계 검증

2. 이전 평가에서 네 가지 입력값 가져오기

워크로드를 이해하기 전에 가격표부터 열지 않는다. 앞선 DDoS 기본 보호 평가에서 네 가지 입력값을 가져온다.

입력값	입문자를 위한 질문	답변 예시
외부 공개 엔드포인트 자산 목록	인터넷 트래픽을 실제로 받는 Azure Public IP는 무엇인가?	Application Gateway의 Standard Public IP 하나
가용성 목표	업무가 허용할 수 있는 중단 또는 성능 저하는 어느 정도인가?	결제 기능은 15분 안에 복구해야 한다
운영 요구사항	어떤 신호, 대응자, 에스컬레이션 경로가 필요한가?	당직자에게 경보를 보내고 완화 로그를 보관한다
비용·위험 요구사항	공격 관련 확장 비용이나 전문가 대응 지원이 필요한가?	DDoS 신속 대응(DDoS Rapid Response, DRR)과 Cost Protection이 계약상 필수다

이 입력값은 두 가지 흔한 실수를 막는다.

현재 리소스 수가 적다는 이유만으로 IP Protection을 선택하는 실수
Network라는 이름이 더 넓고 성숙하게 들린다는 이유만으로 Network Protection을 선택하는 실수

이번 글의 결과물은 제품 선호가 아니라 다음과 같은 의사결정 기록이어야 한다.

<범위·운영·비용 근거>에 따라
<대상 엔드포인트와 VNet>에
<선택한 계층>을 적용한다.
<측정 가능한 조건>이 발생하면 결정을 다시 검토한다.

3. 비교 전에 알아야 할 다섯 가지 명사

Public IP 주소

Azure Public IP 주소는 Load Balancer, Application Gateway, Azure Firewall, Azure Bastion, VPN Gateway 또는 VM Network Interface 같은 지원 리소스에 연결되는 인터넷 라우팅 가능 주소다. DDoS 계획에서 세는 보호 대상은 DNS 이름이나 모든 백엔드 서버가 아니라 이 Public IP 리소스다.

보호 리소스

보호 리소스는 IP Protection을 직접 적용했거나, VNet의 Network Protection을 통해 실제로 보호되는 지원 대상 Azure Public IP다. “구독 어딘가에 DDoS Protection이 있다”는 사실은 특정 엔드포인트가 보호된다는 증거가 아니다.

Virtual Network

Azure Virtual Network, 즉 VNet은 서브넷과 지원 리소스가 배치되는 사설 네트워크 경계다. Network Protection은 VNet을 DDoS Protection Plan과 연결하여 활성화한다. 그 VNet 안의 지원 대상 Public IP 리소스가 보호를 받는다.

DDoS Protection Plan

DDoS Protection Plan은 Network Protection에서 사용하는 관리 및 과금 리소스다. Azure DDoS Protection 개요에 따르면 한 테넌트 안의 Plan 하나를 여러 구독에서 사용할 수 있다. 따라서 여러 VNet, 구독, 지역에 일관된 관리 경계를 적용할 수 있으며 비용은 Plan이 속한 구독에 청구된다.

보호 계층

Azure가 현재 문서화하는 구성 가능한 강화 계층은 DDoS IP Protection과 DDoS Network Protection 두 가지다. 추가 비용 없이 자동 제공되는 기준선은 DDoS Infrastructure Protection이다. 이 비교에서 구성 가능한 세 번째 계층으로 취급하지 않는다.

4. 가장 먼저 지원 가능 여부를 통과하기

조직이 비용을 지불하더라도 지원되지 않는 엔드포인트를 보호할 수는 없다. 기능 비교 전에 모든 Public 엔드포인트에 대해 다음 질문에 답한다.

리소스가 Classic 배포가 아니라 Azure Resource Manager 방식으로 배포되었는가?
지원 리소스에 Azure Public IP가 실제로 연결되어 있는가?
IP Protection이라면 Standard SKU Public IP인가?
현재 비교표에서 지원하지 않는 NAT Gateway에 Public IP가 연결되어 있지는 않은가?
엔드포인트가 지원되는 VNet 통합 리소스인가, 아니면 지원 모델 밖의 다중 테넌트 서비스형 플랫폼(Platform as a Service, PaaS) 가상 IP(VIP)인가?
Public Load Balancer Frontend에 Public IP Prefix가 연결되어 있는가? 현재 문서는 이 시나리오를 Network Protection 지원 범위로 명시한다.
도메인 이름, Front Door 엔드포인트 또는 외부 엔드포인트의 백엔드가 Azure에 있다는 이유만으로 보호된다고 가정하지는 않았는가?

Microsoft의 현재 계층 비교 문서는 NAT Gateway Public IP, Classic VM, Azure Virtual WAN 및 지원되지 않는 다중 테넌트 PaaS 모델 등을 공통 제약으로 제시한다. 또한 IP Protection은 Basic SKU Public IP를 지원하지 않는다고 설명한다.

Basic SKU Public IP는 2025년 9월 30일에 사용 종료되었다. 신규 아키텍처는 Standard Public IP를 사용해야 하며, 퇴역한 설계를 유지하려고 Network Protection을 선택해서는 안 된다. 먼저 엔드포인트 자산 목록을 작성하고 현대화한다.

지원 가능 여부는 명시적으로 기록한다.

엔드포인트	리소스 유형	Public IP SKU	VNet	지원 가능 여부	증적 담당자
`pip-checkout-prod`	Application Gateway WAF_v2	Standard	`vnet-prod-edge`	검토 대기	네트워크 팀
`pip-admin-test`	단일 VM NIC	Standard	`vnet-test`	지원되지만 아키텍처는 비권장	플랫폼 팀
`pip-egress-prod`	NAT Gateway	Standard	`vnet-prod-app`	두 계층의 지원 대상 아님	네트워크 팀

이 표는 “Public IP가 세 개 있다”는 말보다 유용하다. 세 IP 중 하나는 지원 대상 인바운드 애플리케이션 엔드포인트가 아닐 수 있기 때문이다.

5. 두 강화 계층은 핵심 보호 엔진을 공유한다

가장 먼저 바로잡아야 할 내용은 다음과 같다.

IP Protection은 관측 데이터가 없거나 수동으로 조정해야 하는 Network Protection의 하위 제품이 아니다.

Microsoft 계층 비교 문서는 두 계층에 공통으로 다음 기능을 표시한다.

능동 트래픽 모니터링과 상시 탐지
Layer 3·Layer 4 공격 자동 완화
보호 대상 애플리케이션 및 Public IP에 맞춰 조정되는 완화 정책
메트릭과 경보
완화 보고서와 완화 흐름 로그
Azure Firewall Manager 통합
Microsoft Sentinel 커넥터와 워크북 통합

DDoS Protection 개요는 Azure가 트래픽 패턴을 학습하고 보호되는 Public IP마다 자동 조정된 TCP SYN, TCP, UDP 완화 정책을 적용한다고 설명한다. 트래픽 프로필이 해당 임계값을 넘으면 완화가 시작된다. 자동 튜닝이 기본값이다. 다만 검토일 현재 Standard Load Balancer Frontend IP에는 사용자 지정 탐지 임계값이 미리 보기(Preview)로 제공되며, TCP·UDP·TCP SYN 중 고정 임계값을 설정한 프로토콜에서는 자동 튜닝이 비활성화된다.

이 공통 핵심 기능을 알면 질문이 달라진다. 다음처럼 묻지 않는다.

진짜 보호와 약한 보호 중 무엇을 선택할까?

다음처럼 묻는다.

공통 핵심 기능을 선택한 IP에 연결할까,
아니면 추가 대응·비용 혜택과 함께 VNet 단위로 관리할까?

6. 가장 분명한 차이는 연결 방식이다

IP Protection: Public IP 하나에 직접 연결

IP Protection은 지원되는 Public IP에 직접 활성화한다. DDoS Protection Plan이 필요하지 않으며 보호되는 Public IP마다 비용이 발생한다.

Public IP A ── IP Protection 활성화
Public IP B ── 비활성화
Public IP C ── IP Protection 활성화

중요하고 안정적인 엔드포인트가 소수인 작은 워크로드라면 이해하기 쉬운 방식이다. 하지만 리소스 생성, 자산 목록, 정책 및 검토 절차가 약하면 새로 만들어진 IP를 빠뜨리기 쉽다.

Network Protection: VNet에 Plan 연결

Network Protection은 DDoS Protection Plan을 하나 이상의 VNet과 연결한다. 연결된 VNet 안의 지원되는 Public IP 리소스가 보호된다.

DDoS Protection Plan
├─ VNet A
│  ├─ 지원 Public IP A ── 보호됨
│  └─ 지원 Public IP B ── 보호됨
└─ 다른 구독의 VNet B
   └─ 지원 Public IP C ── 보호됨

이 방식은 공유 플랫폼 관리 체계와 잘 맞는다. 의도한 VNet을 연결하고 보호 리소스를 중앙 자산 목록에서 관리하며 예외를 검토할 수 있다. 그래도 “테넌트의 모든 리소스가 보호된다”는 뜻은 아니다. Plan에 연결되지 않은 VNet, 지원되지 않는 리소스 모델, 또는 해당 VNet 밖의 엔드포인트는 주장할 수 있는 보호 범위 밖에 있다.

7. 실제 의사결정에 필요한 비교표

판단 기준	DDoS IP Protection	DDoS Network Protection
연결 단위	지원되는 개별 Public IP	DDoS Plan과 연결된 VNet
핵심 L3/L4 감시 및 완화	제공	제공
Public IP별 적응형 정책	제공	제공
메트릭, 경보, 보고서, 흐름 로그	제공	제공
Standard Public IP 지원	제공	제공
Basic Public IP 지원	미지원	지원으로 표기되어 있으나 Basic Public IP SKU는 퇴역
과금 방식	보호 Public IP별	보호 리소스 기본 수량을 포함한 고정 Plan 비용과 초과 비용
DDoS Rapid Response	미포함	포함
공격 관련 Cost Protection	미포함	현재 조건과 증적 요건에 따라 포함
Application Gateway WAF 요금 혜택	미포함	현재 자격 조건을 충족하면 포함
일반적인 시작점	소수의 명확하고 안정적인 Public IP	여러 VNet·엔드포인트 또는 Plan 단위 운영 혜택과 관리 체계가 필요한 환경

“일반적인 시작점”은 지원 자격 규칙이 아니다. 중요한 엔드포인트 하나만 있어도 DRR이 필수라면 Network Protection이 타당할 수 있다. 반대로 일시적인 Public IP가 스무 개라면 어느 계층을 구매하기 전에 외부 공개 범위를 줄여야 한다는 신호일 수 있다.

8. 암기한 가격이 아니라 비용 모델로 비교하기

Azure 가격은 계약, 지역, 통화 및 날짜에 따라 달라진다. 아키텍처 다이어그램에 숫자를 고정해서 복사하기보다 계산 방식과 검토일을 기록한다.

IP Protection 비용 모델

예상 IP Protection 비용
= 현재 IP별 단가
× 보호할 지원 Public IP 수
× 실제 활성 과금 기간

보호 수량에는 애플리케이션 또는 VNet 수가 아니라 실제로 보호해야 할 Public IP 리소스를 넣는다. 애플리케이션 하나에도 Application Gateway, Azure Firewall, Bastion 등 서로 다른 Public IP가 있을 수 있다.

Network Protection 비용 모델

예상 Network Protection 비용
= 현재 Plan 비용
+ 포함 수량을 초과한 보호 리소스 비용
- 적용 가능한 Application Gateway WAF 요금 혜택
+ 모니터링, 대응, 관리 체계 운영 비용

Microsoft의 현재 가격 페이지에 따르면 Network Protection Plan은 Public IP 리소스 100개까지의 보호를 포함하며 그 이상은 별도로 과금된다. 같은 Plan을 테넌트 안의 여러 구독과 VNet에 연결할 수 있다.

현재 DDoS Protection FAQ는 유용한 가격 출발점을 제공한다. 보호할 Public IP가 15개 미만이면 일반적으로 IP Protection이, 15개를 초과하면 Network Protection이 비용 효율적이라고 설명한다. FAQ는 정확히 15개인 경우를 어느 쪽에도 배정하지 않으므로 이 경계에서는 두 비용을 직접 계산한다. 이 안내를 검토일이 있는 참고 기준으로 사용하고 영구적인 아키텍처 법칙으로 외우지 않는다. 다음 이유로 다시 계산해야 한다.

계약 가격이나 통화가 비교 결과를 바꿀 수 있다.
Public IP 수가 늘어날 수 있다.
Network Protection의 WAF 혜택이 총비용을 크게 바꿀 수 있다.
수치상 분기점 아래에서도 DRR과 Cost Protection이 업무상 가치를 가질 수 있다.
불필요한 Public IP를 없애는 것이 더 좋은 설계일 수 있다.

의사결정 기록에는 세 가지 수량을 남긴다.

수량	필요한 이유
현재 지원 대상 Public IP	현재 비용과 보호 범위
향후 12~24개월 예상 Public IP	마이그레이션 및 예산 재검토 시점
제거해야 할 Public IP	구매 전 공격 표면 축소

9. Network Protection 전용 혜택 세 가지 이해하기

9.1 DDoS 신속 대응(DDoS Rapid Response, DRR)

DDoS Protection 개요에 따르면 Network Protection 고객은 공격이 진행되는 동안 Microsoft DDoS Rapid Response 팀에 조사 지원을 요청하고 공격 후 분석 도움을 받을 수 있다.

조직이 실제로 사용할 준비가 되어 있어야 DRR이 가치가 있다. 다음 내용을 문서화한다.

누가 요청을 열 권한을 갖는가?
필요한 지원 조건과 연락처가 최신 상태인가?
누가 영향받는 Public IP, 시간대별 경과, 메트릭 및 업무 영향을 제공하는가?
누가 애플리케이션, 네트워크, 보안, 커뮤니케이션 팀을 조정하는가?
사고 후 권고사항을 어디에 기록하는가?

에스컬레이션 절차서 없이 구매한 접근 권한은 운영 역량이 아니라 서류상의 혜택에 머문다.

9.2 Cost Protection

Network Protection에는 문서화된 DDoS 공격 때문에 발생한 지원 대상 리소스의 확장 및 데이터 전송 비용에 대한 현재 Cost Protection 혜택이 포함된다. 그렇다고 예산, 자동 확장 한도 또는 애플리케이션 보호 장치 없이 운영해도 된다는 뜻은 아니다. 비용이 큰 모든 트래픽 증가가 자동 환불된다는 뜻도 아니다.

이 혜택을 의사결정 근거로 사용하려면 다음을 기록한다.

현재 Microsoft 약관과 지원되는 비용 항목
문서화된 DDoS 공격이 비용 원인임을 보여 줄 증적
과금 및 지원 담당자
비용 보상 요청 절차
혜택 범위 밖에 남는 비용

9.3 Application Gateway WAF 요금 혜택

Microsoft의 현재 가격 안내는 WAF를 사용하는 Application Gateway가 Network Protection으로 보호되는 VNet에 배치될 경우, 문서화된 조건 아래 더 낮은 WAF 미적용 Application Gateway 요율로 과금되는 혜택을 설명한다.

이를 “Network Protection을 쓰면 모든 WAF가 무료다”라고 줄이면 안 된다. 정확한 WAF 제품, SKU, VNet 관계, 계약 및 현재 조건을 확인한다. Azure Front Door WAF, 타사 WAF 및 다른 보안 서비스가 같은 혜택을 받는다고 가정해서는 안 된다.

10. 시나리오 A: 안정적인 엔드포인트 두 개를 가진 소규모 Public API

작은 회사가 다음 환경을 운영한다고 가정한다.

운영 Application Gateway Public IP 한 개
정해진 테스트 시간에만 사용하는 비운영 Public IP 한 개
필수 DRR 요구사항 없음
현재 Cost Protection 요구사항 없음
향후 1년 동안 Public 엔드포인트를 다섯 개 미만으로 유지할 계획

지원 여부를 확인한 뒤 운영 IP에 IP Protection을 적용하는 것이 합리적인 시작 후보가 될 수 있다. 테스트 엔드포인트에도 같은 보호가 필요한지, 아니면 사설 접근으로 전환하고 필요할 때만 제한적으로 열지 별도로 결정한다.

다음 운영 통제가 있어야 결정이 완성된다.

새 Public IP 생성을 탐지하는 자산 목록 규칙
Azure Monitor 경보와 진단 설정
DDoS 메트릭과 독립적인 애플리케이션 가용성 경보
이름이 지정된 사고 담당자
엔드포인트 수 또는 업무 중요도가 증가할 때의 재검토 조건

“작은 회사라서 IP Protection을 선택했다”는 약한 설명이다. 다음처럼 기록해야 한다.

보호 수량이 안정적이고 공통 완화 및 관측 데이터가 현재 요구사항을 충족하며, DRR, Cost Protection, Network Protection의 WAF 혜택이 아직 필수가 아니므로 운영 엔드포인트 한 개에 IP 단위 보호를 선택한다. Public IP가 다섯 개가 되거나 규제 워크로드가 추가되거나 DRR 요구가 생기면 다시 평가한다.

11. 시나리오 B: 여러 구독을 사용하는 공유 플랫폼

다음과 같은 조직을 가정한다.

여러 구독과 지역에 운영 VNet 배치
Application Gateway WAF와 Azure Firewall Public IP 사용
여러 팀이 엔드포인트를 지속적으로 생성하고 폐기
중앙 네트워크 운영 팀 운영
Microsoft 전문가 지원 요청이 필요한 사고 대응 절차
공격 관련 확장 비용을 검토해야 하는 재무 요구사항

Public IP 수가 가격 분기점에 도달하기 전이라도 Network Protection이 더 강한 후보다. Plan이 관리 체계의 경계와 잘 맞고, DRR이 운영상 의미가 있으며, WAF 및 Cost Protection 혜택이 총가치에 영향을 준다.

Plan에도 다음 통제가 필요하다.

승인된 VNet을 Plan에 연결한다.
새 VNet이 절차를 벗어나지 않게 한다.
보호 리소스와 지원되지 않는 예외를 자산 목록으로 관리한다.
진단 설정과 경보를 표준화한다.
Plan 및 초과 비용을 지불할 구독을 합의한다.

“테넌트에 Plan 하나가 있다”는 완전한 보호 범위 증거가 아니다. 증거는 Plan과 VNet의 연결 관계 및 지원 Public IP 자산 목록이다.

12. 숫자만으로 고르면 틀릴 수 있다

IP가 15개 미만이어도 Network Protection이 맞을 수 있다

엔드포인트가 적어도 DRR이 필수이거나 공격 관련 비용 위험이 크거나 Application Gateway WAF 혜택이 총비용을 바꾼다면 Network Protection이 타당할 수 있다.

IP가 15개를 넘으면 아키텍처 문제일 수 있다

Public IP가 많으면 Network Protection이 경제적으로 유리할 수 있다. 하지만 먼저 모든 엔드포인트가 외부에 공개되어야 하는지 묻는다. Private Endpoint, 사설 관리 경로, 중앙 인그레스 또는 미사용 리소스 제거를 통해 위험과 비용을 함께 줄일 수 있다.

Public IP 하나가 큰 업무 위험을 숨길 수 있다

Application Gateway IP 하나가 매우 중요한 서비스 전체의 프런트엔드일 수 있다. 리소스 수는 매출 영향, 규제 결과, 복구 난이도 또는 고객 신뢰를 측정하지 못한다.

Plan 하나가 보호 공백을 숨길 수 있다

Network Protection Plan이 있어도 새 VNet이 연결되지 않았거나 리소스 모델이 지원되지 않거나 애플리케이션에 Layer 7 보호가 없을 수 있다. Plan 존재와 서비스 복원력은 같은 말이 아니다.

13. 7단계 선택 절차 사용하기

1단계: 외부 공개 범위 줄이기

사용하지 않는 Public IP를 제거하고 관리 및 내부 서비스에는 사설 접근을 우선한다. 가장 안전한 Public 엔드포인트는 워크로드에 필요하지 않아 제거한 엔드포인트일 때가 많다.

2단계: 지원 대상 Public IP 자산 목록 작성

리소스 유형, SKU, VNet, 구독, 지역, 담당자, 환경, 업무 서비스 및 예상 수명을 기록한다.

3단계: 업무 및 운영 요구사항 분류

DRR, Cost Protection, WAF 혜택, 중앙 관리 체계, 증적 보존 및 사고 지원을 필수, 선호, 불필요로 구분한다.

4단계: 두 비용 모델 모두 계산

현재 Azure 가격을 사용해 현재 수량과 최소 하나의 성장 시나리오를 계산한다. 초과 비용과 적용 가능한 WAF 영향을 포함한다. 날짜, 통화, 지역 및 계약 가정을 기록한다.

5단계: 연결 경계 선택

보호가 이름을 지정한 개별 IP를 따라야 하는지, 관리 대상 VNet을 따라야 하는지 결정한다. 새 리소스와 예외를 처리하는 절차도 포함한다.

6단계: 활성화 전에 모니터링과 대응 설계

DDoS 경보, 진단 데이터의 저장 위치, 애플리케이션 상태 신호, 사고 담당자, 에스컬레이션 경로, 보존 기간 및 검토 주기를 정의한다.

7단계: 잔여 위험 승인과 재검토 조건 정의

선택한 계층이 해결하지 못하는 내용을 적고 승인자를 지정한다. 결정을 다시 검토할 측정 가능한 조건을 설정한다.

14. 계층 의사결정 기록 작성하기

짧은 의사결정 기록을 남기면 Azure Portal 설정이 바뀐 뒤에도 판단 근거가 사라지지 않는다.

결정: DDoS IP Protection | DDoS Network Protection | 우선 재설계
검토일: YYYY-MM-DD

워크로드와 가용성 목표:
지원 Public IP 자산 목록:
선택한 연결 경계:
현재 / 12개월 / 24개월 리소스 수:
가격 출처, 지역, 통화 및 계약:
DRR 요구사항:
Cost Protection 요구사항:
Application Gateway WAF 혜택 평가:
모니터링 및 사고 담당자:
지원되지 않거나 제외한 엔드포인트:
남아 있는 Layer 7 및 애플리케이션 용량 위험:
재평가 조건:
승인자:

화면 캡처만 남기지 말고 다음 증적을 연결한다.

기계가 읽을 수 있는 Public IP 자산 목록
VNet과 Plan 연결 내역 또는 IP별 보호 상태 내보내기 파일
계산 워크시트와 가격 출처
Azure Monitor 경보 및 진단 설정 정의
해당하는 경우 사고 및 DRR 절차서
예외 목록
승인 기록

Azure Portal 화면 캡처는 검토를 돕지만 시간이 지나면 낡는다. 의도한 모든 엔드포인트가 계속 보호된다는 사실을 단독으로 증명할 수 없다.

15. 보호 공백 없이 계층 변경 계획하기

아키텍처는 성장하므로 처음 선택한 계층을 영구적으로 유지할 필요는 없다. Microsoft는 계층 전환 절차를 공식 문서로 제공한다.

IP Protection에서 Network Protection으로 이동

관련 VNet을 DDoS Protection Plan에 연결한다. Microsoft 문서에 따르면 보호 서비스가 IP Protection에서 Network Protection으로 자동 전환되므로 먼저 IP Protection을 끌 필요가 없다.

그래도 다음을 검증한다.

올바른 VNet이 연결되었는가?
의도한 Public IP마다 예상 보호 상태가 표시되는가?
경보와 진단 데이터의 저장 위치가 올바른가?
과금 담당자가 예상대로 변경되었는가?
의사결정 기록과 자산 목록이 갱신되었는가?

Network Protection에서 IP Protection으로 이동

VNet을 Network Protection에서 분리하기 전에 유지할 모든 지원 Public IP에 IP Protection을 활성화한다. Microsoft는 DDoS Protection 공백을 피하려면 이 순서를 지켜야 한다고 경고한다.

기존에 보호되던 모든 엔드포인트가 이동 가능한 것으로 가정하지 않는다. Standard Public IP 지원 여부와 현재 제약을 다시 확인한다. 전환 후에는 Public IP별 보호 상태를 검증하고 증적이 완성된 뒤에만 Plan 연결을 제거한다.

16. 보호 설정값이 아니라 운영을 검증하기

두 계층 모두 DDoS 관측 데이터를 제공하지만, 누군가 신호를 받고 해석할 때만 가치가 생긴다.

최소한 다음을 검증한다.

보호 상태: 의도한 Public IP마다 선택한 계층이 표시된다.
공격 신호: Under DDoS attack or not 메트릭 경보가 존재한다.
트래픽 임계값: 기본 TCP SYN, TCP, UDP 자동 조정 임계값을 어디서 확인하는지 안다. 지원되는 Standard Load Balancer Frontend IP라면 사용자 지정 미리 보기 임계값이 특정 프로토콜의 자동 튜닝을 비활성화했는지도 확인한다.
진단: 완화 보고서와 흐름 로그가 승인된 저장 위치로 전송된다.
보존: 사고 및 규정 준수 요구기간 동안 증적이 보관된다.
애플리케이션 상태: 지연 시간, 오류, 포화도 및 종속성 상태를 별도로 감시한다.
담당 체계: 당직, 네트워크, 보안, 애플리케이션, 지원, 재무 및 커뮤니케이션 역할을 지정한다.

Azure DDoS Protection 기능 문서는 Azure Monitor의 DDoS Protection 메트릭 데이터가 30일 동안 보관된다고 설명한다. 더 긴 증적 보관이 필요하다면 내보내기와 보존 정책을 설계해야 한다. 기본 메트릭 기간은 장기 보관 전략이 아니다.

DDoS 트래픽을 직접 생성하지 않는다. Azure는 승인된 테스트 파트너를 통한 시뮬레이션, 사전 승인 및 안전장치를 문서화한다. 이 글에서는 공격 시뮬레이션을 수행하거나 실행 절차를 안내하지 않는다.

17. 어느 계층도 단독으로 해결하지 못하는 것

올바른 계층 선택은 네트워크 계층의 가용성 위험을 줄이지만 애플리케이션 아키텍처를 완성하지는 않는다.

남는 위험	추가 설계 질문
Layer 7 HTTP 요청 폭주	WAF, 엣지 속도 제한, 캐시, 봇 제어 또는 애플리케이션 제한이 필요한가?
단일 인스턴스 장애	가장 작은 구성 요소가 고갈되기 전에 수평 확장 또는 장애 조치가 가능한가?
데이터베이스 또는 종속성 포화	큐, 시간 제한, 회로 차단기 및 종속성 할당량이 설계되었는가?
외부 공개 관리 엔드포인트	Bastion, VPN, 사설 접근 또는 필요한 시간에만 여는 Just-in-Time(JIT) 접근으로 노출을 줄일 수 있는가?
현재 혜택 밖의 비용 고갈	예산, 한도, 경보 및 재무 담당자 보고·에스컬레이션 절차가 정의되었는가?
사고 대응 혼선	연습된 의사결정 및 커뮤니케이션 경로가 있는가?

Azure DDoS Protection은 Layer 3과 Layer 4에서 작동한다. 웹 애플리케이션 방화벽과 애플리케이션 제어는 다른 Layer 7 동작을 다룬다. 복원력, 자동 확장, 장애 조치, 복구 목표 및 사고 담당 체계는 여전히 고객 책임이다.

18. 설계 검토에 넣어야 할 현재 제약

정확한 지원 표는 바뀔 수 있으므로 현재 Microsoft 문서를 의사결정 기록에 연결한다. 이번 검토 시점의 중요한 예시는 다음과 같다.

NAT Gateway에 연결된 Public IP 리소스는 지원되지 않는다.
클래식 배포 모델(RDFE/Azure Service Manager)을 사용하는 VM은 지원되지 않는다.
Azure Virtual WAN과 여러 다중 테넌트 PaaS 모델은 지원되지 않는다.
VPN 또는 Virtual Network Gateway는 DDoS 정책으로 보호되지만 적응형 조정에는 문서화된 제약이 있다.
Public Load Balancer Frontend에 연결된 Public IP Prefix는 Network Protection 지원 대상으로 문서화되어 있다.
IP Protection에는 Standard SKU Public IP가 필요하다.
Public IP 뒤의 단일 VM은 지원되지만, 완화가 애플리케이션 가용성을 충분히 보호하기 전에 VM이 실패할 수 있어 권장되지 않는다.

이 목록을 영구적인 사실로 외우지 않는다. 워크로드를 설계하거나 검토할 때 최신 계층 비교를 확인한다.

19. 오해하기 쉬운 주장 일곱 가지 바꾸기

오해하기 쉬운 주장	더 정확한 표현
“IP Protection은 Basic Protection이다.”	IP Protection은 공통 핵심 완화와 관측 데이터를 제공하며 지원 Public IP별로 과금되는 구성 가능한 강화 계층이다.
“Network Protection은 패킷을 더 강하게 막는다.”	문서상 주요 차이는 연결 범위, 과금, DRR, Cost Protection 및 WAF 혜택이며 두 계층은 핵심 L3/L4 기능을 공유한다.
“IP가 15개 미만이므로 반드시 IP Protection이다.”	현재 수량은 가격 참고 기준이며 운영 요구와 성장 계획에 따라 다른 결정이 가능하다.
“Plan이 구독을 보호한다.”	Network Protection은 연결된 VNet을 통해 지원 Public IP에 적용되며 구독의 모든 리소스에 자동 적용되지 않는다.
“프런트엔드 하나를 보호하면 모든 위험이 해결된다.”	지원 네트워크 엔드포인트를 보호할 뿐 Layer 7, 백엔드 용량, 종속성 및 복구에는 별도 통제가 필요하다.
“Cost Protection이 있으므로 공격 비용은 발생하지 않는다.”	현재 조건과 증적 요건을 충족하는 공격 관련 비용이 보상 대상이 될 수 있지만 예산과 한도는 여전히 필요하다.
“계층은 나중에 계획 없이 바꾸면 된다.”	전환을 지원하지만 순서, 지원 여부, 관측 데이터, 과금 및 보호 상태 검증이 중요하다.

20. 아키텍처 검토 체크리스트

범위와 지원 가능 여부

모든 인터넷 연결 엔드포인트가 Public IP 자산 목록에 있다.
리소스 유형, Public IP SKU, VNet, 구독, 지역 및 담당자를 기록했다.
지원되지 않는 리소스 모델을 보호 대상으로 조용히 포함하지 않았다.
불필요한 Public 엔드포인트마다 담당자와 제거 계획이 있다.
선택한 연결 경계가 실제 아키텍처와 일치한다.

운영과 지원

DDoS 메트릭, 경보, 보고서 및 흐름 로그의 승인된 저장 위치가 있다.
애플리케이션 상태를 DDoS 관측 데이터와 별도로 감시한다.
사고 대응 역할과 에스컬레이션 연락처가 최신 상태다.
Network Protection을 선택했다면 DRR 요청 절차가 문서화되어 있다.
필요 시 기본 메트릭 보관 기간보다 오래 증적을 보관한다.

비용과 관리 체계

동일한 최신 자산 목록으로 두 가격 모델을 모두 계산했다.
지역, 통화, 계약, 출처 URL 및 계산일을 기록했다.
현재, 12개월 및 24개월 엔드포인트 수를 고려했다.
WAF 혜택과 Cost Protection 가정을 추측하지 않고 검증했다.
비용을 지불할 구독, 예산 담당자, 초과 비용 담당자 및 예외 담당자를 정했다.

수명주기

새 Public IP와 VNet 생성 시 보호 범위 검토가 시작된다.
보호 상태를 자동 또는 정해진 주기로 확인한다.
계층 전환 순서가 문서화되어 있다.
재평가 조건이 측정 가능하다.
남은 Layer 7, 복원력 및 복구 위험에 승인자가 있다.

21. 복습 질문

IP Protection을 단순히 약한 완화 엔진이라고 부를 수 없는 이유는 무엇인가?
IP Protection은 어떤 리소스에 직접 연결하는가?
VNet을 Network Protection과 연결하는 리소스는 무엇인가?
DDoS Plan이 있으면 테넌트의 모든 리소스가 자동 보호되는가?
두 계층이 공통 제공하는 관측 데이터 기능은 무엇인가?
Network Protection에만 문서화된 중요한 혜택 세 가지는 무엇인가?
정확히 15개인 경우를 규정하지 않은 현재 Public IP 15개 기준을 왜 영구 규칙이 아닌 참고 기준으로 봐야 하는가?
Application Gateway WAF가 총비용 비교를 어떻게 바꿀 수 있는가?
지원되지 않는 Public IP와 불필요한 Public IP를 보호 가능 IP와 분리해야 하는 이유는 무엇인가?
Network Protection에서 IP Protection으로 이동할 때 보호 공백을 피하는 순서는 무엇인가?
어느 계층을 골라도 남는 애플리케이션 위험은 무엇인가?
어떤 증적이 단순히 VNet이나 Plan이 아니라 의도한 엔드포인트가 실제 보호됨을 보여 주는가?

답변이 “Network가 더 좋다” 또는 “IP가 더 싸다”로 시작한다면 빠진 범위, 지원 여부, 운영, 가격 검토일 및 잔여 위험을 추가한다.

22. 한 페이지 기억 카드

DDoS IP Protection
→ 지원되는 Standard Public IP 하나에 직접 연결
→ 공통 핵심 L3/L4 완화와 관측 데이터
→ 보호 IP별 과금
→ DRR, Cost Protection, Network 계층 WAF 혜택 미포함

DDoS Network Protection
→ 하나 이상의 VNet에 Plan 연결
→ 해당 VNet의 지원 Public IP 보호
→ 공통 핵심 L3/L4 완화와 관측 데이터
→ 리소스 기본 수량과 초과분을 포함한 Plan 과금
→ DRR + Cost Protection + 지원되는 Application Gateway WAF 혜택

선택 순서:
지원 여부 → 범위 → 운영 → 비용 → 성장 → 증적

기억할 한 문장은 다음과 같다.

한쪽만 “진짜” 완화를 제공한다고 생각하지 말고, 관리해야 할 경계와 필요한 운영 혜택을 기준으로 IP Protection과 Network Protection을 선택한다.

다음 Module 1 상세 글은 더 근본적인 노출 질문을 다룬다. Public IP가 전혀 필요하지 않은 Azure VM은 어떻게 설계해야 할까? 완전한 영문·국문 글이 준비되기 전까지 계획 상태로 두며 빈 경로는 연결하지 않는다.