This chapter covers Azure DDoS Protection telemetry and diagnostics, a critical component for detecting and mitigating DDoS attacks. For the AZ-500 exam, this topic falls under Network Security (Domain 3, Objective 3.2: Configure and manage Azure DDoS Protection). Approximately 5-10% of exam questions touch on DDoS telemetry, including metrics, diagnostic logs, alerting, and integration with Azure Monitor. Understanding how to configure and interpret DDoS telemetry directly impacts incident response and compliance reporting.
Jump to a section
Imagine a large office building with a fire alarm system. The system has smoke detectors (metrics) in every room that continuously monitor for smoke particles (packet rates). These detectors send readings to a central panel (Azure Monitor Metrics) every 30 seconds. If a detector detects smoke above a threshold, it triggers a local alarm (attack alert) and logs the time, location, and smoke density (diagnostic logs). The building manager can view a dashboard showing real-time smoke levels across all floors (DDoS Protection telemetry). Additionally, the system can be configured to automatically notify the fire department (Azure Monitor alerts) and record all events in a tamper-proof log (Log Analytics). The key is that the system provides both real-time visibility and post-event forensic data, allowing the manager to distinguish between a small kitchen fire (transient spike) and a full-scale arson attack (DDoS attack). Without telemetry, the manager would only know the building is on fire after it's too late — telemetry enables early detection and informed response.
What is Azure DDoS Protection Telemetry and Diagnostics?
Azure DDoS Protection provides real-time telemetry and diagnostic logs to help you monitor and respond to DDoS attacks. Telemetry includes metrics (e.g., packets per second, attack signatures) and diagnostic logs (e.g., DDoSProtectionNotifications, DDoSMitigationFlowLogs). These are essential for detecting attacks, analyzing impact, and meeting compliance requirements. The exam expects you to know the types of telemetry, how to enable them, and how to interpret the data.
Why Telemetry Matters
Without telemetry, a DDoS attack might go unnoticed until it causes service degradation. DDoS Protection automatically mitigates attacks, but you need visibility to confirm mitigation is working, tune policies, and generate post-incident reports. The exam emphasizes that telemetry is not enabled by default for all resources — you must explicitly configure diagnostic settings.
How DDoS Telemetry Works Internally
DDoS Protection is integrated into Azure’s core network. When traffic passes through Azure’s edge routers, the DDoS mitigation pipeline inspects packets and collects metrics. The pipeline processes traffic in real-time, comparing it against baseline thresholds. Metrics are aggregated per minute and stored in Azure Monitor Metrics for 93 days. Diagnostic logs are sent to a Log Analytics workspace, Storage account, or Event Hub based on your configuration.
Key Components and Defaults
Metrics: Available automatically for DDoS Protection plans. Key metrics include:
- Packets Inbound (per second) - Bytes Inbound (per second) - DDoS Attack Status (0 = no attack, 1 = under attack) - TCP Packets Inbound, UDP Packets Inbound, etc. - Diagnostic Logs: Must be enabled via Diagnostic Settings. Log categories:
DDoSProtectionNotifications: Alerts when a public IP is under attack.
DDoSMitigationFlowLogs: Detailed flow logs during mitigation.
DDoSMitigationReports: Summary reports post-mitigation.
Alerts: You can create metric alerts (e.g., when DDoS Attack Status = 1) or log-based alerts.
Retention: Metrics retained 93 days. Logs retention depends on destination (Log Analytics: up to 2 years per workspace settings).
Configuration and Verification
To configure diagnostic logging: 1. Navigate to the DDoS Protection plan in Azure portal. 2. Under Monitoring, select Diagnostic settings. 3. Add a diagnostic setting, select the logs and metrics you want, and choose destination (Log Analytics, Storage, Event Hubs).
To verify metrics: Use Azure Monitor Metrics explorer, select the DDoS Protection plan resource, and add metrics like "Packets Inbound" or "DDoS Attack Status".
CLI example to enable diagnostic logging:
az monitor diagnostic-settings create \
--resource <DDoS Protection Plan Resource ID> \
--name ddosDiagnostics \
--workspace <Log Analytics Workspace ID> \
--logs '[{"category":"DDoSProtectionNotifications","enabled":true},{"category":"DDoSMitigationFlowLogs","enabled":true},{"category":"DDoSMitigationReports","enabled":true}]' \
--metrics '[{"category":"AllMetrics","enabled":true}]'Interaction with Related Technologies
Azure Monitor: Central hub for metrics and alerts. DDoS metrics appear here automatically.
Log Analytics: Query diagnostic logs using KQL. Example: DDoSProtectionNotifications | where TimeGenerated > ago(1d).
Azure Sentinel: Ingest DDoS logs to create security incidents.
Azure Policy: Enforce diagnostic settings on DDoS plans.
Network Watcher: NSG flow logs can complement DDoS telemetry for deeper analysis.
Exam-Relevant Details
DDoS Protection Standard is required for telemetry on public IPs. Basic tier offers no telemetry.
Diagnostic logs are not enabled by default — you must configure them.
Metrics are free and automatically available for Standard tier.
Log ingestion costs apply to Log Analytics and Storage.
The exam may ask about the difference between DDoSProtectionNotifications (attack start/stop) and DDoSMitigationFlowLogs (per-flow data).
Know that DDoS Attack Status metric is 0 or 1, not a percentage.
Alerts can be based on metric thresholds (e.g., >0 for attack).
Common Commands
Enable diagnostic logging via CLI (as above).
Query logs: DDoSProtectionNotifications | where ResourceId contains "myIP".
Check current attack status: az monitor metrics list --resource <plan ID> --metric "DDoS Attack Status".
Performance Considerations
Metrics are sampled every minute; fine-grained data is not available.
Diagnostic logs can be high volume during attacks; plan storage costs.
Use Log Analytics workspace with appropriate retention and daily cap.
Security and Compliance
Telemetry helps meet compliance requirements (e.g., SOC 2, PCI DSS) by providing evidence of DDoS mitigation.
Diagnostic logs can be sent to a SIEM for centralized monitoring.
Ensure diagnostic settings are configured for all DDoS-protected public IPs.
Troubleshooting
If metrics show no data, verify the DDoS Protection plan is Standard and associated with the virtual network.
If logs are missing, check diagnostic settings and destination health.
Use Azure Monitor Workbooks for pre-built DDoS dashboards.
Summary
DDoS telemetry and diagnostics provide the visibility needed to detect, analyze, and respond to DDoS attacks. The AZ-500 exam focuses on configuration (enabling logs), interpretation (metrics vs. logs), and integration with monitoring tools. Master the default values, log categories, and CLI commands to answer questions confidently.
Enable DDoS Protection Standard
First, create a DDoS Protection plan of tier Standard. This plan must be associated with the virtual network hosting the public IPs you want to protect. Without Standard tier, no telemetry is available. In the Azure portal, navigate to DDoS Protection plans, click Create, select Standard tier, and specify the plan name and region. Then, go to the virtual network's DDoS Protection settings and select the plan. Alternatively, use CLI: `az network ddos-protection create --name MyPlan --resource-group MyRG --location eastus` and `az network vnet update --name MyVNet --resource-group MyRG --ddos-protection-plan MyPlan`. This step is foundational; any subsequent telemetry depends on it.
Configure Diagnostic Settings
After the DDoS Protection plan is active, navigate to the plan resource in Azure portal. Under Monitoring, select Diagnostic settings. Click Add diagnostic setting, give it a name, and check the boxes for the log categories: DDoSProtectionNotifications, DDoSMitigationFlowLogs, and DDoSMitigationReports. Also check the metric category AllMetrics. Choose a destination: Log Analytics workspace (recommended for querying), Storage account (for long-term archiving), or Event Hubs (for streaming to SIEM). You can send to multiple destinations. Click Save. This must be done per DDoS Protection plan, not per public IP. The exam often tests that diagnostic settings are not enabled by default.
Monitor Metrics in Azure Monitor
Once the DDoS Protection plan is associated and diagnostic settings are configured, metrics automatically flow to Azure Monitor. Go to Azure Monitor > Metrics. Select the DDoS Protection plan as the resource scope. Add metrics like "Packets Inbound" or "DDoS Attack Status". The DDoS Attack Status metric shows 0 (no attack) or 1 (under attack). You can set up a metric alert rule to notify when this metric equals 1. For example, create an alert with condition "DDoS Attack Status > 0" and action group (email, SMS, webhook). Metrics are aggregated per minute and retained for 93 days. The exam may ask about the retention period and the metric values.
Query Diagnostic Logs with KQL
If you sent logs to Log Analytics, you can query them using Kusto Query Language (KQL). For example, to see all attack notifications: `DDoSProtectionNotifications | where TimeGenerated > ago(1d)`. To see mitigation flow logs: `DDoSMitigationFlowLogs | where TimeGenerated > ago(1h)`. The DDoSProtectionNotifications log includes fields like ResourceId, AttackStartTime, AttackEndTime, and AttackStatus. DDoSMitigationFlowLogs contains per-flow details (source IP, destination IP, protocol, packet count, etc.). Use these logs for forensic analysis. The exam may ask which log category provides per-flow data: DDoSMitigationFlowLogs.
Set Up Alerts and Workbooks
Create metric alerts based on DDoS Attack Status or other metrics. For example, an alert when "Packets Inbound" exceeds a threshold (e.g., 10,000 packets per second) for 5 minutes. Use action groups to notify the security team. Additionally, Azure provides pre-built DDoS Protection workbooks in Azure Monitor Workbooks. These workbooks visualize metrics and logs in a dashboard. You can also create custom workbooks. The exam may test that workbooks are available for DDoS telemetry. Remember that alerts are not automatically created; you must configure them. Diagnostic logs alone do not trigger alerts — you need alert rules.
Scenario 1: E-commerce Platform During a Flash Sale An online retailer uses Azure DDoS Protection Standard to protect its public-facing load balancer. During a flash sale, traffic spikes legitimately. The security engineer configures diagnostic logs to a Log Analytics workspace and sets up a metric alert on DDoS Attack Status. When the attack status changes to 1, an email is sent to the team. However, during the sale, the metric shows attack status 0 despite high traffic. The engineer queries DDoSProtectionNotifications and sees no entries. This confirms there is no attack — the high traffic is legitimate. The engineer also uses DDoSMitigationFlowLogs to verify that no mitigation actions were triggered. This telemetry provides confidence that the platform is not under attack. Common mistake: Assuming high traffic always means DDoS attack. Telemetry helps distinguish.
Scenario 2: Gaming Company Under UDP Flood A gaming company experiences a UDP flood attack on its game servers. The DDoS Protection plan is configured, and diagnostic logs are sent to Event Hubs, which streams to Azure Sentinel. The security analyst uses Sentinel to create an incident rule based on DDoSProtectionNotifications. When the attack starts, Sentinel generates an incident. The analyst queries DDoSMitigationFlowLogs to see the source IPs and packet sizes. They notice the attack is from many spoofed IPs. The mitigation report shows that the attack was mitigated within 2 minutes. The logs are retained for 90 days for compliance. Without telemetry, the company would not know the attack details for post-mortem. Misconfiguration: If diagnostic settings are not enabled, no logs would be available, and the analyst would have no data to investigate.
Scenario 3: Financial Services Compliance A bank must comply with PCI DSS, which requires logging of security events including DDoS attacks. The Azure administrator enables all three diagnostic log categories and sends them to a Log Analytics workspace with 365-day retention. They also archive logs to a Storage account with immutable storage. During an audit, the auditor asks for evidence of DDoS protection. The administrator provides a query showing DDoSProtectionNotifications for the past year. The auditor also reviews DDoSMitigationReports to confirm mitigation effectiveness. The bank uses Azure Policy to enforce diagnostic settings on all DDoS Protection plans. Common pitfall: Forgetting to enable diagnostic settings on new plans, leaving a gap in compliance. Azure Policy helps enforce this.
What AZ-500 Tests on This Topic (Objective 3.2) The exam focuses on configuring and interpreting DDoS Protection telemetry. Specific objectives include: enabling diagnostic logs, understanding metric vs. log data, setting up alerts, and integrating with Azure Monitor. You must know the three log categories and their purposes. The exam also tests default retention (93 days for metrics) and that diagnostic settings are not enabled by default.
Common Wrong Answers and Why Candidates Choose Them 1. "DDoS Protection Basic provides telemetry." Candidates confuse Basic with Standard. Basic offers no telemetry — only Standard provides metrics and logs. Always choose Standard for telemetry. 2. "Diagnostic logs are enabled automatically." Many think logging is on by default. In reality, you must explicitly configure diagnostic settings. The exam often presents a scenario where logs are missing because settings were not configured. 3. "Use DDoSMitigationFlowLogs to get attack notifications." Candidates mix up log categories. DDoSProtectionNotifications provides attack start/stop notifications; DDoSMitigationFlowLogs provides per-flow details. The correct answer depends on the question (e.g., "which log shows when an attack started?"). 4. "Alerts are automatically created." Some believe enabling diagnostic logs creates alerts. Alerts must be created separately using metric or log search rules. The exam may ask how to get notified of an attack — answer: create a metric alert on DDoS Attack Status.
Specific Numbers and Terms - DDoS Attack Status metric: 0 = no attack, 1 = under attack. - Metrics retention: 93 days. - Log categories: DDoSProtectionNotifications, DDoSMitigationFlowLogs, DDoSMitigationReports. - Diagnostic settings must be configured per DDoS Protection plan. - Metrics are free; log ingestion costs apply.
Edge Cases and Exceptions - If a public IP is not attached to a virtual network with DDoS Protection Standard, no telemetry is available. - During an attack, metrics may show increased packets but DDoS Attack Status may still be 0 if mitigation is not triggered (e.g., if attack is below threshold). - DDoSMitigationFlowLogs only contain data while mitigation is active. - You can send logs to multiple destinations simultaneously.
Eliminating Wrong Answers - If a question asks about "real-time attack status," look for the metric DDoS Attack Status, not logs (logs have latency). - If asked about "details of each flow during mitigation," choose DDoSMitigationFlowLogs. - If asked about "compliance evidence of attacks," choose DDoSProtectionNotifications or DDoSMitigationReports. - If asked about "enabling telemetry," the answer involves configuring diagnostic settings, not just enabling the plan.
DDoS Protection Standard is required for telemetry; Basic offers none.
Diagnostic settings must be explicitly configured; they are not enabled by default.
Three log categories: DDoSProtectionNotifications, DDoSMitigationFlowLogs, DDoSMitigationReports.
Metrics are free and retained for 93 days.
DDoS Attack Status metric is 0 (no attack) or 1 (under attack).
Alerts must be created separately; diagnostic logs alone do not alert.
Use KQL to query logs in Log Analytics for forensic analysis.
These come up on the exam all the time. Here's how to tell them apart.
DDoSProtectionNotifications
Provides attack start and stop notifications
Includes fields: ResourceId, AttackStartTime, AttackEndTime, AttackStatus
Generated at the beginning and end of an attack
Useful for compliance and incident timeline
Lower volume compared to flow logs
DDoSMitigationFlowLogs
Provides per-flow details during mitigation
Includes fields: SourceIP, DestinationIP, Protocol, PacketCount, ByteCount
Generated continuously during active mitigation
Useful for forensic analysis and attacker identification
Higher volume; can be large during attacks
Mistake
DDoS Protection Basic provides telemetry and logs.
Correct
DDoS Protection Basic offers no telemetry or diagnostic logs. Only DDoS Protection Standard provides metrics and logs. Basic only includes automatic mitigation without visibility.
Mistake
Diagnostic logs are enabled by default when you create a DDoS Protection plan.
Correct
Diagnostic settings must be explicitly configured for each DDoS Protection plan. Without enabling them, no logs are sent to Log Analytics, Storage, or Event Hubs.
Mistake
The DDoS Attack Status metric shows the severity of the attack as a percentage.
Correct
The DDoS Attack Status metric is a boolean value: 0 (no attack) or 1 (under attack). It does not indicate severity or percentage.
Mistake
You can get per-flow data from DDoSProtectionNotifications.
Correct
DDoSProtectionNotifications only provides attack start/stop notifications with basic info (time, resource). Per-flow data (source IP, packet count) comes from DDoSMitigationFlowLogs.
Mistake
Enabling diagnostic logs automatically creates alerts for DDoS attacks.
Correct
Diagnostic logs do not create alerts. You must separately create metric alerts or log search alerts (e.g., on DDoS Attack Status = 1) to be notified.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Go to the DDoS Protection plan in Azure portal, under Monitoring select Diagnostic settings, add a setting, choose the log categories (DDoSProtectionNotifications, DDoSMitigationFlowLogs, DDoSMitigationReports) and metrics, then select a destination (Log Analytics, Storage, or Event Hubs). You can also use the CLI command `az monitor diagnostic-settings create` with the appropriate parameters. Diagnostic settings are not enabled by default.
DDoSProtectionNotifications provides notifications when an attack starts and stops, including timestamps and resource information. DDoSMitigationFlowLogs provides detailed per-flow data (source/destination IP, protocol, packet/byte counts) during the mitigation. Use notifications for alerting and compliance; use flow logs for forensic analysis.
No. Only DDoS Protection Standard provides telemetry (metrics and logs). The Basic tier includes automatic mitigation but no visibility. If you need to monitor DDoS attacks, you must upgrade to Standard and configure diagnostic settings.
DDoS Protection metrics are retained for 93 days in Azure Monitor Metrics. Diagnostic logs retention depends on the destination: Log Analytics workspace retention (configurable up to 2 years), Storage account (indefinite if configured), or Event Hubs (no retention; consumed by consumer).
Create a metric alert rule on the DDoS Attack Status metric. Set the condition to 'Greater than 0' (since attack status is 1 during attack). Configure an action group with email, SMS, webhook, etc. You can also create a log search alert based on DDoSProtectionNotifications, but metric alerts are simpler and have lower latency.
DDoSMitigationReports provides summary reports after a mitigation ends. It includes aggregated data such as total packets dropped, attack duration, and top source countries. This is useful for post-incident reports and compliance documentation.
Yes. When configuring diagnostic settings, you can select multiple destinations (Log Analytics, Storage, Event Hubs) simultaneously. Each destination receives the same logs. This is useful for both real-time analysis (Event Hubs) and long-term archival (Storage).
You've just covered Azure DDoS Telemetry and Diagnostics — now see how well it sticks with free AZ-500 practice questions. Full explanations included, no account needed.
Done with this chapter?