Network Topology and Connectivity
Design Considerations
- Consider your networking requirements and use cases, and whether the application is to be exposed to internal users or external users or both, and the appropriate App Service Plan tier that will be required to support those networking requirements.
Multi-Tenanted:
- App Services in the multi-tenanted service share a single inbound and multiple outbound IP addresses with other App Services in the same deployment unit. These can change for a variety of reasons. If consistent outbound IP addresses are needed for multi-tenant App Service, a NAT gateway can be configured, or VNet Integration can be used.
- If a dedicated IP address is required by which to address your App Service, you can make use of App-assigned addresses, or you could front your App Service with an Application Gateway (which is assigned a static IP address).
- When there is a need to connect from an App Service to on-prem, private, or IP-restricted services, consider that:
- When running in the multi-tenanted environment, the App Service call can originate from a wide range of IP addresses, and VNet Integration may be needed.
- Services like API Management (APIM) could be used to proxy calls between networking boundaries and can provide a static IP if needed.
- App Services in the multi-tenanted environment can be deployed with a private or a public endpoint. When deployed with a Private Endpoint, public exposure of the App Service is eliminated. If there is a requirement for the private endpoint of the App Service to also be reachable via the Internet, consider the use of App Gateway to expose the app service.
- The multi-tenanted App Service exposes a set of ports, and these cannot be changed or blocked.
- Plan your subnets correctly for outbound VNet integration and consider the number of IP addresses that are required. VNet Integration depends on a dedicated subnet. When you provision a subnet, the Azure subnet loses five IPs from the start. One address is used from the integration subnet for each plan instance. When you scale your app to four instances, then four addresses are used. When you scale up or down in size, the required address space is doubled for a short period of time. This affects the real, available supported instances for a given subnet size.
App Service Environment:
- App Services deployed on an ASE get static, dedicated IP addresses for inbound and outbound communication, for the lifetime of the ASE.
- When there is a need to connect from an App Service to on-prem, private, or IP-restricted services, consider that:
- When running in an ASE, the App Service is running within the context of a VNet.
- A service like API Management (APIM) could be used to proxy calls between networking boundaries and can provide a static IP if needed.
- Consider whether your app services on an ASE needs to be exposed externally or if they only need to be exposed on the private network.
- The size of the subnet you select when deploying an ASE cannot be changed later, so be sure to consider your maximum scale needs.
Design Recommendations
- Connecting to an App Service:
- Ensure you have a Web Application Firewall (WAF) implemented in front of your App Service, using Azure Front Door, Azure Application Gateway, or a third-party service, to provide OWASP-based protection. You can use either Front Door or App Gateway for a single region, or both if you are doing multi-region. If you need path routing within the region, you would need App Gateway, and if you need multi-region load balancing and WAF, you would need Front Door.
- Employ the appropriate use of access restrictions so that the app service is only reachable from valid locations. For example, if the app service is hosting APIs, and is fronted by APIM, setup an access restriction so that the app service is only accessible from APIM.
- Connecting from an App Service:
- Use the built-in tools for troubleshooting any networking issues
- Avoid SNAT port exhaustion by utilizing connection pools. The creation of new connections repetitively to the same host and port can cause slow response times, intermittent 5xx errors, timeouts, or external endpoint connection issues.
- Review and follow the recommendations outlined in the Network Security section of the Azure security baseline for App Service.
Multi-Tenanted:
- If you need a dedicated outbound address when connecting to an multi-tenanted App Service, use a NAT Gateway.
- Since subnet size can’t be changed after assignment, use a subnet that’s large enough to accommodate whatever scale your app might reach. To avoid any issues with subnet capacity, you should use a /26 with 64 addresses for VNet integration.
App Service Environment:
- Your subnet should be sized with a /24 CIDR range, providing 256 addresses.
Azure Cache for Redis Enterprise
- For security and isolation reasons the bicep files will deploy Azure Cache for Redis Enterprise inside its own subnet using a private endpoint. Depending on the level of security needed and the topology of your network, you can us as-is or deploy to an already established subnet that you have.