A common requirement in Azure is to expose a web application to the internet without assigning a public IP address to the virtual machine running it. This is especially true for IIS-based workloads where security, control, and scalability matter.
Azure Application Gateway is a natural fit for this scenario. It acts as a managed, Layer-7 entry point that receives public traffic and forwards it to backend servers that live entirely on private IP space.
This article walks through an architecture where IIS runs on an Azure virtual machine that is only accessible inside a virtual network, while Application Gateway handles all inbound traffic from the internet.
The design centers around a virtual network that separates responsibilities clearly.
Inbound traffic from users is directed to a public IP address associated with Azure Application Gateway. Application Gateway terminates the connection, evaluates routing rules, performs health checks, and forwards requests to a backend pool consisting of an IIS server hosted on an Azure VM.
The VM itself has no public IP address. It can only be reached from within the virtual network, ensuring it is not directly exposed to the internet.
Key Components
• Azure Virtual Network with multiple subnets
• Azure Application Gateway (Standard_v2 or WAF_v2)
• Windows Server VM running IIS
• Network Security Groups to restrict traffic flow
• Optional Azure Bastion for secure administrative access
Virtual Network and Subnet Design
The virtual network contains two dedicated subnets, each serving a specific purpose.
One subnet is reserved exclusively for Azure Application Gateway. Azure enforces this requirement, and no other resources can be deployed into that subnet. The second subnet hosts the IIS virtual machine and any additional backend components.
This separation allows traffic to be tightly controlled using network security groups while also meeting Application Gateway deployment requirements.
_______________________________________________________________________________
IIS Virtual Machine with Private Connectivity
The IIS server runs on a Windows Server virtual machine deployed into the backend subnet. The VM is configured with only a private IP address, typically set to static to ensure backend stability.
IIS listens on HTTP or HTTPS, depending on whether end-to-end encryption is required. A simple site hosted in inetpub\wwwroot is sufficient for validation and health probing.
Because the VM has no public IP, administrative access is handled through private mechanisms such as Azure Bastion or a jump host within the virtual network.
Network Security Considerations
Inbound access to the IIS VM is restricted using NSGs. Only traffic originating from the Application Gateway subnet is allowed to reach the IIS listening ports. All other inbound internet traffic is denied by default.
This ensures that the VM can only receive web requests that have already passed through Application Gateway.
_______________________________________________________________________________
Application Gateway as the Public Entry Point
Azure Application Gateway is deployed using the v2 SKU, which provides autoscaling and improved performance. It is assigned a static public IP address, which becomes the externally accessible endpoint for the application.
Application Gateway performs several critical functions:
• Acts as the internet-facing endpoint
• Terminates HTTPS connections
• Evaluates routing rules
• Performs health probes against backend servers
The backend pool is configured using the private IP address (or NIC) of the IIS virtual machine. From Application Gateway’s perspective, the VM is just another internal backend endpoint.
_______________________________________________________________________________
Health Probing and Traffic Flow
Health probes play a key role in this architecture. Application Gateway continuously checks the IIS server by sending requests to a configured path, commonly /.
If IIS responds successfully, the backend is marked healthy and traffic is forwarded. If it fails to respond, Application Gateway automatically stops sending traffic, protecting users from failed requests.
This mechanism allows Application Gateway to act as a smart traffic manager rather than a simple reverse proxy.
_______________________________________________________________________________
Routing and Request Handling
Listeners on Application Gateway define how incoming traffic is accepted, typically over HTTP or HTTPS. These listeners are associated with routing rules that map requests to backend pools and HTTP settings.
This setup supports simple one-to-one routing as well as more advanced scenarios such as path-based routing, host-based routing, and multiple IIS sites behind the same gateway.
_______________________________________________________________________________
Security Posture and Best Practices
This architecture significantly improves security by design:
• IIS VMs are never exposed to the internet
• All inbound traffic is centralized through Application Gateway
• TLS certificates are managed at the gateway
• Optional WAF rules protect against common web attacks
Additional hardening can include enabling end-to-end HTTPS, storing certificates in Azure Key Vault, and enabling diagnostics and access logs on Application Gateway.
_______________________________________________________________________________
Why This Pattern Is Effective
Using Application Gateway in front of a private IIS VM creates a clean separation between the public edge and the backend workload. It provides visibility, control, and protection while keeping the VM isolated from direct internet access.
This approach is well suited for production IIS workloads, legacy web applications, and scenarios where security and compliance are primary concerns.
