Azure DDoS IP Protection vs. Network Protection: Choose by Scope, Operations, and Cost

DDoS IP Protection is not simply a “small” version of DDoS Network Protection, and Network Protection is not automatically the correct enterprise answer. Both tiers share the core job of monitoring a supported Azure public IP and mitigating Layer 3 and Layer 4 attacks. The important differences are what you attach protection to, how broadly it follows the architecture, how you pay, and which response and financial benefits you need.

A beginner-friendly analogy is insurance for buildings. IP Protection is like insuring one named storefront. Network Protection is like placing the eligible storefronts across a managed campus under one plan. The alarm and emergency controls inside each protected storefront can be comparable, but the contract boundary, included support, and economics are different. Counting buildings alone is not enough; you must also ask which buildings matter, how the campus will grow, and who must help during a serious incident.

This is the third 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 full security map. The preceding DDoS infrastructure protection note explains why Azure’s automatic provider baseline is not the same as customer-specific DDoS readiness. This article begins after that gap assessment and asks which enhanced tier fits the workload.

These are independent study notes, not a transcript, assessment answer, purchasing recommendation, deployment record, or attack-test report. Product capabilities, limitations, and current pricing guidance were reviewed against official Microsoft sources on August 11, 2026. Prices and commercial terms can change, so a real decision must be recalculated for the relevant region, currency, agreement, and review date.

1. The question this article answers

After deciding that a workload needs enhanced Azure DDoS Protection, should the team protect selected public IP addresses individually or associate the workload’s virtual networks with a DDoS protection plan?

By the end, you should be able to:

explain the difference between a public IP, a virtual network, and a DDoS protection plan;
verify whether the endpoint is eligible before comparing prices;
describe the important protection and telemetry features shared by both tiers;
identify the Network Protection-only benefits without calling IP Protection “weak”;
estimate cost using a resource inventory instead of guessing from the number of virtual machines;
choose a tier with a repeatable decision workflow;
plan a safe tier transition; and
record what the decision proves, what it does not prove, and when it must be reviewed again.

This article does not repeat the detailed boundary of the built-in infrastructure baseline. It does not provide portal, CLI, PowerShell, Bicep, or Terraform deployment steps. It also does not compare DDoS Protection in full with network security groups (NSGs), Azure Firewall, or a web application firewall (WAF); that is a later Module 1 topic.

The decision starts with this sequence:

Need for enhanced protection confirmed
→ Endpoint is eligible
→ Protection scope is inventoried
→ Operational benefits are classified
→ Current and future cost is estimated
→ Tier is selected and recorded
→ Telemetry and response are validated

2. Bring four inputs from the previous assessment

Do not open a pricing page before understanding the workload. Bring four inputs from the earlier DDoS baseline assessment.

Input	Beginner question	Example answer
Public endpoint inventory	Which Azure public IP actually receives internet traffic?	One Standard public IP on an Application Gateway
Availability objective	What outage or degradation can the business tolerate?	Checkout must recover within 15 minutes
Operations requirement	Which signals, responders, and escalation path are required?	Alert the on-call team and retain mitigation logs
Cost-risk requirement	Does the organization require help with attack-related scale cost or specialist response?	DDoS Rapid Response (DRR) and cost protection are contractual requirements

These inputs prevent two common mistakes:

choosing IP Protection only because the current resource count is small; and
choosing Network Protection only because its name sounds broader or more mature.

The output of this article should be a decision record, not a product preference:

We selected <tier>
for <eligible endpoints and VNets>
because <scope, operations, and cost reasons>.
We will review the decision when <measurable trigger> occurs.

3. Learn the five nouns before comparing the tiers

Public IP address

An Azure public IP address is the internet-routable address associated with a supported resource such as a load balancer, Application Gateway, Azure Firewall, Azure Bastion, VPN Gateway, or a VM network interface. It is the protected resource counted in DDoS planning—not a DNS name and not automatically every backend server.

Protected resource

A protected resource is an eligible Azure public IP that is actually covered by IP Protection or by Network Protection through its VNet. “The subscription has DDoS Protection somewhere” does not prove that a particular endpoint is protected.

Virtual network

An Azure virtual network, or VNet, is the private network boundary in which subnets and supported resources are placed. Network Protection is enabled by associating a VNet with a DDoS protection plan. Eligible public IP resources in that VNet then receive protection.

DDoS protection plan

A DDoS protection plan is the management and billing resource used by Network Protection. According to the Azure DDoS Protection overview, one plan in a tenant can be used across multiple subscriptions. The plan can therefore provide a consistent boundary across several VNets, subscriptions, and regions while billing is associated with the plan’s subscription.

Tier

Azure currently documents two configurable enhanced tiers: DDoS IP Protection and DDoS Network Protection. The automatic no-additional-cost baseline is called DDoS infrastructure protection; it is not a third configurable tier in this comparison.

4. Pass the eligibility gate first

A tier cannot protect an unsupported endpoint merely because the organization pays for it. Before comparing features, answer these questions for every public endpoint.

Is the resource deployed through Azure Resource Manager rather than a classic deployment?
Is there an Azure public IP attached to a supported resource?
For IP Protection, is the public IP a Standard SKU public IP?
Is the public IP attached to a NAT Gateway, which the current tier comparison lists as unsupported?
Is the endpoint a supported VNet-integrated resource rather than a multitenant platform as a service (PaaS) virtual IP (VIP) outside the supported models?
Is a public IP prefix attached to a public load balancer frontend? The current comparison lists that scenario under Network Protection support.
Is the team assuming that a domain name, Front Door endpoint, or external endpoint is protected merely because its backend is in Azure?

Microsoft’s current tier comparison lists shared limitations including NAT Gateway public IPs, classic VMs, Azure Virtual WAN, and unsupported multitenant PaaS models. It also states that IP Protection does not support Basic SKU public IPs.

Basic SKU public IPs retired on September 30, 2025. A new architecture should use Standard public IP resources and should not select Network Protection merely to preserve a retired design. Inventory and modernize the endpoint first.

Use an explicit eligibility result:

Endpoint	Resource type	Public IP SKU	VNet	Eligible model?	Evidence owner
`pip-checkout-prod`	Application Gateway WAF_v2	Standard	`vnet-prod-edge`	Pending review	Network team
`pip-admin-test`	Single VM NIC	Standard	`vnet-test`	Supported but architecture not recommended	Platform team
`pip-egress-prod`	NAT Gateway	Standard	`vnet-prod-app`	Not supported by these tiers	Network team

This table is more useful than saying “we have three public IPs.” One of those IPs might not be an eligible inbound application endpoint at all.

The most important correction is this:

IP Protection is not a telemetry-free or manually tuned edition of Network Protection.

Microsoft’s tier comparison lists the following capabilities for both tiers:

active traffic monitoring and always-on detection;
automatic Layer 3 and Layer 4 attack mitigation;
mitigation policies tuned to the protected application and public IP;
metrics and alerts;
mitigation reports and mitigation flow logs;
integration with Azure Firewall Manager; and
Microsoft Sentinel connector and workbook integration.

The DDoS Protection overview explains that Azure learns traffic patterns and applies auto-tuned TCP SYN, TCP, and UDP mitigation policies per protected public IP. Mitigation begins when the traffic profile crosses the relevant threshold. Auto-tuning is the default. As of this review, Microsoft also offers custom detection thresholds in preview for Standard Load Balancer frontend IPs; setting a fixed TCP, UDP, or TCP SYN threshold disables auto-tuning only for that protocol.

This shared core changes the decision. The question is not:

Do we want real protection or a weak version?

It is:

Do we want the shared core attached to selected IPs,
or governed across VNets with additional response and financial benefits?

6. The attachment model is the clearest difference

IP Protection: attach protection to one public IP

IP Protection is enabled directly on an eligible public IP. No DDoS protection plan is required. Billing follows each protected public IP.

Public IP A ── IP Protection enabled
Public IP B ── not enabled
Public IP C ── IP Protection enabled

This model can be easy to understand for a small workload with a few stable, important endpoints. It is also easy to leave a new IP unprotected if creation, inventory, policy, and review processes are weak.

Network Protection: attach a plan to the VNet

Network Protection uses a DDoS protection plan associated with one or more VNets. Supported public IP resources in the associated VNets are protected.

DDoS protection plan
├─ VNet A
│  ├─ eligible Public IP A ── protected
│  └─ eligible Public IP B ── protected
└─ VNet B in another subscription
   └─ eligible Public IP C ── protected

This model aligns well with shared platform governance: associate the intended VNets, inventory protected resources centrally, and review exceptions. It still does not mean “every resource in the tenant is protected.” A VNet not associated with the plan, an unsupported resource model, or an endpoint outside that VNet remains outside the claimed scope.

7. The comparison table that matters

Decision axis	DDoS IP Protection	DDoS Network Protection
Attachment	Individual eligible public IP	DDoS plan associated with VNet
Core L3/L4 monitoring and mitigation	Yes	Yes
Adaptive per-public-IP policies	Yes	Yes
Metrics, alerts, reports, flow logs	Yes	Yes
Standard public IP support	Yes	Yes
Basic public IP support	No	Listed as supported, but Basic public IP SKU is retired
Billing model	Per protected public IP	Fixed plan charge including a protected-resource allowance, then overage
DDoS Rapid Response	Not included	Included
Attack-related cost protection	Not included	Included under current terms and evidence requirements
Application Gateway WAF pricing benefit	Not included	Included when current eligibility conditions are met
Typical starting fit	A small, explicit set of stable public IPs	Multiple VNets/endpoints or a need for plan-level benefits and governance

“Typical starting fit” is not an eligibility rule. One critical endpoint might justify Network Protection because DRR is mandatory. Twenty temporary public IPs might instead indicate that the architecture should reduce public exposure before buying either tier.

8. Compare cost as a model, not as a memorized price

Azure prices vary by agreement, region, currency, and date. Record the model and calculation date rather than copying a price into an architecture diagram.

IP Protection cost model

Estimated IP Protection cost
= current per-IP rate
× protected eligible public IP count
× active billing period

The count must include the actual public IP resources that need protection—not only applications or VNets. A single application can have separate public IPs for Application Gateway, Azure Firewall, Bastion, and other supported entry points.

Network Protection cost model

Estimated Network Protection cost
= current plan charge
+ overage for protected resources above the included allowance
- eligible Application Gateway WAF pricing benefit
+ operational costs for monitoring, response, and governance

Microsoft’s current pricing page states that a Network Protection plan includes protection for up to 100 public IP resources, with additional resources charged separately. The same plan can be linked to multiple VNets across subscriptions in the tenant.

The current DDoS Protection FAQ offers a useful pricing heuristic: IP Protection is generally more cost-effective below 15 protected public IP resources, while Network Protection becomes more cost-effective above 15. The FAQ does not assign exactly 15 resources to either side, so calculate both options at that boundary. Treat the guidance as a dated starting point, not a permanent architecture law. Recalculate because:

negotiated pricing or currency can change the comparison;
the number of public IPs can grow;
Network Protection’s WAF benefit can materially change total cost;
DRR and cost protection can have business value even below the numerical crossover; and
the better design might remove unnecessary public IPs.

Use three counts in the decision record:

Count	Why it matters
Eligible public IPs today	Current bill and current protection scope
Expected eligible public IPs in 12–24 months	Migration and budget trigger
Public IPs that should be removed	Attack-surface reduction before purchase

9. Understand the three Network Protection-only benefits

9.1 DDoS Rapid Response

The DDoS Protection overview states that Network Protection customers can engage Microsoft’s DDoS Rapid Response team during an active attack for investigation assistance and post-attack analysis.

DRR is valuable only when the organization can use it. Document:

who is authorized to open the request;
which support prerequisites and contacts are current;
who supplies the affected public IP, timeline, metrics, and business impact;
who coordinates application, network, security, and communications teams; and
how recommendations are captured after the incident.

Buying access without an escalation runbook leaves a paper benefit rather than an operating capability.

9.2 Cost protection

Network Protection includes current cost-protection benefits for eligible resource scale-out and data-transfer costs caused by a documented DDoS attack. This is not permission to run without budgets, autoscale limits, or application safeguards. It is also not an automatic refund for every expensive traffic spike.

Before relying on it, record:

the current Microsoft terms and eligible cost categories;
the evidence needed to show that a documented DDoS attack caused the cost;
the billing and support owners;
the claim or credit process; and
costs that remain outside the benefit.

9.3 Application Gateway WAF pricing benefit

Microsoft’s current pricing guidance describes a benefit when Application Gateway with WAF is deployed in a VNet protected by Network Protection: the WAF is billed at the lower non-WAF Application Gateway rate under the documented conditions.

Do not shorten this into “Network Protection makes every WAF free.” Verify the exact WAF product, SKU, VNet relationship, agreement, and current terms. Azure Front Door WAF, third-party WAFs, and unrelated security services should not be assumed to receive the same benefit.

10. Scenario A: a small public API with two stable endpoints

Consider a small company operating:

one production Application Gateway public IP;
one nonproduction public IP used only during scheduled testing;
no mandatory DRR requirement;
no current cost-protection requirement; and
a plan to keep the public endpoint count below five for the next year.

After confirming eligibility, IP Protection can be a reasonable starting candidate for the production IP. The team should still decide whether the test endpoint needs equivalent protection or should be private and enabled only temporarily.

The decision is not complete until the team implements:

an inventory rule that detects a newly created public IP;
Azure Monitor alerts and diagnostic settings;
an application availability alert independent of DDoS metrics;
a named incident owner; and
a review trigger if the endpoint count or business criticality grows.

The weak statement is “we chose IP Protection because we are small.” The useful statement is:

We chose per-IP protection for one eligible production endpoint because the protected count is stable, the shared mitigation and telemetry meet the current requirement, and DRR, cost protection, and the Network Protection WAF benefit are not current requirements. We will reassess at five public IPs, a new regulated workload, or a DRR requirement.

11. Scenario B: a shared platform across subscriptions

Now consider an organization with:

production VNets in several subscriptions and regions;
Application Gateway WAF and Azure Firewall public IPs;
teams that create and retire endpoints over time;
a central network operations team;
an incident process that requires Microsoft specialist escalation; and
a finance requirement to review attack-related scale costs.

Network Protection is the stronger candidate even before the public IP count reaches a pricing crossover. The plan aligns with the governance boundary, DRR is operationally relevant, and the WAF and cost-protection benefits affect total value.

The organization still needs controls around the plan:

approved VNets must be associated;
newly created VNets must not escape the process;
protected resources and unsupported exceptions must be inventoried;
diagnostic settings and alerts must be standardized; and
the subscription paying for the plan and overage must be agreed.

“One tenant has one plan” is not evidence of complete coverage. The evidence is the plan-to-VNet association plus the eligible public IP inventory.

12. Numbers alone can produce the wrong answer

Fewer than 15 IPs can still favor Network Protection

Network Protection can be justified with a small endpoint count when DRR is required, attack-related cost risk is material, or the Application Gateway WAF benefit changes the total cost.

More than 15 IPs can expose an architecture problem

A large public IP count can make Network Protection economically attractive, but first ask why every endpoint is public. Private endpoints, private administration, centralized ingress, or retiring unused resources might reduce both risk and cost.

One public IP can hide a large business risk

One Application Gateway IP can front a high-value service. Resource count does not measure revenue impact, regulatory consequence, recovery complexity, or customer trust.

A plan can hide gaps

A Network Protection plan can exist while a new VNet is not associated, a resource model is unsupported, or the application has no Layer 7 protection. Plan existence is not the same as service resilience.

13. Use this seven-step selection workflow

Step 1: reduce public exposure

Remove unused public IPs and prefer private access for administration and internal services. The safest public endpoint is often the one the workload does not need.

Step 2: inventory eligible public IP resources

Record resource type, SKU, VNet, subscription, region, owner, environment, business service, and expected lifetime.

Step 3: classify business and operational requirements

Mark DRR, cost protection, WAF benefit, centralized governance, evidence retention, and incident support as required, preferred, or not required.

Step 4: calculate both cost models

Use current Azure pricing for today’s count and at least one growth scenario. Include overage and eligible WAF impact. Record the date, currency, region, and agreement assumptions.

Step 5: choose the attachment boundary

Decide whether protection should follow named individual IPs or governed VNets. Include the process for new resources and exceptions.

Step 6: design monitoring and response before enablement

Define DDoS alerts, diagnostic destinations, application health signals, incident owner, escalation path, retention, and review cadence.

Step 7: approve residual risk and review triggers

State what the tier does not solve and name the approver. Set measurable triggers for reconsidering the decision.

14. Write a tier decision record

A short decision record prevents the reasoning from disappearing after the portal change.

Decision: DDoS IP Protection | DDoS Network Protection | Redesign first
Review date: YYYY-MM-DD

Workload and availability objective:
Eligible public IP inventory:
Selected attachment boundary:
Current / 12-month / 24-month resource counts:
Pricing source, region, currency, and agreement:
DRR requirement:
Cost-protection requirement:
Application Gateway WAF benefit assessment:
Monitoring and incident owner:
Unsupported or excluded endpoints:
Residual Layer 7 and application-capacity risks:
Reassessment triggers:
Approver:

Attach evidence rather than screenshots alone:

machine-readable public IP inventory;
VNet-to-plan association export or per-IP protection-state export;
calculation worksheet and pricing source;
Azure Monitor alert and diagnostic-setting definitions;
incident and DRR runbook where applicable;
exception register; and
the approval record.

A portal screenshot can help a reviewer, but it becomes stale and cannot prove that every intended endpoint remains covered.

15. Plan tier changes without a protection gap

Architecture grows, so the first tier does not have to be permanent. Microsoft documents a supported tier-switching process.

Move from IP Protection to Network Protection

Associate the relevant VNet with the DDoS protection plan. Microsoft states that protected services transition automatically from IP Protection to Network Protection; IP Protection does not need to be disabled first for that transition.

Validation should still confirm:

the correct VNet is associated;
each intended public IP reports the expected protection status;
alerts and diagnostic destinations remain correct;
billing ownership changed as expected; and
the decision record and inventory were updated.

Move from Network Protection to IP Protection

Enable IP Protection on every intended eligible public IP before dissociating the VNet from Network Protection. Microsoft warns that this order is required to avoid a DDoS protection gap.

Do not assume that every previously covered endpoint can move. Recheck Standard public IP eligibility and current limitations. After the transition, verify protection state per public IP and remove the plan association only when evidence is complete.

16. Validate operations, not only the protection toggle

Both tiers expose DDoS telemetry, but telemetry creates value only when someone receives and interprets it.

At minimum, validate:

Protection status: each intended public IP reports the selected tier;
Attack signal: an alert exists for the Under DDoS attack or not metric;
Traffic thresholds: the team knows where to view the default auto-tuned TCP SYN, TCP, and UDP thresholds and, for a supported Standard Load Balancer frontend IP, whether a custom preview threshold has disabled auto-tuning for a protocol;
Diagnostics: mitigation reports and flow logs go to an approved destination;
Retention: evidence is retained for the incident and compliance requirement;
Application health: latency, errors, saturation, and dependency health are monitored separately; and
Ownership: on-call, network, security, application, support, finance, and communications roles are named.

The Azure DDoS Protection features page notes that Azure Monitor metric data for DDoS Protection is retained for 30 days. If the organization needs longer evidence retention, export and retention must be designed; the default metric window is not an archive strategy.

Do not generate DDoS traffic yourself. Azure documents simulations through approved testing partners, with authorization and safeguards. This article does not perform or instruct an attack simulation.

17. What neither tier solves alone

Choosing the correct tier reduces network-layer availability risk. It does not complete the application architecture.

Residual risk	Additional design question
Layer 7 HTTP request floods	Is a WAF, edge rate limit, caching, bot control, or application throttle required?
Single-instance failure	Can the service scale or fail over before its smallest component is exhausted?
Database or dependency saturation	Are queues, timeouts, circuit breakers, and dependency quotas designed?
Public administration endpoint	Can Bastion, VPN, private access, or just-in-time (JIT) access remove or reduce exposure?
Cost exhaustion outside current benefit	Are budgets, limits, alerts, and finance escalation defined?
Incident confusion	Does the team have a practiced decision and communication path?

Azure DDoS Protection operates at Layers 3 and 4. Web Application Firewall and application controls address different Layer 7 behavior. Resilience, autoscale, failover, recovery objectives, and incident ownership remain customer responsibilities.

18. Current limitations worth placing in the design review

The exact support matrix changes, so link the current Microsoft page in the decision record. As of this review, important examples include:

public IP resources attached to NAT Gateway are not supported;
VMs that use the classic deployment model (RDFE/Azure Service Manager) are not supported;
Azure Virtual WAN and several multitenant platform as a service (PaaS) models are not supported;
VPN or virtual network gateways are protected through a DDoS policy, but adaptive tuning has a documented limitation;
public IP prefixes attached to a public load balancer frontend are documented for Network Protection;
IP Protection requires a Standard SKU public IP; and
a single VM directly behind a public IP is supported but not recommended because the VM can fail before mitigation fully protects application availability.

Do not memorize this list as permanent. Verify the current tier comparison when designing or reviewing the workload.

19. Replace seven misleading claims

Misleading claim	More accurate statement
“IP Protection is basic protection.”	IP Protection is a configurable enhanced tier with the shared core mitigation and telemetry, billed per eligible public IP.
“Network Protection has stronger packets.”	The major documented differences are attachment, pricing, DRR, cost protection, and WAF benefit; both tiers share core L3/L4 capabilities.
“We have fewer than 15 IPs, so IP Protection is mandatory.”	The current count is a pricing heuristic; operational requirements and growth can justify another decision.
“The plan protects the subscription.”	Network Protection applies through associated VNets to supported public IP resources, not automatically to every subscription resource.
“One protected frontend protects every risk.”	It protects an eligible network endpoint; Layer 7, backend capacity, dependencies, and recovery still need controls.
“Cost protection means attacks cannot create cost.”	Current eligible attack-related costs may qualify under documented terms and evidence requirements; budgets and limits remain necessary.
“We can switch tiers later with no planning.”	Switching is supported, but order, eligibility, telemetry, billing, and protection-state validation matter.

20. Architecture review checklist

Scope and eligibility

Every internet-facing endpoint is in the public IP inventory.
Resource type, Public IP SKU, VNet, subscription, region, and owner are recorded.
Unsupported resource models are identified rather than silently counted as protected.
Unnecessary public endpoints have an owner and removal plan.
The selected attachment boundary matches the real architecture.

Operations and support

DDoS metrics, alerts, reports, and flow logs have approved destinations.
Application health is monitored separately from DDoS telemetry.
Incident roles and escalation contacts are current.
If Network Protection is chosen, the DRR engagement procedure is documented.
Evidence retention exceeds the default metric window when required.

Cost and governance

Both pricing models were calculated from the same current inventory.
Region, currency, agreement, source URL, and calculation date are recorded.
Current, 12-month, and 24-month endpoint counts were considered.
WAF benefit and cost-protection assumptions were verified rather than guessed.
The paying subscription, budget owner, overage owner, and exception owner are named.

Lifecycle

New public IP and VNet creation can trigger a coverage review.
Protection status is checked automatically or on a defined cadence.
Tier-switching order is documented.
Reassessment triggers are measurable.
Residual Layer 7, resilience, and recovery risks have an approver.

21. Self-review questions

Why is IP Protection not merely a weaker mitigation engine?
What resource do you attach IP Protection to?
What connects a VNet to Network Protection?
Does a DDoS plan automatically protect every resource in the tenant?
Which telemetry capabilities are available in both tiers?
Which three important benefits are documented only for Network Protection?
Why is the current 15-public-IP guidance—including its unspecified exactly-15 boundary—a heuristic rather than a permanent rule?
How can an Application Gateway WAF change the total-cost comparison?
Why should unsupported and unnecessary public IPs be separated from eligible protected IPs?
What order avoids a protection gap when moving from Network Protection to IP Protection?
Which application risks remain after choosing either tier?
What evidence would prove that the intended endpoint—not merely some VNet or plan—is protected?

If an answer begins with “Network is better” or “IP is cheaper,” add the missing scope, eligibility, operations, pricing date, and residual risk.

22. One-page memory card

DDoS IP Protection
→ attach to one eligible Standard public IP
→ shared core L3/L4 mitigation and telemetry
→ pay per protected IP
→ no DRR, cost protection, or Network-tier WAF benefit

DDoS Network Protection
→ attach a plan to one or more VNets
→ protect supported public IPs in those VNets
→ shared core L3/L4 mitigation and telemetry
→ plan pricing with included resource allowance and overage
→ DRR + cost protection + eligible Application Gateway WAF benefit

Choose with:
Eligibility → Scope → Operations → Cost → Growth → Evidence

The memory line is:

Choose IP Protection or Network Protection by the boundary you must govern and the operating benefits you require—not by assuming that one has “real” mitigation and the other does not.

The next Module 1 note will ask a more fundamental exposure question: how should an Azure VM be designed when it does not need a public IP at all? It remains planned until the complete English and Korean article pair is ready; no empty route is linked.