Azure 기본 DDoS 인프라 보호의 실제 범위: 자동 보호와 고객 책임 구분

Azure는 고객이 강화된 DDoS 보호 Tier를 구매하거나 구성하기 전부터 기본 기준선을 제공한다. 이 문장은 사실이고 중요하지만 쉽게 오해된다. “Azure가 모든 서비스 거부 공격을 흡수한다”, “우리 Application은 이미 DDoS-ready 상태다”, “사고가 나면 Azure Alert가 생성된다”는 결론으로 확장되기 쉽다. 그러나 기본 기준선만으로는 어느 주장도 성립하지 않는다.

중요한 구분은 Azure의 공유 Infrastructure를 보호하는 일과 특정 고객 Application을 그 자체의 Capacity와 Recovery Objective 안에서 가용하게 유지하는 일이다. Azure Platform이 정상이어도 작은 Application의 Worker, Connection Pool, Downstream Quota 또는 비용 한도가 먼저 고갈될 수 있다. Provider가 운영하는 통제가 Network Risk 일부를 줄인다는 사실만으로 Workload가 공격을 견뎠다는 증적이 되지는 않는다.

이 글은 Coursera Azure Cybersecurity Solutions and Microsoft Defender 강좌 Module 1을 12개 주제로 분해한 학습 계획의 두 번째 상세 노트다. 기존 Module 1 복습 글은 DDoS, Firewall, JIT, Encryption의 전체 지도를 제공한다. 앞선 Defense in Depth 상세 글은 통제, 신호, 책임자, 복구를 연결하는 방법을 설명했다. 이 글은 그 방법을 하나의 좁은 질문에 적용한다. Workload가 Azure의 기본 DDoS Infrastructure Protection에만 의존할 때 우리는 어디까지 정직하게 보호를 주장할 수 있는가?

이 글은 강의 Transcript, 평가 답안, 실제 배포 기록 또는 공격 Test 보고서가 아닌 독립 학습 노트다. 제품 용어와 범위는 2026년 8월 10일 Microsoft Learn을 기준으로 검토했다. DDoS Traffic은 생성하지 않았다.

1. 이 글의 질문과 범위

Azure가 자동 제공하는 Infrastructure-level DDoS Protection은 어떤 위험을 줄이며, 그것만으로 개별 Application이 DDoS-ready라고 말할 수 없는 이유는 무엇인가?

이 글을 반복해서 검토한 뒤에는 다음을 설명할 수 있어야 한다.

• 현재 용어인 DDoS Infrastructure Protection을 사용하고 구매 가능한 “Basic” Tier를 찾지 않는다.
• Provider Infrastructure의 정상 상태와 Workload 가용성을 분리한다.
• Network-layer Mitigation과 Application-layer Resource Exhaustion을 구분한다.
• 실제 Traffic을 받는 Public Endpoint와 Service Boundary를 Inventory로 작성한다.
• 기본 기준선에는 고객별 DDoS Telemetry와 Alert가 없다는 사실을 증적 계획에 반영한다.
• 별도로 필요한 Application Signal을 정의한다.
• Tier를 성급히 고르지 않고 Enhanced Protection 검토를 시작할 조건을 식별한다.

이 글에서는 DDoS IP Protection과 DDoS Network Protection의 세부 비용, 연결 방식, 기능 차이를 비교하지 않는다. Portal, CLI, PowerShell, Terraform 활성화 절차도 다루지 않는다. 먼저 보호 공백을 정의한 뒤 다음 상세 글에서 다룰 질문이다.

범위는 다음 세 문장으로 정리된다.

Azure는 기본 DDoS Infrastructure Protection을 운영한다.
이 사실이 특정 고객 Application의 가용성을 보장하지는 않는다.
IP Protection과 Network Protection 중 무엇을 선택할지는 별도 결정이다.

2. “Basic Protection”을 현재 용어로 번역하기

강의, 오래된 Architecture Discussion, 일부 입문 문서에서는 추가 비용 없는 기준선을 “Basic Protection”이라고 부를 수 있다. 그러나 Microsoft의 현재 DDoS Tier 비교는 구성 가능한 Tier를 DDoS IP Protection과 DDoS Network Protection으로 구분하고, 자동 기준선을 Azure DDoS Infrastructure Protection이라고 표현한다.

학습 자료에서 만나는 표현	이 글에서 사용하는 의미	구성 가능한 유료 Tier인가?
Basic DDoS Protection	Azure가 자동 운영하는 DDoS Infrastructure Protection	아니요
Default 또는 Built-in Protection	같은 Infrastructure-level 기준선	아니요
Enhanced DDoS Protection	고객이 Onboarding하는 Azure DDoS Protection의 포괄적 표현	그 자체는 Tier명이 아님
Public IP별 강화 보호	DDoS IP Protection	예
VNet 또는 Plan 기반 보호	DDoS Network Protection	예

“Basic DDoS Protection”과 Basic SKU Public IP도 혼동하면 안 된다. 하나는 보안 기준선을 설명하고, 다른 하나는 2025년 9월 30일 은퇴한 별도의 Legacy IP Resource SKU다. 단어가 비슷해도 같은 통제가 아니다.

로드맵과 Slug의 안정성을 위해 파일명은 azure-ddos-basic-protection-scope를 유지하지만, 제목과 결론에서는 현재 제품 용어를 사용한다.

3. DDoS는 단순히 “Traffic이 많은 상태”가 아니라 가용성 실패다

Distributed Denial-of-Service Attack은 여러 Source 또는 분산된 처리 능력을 이용해 정상 사용자가 서비스를 이용하지 못하게 만든다. 다음 결과 흐름으로 기억하면 유용하다.

공격 또는 비정상적인 수요
→ Network, Protocol, Compute, Memory, Queue, Dependency 고갈
→ 정상 업무의 지연 또는 거부
→ Business Availability Objective 실패

Traffic 양도 중요하지만 실제 Incident는 가장 먼저 고갈되는 Resource가 결정한다. 세 가지 큰 형태로 실패 위치를 찾을 수 있다.

형태	대표적인 압력	최초 실패 가능 지점
Volumetric Network Attack	매우 높은 Packet 또는 Bit 처리량	Network Edge, Bandwidth, Packet-processing Capacity
Protocol 또는 State Exhaustion	Connection과 Protocol State	Load Balancer, Firewall, Host Networking, Session Table
Application-layer Exhaustion	정상처럼 보이지만 비싼 Request	HTTP Edge, Application Worker, Parser, Database, External Dependency

공격 이름을 외우기 위한 구분이 아니다. 활동을 어느 계층에서 관찰하고 제한할 수 있는지 찾기 위한 구분이다. Packet 중심 통제는 Search Request의 Business Cost를 이해하지 못하고, Application Rate Limit은 Network Edge에 도달하는 모든 Flood를 흡수하지 못한다.

4. Infrastructure 기준선이 실제로 보호하는 것

Microsoft의 현재 Tier 비교 문서는 추가 비용 없이 Public IPv4와 IPv6 Address를 사용하는 Azure Service에 Infrastructure Protection이 적용되고, 고객 Configuration이나 Application 변경 없이 지속적인 보호를 제공한다고 설명한다. Azure DDoS Protection 개요는 강화된 VNet 기반 보호 밖의 Service에 기본 Infrastructure-level Protection이 적용되어 일반적인 Network-layer Attack을 방어한다고 설명한다.

이를 Application 보증이 아니라 책임 경계로 읽어야 한다.

보호 대상	Azure 기본 기준선의 역할	고객에게 남는 질문
Azure Global·Regional Network Infrastructure	Platform을 위협하는 일반 Network-layer Attack을 Provider가 완화	내 Workload는 훨씬 낮은 Traffic에서 먼저 실패하는가?
Public Azure Service Endpoint	Service Platform을 통해 Infrastructure-level Protection 상속	Client Traffic을 실제로 받는 Service와 Endpoint 유형은 무엇인가?
고객 Application Capacity	모든 Workload Bottleneck을 보호한다는 보장 없음	Worker, Queue, Connection, Database, Dependency의 검증된 한계는 무엇인가?
Application-layer Request	Workload Business Operation의 의미를 검사하지 않음	WAF, Rate Limit, 인증, Cache, Abuse Control을 어디서 강제하는가?
Workload Incident Evidence	기본 기준선에는 고객별 DDoS Mitigation Telemetry와 Alert 없음	어떤 독립적인 Application·Business Signal로 Impact를 탐지하는가?
Recovery와 Continuity	Workload Recovery Strategy를 생성하지 않음	어떻게 Degraded Mode, Failover, Recovery, 고객 Communication을 수행하는가?

Workload가 Azure가 운영하는 공유 Network-layer Control을 상속한다는 점에서 기본 기준선은 가치가 크다. 그러나 가치가 통제의 계약 범위를 확장하지는 않는다. “Azure가 Infrastructure를 보호한다”와 “우리 예약 API가 비정상 부하에서도 Availability Target을 충족한다”는 서로 다른 주장이고 서로 다른 증적이 필요하다.

5. “구성할 필요 없음”과 “설계할 필요 없음”은 다르다

Infrastructure Protection에 Configuration이 필요 없다는 말은 다음을 뜻한다.

• 고객이 기본 DDoS Plan을 생성하지 않는다.
• 고객이 Platform의 공유 Protection Policy를 Tuning하지 않는다.
• Microsoft가 Mitigation Capability를 운영한다.
• Provider 기준선을 상속하기 위해 Application Code를 변경하지 않는다.

다음까지 의미하지는 않는다.

• 모든 Public Endpoint가 필요하고 정확히 파악되어 있다.
• 모든 Workload에 Application-specific Mitigation Threshold가 있다.
• DDoS Metric, Flow Log, Report, Alert를 고객이 볼 수 있다.
• HTTPS를 사용하므로 Layer 7 Request가 안전하다.
• Autoscale, Queue, Cache, Database, DNS, Third-party Dependency가 복원력 있게 구성되었다.
• SLA, Recovery Objective, Business Continuity Target이 자동 충족된다.
• Incident Owner가 없어도 된다.

이 구분은 다른 Cloud Service에도 재사용할 수 있다. Fully Managed Provider Control은 한 가지 Configuration Task를 제거할 수 있지만 Architecture, Observability, Response, Assurance 책임까지 제거하지는 않는다.

6. Public Endpoint Inventory에서 시작하기

“이 Application은 Azure에서 실행된다”는 설명만으로 DDoS Review를 할 수 없다. Traffic은 Azure Front Door, Multitenant PaaS Hostname, Application Gateway, Load Balancer, Azure Firewall Public IP, 직접 노출된 VM 또는 Third-party Edge에서 종료될 수 있다.

관리, Callback, Status, API, Upload, Legacy Name을 포함한 모든 Public Hostname에 한 줄씩 작성한다.

Endpoint 질문	기록할 값	필요한 이유
외부 사용자가 접근할 수 있는 Hostname은 무엇인가?	Public FQDN 또는 비식별 Alias	잊힌 Endpoint와 Nonproduction Exposure 발견
DNS는 어디를 가리키는가?	Azure Edge, Service Hostname, 고객 Public IP, Third Party	최초 Enforcement·Failure Boundary 확인
고객이 ARM Public IP Resource를 소유하는가?	Identifier를 제거한 Resource Type과 SKU	Enhanced Tier 지원 여부는 단순한 “Azure 사용”이 아니라 Architecture에 따라 달라짐
Multitenant PaaS Endpoint인가?	Service와 Deployment Model	Platform Endpoint와 VNet Public IP의 동작이 다름
의도한 Edge를 우회해 Origin에 직접 접근할 수 있는가?	예, 아니요, 미검증	Direct Origin은 L7 Policy와 증적을 우회할 수 있음
Layer 7 Control은 어디서 강제되는가?	WAF, Gateway, API Policy, Application, 없음	Request-aware Protection 위치 확인
가장 먼저 실패하는 Resource는 무엇인가?	Worker, CPU, Memory, Queue, Connection, DB, Quota, Dependency	실제 Workload Threshold 발견
Incident 중에도 어떤 Signal이 남는가?	Availability SLI, Latency, Error, Saturation, Dependency, Business Metric	Impact 관찰 가능성 확인

자동 Infrastructure Protection 적용 범위와 구성 가능한 Enhanced Tier의 지원 범위는 같은 질문이 아니다. Service별 보호를 주장하기 전에 현재 DDoS Protection Reference Architecture에서 지원 여부를 확인한다.

Inventory는 공격 표면도 줄여야 한다. Private Endpoint 전환, 불필요한 Public IP 제거, 승인된 Edge에서만 접근 가능한 Origin은 필요 없던 노출에 Protection을 구매하는 것보다 가치가 클 수 있다.

7. Network-layer Protection과 Layer 7 가용성은 다른 문제다

Request Path를 그리면 책임 경계가 보인다.

Internet
  → Azure Network Edge        Network-layer Volume과 Protocol Behavior
  → HTTP Edge 또는 WAF        Request Rate, Bot, Path, Header, Payload Context
  → Application Runtime       CPU, Thread, Memory, Parser, Cache, Queue Capacity
  → Data와 Dependency         Connection, Query, Quota, Lock, Downstream Capacity

Azure DDoS Protection은 Layer 3과 Layer 4에 초점을 둔다. Microsoft는 DDoS 개요와 기본 Best Practice에서 Layer 7 Risk에는 Web Application Firewall과 Application Design이 필요하다고 설명한다.

낮은 Request Rate도 비쌀 수 있다. 여러 개의 Uncached Query를 발생시키는 검색, CPU를 많이 쓰는 Parsing을 유발하는 파일, 여러 Identity·Risk Check를 호출하는 Login, Database Connection을 오래 점유하는 Export를 생각해 보자. 각 Packet이 유효하고 TLS Session이 정상이어도 Business Operation이 Backend를 고갈시킬 수 있다.

WAF도 완전한 답은 아니다. Origin Bypass를 막는 Architecture, Application에 맞는 Rule, 허용 Traffic을 처리할 Capacity, False Positive 대응 경로가 필요하다. Microsoft는 WAF 자체도 Volumetric·State-exhaustion Attack의 영향을 받을 수 있으므로 Architecture가 지원되는 경우 WAF VNet에 DDoS Protection을 적용하도록 권고한다. Defense in Depth는 계층이 서로 보완한다는 뜻이지 한 제품의 이름이 모든 계층으로 확장된다는 뜻이 아니다.

8. Platform과 Workload는 서로 다른 Threshold를 가질 수 있다

Microsoft DDoS FAQ는 핵심 차이를 명확하게 설명한다. Infrastructure Protection은 Azure Infrastructure를 보호하기 위한 Threshold를 사용하며, 그 Threshold는 개별 Application이 감당할 수 있는 수준보다 높을 수 있다. 또한 기본 기준선에는 고객용 DDoS Telemetry와 Alerting이 제공되지 않는다고 설명한다.

임의의 Packet 수를 만들지 않고 위험을 다음처럼 표현할 수 있다.

Workload Failure Threshold < Platform Mitigation Threshold

이 관계가 성립하면 Traffic이 Provider의 공유 Mitigation Trigger보다 낮아도 Application Capacity를 넘을 수 있다. Azure Infrastructure가 설계대로 정상 작동하는 동안 정상 사용자는 이미 Timeout이나 Error를 경험할 수 있다.

각 Threshold는 서로 다른 질문에 답한다.

Threshold	질문	가능한 입력
Platform Mitigation Threshold	Azure Infrastructure 규모에서 Network Traffic이 비정상적이고 유해한가?	Provider Network Profile과 Attack Signal
지원 대상 Resource의 Enhanced Per-resource Threshold	보호된 Public IP의 정상 패턴과 비교해 Traffic이 비정상적인가?	Application-specific L3/L4 Traffic Profile
Workload Capacity Threshold	Application이 Objective 안에서 정상 업무를 완료할 수 있는가?	Load Test, Queue Depth, Saturation, Latency, Dependency Limit
Business Impact Threshold	언제 Incident를 선언하고 고객에게 알려야 하는가?	Availability SLI, 실패 Transaction 비율, 지속 시간, Critical Journey

Azure는 첫 번째 Threshold를 기본 기준선의 일부로 내부 운영하지만 그 값이나 고객별 Mitigation 상태를 Workload Owner에게 노출하지 않는다. Enhanced DDoS Tier를 나중에 구매하더라도 나머지 Threshold는 고객이 결정하고 증명해야 한다. Adaptive Tuning 적용 여부도 지원 Resource Type에 따라 다르다. 현재 Tier 비교 문서는 VPN Gateway와 Virtual Network Gateway에는 DDoS Policy가 적용되지만 Adaptive Tuning은 지원되지 않는다고 명시한다.

9. 시나리오: 작은 예약 서비스가 Platform보다 먼저 지친다

Public Azure PaaS Endpoint로 노출된 소규모 예약 서비스를 가정한다. 평소 Traffic은 많지 않다. 예약 가능 시간을 조회하는 Request 하나가 여러 Database Query를 실행한다. 결과 Cache가 없고, Backend Connection Pool이 작으며, 비싼 Search Path에 Rate Limit도 없다.

비정상적인 이벤트는 다음처럼 진행된다.

1. 많은 Client가 문법적으로 정상인 HTTPS Search를 보낸다.
2. Traffic이 Azure Network Infrastructure 규모에서 반드시 유해한 것은 아니다.
3. Application Worker가 Database Connection을 기다린다.
4. Connection Pool과 Query Capacity가 포화된다.
5. 정상 Booking과 Cancellation Request가 Timeout된다.
6. Infrastructure 기준선은 Workload-specific DDoS Alert를 생성하지 않는다.
7. 운영자는 Application Latency, Dependency Failure, 완료된 예약 수 감소로 사고를 발견한다.

정확한 결론은 다음과 같다.

기본 보호가 “실패한” 것이 아니다. Infrastructure 기준선이 보호한다고 약속하지 않은 계층과 Threshold에서 Workload가 실패했다.

우선 개선 항목은 Cache, Bounded Work, Query Optimization, Queue Isolation, Path-specific Rate Limit, WAF 또는 Edge Control, Dependency Timeout, Load Shedding, 검증된 Scaling일 수 있다. Enhanced Network DDoS Tier도 정당화될 수 있지만 무제한 Database Operation을 직접 고치지는 못한다.

10. 같은 Traffic을 네 가지 운영 관점으로 읽기

DDoS는 Network Team만의 Incident가 아니다. 같은 Traffic도 Provider, Endpoint, Application, Business Boundary에서 서로 다른 질문을 만든다.

관점	질문	Signal 또는 Artifact
Azure Infrastructure	Traffic이 공유 Network Availability를 위협하는가?	Microsoft가 운영하는 Platform Protection
Public Endpoint	어느 Hostname, Service, Public IP, Origin Path가 Traffic을 받는가?	Endpoint Inventory, DNS Path, Architecture Record
Application	Throughput, Latency, Error, Saturation, Dependency가 안전 한계를 넘었는가?	Application Insights 또는 동등한 Metric, Log, Trace, Synthetic Check
Business	어떤 정상 Customer Journey가 얼마 동안 어떤 영향으로 실패했는가?	SLI·SLO Record, 완료 Transaction 수, Incident Timeline

Application Alert가 Azure의 DDoS Mitigation을 증명하지는 않는다. Azure Status가 정상이라고 고객이 예약을 완료했다는 뜻도 아니다. Network Attack Metric만으로 Business Impact가 입증되지도 않는다. 네 관점을 Correlation한 결과가 증적 패키지가 된다.

11. 기본 기준선에는 증적 공백이 있다

Enhanced Azure DDoS Protection은 지원되는 보호 대상 Public IP에 고객용 Metric, Alert, Mitigation Report, Mitigation Flow Log를 제공한다. Infrastructure 기준선에는 고객 전용 DDoS Telemetry와 Alerting이 없다.

따라서 기본 기준선만 사용하는 Workload는 관찰할 수 없는 증적을 주장하면 안 된다.

원하는 주장	기본 기준선만으로 증명 가능한가?	더 나은 증적 방법
“Endpoint가 Azure Infrastructure Protection을 상속한다.”	현재 Microsoft Service 문서와 Endpoint 분류를 통해 일부 가능	공식 Source, Service Boundary, 검토일 기록
“이 시각에 DDoS Attack이 시작됐다.”	고객별 Baseline Attack Alert 없음	사용 가능한 App, Edge, Network, Support, Incident Evidence를 Correlation하고 불확실성 표시
“Azure가 이만큼의 Packet을 완화했다.”	Baseline 전용 Mitigation Metric·Report 없음	주장을 만들지 않고 해당 증적이 필요하면 Enhanced Telemetry 검토
“Application이 가용했다.”	불가능	Synthetic Availability, Request Success, Latency, Saturation, Business Journey 측정
“Alert가 없었으므로 공격도 없었다.”	불가능	기본 기준선에 Workload-specific DDoS Alert가 없음을 기록
“목표 시간 안에 대응했다.”	불가능	Acknowledge, Investigation, Containment, Recovery, Communication Timestamp 보존

일반 Service Metric은 존재할 수 있지만 DDoS Mitigation Telemetry와 같지 않다. CPU 급증과 성공 Request 감소는 Workload Impact를 보여 주지만 Attack Vector나 Provider Mitigation Action을 증명하지 않는다.

그래서 Telemetry는 Dashboard 편의 기능이 아니라 Security Capability다. Telemetry가 없으면 분류, Escalation, Post-incident Analysis, Compliance Evidence의 확신이 낮아진다.

12. Shared Responsibility를 운영 모델로 바꾸기

다음 RACI 형태 표는 학습용 Template이며 모든 조직에 그대로 적용되는 조직도가 아니다. 실제 Service Model과 Team Boundary에 맞게 수정해야 한다.

활동	Microsoft	Platform·Network Team	Application Team	SOC·Operations
Azure Infrastructure Mitigation 운영	Responsible	Informed	Informed	Informed
Public Endpoint Inventory 유지	Service 정보 제공	Accountable·Responsible	Consulted	Consulted
Layer 7·Capacity Control 설계	Platform Capability 제공	Consulted	Accountable·Responsible	Consulted
Application Health Signal 생성	Monitoring Platform 기능 제공	Consulted	Responsible	Alert Workflow에 Accountable
Incident와 Customer Impact 선언	Support·Service 정보 제공	Consulted	Consulted	Accountable·Responsible
Enhanced DDoS Protection 검토	Service 제공·운영	Accountable	Consulted	Consulted
Recovery·Degraded Mode Test	Platform 동작 지원	Consulted	Accountable·Responsible	참여하고 Timeline 기록

“Microsoft가 DDoS를 책임진다”는 표현은 너무 넓다. Microsoft는 Provider Mitigation Control을 책임진다. 고객은 Endpoint 결정, Workload Capacity, Layer 7 Behavior, Monitoring, Incident Response, Communication, Risk Acceptance를 계속 책임진다.

13. Enhanced Protection은 언제 검토해야 하는가?

모든 Endpoint가 즉시 유료 Tier를 구매해야 한다는 것이 이 글의 결론은 아니다. 기본 기준선에 의존하는 선택이 우연히 상속된 가정이 아니라 명시적인 Risk Decision이어야 한다는 것이 핵심이다.

다음 조건 중 하나 이상이 중요하면 Enhanced DDoS Protection 평가를 시작한다.

• Public Workload에 엄격한 Availability 또는 Revenue Objective가 있다.
• 검증된 Workload Failure Point가 공유 Platform Threshold보다 훨씬 낮을 수 있다.
• Responder에게 고객별 Network Attack Metric, Alert, Report가 필요하다.
• Audit 또는 Regulatory Obligation이 Mitigation Evidence를 요구한다.
• DDoS 전문가에게 연결되는 명확한 Escalation Path가 필요하다.
• 공격으로 인한 Scale-out 또는 Data-transfer 비용이 Business Risk다.
• 여러 지원 대상 Public IP Resource에 일관된 Coverage와 Governance가 필요하다.
• 이전 Event를 확신 있게 분류하지 못했다.
• Application Team과 Network Team이 남은 공백의 Owner에 합의하지 못했다.

이는 평가를 시작할 조건이지 Tier 선택 Algorithm이 아니다. DDoS IP Protection과 DDoS Network Protection은 핵심 Mitigation Capability를 공유하지만 연결, Coverage, Support, Cost Protection, Commercial Structure가 다르다. 이번 검토 시점 기준으로 DDoS Rapid Response, Cost Protection, Application Gateway WAF 할인은 Network Protection의 Benefit이며 Infrastructure Baseline이나 IP Protection Benefit이 아니다. 변동 가능한 세부 조건은 다음 글에서 현재 문서를 기준으로 검증한다.

14. 비용 없이 수행하는 Endpoint Tabletop

Resource를 배포하거나 공격 Traffic을 생성하지 않고도 Protection Claim의 품질을 높일 수 있다.

1. Nonproduction과 Administrative Name을 포함한 모든 Public Hostname을 적는다.
2. DNS를 최초 Azure·Third-party Edge부터 Origin까지 추적한다.
3. 고객 소유 ARM Public IP와 Multitenant Service Endpoint를 구분한다.
4. 오래되었거나 우회 가능한 Endpoint를 제거하거나 Owner를 지정한다.
5. L3/L4, L7, Application, Data, Dependency Enforcement Point를 표시한다.
6. 정상 Peak와 비정상 수요에서 어떤 Resource가 먼저 포화되는지 추정한다.
7. Request Success, Latency, Saturation, Queue, Dependency, Business Transaction의 정상 범위와 Alert를 기록한다.
8. 기본 기준선으로 증명할 수 없는 DDoS-specific Statement를 나열한다.
9. Incident Owner와 Customer Communication Trigger를 지정한다.
10. Enhanced Protection을 공식 평가할 필요와 이유를 기록한다.

결과물은 Azure Blade Screenshot이 아니다. 모든 Availability Claim에 Owner와 Observable Result가 연결된 Endpoint-to-impact Model이다.

직접 만든 DDoS Test를 실행하면 안 된다. Microsoft의 Simulation Policy는 승인된 Testing Partner, 고객 소유의 Azure-hosted Target, Azure DDoS Protection으로 보호되는 Public IP로 Simulation 범위를 제한한다. Tabletop, 정상적인 승인 Load Test, 공식 DDoS Simulation은 위험과 승인 요구가 서로 다른 활동이다.

15. 증명할 수 없는 내용까지 기록하는 증적 패키지

유용한 Baseline Assessment Package에는 다음이 포함된다.

• 비식별 처리한 Public Endpoint Inventory
• DNS, Edge, Origin Data-flow Diagram
• Service Type별 공식 Protection 문서와 검토일
• L3/L4, L7, Application, Dependency, Recovery 책임 지도
• 정상 Peak, 검증된 Capacity, 알려진 Dependency Limit 가정
• Application Availability, Latency, Error, Saturation, Business-impact Signal
• 고객별 DDoS Telemetry를 확보할 수 없다는 명시적인 Gap
• Incident Owner, Escalation Path, Communication 조건
• Enhanced Protection 평가 결정과 승인자
• Review Date가 포함된 Residual Risk

Diagram이 반복을 통해 증적으로 둔갑하지 않도록 Claim Ledger를 사용한다.

주장	Source 또는 Test	Expected Result	Observed Result	한계	Owner·Review Date
Endpoint가 Infrastructure Protection 상속	현재 Microsoft 문서와 Endpoint 분류	Service가 문서의 Baseline 범위에 포함	문서 검토 결과 기록	Workload Availability는 증명하지 않음	Platform Owner
Origin은 승인 Edge를 통해서만 접근	승인된 Positive·Negative Path Test	Edge 성공, Direct Origin 실패	실제 결과 기록	한 번의 Test가 영구 Configuration을 보장하지 않음	Network Owner
Peak에서 Booking 사용 가능	승인된 Load·Journey Test	SLI가 Objective 안에 유지	실제 결과 기록	DDoS Simulation이 아님	Application Owner
DDoS Alert 없이 Incident 선언 가능	Tabletop과 Alert Drill	Application·Business Signal이 Owner를 호출	Timeline 기록	Attack 분류에는 불확실성이 남을 수 있음	Operations Owner

Limitation Column은 부족한 작업을 고백하는 칸이 아니다. Control Statement를 정직하게 만들고 다음 Reviewer가 어디에 투자할지 알려 주는 칸이다.

16. 위험한 다섯 가지 주장을 교체하기

위험한 주장	잘못된 이유	방어 가능한 표현
“Azure에 있으므로 DDoS에 안전하다.”	Infrastructure Health와 Workload Availability의 Threshold가 다름	“Endpoint는 Azure Infrastructure Baseline을 상속하며 Workload Resilience는 별도로 평가한다.”
“무료 기준선이 모든 DDoS를 막는다.”	일반 Network-layer Threat를 줄이지만 모든 Application Exhaustion Path를 다루지 않음	“Provider Network Risk를 줄이는 기준선이며 L7·Capacity Control을 대체하지 않는다.”
“Alert가 없으니 공격도 없었다.”	기본 기준선에는 고객별 DDoS Alert가 없음	“존재하지 않는 Signal로 공격 부재를 추론할 수 없다.”
“WAF가 Baseline 범위를 확장한다.”	WAF는 별도의 Request-aware Layer를 추가함	“WAF와 Infrastructure Protection은 서로 다른 Failure Mode를 다루며 각각 검증한다.”
“무료 보호는 가치가 없다.”	Provider-scale Mitigation은 중요한 상속 통제임	“가치 있는 Platform Baseline이지만 Enhanced Protection보다 Scope와 Evidence가 좁다.”

좋은 Architecture Statement에는 네 부분이 있다.

상속한 Provider Control
+ 구현한 Workload Control
+ 확보 가능한 Evidence
+ 승인하거나 개선 일정에 넣은 Residual Gap

17. Architecture Review Checklist

용어와 범위

• “Basic Protection”을 현재 구매 가능한 Azure DDoS Tier로 설명하지 않았다.
• DDoS Infrastructure Protection을 IP Protection·Network Protection과 구분했다.
• 모든 Public Hostname과 실제 Service Boundary를 Inventory로 만들었다.
• 자동 Baseline 적용 범위와 Enhanced Tier 지원 범위를 같은 질문으로 다루지 않았다.
• 공식 Source와 Review Date를 기록했다.

가용성과 통제 계층

• Network-layer Volume, Protocol State, Application-layer Exhaustion을 구분했다.
• 가장 낮은 Workload·Dependency Capacity Limit을 문서화했다.
• Direct Origin과 Legacy Endpoint 우회 경로를 Test하거나 미검증으로 표시했다.
• Layer 7 Control, Application Load Shedding, Scaling, Recovery에 Owner가 있다.
• 실제 Customer Journey로 Business Impact를 측정한다.

관찰과 대응

• 기본 기준선에 고객별 DDoS Telemetry·Alert가 없다는 점을 명시했다.
• Application Availability, Latency, Error, Saturation, Queue, Dependency, Business Signal에 Owner가 있다.
• 추측한 Screenshot이나 발생하지 않은 Alert로 Mitigation·Attack을 주장하지 않는다.
• Incident Declaration, Escalation, Communication, Recovery Target을 문서화했다.
• Enhanced Protection Trigger와 Residual-risk Approver를 기록했다.
• 승인되지 않은 DDoS Simulation을 계획하지 않았다.

18. 스스로 설명해 볼 질문

1. Azure DDoS Infrastructure Protection은 무엇을 보호하며 누가 운영하는가?
2. Azure Platform이 정상인데 특정 고객 Application만 중단될 수 있는 이유는 무엇인가?
3. Workload Failure Threshold가 Platform Mitigation Threshold보다 낮을 수 있는 이유는 무엇인가?
4. 정상 HTTPS Search가 Network-layer Flood 없이 Application을 고갈시킬 수 있는 이유는 무엇인가?
5. “Azure에 Hosting”과 “구성 가능한 DDoS Tier 지원 대상”이 서로 다른 주장인 이유는 무엇인가?
6. 기본 DDoS Alert가 없다는 사실로 공격 부재를 증명할 수 없는 이유는 무엇인가?
7. DDoS-specific Telemetry가 없을 때 어떤 Application·Business Signal이 필요한가?
8. 현재 Workload에서 가장 먼저 포화될 Resource는 무엇인가?
9. 어떤 Availability, Evidence, Response, Cost 요구가 Enhanced Tier 검토를 촉발하는가?
10. 다음 IP Protection 대 Network Protection 비교에서 무엇을 검증해야 하는가?

답이 “Azure가 처리한다”로 끝난다면 Endpoint, Threshold, Signal, Owner, Residual Risk를 다시 추가한다.

19. 한 페이지 기억 카드

Built-in Infrastructure Protection
≠ Application-specific Threshold
≠ Customer DDoS Telemetry
≠ Layer 7 Protection
≠ Workload Resilience

Public Endpoint
→ Azure Service Boundary
→ Provider Baseline
→ Workload Capacity
→ Observable Signal
→ Incident Owner
→ Residual Gap

마지막 기억 문장은 다음과 같다.

Azure의 기본 DDoS Infrastructure Protection은 중요한 Provider 기준선이지만, 고객 Application의 Capacity, Telemetry, Layer 7 Defense, Incident Response까지 대신 설계하지는 않는다.

다음 Module 1 상세 글에서는 여기서 발견한 Gap을 기준으로 DDoS IP Protection과 DDoS Network Protection을 비교한다. 영문·국문 글이 완성되기 전까지는 Planned 상태로 두고 빈 Route를 연결하지 않는다.

참고 자료

• Coursera: Azure Cybersecurity Solutions and Microsoft Defender
• Microsoft Learn: Azure DDoS Protection Tier 비교
• Microsoft Learn: Azure DDoS Protection 개요
• Microsoft Learn: Azure DDoS Protection FAQ
• Microsoft Learn: Azure DDoS Protection 기능
• Microsoft Learn: Azure DDoS Protection 기본 Best Practice
• Microsoft Learn: Azure DDoS Protection 배포 보안
• Microsoft Learn: Azure DDoS Protection Reference Architecture
• Microsoft Learn: Azure DDoS Protection Reliability
• Microsoft Learn: Azure DDoS Protection Simulation Test
• Microsoft Learn: Public IP Address와 은퇴한 Basic SKU
• Microsoft Learn: Cloud 공동 책임 모델
• Microsoft Learn: Azure DDoS Protection Monitoring