What are some legitimate use-cases for fronting an Azure "Web App" service with a reverse proxy (i.e. ARR)?
I'm specifically interested in security considerations. For the purposes of this question, let's assume load balancing is handled by the Azure load balancer and the proxy would not perform any additional features such as caching or compression.
The Azure Load Balancer is a Layer-4 component. ARR is a Layer-7 router, therefore it can do sticky sessions (instance affinity) and health checking.
In App Service it also does TLS offloading, which is pretty nice since your application code only has to deal with plain HTTP. More on that here: https://stackoverflow.com/a/38726543/4148708
If you don't need/want any of that, then by all means, go to Cloud Services, VM Scale Sets or vanilla VMs.
Related
I am creating a standard multi-tenant site that has the following structure:
example.com
tenant1.example.com
tenant2.example.com
The hosting is Azure web apps. Tenants are generated dynamically (there could be many) and the site includes real-time components, so utilises Azure SignalR. The site will have a wildcard SSL/TLS certificate to enable the subdomain structure.
Rather than going direct to the app service in one region, I'd like to put a load balancer in front of this and route traffic to regional clusters, or maybe even isolated instances for larger clients. It would also be good to have the DDOS protection that comes in-built with these things.
Azure Front Door was my first investigation, this can handle wildcard certificates but doesn't support SignalR.
Application Gateway was my next investigation, this can handle SignalR, but doesn't support wilcard certificates.
In terms of DDOS attacks, it seems we can enable a form of protection directly on the web apps. However, to me, this seems like it would throttle an attack rather than provide (low-cost) protection, as I believe a load balancer would.
How can I load balance this situation please?
I have 2 same Web App and I have added them to application gateway's backed pool in Azure.
I have one domain for the application Gateway and I can bind only one web app to it.
Is there any way to add 2 Web App with the same domain of application gateway?
If not, then any other way to achieve high availability for Web Apps?
I want that if one Web App is not reachable, the traffic should go to other Web App. The Web Apps are not stateless and therefore ruled out the use of Traffic Manager Profile due to lack of Session Persistence.
I have gone through various questions mentioned below on the same topic, but none is related or have satisfactory solution.
- DNS: High Availability with Azure Web Apps + Traffic Manager
- Achieving High Availability using Azure Traffic Manager
- Is it possible that one domain name has multiple corresponding IP addresses?
For App Service, Application Gateway cannot be used for Load balancing Purpose. You can use Application Gateway as WAF. In your scenario, as Thomas stated, AFD would be the best option.
You can leverage the priority option which can be configured while adding App Service to the backend pool to achieve your ask.
You can assign priorities to your different backends when you want to use a primary service backend for all traffic, and provide backups in case the primary or the backup backends are unavailable.
In this case, when the probe to the Primary goes down, then the traffic will be routed to the secondary Web App.
Reference: https://learn.microsoft.com/en-in/azure/frontdoor/front-door-routing-methods
I am creating a network with 2 app services, containing 2 slots each
I know the load balancers are designed to work with VM's, but I am wondering if it is possible to place a load balencer on these 2 app services to balance the load between them, Is it possible to do so??
When you Scale your Web App you add instances of your current pricing tier and Azure deploys your Web App package to each of them.
There's a Load Balancer over all your instances, so, traffic is automatically load balanced between them. You shouldn't need a Virtual Machine for this and you don't need to configure any extra Traffic Manager.
You may want to refer: scale your app in Azure App Service for more details.
but I am wondering if it is possible to place a load balencer on
these 2 app services to balance the load between them, Is it possible
to do so??
According to your description, maybe you are looking for Azure application gateway(layer 7).
Azure application gateway works at the application layer (Layer 7 in the OSI network reference stack). It acts as a reverse-proxy service, terminating the client connection and forwarding requests to back-end endpoints.
Azure application gateway support HTTP, HTTPS and Websockets.
Here is the features offered by each service:
More information about Application gateway, please refer to this article.
Maybe little late but I guess this what you are looking at
Scale Out- A scale out operation is the equivalent of creating multiple copies of your web site and adding a load balancer to distribute the demand between them. When you scale out a web site in Windows Azure Web Sites there is no need to configure load balancing separately since this is already provided by the platform.
https://azure.microsoft.com/en-us/blog/scaling-up-and-scaling-out-in-windows-azure-web-sites/
Currently I have a Service Fabric cluster with 2 stateless services hosting Asp Web APIs. While creating the cluster also appropriate Azure Load Balancers got created.
Now I would like to add Application Gateway in front of my cluster for various reasons like SSL offloading, url-routing etc.
I'd like to understand how to configure the Application Gateway correctly. I see 2 options, not sure which one is valid:
Application Gateway replaces the existing Load Balancer and points directly to SF services hosting WebApi
I keep existing LB configuration and Application Gateway points to this LB (seems like 1 LB solution too many)
Which one is correct? Any advise how to configure?
Approach 2 is what we are using, We have kept the load balancer and that is routing any request received from the Application Gateway. We found this to be easiest and simplest choice, as this involves minimum changes to be done in Application Gateway.
Your two web api's can run on every node in the VM scale set. The Azure Load Balancer is used to distribute traffic over those nodes. Targeting a single service on a single node will reduce scalability and fault tolerance.
You could use the App Gateway to translate incoming request to different ports on the Load Balancer. (E.g. direct traffic to API 1 #url ~/1/ and API 2 #url ~/2/)
Favor using load balancing rules (using all nodes) over NAT redirections (to single nodes). This way you'll have a performant, reliable system.
Solution 2 would also provide possibly to create VPN connection e.g to manage your cluster. Then no need to expose management endpoint to the public. Internal lb also brings on additional features to utilize in the future.
I would go with your first option and to implement it create / modify your ARM template so that it doesn't contain the load balancer and instead contains the application gateway.
Here is a link to the quick starts for ARM templates which you can use. There isn't an out of the box example for service fabric with a gateway but it will give you a great starting place.
link
I'm trying to add web app endpoints from the same location, to an azure traffic manager, when I try to do this, it tells me that App Service will use load balancing to do this for me, when we apps are in the same location.
My understanding is that load balancing is for distributing requests between multiple VMs on one web app. The plan was to use out single DNS and allow traffic manager to determine which endpoint to go to using round-robin or failover. How will load balancing know to direct to one of the web apps from this single address?
Azure Web Apps already have built in load balancing between instances within the web app. So for example if you have a web app with 10 instances under the endpoint: tester.azurewebsites.net, Azure load balances appropriately across those instances.
When you bring in traffic manager, that is looking for different endpoints to facilitate between. Incoming requests will be routed based on proximity to endpoints it is managing, load and if the endpoint is available. Traffic Manager takes care of all of those complexities for you.
This allows you to have a single endpoint myapp.azurewebsites.net; which may route to myapp-west.azurewebsites.net and myapp-east.azurewebsites.net. That routing as I indicated is based on proximity, load and availability.
How it actually works is the magic sauce of Azure Traffic Manager. I use it in production and it has been working very well for me. I primarily use it for routing based on proximity, and have yet to experience a failure on a web app to test a production failover reroute.
Hope that helps!