Azure Application Gateway is a managed regional reverse proxy with optional WAF (Web Application Firewall) capability used to expose web applications:
The intent of this MicroHack is to play with several Application Gateway features through different scenarios.
All scenarios except #1 and #2 can be done independently.
Application Gateway cannot use the same port for both public & private listeners.
To address this limitation, it is common for organizations to deploy at least 2 Application Gateways: one to carry public site exposure, and another to carry private site exposure.
It is then the limits (listeners, SSL certificates ...) that derive the number of Application Gateway that are deployed.
As seen during this MicroHack, Application Gateway is a component that can be massively mutualized, which optimizes costs.
Historically, Application Gateways were deployed in the Hub as infrastructure elements. This can lead to limitations if new Application Gateways are to be deployed because IP availabilies in hub-vnet: recommended application gateway subnet size is /24.
If a routing NVA is available in the hub (Azure Firewall, 3rd party FW), it is quite conceivable to deploy Application Gateways in spokes VNets as soon as you are comfortable with UDRs (as seen in scenario #4), to keep the symmetry of the routing.
My colleague Cynthia Treger published a Scaling guide with Azure Application Gateway v2.
Based on this guide, we can produce this AppGw capabilities table:
Note: Pricing columns (generated on february 2023, east US region, 5GB Outbound Data Transfer baseline) may not be relevant when auto scaling feature is enabled.
There are several components that can be placed in front of a (web) application:
Source
Azure Architecture Center provides an interesting decision tree:
