Azure DDoS Infrastructure Protection: What the Built-In Baseline Actually Covers

Azure provides a DDoS baseline before a customer buys or configures an enhanced protection tier. That sentence is true, useful, and easy to misuse. It can become “Azure absorbs every denial-of-service attack,” “our application is already DDoS-ready,” or “an incident would produce an Azure alert.” None of those conclusions follows from the baseline alone.

The important distinction is between protecting Azure’s shared infrastructure and keeping one customer application available within its own capacity and recovery objectives. The platform can remain healthy while a small application has exhausted its workers, connection pool, downstream quota, or budget. A provider-operated control can reduce a class of network risk without becoming evidence that the workload survived it.

This is the second detailed note in the 12-topic Module 1 study plan for Coursera’s Azure Cybersecurity Solutions and Microsoft Defender course. The Module 1 review provides the broad DDoS, firewall, JIT, and encryption map. The preceding defense-in-depth note explains how to connect controls, signals, owners, and recovery. This article applies that method to one narrow question: what can we honestly claim when a workload relies only on Azure’s built-in DDoS infrastructure protection?

These are independent study notes, not a transcript, assessment answer, deployment record, or attack-test report. Product terminology and scope were reviewed against Microsoft Learn on August 10, 2026. No DDoS traffic was generated.

1. The question and the boundary of this article

What risk does Azure’s automatic infrastructure-level DDoS protection reduce, and why is that not enough to declare an individual application DDoS-ready?

By the end, you should be able to:

• use the current term DDoS infrastructure protection instead of looking for a purchasable “Basic” tier;
• separate provider infrastructure health from workload availability;
• distinguish network-layer mitigation from application-layer exhaustion;
• inventory the public endpoint and service boundary that actually receive traffic;
• document the absence of customer-specific DDoS telemetry and alerts in the built-in baseline;
• identify application signals that remain necessary; and
• state when an enhanced protection evaluation should begin without prematurely selecting a tier.

This article does not compare the detailed economics or attachment models of DDoS IP Protection and DDoS Network Protection. It also does not provide portal, CLI, PowerShell, or Terraform enablement steps. Those belong in the next note, after the protection gap has been defined.

Three statements frame the scope:

Azure operates built-in DDoS infrastructure protection.
That fact does not guarantee the availability of one customer application.
Choosing IP Protection or Network Protection is a separate decision.

2. Translate “Basic Protection” into current terminology

Course material, older architecture discussions, and even some current overview pages can use “Basic protection” as a convenient label for the no-additional-cost baseline. Microsoft’s current DDoS tier comparison, however, lists two configurable tiers—DDoS IP Protection and DDoS Network Protection—and calls the automatic baseline Azure DDoS infrastructure protection.

Phrase encountered in study material	Meaning used in this article	A configurable paid tier?
Basic DDoS protection	DDoS infrastructure protection automatically operated by Azure	No
Default or built-in protection	The same infrastructure-level baseline	No
Enhanced DDoS protection	General reference to customer-onboarded Azure DDoS Protection	Not a tier name by itself
Per-IP enhanced protection	DDoS IP Protection	Yes
VNet or plan-based protection	DDoS Network Protection	Yes

Do not confuse “Basic DDoS protection” with a Basic SKU public IP. One describes a security baseline; the other is a separate legacy IP resource SKU that retired on September 30, 2025. Similar words do not make them the same control.

The roadmap slug remains azure-ddos-basic-protection-scope so the planned sequence stays stable. The article uses the current product language in its title and conclusions.

3. DDoS is an availability failure, not merely “a lot of traffic”

A distributed denial-of-service attack uses multiple sources or distributed capacity to make a service unavailable to legitimate users. The useful outcome chain is:

Attack or abusive demand
→ network, protocol, compute, memory, queue, or dependency exhaustion
→ legitimate work is delayed or rejected
→ a business availability objective is missed

Traffic volume matters, but the smallest exhausted resource determines the incident. Three broad patterns help locate that resource.

Pattern	Typical pressure	Where the first failure can occur
Volumetric network attack	Very high packets or bits per second	Network edge, bandwidth, packet-processing capacity
Protocol or state exhaustion	Connection and protocol state	Load balancer, firewall, host networking, session table
Application-layer exhaustion	Valid-looking but expensive requests	HTTP edge, application worker, parser, database, external dependency

This classification is not an invitation to memorize attack names. It tells us which layer can observe and constrain the activity. A control designed around packets cannot understand the business cost of a search request, and an application rate limit cannot absorb every network flood before traffic reaches it.

4. What the infrastructure baseline actually covers

Microsoft’s current tier comparison states that, at no additional cost, infrastructure protection applies to Azure services using public IPv4 and IPv6 addresses, requires no customer configuration or application change, and provides continuous protection. The Azure DDoS Protection overview describes the default infrastructure-level capability as protection against common network-layer attacks for services outside enhanced VNet-based coverage.

The correct interpretation is a responsibility boundary, not an application guarantee.

Protection subject	What the Azure baseline contributes	Question still owned by the customer
Azure global and regional network infrastructure	Provider-operated mitigation of common network-layer attacks that threaten the platform	Can the workload fail at a much lower traffic level?
Public Azure service endpoint	Inherits infrastructure-level protection through the service platform	Which service and endpoint type actually receive client traffic?
Customer application capacity	No promise that every workload bottleneck is protected	What are the tested limits of workers, queues, connections, databases, and dependencies?
Application-layer requests	No semantic inspection of the workload’s business operations	Where are WAF, rate limiting, authentication, caching, and abuse controls enforced?
Workload incident evidence	No customer-specific baseline DDoS mitigation telemetry or alert	Which independent application and business signals detect impact?
Recovery and continuity	Does not create a workload recovery strategy	How does the service degrade, fail over, recover, and communicate impact?

The baseline is valuable because the workload inherits an Azure-operated shared network-layer control. Its value does not expand its contract. “Azure protects the infrastructure” and “our reservation API meets its availability target under abusive load” are different claims requiring different evidence.

5. “No configuration required” does not mean “no design required”

For infrastructure protection, no configuration means:

• the customer does not create a baseline DDoS plan;
• the customer does not tune the platform’s shared protection policy;
• Microsoft operates the mitigation capability; and
• the application does not need a code change to inherit that provider baseline.

It does not mean:

• every public endpoint is necessary or correctly understood;
• every workload has an application-specific mitigation threshold;
• DDoS metrics, flow logs, reports, and alerts are available to the customer;
• layer 7 requests are safe because they use HTTPS;
• autoscale, queues, caches, databases, DNS, and third-party dependencies are resilient;
• an SLA, recovery objective, or business continuity target is automatically met; or
• nobody needs an incident owner.

This distinction is a reusable cloud lesson. A fully managed provider control can remove one configuration task while leaving architecture, observability, response, and assurance work with the customer.

6. Start with a public-endpoint inventory

The statement “this application runs in Azure” is too vague for a DDoS review. Traffic might terminate at Azure Front Door, a multitenant PaaS hostname, Application Gateway, Load Balancer, an Azure Firewall public IP, a directly exposed VM, or a third-party edge before it ever reaches the application.

Create one row for every public hostname, including administrative, callback, status, API, upload, and legacy names.

Endpoint question	Record this value	Why it matters
What hostname can an external party reach?	Public FQDN or a sanitized alias	Finds forgotten and nonproduction exposure
Where does DNS point?	Azure edge, service hostname, customer public IP, or third party	Identifies the first enforcement and failure boundary
Does the customer own an ARM public IP resource?	Resource type and SKU, with identifiers redacted	Enhanced-tier eligibility depends on architecture, not just “being in Azure”
Is this a multitenant PaaS endpoint?	Service and deployment model	Platform endpoint behavior differs from a VNet public IP
Can a client bypass the intended edge and reach the origin?	Yes, no, or unverified	A direct origin can bypass L7 policy and its evidence
Where is layer 7 control enforced?	WAF, gateway, API policy, application, or none	Locates request-aware protection
What resource fails first?	Worker, CPU, memory, queue, connection, database, quota, dependency	Reveals the true workload threshold
Which signals survive an incident?	Availability SLI, latency, error, saturation, dependency and business metrics	Determines whether impact is observable

Automatic infrastructure protection and support for a configurable enhanced tier are not the same scope question. Consult the current DDoS Protection reference architectures for service-specific support before making a coverage claim.

Inventory should also reduce the target set. A private endpoint, removal of an obsolete public IP, and an origin restricted to the approved edge can be more valuable than purchasing protection for exposure the workload never needed.

7. Network-layer protection and layer 7 availability solve different problems

The request path makes the boundary visible.

Internet
  → Azure network edge        Network-layer volume and protocol behavior
  → HTTP edge or WAF          Request rate, bot, path, header, and payload context
  → Application runtime       CPU, thread, memory, parser, cache, and queue capacity
  → Data and dependencies     Connection, query, quota, lock, and downstream capacity

Azure DDoS Protection focuses on layers 3 and 4. Microsoft recommends a web application firewall and application design for layer 7 risks in its DDoS overview and fundamental best practices.

A low-rate request can still be expensive. Consider a search that performs several uncached queries, a file that triggers CPU-heavy parsing, a login that invokes multiple identity and risk checks, or an export that holds a database connection. Each packet can be valid and each TLS session can be well formed while the business operation exhausts the backend.

A WAF is not a complete answer either. It needs an architecture that prevents origin bypass, rules appropriate to the application, capacity to process allowed traffic, and a path for false-positive handling. Microsoft also notes that a WAF can itself be affected by volumetric and state-exhaustion attacks and recommends DDoS Protection for the WAF virtual network where the architecture is supported. Defense in depth means the layers complement one another; it does not mean one product’s label expands to every layer.

8. The platform and the workload can have different thresholds

The Microsoft DDoS FAQ makes the decisive point: infrastructure protection uses a threshold intended to safeguard Azure infrastructure, and that threshold can be higher than an individual application can handle. It also states that the built-in baseline does not provide customer DDoS telemetry or alerting.

Represent the risk without inventing packet counts:

Workload failure threshold < Platform mitigation threshold

If that relationship is true, traffic can remain below the provider’s shared mitigation trigger while exceeding the application’s capacity. Azure infrastructure can be operating as designed, yet legitimate users can already receive timeouts or errors.

The thresholds answer different questions.

Threshold	Question	Possible input
Platform mitigation threshold	Is network traffic abnormal and harmful at Azure infrastructure scale?	Provider network profile and attack signals
Enhanced per-resource threshold for a supported resource	Is traffic abnormal for this protected public IP?	Application-specific L3/L4 traffic profile
Workload capacity threshold	Can the application complete legitimate work within its objective?	Load test, queue depth, saturation, latency, dependency limit
Business impact threshold	When must an incident be declared and customers informed?	Availability SLI, failed transaction rate, duration, critical journey

Azure operates the first threshold internally as part of the built-in baseline, but it does not expose that threshold or its customer-specific mitigation state to the workload owner. The other thresholds require customer decisions and evidence, even if an enhanced DDoS tier is later purchased. Adaptive tuning also depends on the supported resource type: the current tier comparison notes that VPN and virtual network gateways receive a DDoS policy but do not support adaptive tuning.

9. Scenario: a booking service fails before the platform does

Consider a small appointment-booking service exposed through a public Azure PaaS endpoint. Normal volume is modest. A request to list available appointments performs several database queries. There is no result cache, the backend connection pool is small, and no rate limit protects the expensive search path.

An abusive event proceeds as follows.

1. Many clients submit syntactically valid HTTPS searches.
2. The traffic is not necessarily harmful at Azure network-infrastructure scale.
3. Application workers wait on database connections.
4. The connection pool and query capacity saturate.
5. Legitimate booking and cancellation requests time out.
6. No workload-specific DDoS alert is produced by the infrastructure baseline.
7. Operations notices the incident through application latency, dependency failures, and a drop in completed bookings.

The precise conclusion matters:

The built-in protection did not “fail.” The workload failed in a layer and at a threshold that the infrastructure baseline did not promise to protect.

The first improvements might include caching, bounded work, query optimization, queue isolation, path-specific rate limits, WAF or edge controls, dependency timeouts, load shedding, and tested scaling. An enhanced network DDoS tier may also be justified, but it cannot repair an unbounded database operation by itself.

10. Read the same traffic from four operating views

DDoS is not exclusively a network-team event. The same traffic produces different questions at the provider, endpoint, application, and business boundaries.

View	Question	Signal or artifact
Azure infrastructure	Does the traffic threaten shared network availability?	Microsoft-operated platform protection
Public endpoint	Which hostname, service, public IP, and origin path receive the traffic?	Endpoint inventory, DNS path, architecture record
Application	Did throughput, latency, error, saturation, or dependency behavior cross a safe limit?	Application Insights or equivalent metrics, logs, traces, synthetic checks
Business	Which legitimate journey failed, for how long, and with what customer impact?	SLI/SLO record, completed transaction count, incident timeline

An application alert does not prove Azure performed DDoS mitigation. A healthy Azure status page does not prove customers completed bookings. A network attack metric does not by itself prove business impact. Correlation across the four views is the evidence package.

11. The built-in baseline has an evidence gap

Enhanced Azure DDoS Protection exposes customer-facing metrics, alerts, mitigation reports, and mitigation flow logs for supported protected public IPs. The infrastructure baseline does not give the customer that dedicated DDoS telemetry and alerting.

That means a baseline-only workload should not claim evidence it cannot observe.

Desired statement	Can the baseline alone prove it?	Better evidence approach
“Our endpoint inherits Azure infrastructure protection.”	Partly, through current Microsoft service documentation and endpoint classification	Record the official source, service boundary, and review date
“A DDoS attack started at this time.”	No customer-specific baseline attack alert	Correlate available application, edge, network, support, and incident evidence; label uncertainty
“Azure mitigated this many packets.”	No dedicated baseline mitigation metric or report	Do not invent the claim; enhanced telemetry is required for that evidence type
“The application stayed available.”	No	Use synthetic availability, request success, latency, saturation, and business-journey measures
“No attack occurred because no alert fired.”	No	Record that the baseline provides no workload-specific DDoS alert
“Response met its target.”	No	Preserve acknowledgement, investigation, containment, recovery, and communication timestamps

General service metrics can still exist. They are not the same as DDoS mitigation telemetry. A spike in CPU and a drop in successful requests prove workload impact, not the attack vector or the provider mitigation action.

This is why telemetry is a security capability rather than a dashboard luxury. Without it, the organization has less confidence in classification, escalation, post-incident analysis, and compliance evidence.

12. Convert shared responsibility into an operating model

The following RACI-like table is a study template, not a universal organization chart. Adapt it to the actual service model and team boundaries.

Activity	Microsoft	Platform or network team	Application team	SOC or operations
Operate Azure infrastructure mitigation	Responsible	Informed	Informed	Informed
Maintain public-endpoint inventory	Provides service information	Accountable and responsible	Consulted	Consulted
Design layer 7 and capacity controls	Provides platform capabilities	Consulted	Accountable and responsible	Consulted
Produce application health signals	Provides monitoring platform features	Consulted	Responsible	Accountable for alert workflow
Declare incident and customer impact	Provides support and service information	Consulted	Consulted	Accountable and responsible
Evaluate enhanced DDoS protection	Provides and operates the service	Accountable	Consulted	Consulted
Test recovery and degraded mode	Supports platform behavior	Consulted	Accountable and responsible	Participates and records timeline

The phrase “Microsoft owns DDoS” is therefore too broad. Microsoft owns the provider mitigation control. The customer still owns endpoint decisions, workload capacity, layer 7 behavior, monitoring, incident response, communication, and risk acceptance.

13. When should enhanced protection be evaluated?

The point of this article is not that every endpoint must immediately buy a tier. It is that reliance on the baseline must be an explicit risk decision rather than an inherited assumption.

Start an enhanced DDoS Protection evaluation when one or more of these conditions is material:

• a public workload has a strict availability or revenue objective;
• its tested failure point could be far below a shared platform threshold;
• responders require customer-specific network attack metrics, alerts, and reports;
• audit or regulatory obligations require mitigation evidence;
• the organization needs a defined escalation path to DDoS specialists;
• attack-driven scale-out or data-transfer cost is a business concern;
• several supported public IP resources need consistent coverage and governance;
• an earlier event could not be confidently classified; or
• application and network teams cannot agree who owns the remaining gap.

These are evaluation triggers, not a tier selection algorithm. DDoS IP Protection and DDoS Network Protection share core mitigation capabilities but differ in attachment, coverage, support, cost-protection, and commercial structure. As of this review, DDoS Rapid Response, cost protection, and the Application Gateway WAF discount are Network Protection benefits; they are not infrastructure-baseline or IP Protection benefits. Those current details will be verified in the next article instead of being frozen here.

14. A zero-cost endpoint tabletop

You can improve the protection claim without deploying a resource or generating attack traffic.

1. List every public hostname, including nonproduction and administrative names.
2. Trace DNS to the first Azure or third-party edge and then to the origin.
3. Mark customer-owned ARM public IPs separately from multitenant service endpoints.
4. Remove or create an owner for obsolete and bypass endpoints.
5. Label the L3/L4, L7, application, data, and dependency enforcement points.
6. Estimate which resource reaches saturation first under legitimate peak and abusive demand.
7. Record the normal range and alert for request success, latency, saturation, queue, dependency, and business transactions.
8. List which DDoS-specific statements cannot be proven with the baseline.
9. Assign an incident owner and a customer-communication trigger.
10. Record whether enhanced protection needs formal evaluation and why.

The deliverable is not a screenshot of an Azure blade. It is an endpoint-to-impact model in which every availability claim has an owner and an observable result.

Do not create a homemade DDoS test. Microsoft’s simulation policy restricts simulations to approved testing partners, customer-owned Azure-hosted targets, and public IPs protected by Azure DDoS Protection. A tabletop, ordinary authorized load test, and formal DDoS simulation are different activities with different risk and authorization requirements.

15. Build an evidence package that says what it cannot prove

A useful baseline assessment package contains:

• a sanitized public-endpoint inventory;
• a DNS, edge, and origin data-flow diagram;
• the official protection documentation for each service type and its review date;
• an L3/L4, L7, application, dependency, and recovery responsibility map;
• normal peak, tested capacity, and known dependency-limit assumptions;
• application availability, latency, error, saturation, and business-impact signals;
• a written gap for unavailable customer-specific DDoS telemetry;
• the incident owner, escalation path, and communication condition;
• the enhanced-protection evaluation decision and approver; and
• residual risk with a review date.

Use a claim ledger to prevent a diagram from becoming evidence by repetition.

Claim	Source or test	Expected result	Observed result	Limitation	Owner and review date
Endpoint inherits infrastructure protection	Current Microsoft documentation plus endpoint classification	Service falls within documented baseline	Documentation reviewed	Does not prove workload availability	Platform owner
Origin is reachable only through approved edge	Authorized positive and negative path test	Edge succeeds; direct origin fails	Record actual result	One test does not prove permanent configuration	Network owner
Booking remains usable at peak	Authorized load and journey test	SLI stays within objective	Record actual result	Not a DDoS simulation	Application owner
Incident can be declared without DDoS alert	Tabletop and alert drill	Application and business signals page the owner	Record timeline	Attack classification may remain uncertain	Operations owner

The limitation column is not an admission of poor work. It is what keeps a control statement honest and tells the next reviewer where to invest.

16. Replace five dangerous claims

Dangerous claim	Why it fails	Defensible replacement
“It is in Azure, so it is safe from DDoS.”	Infrastructure health and workload availability have different thresholds	“The endpoint inherits Azure’s infrastructure baseline; workload resilience is assessed separately.”
“The free baseline blocks every DDoS attack.”	It addresses common network-layer threats, not every application exhaustion path	“The baseline reduces provider network risk but does not replace L7 and capacity controls.”
“No alert means no attack.”	The built-in baseline provides no customer-specific DDoS alert	“We cannot infer absence of attack from an unavailable signal.”
“A WAF extends the baseline.”	A WAF adds a separate request-aware layer	“WAF and infrastructure protection cover different failure modes and must be verified independently.”
“Free protection has no value.”	Provider-scale mitigation is a meaningful inherited control	“It is a valuable platform baseline whose scope and evidence are narrower than enhanced protection.”

The best architecture statement contains four parts:

Provider control inherited
+ workload control implemented
+ evidence available
+ residual gap accepted or scheduled

17. Architecture review checklist

Terminology and scope

• “Basic Protection” is not described as a currently purchasable Azure DDoS tier.
• DDoS infrastructure protection is separated from IP Protection and Network Protection.
• Every public hostname and actual service boundary has been inventoried.
• Automatic baseline coverage and enhanced-tier support have not been treated as the same question.
• The official source and review date are recorded.

Availability and control layers

• Network-layer volume, protocol state, and application-layer exhaustion are distinguished.
• The lowest workload and dependency capacity limits are documented.
• Direct origin and legacy endpoint bypass paths are tested or marked unverified.
• Layer 7 controls, application load shedding, scaling, and recovery are owned.
• Business impact is measured through a real customer journey.

Observation and response

• The absence of customer-specific baseline DDoS telemetry and alerts is explicit.
• Application availability, latency, error, saturation, queue, dependency, and business signals have owners.
• No mitigation or attack claim is based on a guessed screenshot or missing alert.
• Incident declaration, escalation, communication, and recovery targets are documented.
• Enhanced protection triggers and the residual-risk approver are recorded.
• No unauthorized DDoS simulation is planned.

18. Self-review questions

1. What does Azure DDoS infrastructure protection protect, and who operates it?
2. Why can Azure remain healthy while one customer application becomes unavailable?
3. How can a workload failure threshold be lower than a platform mitigation threshold?
4. Why can valid HTTPS searches exhaust an application without being a network-layer flood?
5. Why are “hosted on Azure” and “supported by a configurable DDoS tier” different claims?
6. Why can the absence of a baseline DDoS alert not prove that no attack occurred?
7. Which application and business signals must exist when DDoS-specific telemetry does not?
8. What is the first resource likely to saturate in your workload?
9. Which availability, evidence, response, or cost requirement would trigger an enhanced-tier review?
10. What must be verified in the next IP Protection versus Network Protection comparison?

If an answer ends with “Azure handles it,” add the missing endpoint, threshold, signal, owner, and residual risk.

19. One-page memory card

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

The memory line is:

Azure’s built-in DDoS infrastructure protection is an important provider baseline, but it does not design the customer’s application capacity, telemetry, layer 7 defense, or incident response.

The next Module 1 note will compare DDoS IP Protection and DDoS Network Protection against the gaps identified here. It remains planned until the bilingual article is complete, so no empty route is linked.

References

• Coursera: Azure Cybersecurity Solutions and Microsoft Defender
• Microsoft Learn: Azure DDoS Protection tier comparison
• Microsoft Learn: Azure DDoS Protection overview
• Microsoft Learn: Azure DDoS Protection FAQ
• Microsoft Learn: Azure DDoS Protection features
• Microsoft Learn: Azure DDoS Protection fundamental best practices
• Microsoft Learn: Secure your Azure DDoS Protection deployment
• Microsoft Learn: Azure DDoS Protection reference architectures
• Microsoft Learn: Reliability in Azure DDoS Protection
• Microsoft Learn: Azure DDoS Protection simulation testing
• Microsoft Learn: Public IP addresses and the retired Basic SKU
• Microsoft Learn: Shared responsibility in the cloud
• Microsoft Learn: Monitor Azure DDoS Protection