Secure an Azure VM Without a Public IP: Separate Management, Inbound, and Outbound Paths

Removing a public IP address from an Azure virtual machine is one of the clearest ways to reduce its directly reachable attack surface. It closes the simplest internet-to-VM route, makes broad scans less useful, and encourages administrators to use a controlled path. It is an important design decision—but it is not a complete security architecture.

A private VM may still need four very different kinds of connectivity:

1. an administrator needs to reach the guest operating system;
2. users may need to reach an application running on the VM;
3. the VM may need outbound access for updates, repositories, APIs, or activation; and
4. the VM may need private access to Azure services such as Storage or Key Vault.

If these flows are treated as one vague requirement called “network access,” teams either expose too much or break necessary operations. The safer approach is to design, authorize, route, observe, and test each path independently.

This is the fourth detailed note in the 12-topic Module 1 study plan for Coursera’s Azure Cybersecurity Solutions and Microsoft Defender course. The Module 1 review gives the wider security map, and the preceding DDoS tier selection note covers protection for public endpoints. This article asks an earlier architectural question: does the VM itself need to be a public endpoint at all?

These are independent study notes, not a transcript, assessment answer, production deployment record, or substitute for a workload-specific threat model. Product behavior and limitations were reviewed against official Microsoft documentation on August 11, 2026.

Explicitly out of scope

This article explains architecture and verification, not click-by-click deployment. It does not provide complete Bastion, VPN, ExpressRoute, Firewall, or Private Endpoint deployment commands; WAF rule tuning; operating-system hardening benchmarks; infrastructure-as-code modules; or workload-specific cost estimates. Those decisions require the real region, topology, identity model, availability objective, and change process.

1. The target state, stated precisely

The weak goal is:

The VM has no public IP.

The useful goal is:

The VM NIC has no public IP.
Guest administration uses an approved, identity-aware path.
Application inbound traffic uses only an approved frontend, if required.
Internet outbound traffic uses an explicit, observable egress path.
Supported Azure services use private endpoints where justified.
Every allowed and denied path has an owner, evidence, and a test.

This distinction matters because “no VM public IP” does not necessarily mean “the workload is private.” A public Application Gateway, Load Balancer, reverse proxy, or Azure Firewall destination NAT rule can still deliver internet traffic to a VM’s private IP. That may be exactly the right architecture for a public website: the edge is public, while the backend VM is private. The security review must name the public edge instead of claiming that the whole workload has disappeared from the internet.

The memory line for this article is:

A VM without a public IP is a smaller target, not a finished security architecture.

2. Learn the basic nouns before selecting products

Network interface and IP configuration

An Azure VM connects to a virtual network through a network interface (NIC). An IP configuration on the NIC has a private IP address and can optionally reference a public IP resource. Removing that public IP reference prevents direct addressing of the NIC from the internet. It does not remove the private IP, the NIC, or every route the VM can use.

Virtual network and subnet

A virtual network (VNet) is the private address space. A subnet is a range within that VNet where NICs or platform resources are placed. The subnet is also a useful policy boundary: route tables, network security groups (NSGs), NAT Gateway, and some service delegations operate at subnet scope.

Route

A route answers where should a packet go next? Azure combines system routes, user-defined routes, and routes propagated from connected networks. A route does not identify a human user, authenticate the guest OS, or decide whether an application is safe.

Network security group

An NSG answers is this network flow allowed or denied? It contains stateful inbound and outbound rules evaluated by priority. An NSG does not create reachability, translate private addresses into public addresses, or resolve DNS names.

DNS

DNS answers which address should this name resolve to? For private endpoints, correct private DNS resolution is often what makes an application select the private address. DNS does not authorize the resulting connection; routing, network controls, service policy, identity, and application authorization still apply.

These three sentences prevent many troubleshooting mistakes:

DNS selects an address.
Routing selects a next hop.
An NSG permits or denies the flow.

3. Separate the control plane from four data paths

Azure resource management and guest operating-system access are not the same path. A user can be allowed to start or stop a VM through Azure Resource Manager and still be unable to sign in to Windows or Linux. Conversely, a local OS account might sign in through an exposed protocol even if it has no Azure subscription role.

Use this map during design reviews:

Azure resource management
Admin → Microsoft Entra ID / Azure RBAC → Azure Resource Manager → VM resource

Guest administration
Admin → Bastion or private connected network → VM private IP → RDP / SSH

Application inbound
Internet user → approved public edge / WAF → VM private IP → application port

Internet outbound
VM private IP → NAT Gateway or Azure Firewall → internet dependency

Azure service access
VM private IP → Private Endpoint + private DNS → supported Azure service

For each arrow, ask five questions:

1. Purpose: Which business or operational task requires this flow?
2. Identity: Who or what is allowed to initiate it?
3. Network path: Through which source, destination, port, route, and control does it travel?
4. Evidence: Which logs, effective configuration, and test prove that it works as designed?
5. Failure behavior: What breaks if the path is denied, unavailable, or misconfigured?

4. Build a flow inventory before changing the NIC

Do not remove a public IP and then wait for incident reports to reveal dependencies. Create a small flow inventory first.

Flow	Source	Destination	Port or protocol	Approved path	Owner	Failure impact
Windows administration	Named operations group	Private VM	TCP 3389	Azure Bastion	Platform team	Delayed incident response
Linux administration	Named operations group	Private VM	TCP 22	VPN and hub firewall	Platform team	Delayed incident response
Public web request	Internet user	Web application	HTTPS 443	WAF frontend to private backend	App team	Customer outage
OS updates	Private VM	Configured Windows Update, WSUS, or Linux repository	Repository-specific, commonly TCP 80/443	Approved firewall or private repository path	Platform team	Patch delay
Package retrieval	Private VM	Approved repository	HTTPS 443	NAT Gateway or firewall	App team	Deployment failure
Secret retrieval	Workload identity	Key Vault	HTTPS 443	Private Endpoint	Security team	Application startup failure
Monitoring	Agent or guest	Monitoring endpoints	HTTPS 443	Explicit egress	Observability team	Missing telemetry

“Internet access required” is not a usable row. Record the actual dependency, direction, owner, and consequence. If the destination cannot be enumerated, record how it will be governed—for example, by an Azure Firewall application rule using approved fully qualified domain names (FQDNs)—and who reviews changes.

5. What removing the VM public IP changes

Removing the public IP from the VM NIC gives a meaningful benefit:

• there is no longer a public address directly mapped to that NIC;
• an internet scanner cannot initiate RDP, SSH, or an application flow directly to that NIC public address;
• operations must use a separate path such as Bastion, VPN, ExpressRoute, or another controlled network; and
• the public entry point, if any, can be concentrated at an edge designed for that purpose.

It does not automatically do the following:

• remove an application frontend that forwards to the VM;
• block outbound internet access;
• create a secure administrative path;
• correct permissive NSG rules;
• patch, harden, or monitor the guest OS;
• replace identity and least-privilege controls;
• make Azure service traffic private; or
• prove that DNS and routes follow the intended path.

Also distinguish configuration from completion. Adding an explicit outbound method does not by itself remove an allocated default outbound IP if the subnet remains nonprivate. To remove it completely, set defaultOutboundAccess=false on the subnet and stop and deallocate the affected VMs. Validate the observed state rather than assuming that editing one property immediately removes every old behavior.

6. Current Azure outbound behavior: avoid an outdated shortcut

For years, a VM without an explicitly configured outbound method could receive default outbound access through a Microsoft-owned public address. That behavior is implicit, can change, and is unsuitable when production systems need a stable address or deliberate control.

For subnet resources created as part of a new VNet by API versions released after March 31, 2026—currently Microsoft.Network/virtualNetworks@2025-07-01—Azure sets defaultOutboundAccess=false by default. Existing VNets are not automatically converted, and older API versions can leave the property null, which implicitly permits default outbound access. Therefore, neither of these statements is safe:

“Every new Azure VM automatically has outbound internet.”
“After September 2025, every new Azure VM lost outbound internet.”

Inspect the actual subnet’s defaultOutboundAccess state, effective routes, NIC configuration, and explicit outbound resource. A private subnet means VMs do not receive default outbound access; it does not prevent you from adding NAT Gateway, Azure Firewall, another network virtual appliance, or another supported explicit egress method.

The design rule is simpler than the history:

Production outbound connectivity should be explicit, intentional, and observable.

Without a valid egress path, Windows activation and updates, Linux package repositories, monitoring agents, certificate checks, external APIs, or your own deployment process may fail. “Private” should not mean “we discover dependencies during the next patch window.”

7. Choose the application inbound path separately

First ask whether the workload serves internet users.

No public application

For a management server, batch worker, internal API, or domain service, there may be no reason for public application inbound traffic. Keep the VM on a private subnet and expose the service only to approved VNet, peered VNet, VPN, or ExpressRoute sources. Use NSGs and firewall policy to restrict the actual source and port.

Public web application

A public website still needs a public edge. Put the public address on an approved frontend such as Application Gateway with WAF or another suitable load-balancing and protection service, then send only the required backend port to the VM private IP.

Internet
  ↓ HTTPS 443
Public edge with TLS/WAF policy
  ↓ approved backend flow only
Private VM application port

The backend NSG should allow the required frontend source and port, not Internet → Any. Administration should not reuse the application path. DDoS protection, WAF policy, certificates, health probes, backend authentication where supported, and application logs remain separate review items.

Private application published to partners or employees

Use private connectivity, an identity-aware application access pattern, or an approved private ingress service according to the requirement. Do not add a VM public IP merely because one remote user needs access. That changes a user-access problem into a permanently exposed network endpoint.

8. Choose a guest-administration path

The common choices solve different connectivity problems.

Option	How the operator reaches the VM	Best fit	Important boundary
Azure Bastion	Browser or native client through managed Bastion to the VM private IP	Azure-hosted administration without a VM public IP	Target NSG and guest authentication still apply
Point-to-site VPN	Operator device joins an approved private network path	Individual administrators and remote staff	Device, identity, routes, DNS, and VPN operations matter
Site-to-site VPN	On-premises network connects to Azure	Offices or datacenters with established network controls	Redundancy, routing, and source scope matter
ExpressRoute	Private circuit connects organizational networks to Azure	Enterprise private connectivity and predictable network integration	It is not internet encryption by itself and needs resilient design
Jump host	Operator reaches a hardened intermediary first	Legacy or specialized workflows	You own patching, hardening, credentials, availability, and logs
Run Command / Serial Console	Azure control and platform paths run a command or provide emergency console access	Diagnosis and break-glass recovery	Not a replacement for routine interactive administration

Choose one primary path and one tested recovery path. A list of several possible tools without ownership is not resilience.

9. What Azure Bastion does—and does not do

Azure Bastion is a managed platform service for RDP and SSH connectivity to VMs over their private IP addresses. The user connects to Bastion over TLS, commonly through port 443, and Bastion connects to the target VM. The target VM needs no public IP, no Bastion agent, and no special client for the portal-based experience.

That does not mean the target VM accepts no RDP or SSH. Its NSG must still permit the required management port from the correct Bastion source, commonly the dedicated AzureBastionSubnet, while denying unapproved sources. The guest OS firewall and RDP/SSH service must also allow the connection.

Dedicated Basic, Standard, and Premium Bastion deployments use an AzureBastionSubnet of /26 or larger; a regular deployment has its own Standard public IP even though the target VM does not. Premium supports a private-only deployment for organizations that require Bastion itself to have no public IP, but this must be selected at creation and requires an existing private path such as VPN or ExpressRoute for the operator. End-to-end private connectivity uses the native client. A regular Bastion deployment cannot simply be converted in place to private-only.

Bastion is an administration transport. It does not:

• grant permission to the Azure resource;
• authenticate a user inside Windows or Linux by itself;
• provide the VM’s outbound internet path;
• patch or harden the guest;
• replace an application load balancer or WAF; or
• make an overly broad target NSG acceptable.

Finally, Bastion billing starts while the deployment exists, not only while an RDP or SSH tab is open. Include deployment tier, scale, private-only requirement, native-client requirement, logging, and operating cost in the design.

10. Treat Azure permission and guest sign-in as two locks

An administrator normally passes two authorization boundaries:

Lock 1: May this identity operate the Azure VM resource?
Lock 2: May this identity sign in to the guest operating system?

Azure RBAC roles such as Owner or Contributor authorize management actions on resources. They do not automatically make the user a Windows or Linux administrator inside every VM. Microsoft Entra sign-in for Azure VMs uses dedicated roles such as Virtual Machine Administrator Login or Virtual Machine User Login, together with the required guest extension and configuration. Local or domain accounts have their own lifecycle and policy.

Prefer named identities, multifactor authentication, conditional access where supported, least-privilege Azure roles, separate admin accounts where required, and time-bound elevation through Privileged Identity Management. Avoid shared local administrator credentials. Record both the Azure authorization evidence and the guest authorization evidence.

11. Bastion and just-in-time access answer different questions

Azure Bastion answers:

Through which controlled transport can the administrator reach the private VM?

Just-in-time (JIT) VM access in Microsoft Defender for Cloud answers:

For which source, port, and limited duration should the management rule be opened?

JIT is available with Defender for Servers Plan 2. It can temporarily change NSG rules or a supported same-VNet Azure Firewall classic-rule configuration to allow a requested management connection. Azure Firewalls managed through Azure Firewall Manager or Azure Firewall Policy do not support JIT integration. JIT does not build a missing route, create a VPN, deploy Bastion, or authenticate the user inside the guest.

Bastion and JIT can be used together when the operational model benefits from both a controlled path and time-limited target access. If JIT is used, do not accept a convenient default such as source Any without review. Restrict the source, ports, duration, approvers, alerts, and exception behavior.

12. Choose explicit outbound: NAT Gateway or Azure Firewall

Many private VMs still need outbound connectivity. Two common Azure services have different jobs.

NAT Gateway: predictable subnet egress

NAT Gateway provides source network address translation (SNAT) for outbound flows from a subnet. A VM can initiate internet connections through one or more explicit static public IP addresses or a public IP prefix without having a public IP on its NIC. Return traffic for an initiated flow is allowed; unsolicited inbound connections through NAT Gateway are not.

Use NAT Gateway when the principal requirements are:

• explicit and predictable outbound public addresses;
• scalable outbound SNAT for one or more subnets;
• destination allow-listing by external partners using a stable source IP; and
• no requirement for centralized application-aware destination policy at this hop.

NAT Gateway is not a firewall. It does not inspect destinations, apply FQDN application rules, or replace endpoint and application security. It normally needs no user-defined route for direct internet egress.

Azure Firewall: centralized policy and inspection

Azure Firewall is a managed, stateful network firewall. Depending on the selected SKU and design, it can apply network and application rules, threat intelligence controls, TLS inspection features, and centralized logging. Use it when the organization needs to govern where workloads may connect, not merely which public address performs translation.

A deployed firewall does not automatically inspect traffic. Workload subnet routes—often a 0.0.0.0/0 user-defined route—must direct the intended flow to the firewall as the next hop. Policies, DNS behavior, diagnostics, availability, capacity, and ownership must also be configured.

Do not combine them by accident

A default route to a virtual appliance or firewall overrides the subnet’s direct internet route, so traffic does not simply choose NAT Gateway because it is attached. In the documented combined design, the workload subnet route sends traffic to Azure Firewall and NAT Gateway is associated with AzureFirewallSubnet for firewall egress; attaching NAT Gateway only to the workload subnet does not place it automatically behind a 0.0.0.0/0 → VirtualAppliance route. If the services are combined, the topology and supported integration must be deliberate. Start from the required control outcome:

Requirement	Starting choice
Stable, scalable outbound IP with simple direct egress	NAT Gateway
Central destination allow/deny policy and inspection	Azure Firewall
No internet dependency	No internet egress; prove all required private dependencies
Hybrid centralized security appliance	Approved route through that appliance, with redundancy and evidence

13. Use Private Endpoint for supported Azure service dependencies

Azure Private Link is the private-connectivity technology. A Private Endpoint is the consumer-side network interface and private IP placed in your VNet to connect to a supported service. It can let the VM reach a specific Azure service instance, such as a Storage account or Key Vault, through a private address rather than that service’s public endpoint. Designing a provider-side Private Link Service is outside this article’s scope.

Three conditions must line up:

1. the correct Private Endpoint and service subresource exist;
2. the service name resolves to the Private Endpoint’s private IP from the VM’s DNS context; and
3. routes, NSGs where applicable, service configuration, and identity allow the connection.

Private DNS is not an optional afterthought. If myvault.vault.azure.net or a Storage FQDN still resolves to a public address from the VM, the application may follow the wrong path even though a Private Endpoint resource exists. Link the appropriate private DNS zone to the VNet or integrate it correctly with the organization’s DNS forwarders, then test the actual name from the workload.

Creating a Private Endpoint does not always disable the service’s public network access. Configure the target service’s public access or firewall settings separately, according to that service’s behavior. Some services also expose separate subresources—for example, Storage blob and file services may require distinct endpoints and DNS records.

Private Endpoint is not:

• a way for an administrator to RDP or SSH to the VM;
• general private access to every internet site;
• a replacement for workload identity and service authorization; or
• proof that the public endpoint has been disabled.

14. Make NSGs, routes, and DNS express the design

Once the four paths are selected, configuration should make the diagram true.

NSG principles

• Allow management only from the real Bastion subnet, VPN address range, or approved management segment.
• Allow application traffic only from the intended frontend or private client range and only to required ports.
• Review outbound rules; an inbound-only NSG review misses data exfiltration and unintended dependencies.
• Prefer stable service tags or application security groups where they accurately represent the requirement, but understand their scope.
• Use explicit priorities and descriptions so the reason and owner survive the original deployment.
• Check effective security rules on the NIC instead of reading only one subnet NSG file.

Routing principles

• Check effective routes from the workload NIC.
• Confirm whether the effective 0.0.0.0/0 next hop is Internet, VirtualAppliance, VirtualNetworkGateway, or None. Check NAT Gateway association separately: NAT Gateway performs SNAT for traffic whose selected next hop is Internet; it is not shown as a route next hop.
• Check return routes for hybrid connections; an allowed forward path with an asymmetric or missing return path still fails.
• Do not assume peering is transitive. Hub-and-spoke routing requires explicit design.

DNS principles

• Test name resolution from the VM, not only from an administrator laptop.
• Record whether Azure-provided DNS, custom DNS servers, Private DNS Resolver, or on-premises forwarders answer the query.
• Validate both the returned address and the intended DNS zone link or forwarding rule.
• Treat a public result for a private-endpoint FQDN as a design signal, not merely an application error.

15. Three reference scenarios

Scenario A: small internal operations VM

Operator → Azure Bastion → VM private IP
VM → NAT Gateway → required external update endpoints
VM → Private Endpoint → Key Vault
No public application inbound

The VM NIC has no public IP. The target NSG allows SSH or RDP only from AzureBastionSubnet. NAT Gateway provides an explicit outbound source address; it does not approve update destinations, so destination policy must be enforced elsewhere if the requirement calls for it. Endpoint security and update policy remain required. Key Vault uses a Private Endpoint with validated private DNS. A separate break-glass method and responsible owner are documented.

This is simple, but it is not “zero trust” merely because Bastion exists. Identity strength, endpoint health, guest authorization, session evidence, and least privilege still determine who can administer the system.

Scenario B: public web application on private VMs

Customer → Public Application Gateway + WAF → private VM backend
Operator → Bastion or VPN → private VM management port
VM → Azure Firewall → approved dependencies
VM → Private Endpoint → database or secret service

The workload remains internet-facing at Application Gateway, so the public IP, DDoS posture, WAF, TLS, health probes, and application capacity must be reviewed. The backend NSG accepts only the frontend flow. Management uses a separate path. Azure Firewall enforces outbound destination policy. Private Endpoints reduce public service dependencies where justified.

The accurate statement is “the backend VMs have no public IP,” not “the application is private.”

Scenario C: enterprise hub and spoke

Administrator network → VPN/ExpressRoute → hub security controls → spoke VM
Spoke VM → hub Azure Firewall → approved internet destinations
Spoke VM → Private Endpoint / private connected service
Public applications → governed edge → private spoke backend

This pattern centralizes policy and evidence, but routing is more complex. Verify peering settings, gateway transit, route propagation, default routes, firewall policy, DNS forwarding, return paths, and ownership between platform and application teams. Centralization without clear service-level objectives can turn the hub into a shared outage boundary.

16. A repeatable nine-step implementation workflow

Step 1: classify the workload

Record data sensitivity, business impact, availability objective, user population, and whether the application is public, private, or mixed.

Step 2: inventory all flows

List administration, application inbound, outbound dependencies, Azure service dependencies, monitoring, backup, time synchronization, identity, activation, and recovery paths. Name owners.

Step 3: choose the public edge, if any

Decide where internet exposure belongs. Remove unnecessary direct public IPs. Do not move a public IP from the VM to an unmanaged jump host and call the risk solved.

Step 4: select primary and recovery administration paths

Choose Bastion, VPN, ExpressRoute, or another controlled path. Define guest identity, least privilege, conditional access, JIT if used, logging, and break-glass ownership.

Step 5: select explicit outbound behavior

Choose NAT Gateway, Azure Firewall, a governed virtual appliance, or no internet egress. Record destination requirements and failure behavior.

Step 6: privatize supported service dependencies

Evaluate Private Endpoint per service and subresource. Configure DNS and public network access separately. Do not create endpoints with no owner or test.

Step 7: encode NSGs, routes, DNS, and policy

Use infrastructure as code and policy controls where practical. Make exceptions time-bound and reviewable. Capture effective configuration, not only intended templates.

Step 8: test positive and negative paths

Prove what must work and what must fail from realistic sources. Do not stop after one successful RDP session.

Step 9: operate and reassess

Monitor configuration changes, flows, guest health, application health, and dependency failures. Review when the workload, edge, network, identity model, or Microsoft service behavior changes.

17. Prove the design with positive and negative tests

Use a matrix like this as deployment evidence.

Test	Expected result	Useful evidence
Connect to old VM public address from internet	Fails; no public NIC mapping exists	NIC/IP inventory and connection result
RDP/SSH through approved admin path with authorized identity	Succeeds	Bastion/VPN logs, guest auth log, session record
RDP/SSH from unapproved internet source	Fails	NSG flow evidence or connection troubleshoot result
Public HTTPS through approved WAF frontend	Succeeds if workload is public	Frontend access/WAF log and application health
Direct backend application connection from internet	Fails	NSG/effective rule and connection result
Approved outbound dependency	Succeeds through selected next hop	Effective route, firewall/NAT evidence, application test
Unapproved outbound destination	Fails when policy requires denial	Firewall rule/log and application result
Azure service FQDN lookup from VM	Returns intended private IP	DNS query result and Private Endpoint record
Azure service access with valid workload identity	Succeeds	Service audit and identity sign-in evidence
Same service through public network	Fails if public access is disabled	Service firewall/public access configuration and test

Azure Network Watcher connection troubleshoot can help identify reachability and next-hop problems, while IP flow verify can evaluate whether NSG rules allow a specific flow. For new flow-logging designs, use Virtual Network flow logs. Microsoft stopped allowing new NSG flow log creation after June 30, 2025 and plans to retire existing NSG flow logs on September 30, 2027, so do not build a new evidence strategy around the retiring feature.

18. Monitoring and evidence ownership

A secure diagram that nobody monitors degrades quietly. Assign owners and retention for:

• Azure Activity Log events that change NICs, public IPs, NSGs, routes, Bastion, firewalls, and Private Endpoints;
• Azure Policy compliance for prohibited VM public IPs or required controls;
• Azure Firewall, Bastion, VPN, WAF, and load-balancer diagnostics as applicable;
• Virtual Network flow logs and Network Watcher tests;
• guest Windows/Linux authentication and security logs;
• application, dependency, and health telemetry;
• Defender for Cloud recommendations and JIT events when those services are used; and
• DNS query or resolver evidence where private name resolution is critical.

Alerting needs a human destination and a response. Examples include a new public IP attached to a production NIC, an NSG rule opened to 0.0.0.0/0 on port 22 or 3389, a default route bypassing the firewall, a Private Endpoint DNS record removed, or repeated failed guest sign-ins.

19. Break-glass and patching are part of the private design

A private administration path can fail. Bastion, VPN, a hub firewall, custom DNS, identity services, or the VM guest itself might be unavailable. Define a controlled recovery method before the incident.

Azure Run Command can execute scripts through the VM agent and is useful for diagnosis or remediation, but it fails when the agent or its dependencies are unhealthy and is not a normal interactive administration channel. Action Run Command also requires outbound TCP 443 connectivity to Azure public IP addresses to return results; it is not guaranteed to work in a fully isolated subnet merely because no inbound port is required. Azure Serial Console provides a network-independent console for supported recovery scenarios, but it is highly privileged and should be treated as break-glass access with restricted roles and monitoring.

Azure Update Manager orchestrates update assessment and installation; it does not host every operating-system package. The VM still needs a working path to Windows Update, WSUS, a Linux repository, or the organization’s approved content source. Verify this dependency before removing or restricting outbound access.

A recovery record should state:

• trigger and incident owner;
• who can authorize the method;
• required Azure and guest roles;
• credentials or identity recovery procedure;
• log and review requirements; and
• how normal controls are restored afterward.

20. Common misconceptions corrected

Misconception	More accurate statement
“No public IP means the VM cannot be reached from the internet.”	It cannot be addressed directly through a NIC public IP, but a public frontend or DNAT path can still reach its private address.
“No public IP means no outbound internet.”	Outbound is separate; implicit behavior may exist on older/nonprivate subnets, or an explicit NAT/firewall path may be configured.
“Bastion removes RDP and SSH.”	Bastion carries RDP/SSH to the private VM; target NSG, guest firewall, service, and authentication still matter.
“Owner can sign in to every VM.”	Azure resource roles and guest login authorization are distinct boundaries.
“JIT creates private connectivity.”	JIT temporarily changes supported access rules; it does not create routing, VPN, or guest authentication.
“NAT Gateway filters dangerous destinations.”	NAT Gateway provides outbound translation and return-flow handling, not firewall inspection or destination policy.
“Deploying Azure Firewall protects every subnet.”	Routes must direct the intended traffic to the firewall and policy must allow or deny it.
“A Private Endpoint automatically disables public access.”	Private Endpoint creates a private service path; public access is a separate service configuration.
“NSG allowed means the application must work.”	DNS, routes, return path, guest firewall, listener, identity, TLS, and application health can still block it.
“Private means no monitoring is necessary.”	Private paths can be abused or misconfigured; configuration, flow, identity, guest, and application evidence remain necessary.

21. Architecture review checklist

Exposure

• Every VM NIC public IP is inventoried and justified.
• The intended public application edge is named separately from backend VMs.
• Direct RDP and SSH from the internet are absent.
• Public DNAT and load-balancing rules are included in the exposure review.
• DDoS and WAF requirements are evaluated at the actual public edge.

Administration and identity

• One primary and one recovery administration path are documented and tested.
• Azure resource authorization and guest login authorization are reviewed separately.
• Target NSGs allow only the real management source and required port.
• JIT source, duration, ports, and Defender for Servers Plan 2 dependency are recorded if used.
• Shared credentials and permanent broad administrator assignments are avoided or formally excepted.

Outbound and service access

• The subnet’s actual default outbound state is verified.
• Every required internet dependency has a named owner and explicit egress path.
• NAT Gateway and Azure Firewall are selected by control requirement, not product familiarity.
• Private Endpoint subresources and private DNS results are validated from the VM.
• Public service access is separately disabled or restricted where required.
• Update, activation, monitoring, backup, and identity dependencies are tested.

Evidence and operations

• Effective routes and effective security rules match the intended diagram.
• Positive and negative connectivity tests are retained.
• Activity, flow, identity, guest, firewall, and application logs have owners and retention.
• Alerts exist for newly attached public IPs and dangerously broad management rules.
• Break-glass access is restricted, monitored, and reviewed after use.
• A measurable reassessment date or trigger is recorded.

22. Self-review questions

1. Which direct path disappears when a public IP is removed from a VM NIC?
2. Why might the application still be internet-facing afterward?
3. What is the difference between Azure Resource Manager access and Windows/Linux guest access?
4. What three separate questions do DNS, a route, and an NSG answer?
5. Why is Azure Bastion not the VM’s outbound path?
6. What additional requirement does private-only Bastion have for the administrator?
7. How does JIT differ from Bastion?
8. When would NAT Gateway be a better starting point than Azure Firewall?
9. Why does deploying Azure Firewall alone not prove that the VM uses it?
10. Which two settings must be considered separately when adopting a Private Endpoint?
11. Why can patching fail even when Azure Update Manager is configured?
12. Which negative test proves that the backend is not directly exposed?

If any answer is simply “because it is private,” return to the flow map and name the identity, address, route, control, and evidence.

23. One-page memory card

1. Remove the VM NIC public IP
   → removes direct public addressing of that NIC
   → does not remove public frontends or outbound access by itself

2. Separate four paths
   → guest administration
   → application inbound
   → internet outbound
   → private Azure service access

3. Choose controls by job
   Bastion / VPN / ExpressRoute → administration path
   WAF / load balancer / approved edge → application inbound
   NAT Gateway → predictable outbound translation
   Azure Firewall → centralized destination policy and inspection
   Private Endpoint + private DNS → private path to a supported service
   NSG → allow or deny a network flow
   Route → select the next hop
   Identity + guest authorization → decide who may act or sign in

4. Prove both directions
   required flow succeeds
   forbidden flow fails
   logs and effective configuration explain why

The final memory line is:

Design a private Azure VM by separating paths, not by treating the absence of one public IP as the absence of every risk.

The next Module 1 note will return to the building blocks behind this design: VNet and NSG fundamentals for cloud beginners. It remains planned until the complete English and Korean article pair is ready; no empty route is linked.

References

• Coursera: Azure Cybersecurity Solutions and Microsoft Defender
• Microsoft Learn: Default outbound access in Azure
• Microsoft Learn: Azure Bastion overview
• Microsoft Learn: Deploy private-only Azure Bastion
• Microsoft Learn: Enable just-in-time access on VMs
• Microsoft Learn: Azure NAT Gateway overview
• Microsoft Learn: Azure NAT Gateway design considerations
• Microsoft Learn: Azure Firewall overview
• Microsoft Learn: Integrate Azure Firewall with NAT Gateway
• Microsoft Learn: Azure Private Endpoint overview
• Microsoft Learn: Azure Private Endpoint DNS integration
• Microsoft Learn: Network security groups overview
• Microsoft Learn: Azure Resource Manager overview
• Microsoft Learn: Microsoft Entra sign-in for Windows VMs
• Microsoft Learn: Microsoft Entra sign-in for Linux VMs
• Microsoft Learn: Run Command overview
• Microsoft Learn: Run Command for Windows VMs
• Microsoft Learn: Azure Serial Console for Windows
• Microsoft Learn: Azure Update Manager workflow
• Microsoft Learn: Azure Update Manager prerequisites
• Microsoft Learn: Network Watcher connection troubleshoot
• Microsoft Learn: Diagnose VM traffic filtering with IP flow verify
• Microsoft Learn: Migrate from NSG flow logs to virtual network flow logs
• Microsoft Learn: Monitor Azure virtual machines