Is it possible to include a separate Azure App Service as part of another App Service?
For example lets say that I have a website called www.mycompany.com hosted in its own Azure App Service. I have another Azure App Service that I want to make it accessible by going to a specific URL in the first App Service.
So in other words when a request comes to www.mycompany.com/eu/ I want the content of this endpoint (/eu) to be served from the other app service. Would a load balancer work? The reason I want to do this is because the /eu endpoint has grown too big and I would like to separate that from the main site and host it on a separate app service. I hope my question is clear.
Thanks in advance.
For this purpose you could use Application Gateway.
In a certain sense it resembles a load balancer (it is a L7 LB indeed) as you indicated, but the product provides many additional features.
The following image, extracted from the product documentation, explains how it works:
Basically, as outlined in the aforementioned docs, when describing how an Application Gateway accepts a request (note they mention WAF in the explanation, an optional security threat prevention system):
Before a client sends a request to an application gateway, it
resolves the domain name of the application gateway by using a Domain
Name System (DNS) server. Azure controls the DNS entry because all
application gateways are in the azure.com domain.
The Azure DNS returns the IP address to the client, which is the
frontend IP address of the application gateway.
The application gateway accepts incoming traffic on one or more
listeners. A listener is a logical entity that checks for
connection requests. It's configured with a frontend IP address,
protocol, and port number for connections from clients to the
application gateway.
If a web application firewall (WAF) is in use, the application
gateway checks the request headers and the body, if present,
against WAF rules. This action determines if the request is valid
request or a security threat. If the request is valid, it's routed
to the backend. If the request isn't valid and WAF is in Prevention
mode, it's blocked as a security threat. If it's in Detection mode,
the request is evaluated and logged, but still forwarded to the
backend server.
The routing to one backend or another can be based on URL Paths:
You can find an example of this configuration in this related Microsoft article.
In your use case, you will need to define two backends, one for every App Service, and define routing rules as appropriate.
As indicated before, your DNS should point to the Application Gateway: it will handle the routing to one or other App Service based on the route, /eu/* or /*, provided by the client.
The order of the routes is important: once a rule is matched, it will be the one processed.
Application Gateway is a regional service: Azure Front Door leverages a similar functionality (and much more) globally.
Please, consider review the associated costs of these services.
I am answering my own question to hopefully help others in the same situation. This was simply done using a reverse proxy. This article explains everything you need to set it up - https://ruslany.net/2014/05/using-azure-web-site-as-a-reverse-proxy/
Related
I am getting to the point of my project where I am ready to deploy it online with my custom domain via Azure once I make the upgrade from my Free Subscription.
So a little context, I have 1 web app service and 4 api services and each one is hosted in a separate app service such as:
www.sitename.azurewebsites.net
www.sitename-api1.azurewebsites.net
www.sitename-api2.azurewebsites.net
www.sitename-api3.azurewebsites.net
www.sitename-api4.azurewebsites.net
And the above web app communicates to all 4 api's and some api's may or may not talk to another. (Would have loved an application gateway so hopefully I'll be changing this architecture later down the road).
So as I get ready to associate my domain to the services, the web container seems pretty straight forward to me as it just becomes www.sitename.com, but I am a little confused about the api services. The way I am thinking about this is that each api service will be in it's own subdomain, such as:
www.api1.sitename.net
www.api2.sitename.net
www.api3.sitename.net
www.api4.sitename.net
where I believe I can register my SSL and domain to each app service somehow, but this leaves me with a few questions.
Do I host each api in a subdomain using the same domain as the web
app, or is there a different way preferred like where I host them
all on the same domain with different exposed ports per API and web
listening 80/443, or maybe just use the IP address of the api app
service and allow www.sitename.com as the origin for CORS?
I am assuming that since I am associating my SSL cert to the web
service, I will need to do the following on the api services?
Would it be better (and still affordable) if I just had a VNET
associated to the app services and the domain only registered with
the web app?
Any insight into this would be greatly appreciated on how I can establish communication between my app services with my custom domain and SSL as I am fairly new to this part of the stack, but excited about learning!
As I known, on Azure cloud, there are two services can help to manage your APIs deployed on multiple app service containers: API Management and Application Gateway.
The Premium tier of API Management has the feature for multiple custom domain names, please see the offical document Feature-based comparison of the Azure API Management tiers as the figure below.
You can refer to the quick start tutorial of Create a new Azure API Management service instance and other related documents to kown how to.
"Azure Application Gateway is a web traffic load balancer that enables you to manage traffic to your web applications." said in the introduce What is Azure Application Gateway?. And as the figure of its architecture below, "With Application Gateway, you can make routing decisions based on additional attributes of an HTTP request, such as URI path or host headers. For example, you can route traffic based on the incoming URL. So if /images is in the incoming URL, you can route traffic to a specific set of servers (known as a pool) configured for images. If /video is in the URL, that traffic is routed to another pool that's optimized for videos."
I recommended to use Azure Application Gateway which be a good choice to manage multiple app services and expose the unified urls of APIs.
I'm migrating a complete infrastructure over to Azure; it's been slow going as there's so much to learn and for every two steps forward, there seems to be one step back.
After what seems like an eternity, I think I've got it all sorted with one exception.
The architecture is as follows:
Azure Traffic Manager ==> 2 Azure Application Gateways (geo separated) ==> Azure App Service
A custom domain is used for the traffic manager and the gateways are listening for the same domain and, when the route matches, passing on the requests down to the app service.
The actual app itself is a ASP.NET MVC application and it uses forms authentication; and this is where the challenge happens.
When navigating to the public address: client.domain.com and hitting the website, it determines that the user is not authenticated and sends the browser to the login page... so far so good but, rather than using client.domain.com/login it uses the web-server dns name, so client.azurewebsites.com/login
How do I go about changing the behaviour so that it uses the external DNS name rather than the website name?
I can't setup custom domains on the app service as the only route into the site is via the gateway as this is also the firewall.
Is there some Web Config setting I can make? I'm looking at the outbound rewrite rules but these seem to only work on tags rather than 302 redirects.
Any thoughts would be most welcome.
You need to setup custom dns names on your webapp (you can use TXT record to verify dns name, so i dont see a reason why you can add it to the webapp). or you can alter the code.
In order to solve this problem, I had to make a code change to the web app itself. Not ideal but it worked.
What I had to do was to extend the code that redirects an unauthenticated request to the login page by sniffing for the X-Original-Host HTTP Header that the App Gateway forwards on. This contains the public facing DNS name. If the header is present and it is on a pre-approved white-list (so as to prevent any hijacking), then redirect the user to the login page for this domain, rather than the one the server is listening on directly (so use client.domain.com rather than client.azurewebsites.com)
Is there any way to secure an HTTP endpoint of an Azure Logic App ?
For example if I'm using my Logic App's HTTP request endpoint to be triggered as a webhook from a payment gateway, I'd want to restrict only certain static IP Addresses to access it and enable HTTPS.
I didn't find any firewall options like those present in Azure SQL for IP base restrictions.
You can put the manual trigger endpoint behind Azure API Management, using its "Restrict caller IPs" policy should help you accomplish what you need.
See https://learn.microsoft.com/en-us/azure/logic-apps/logic-apps-securing-a-logic-app
Restrict incoming IP addresses
In addition to the Shared Access Signature, you may wish to restrict calling a logic app only from specific clients. For example, if you manage your endpoint through Azure API Management, you can restrict the logic app to only accept the request when the request comes from the API Management instance IP address.
This setting can be configured within the logic app settings:
In the Azure portal, open the logic app you want to add IP address restrictions
Click the Access control configuration menu item under Settings
Specify the list of IP address ranges to be accepted by the trigger
A valid IP range takes the format 192.168.1.1/255. If you want the logic app to only fire as a nested logic app, select the Only other logic apps option. This option writes an empty array to the resource, meaning only calls from the service itself (parent logic apps) fire successfully.
I could be wrong but all App Services (Web Apps, Logic Apps, API Apps) are, by default, publically accessible and, by default, do not enable IP Filtering via Azure resource configuration (meaning, a setting on the Logic App). Options I can think of enabling this would be:
If you have access to a Web.config, use an element to restrict traffic to only a specific set of address (see MSDN)
Consider putting the Logic App behind an API Management resource and enforce a IP restriction policy (see Azure API Management Documentation); I'm guessing this may not apply for Logic Apps but including it anyway
Scale to a Premium App Service Plan, deploy Logic App to an App Service Environment which gives you the ability to specify whether there is a Public IP (VIP) used for load balancing requests or internal load balancer (which would be used for cross-premise connectivity between your LAN and Azure); you can also deploy a virtual Web Application Firewall (WAF) which would allow you to place explicit IP filters as well
Not knowing your requirements, I'd lean more towards option 3 simply because there is documentation supporting that scenario (at least for Web, Mobile and API Apps -- Logic Apps are not mentioned). Otherwise, if you're not able to modify the web.config to include the filters and cannot put an API Management instance in front of the logic app, I'm not sure what other options you may have.
Hope this helps and if you find a solution, I'd be interested in learning it as well.
My company wants something like the Application Gateway to be a scalable entrypoint of all incoming requests, with SSL offloading, and balance those requests to external web servers, which are not on our Azure subscription, but belong to the company.
If Application Gateway is indeed the recommended way, how can I declare in the XML configuration file something like that? And if it's not, what's the best way I can achieve that?
application gateway is an option to achive this but by using an application gateway you use an AzureVM ressource. The scalability is ok but we have to pre-create more application gateways in case of a scale out. For a scale down you should also check first how to reroute traffic from the current gateway to the others before you scale down.
i would reccomend an another design. by using azure app-services. this is a webserver farm as a service. in the webserver is IIS running and you can create a forward / redirect reverse proxy or ARR. check out point like azure topics like Application request routing and reverse proxy:
http://blogs.iis.net/carlosag/setting-up-a-reverse-proxy-using-iis-url-rewrite-and-arr
http://www.iis.net/learn/extensions/url-rewrite-module/iis-url-rewriting-and-aspnet-routing
regards
patrick
How can I maintain users to get redirected to the same Server in a Load-Balanced Web Apps
Your answer will be very helpful
Traffic Manager directs the user to the appropriate region, but assuming you have your web app scaled out to at least two instances, ARR (Application Request Routing) is what directs each request to a specific instance of the app.
ARR has a feature called Session Affinity which is enabled by default. It uses an ARRAffinity cookie to attempt to route all requests from a client to the same instance of your application. I say "attempt" because, the cloud being what it is, instances of your app can come and go due to autoscaling or maintenance activities.
Your best bet is to use Azure Traffic manager. When setup correctly it will route users to the proper cloud service in their region and provide them with the best possible experience.
More information can be found here
Azure Traffic Manager
Azure Traffic Manager Documentation
Traffic Routing Methods