Why does Azure Application Gateway require an empty subnet

Question

When I try to execute New-AzureRmApplicationGatewayIPConfiguration to create an application gateway, I get an exception:

Subnet xxx cannot be used for application gateway yyy since subnet is not empty.

I encountered this error when I tried to add the application gateway to the same subnet as the backend servers.

Why is this not an option? Does each gateway require a separate subnet? What is the recommended configuration?

Related questions:

• The documentation says backend servers can be added when they belong to the virtual network subnet. How can a back-end server belong to the virtual network subnet of the application gateway if the application gateway must be in a separate subnet?
• How can the application gateway be configured without requiring a public IP address on the backend servers?

Churchyard

Answer 1

The application gateway must be in a subnet by itself as explained in the documentation, hence the reason it is not an option. Create a smaller address space for your application gateway subnet (CIDR 'x.x.x.x/29') so you're not wasting IP addresses unnecessarily.

It's a good practice to strive for a multi-tier network topology using subnets. This enables you to define routes and network security groups (ie: allow port 80 ingress, deny port 80 egress, deny RDP, etc.) to control traffic flow for the resources in the subnet. The routing and security group requirements for a gateway are generally going to be different than routing and security group requirements of other resources in the virtual network.

Gentle

Indeed the documentation says to do it that way. Unfortunately it doesn't say why. Thanks for clarifying. – Churchyard

can you take a look at my related questions? – Churchyard

I would not recommend putting a public IP address on the backend servers. They should be private resources that are accessible from the app gateway that is publicly accessible. If you do, perhaps to RDP over public internet, then you should still use the internal network IP for the backend server pool when configuring the app gateway. – Gentle

that's exactly what these related questions are about. Can you take a look at them? Perhaps my questions are not clear but I am trying to figure out how to configure the application gateway in case the backend servers only have a private IP. – Churchyard

Have you tried this? The backend IP's in the backend server pool are private by default. Unless you put a public IP Address on them they will remain private. – Gentle

Currently I have the backend servers setup with a public and a private IP. When I configure the gateway with the public IPs, it works as expected, when I use the private IPs the gateway gives an error indicating it can not reach the backend. Do I need to setup some routing or security settings to allow the subnet of the gateway to talk to the backend subnet? – Churchyard

I just checked my environment and there are no additional requirements. However, after looking at the documentation again I see where some of the confusion may be. Let's take this offline. – Gentle

I put an application gateway on a subnet and proceeded to add other resources on the same subnet. Looks like everything is working. I saw in certain areas of documentation that this was mentioned but somehow I ended up doing it anyway and it works. Wondering how that’s possible. – Jabberwocky

In addition to the good practice of multi-tier topology, I have also observed app gateways spawning health check services that communicate from addresses within the app gateway subnet. For example, if subnet is 10.0.4.0/30, it looks like app gateway spawns services on 10.0.4.X depending on how many targets are in your backend pool, so it can perform health checks without impacting flow over normal routes. This would be an additional reason why app gateways want their own subnet. – Acquiescence

Answer 2

I had the same issue, so my virtual network was 10.0.0.0/24 which was not allowing me to create a separate subnet. I solved the issue as we added another address space into the azure virtual network e.g. 10.10.0.0.24, then created a new subnet so that the application gateway was happy to work with the backend servers.

Redness