We have web apps hosted on two data centers for high availability and we used traffic manager with round robin routing method to route traffic to either of the two data centers.
Now per business requirement, we need route the traffic by URL pattern. Say, for url /api/v1, route to data center 1, for url /api/v2, route to data center 2.
I know traffic manager does not support url based routing. Any workaround?
Azure Traffic Manager operates at the DNS layer and as such does not know any details about the URL related to the DNS request it receives - therefore URL based routing is not possible with Azure Traffic Manager. I encourage you to consider using Azure Application Gateway for URL based routing within a single region. For inter-region routing based on URLs, you could consider making the subdomains different and using DNS layer routing.
Related
We are trying to host multiple sites at the backend of Azure Firewall, however we have about 30 different sites and each with their own test\dev and UAT site, which means 30 x 4 and 120 sites, each one is hosted on port 443, all have their own public IP, and are configured with a DNAT rule for directing the traffic based on the source to the correct backend, we have considered a Azure Application Gateway, with host header redirect, but we haven't had a chance to implement it yet, I was wondering is there a way to be cleverer and use Azure firewall with less public IP's and route to various backends, also the prod public sites have no source specified as they're open to the public.
Hope I've explained that clearly. Thanks
• Yes, what you are trying to achieve is very much possible by creating backend pools of websites according to their purpose, common domain name or the URL path routing. For this purpose, you can use the Azure application gateway efficiently by configuring it with the required features given in it.
First, you can define wildcard hostnames in multiple site listeners for up to 5 hostnames per listener, i.e., suppose you have three domain names under which the multiple various web sites are hosted, then you can create pools of public IP addresses under that respective domain name and ensure that the request for that domain’s website is routed accordingly in application gateway. Similarly, you can host multiple subdomains of the same parent domain on the same application gateway deployment.
For more information on configuring the above, kindly refer to the documentation link below: -
https://learn.microsoft.com/en-us/azure/application-gateway/multiple-site-overview#wildcard-host-names-in-listener
• Also, you can distinguish the requests to each one of the websites with a public IP address by configuring URL based path routing rules for either each one of them or categorizing them into pools of common domain name, common URL path, content to be fetched, common purpose or any such characteristic through which you can make a collection of them. URL Path Based Routing allows you to route traffic to back-end server pools based on URL Paths of the request. One of the scenarios is to route requests for different content types to different backend server pools. Thus, in this way, you can route requests to backend website pools by defining the correct required parametric configurations.
For more information on configuring the above, kindly refer to the documentation link below: -
https://learn.microsoft.com/en-us/azure/application-gateway/url-route-overview\
Also, you can configure request routing rules based on combining the above two features in one. For more information regarding this, kindly refer to the documentation link below which describes in detail when and how you should configure the various path based and listener-based rules in application gateway: -
https://learn.microsoft.com/en-us/azure/application-gateway/configuration-request-routing-rules
Currently, I am trying to setup a traffic manager profile for our company needs. Although I read the articles and documentation, I did no find an answer. Our goal is the following:
Route traffic based on domain name/website:
abc.com - routed to West Europe / West US is a backup
def.com - routed to West US / West Europe is a backup
Do we need to create separate traffic manager profile for each website we want to route to these regions. As I understand with custom headers it is possible to monitor different websites inside the profile, but obviously not to direct traffic using different rules for each website.
Probably, I am missing something out.
Thank you in advance.
Azure traffic manager supports the following traffic routing methods:
Priority, Weighted, Performance, Geographic, Multivalue, Subnet.
If you want to direct traffic based on the domain name, you need to create a separate traffic manager profile for each domain. Then create two endpoints by selecting Priority routing rules in each profile.
In addition, you could have a look at the Azure front door. With Front Door, you can transform your global consumer and enterprise applications into robust, high-performing personalized modern applications with content that reach a global audience through Azure. It supports URL-path based routing for requests. You also could assign priorities to your different backends when you want to use a primary service backend for all traffic.
TL;DR;
What's the way to distribute an SSL certificate across regions, so that no matter which region the application is hosted - it will serve the SSL certificate for the requested custom domains.
Explanation:
We have an Azure Web app where we add custom domains per user. We want to scale the app in different geographic regions behind a traffic manager so that when the website is accessed from Australia - it will be served from the Auatralia's Web App, and when the request comes from Europe - the web app in Europe will serve the request. So, in current situation, regardless of where the request is coming from it will always be served from one location, for example: Europe.
The challenge here is we can add the custom domain in only one of the web app, due to the fact that you need a CNAME entry pointing to an individual URL. It cannot point at two different URLs at the same time. It is possible to route the requests to individual apps but the other web app will not be able to serve the SSL certificate if it's mapped on App1 in region1.
How to distribute or maintain the pool of certificates which can be access by the web apps in different regions? Is there any way with Microsoft Azure?
Update:
We are going to have N number of custom domains, and so N number of SSL certs to handle. AFAIK, Azure Front Door and Azure Traffic Manager - we can map a custom domain to their own endpoints, and is limited to one custom domain. Here I'm talking about handling thousands of external custom domains/SSL Certs.
Thanks in Advance! 🙏
Instead of using Traffic Manager, I would use Azure Front Door. This has a built-in SSL certificate management. You don't even need to purchase the certificate yourself.
What I understood from the question is basically you would like to address the request from the same region rather than from one location. In that case, I would suggest have a look at azure application gateway. Here, you can define path-based load-balancing rules. In that path based, basically you can have one attribute which identifies location say /api/emea/images, /api/apac/images. Off-course you need to first define API on these lines to accommodate some kind of identifier. Once done, then based on this you can create this load-balancing rule in application gateway. Then, you can have different backend pools say one sitting in EMEA region with four-five virtual machines, that can handle traffic from EMEA region. Similarly, it goes for another region as well. Try implementing the same on these lines. You can also explore front door option as well as it handles load-balancing globally and your certificate related stuff should also get addressed. It should address your problem.
My traffic manager with performance routing method has two endpoints.They are in different region. I wanted to validate when I make a request to webpage, which endpoints served that requests. Is there a way to validate that, like any third party website or some tool in Azure itself?
You can use Traffic View to achieve the purpose. In Azure portal, find your Traffic Manager. Then click Traffic view in left and enable Traffic view.
After that, you can check DNS QUERY SOURCE IP and ENDPOINT to see where the request come from and which endpoint serve this request.
The result likes this screenshot:
I want to provide failover proof url for my service endpoint to users using traffic management. I have a service instance running at http://vm1.cloudapp.net/myservice:8888/index.html. If this instance goes down then the service auto starts on vm2 at http://vm2.cloudapp.net/myservice:8888/index.html n vice versa.
I want azure to hide the underlying service urls to user and expose the service at http://myservice.trafficmanager.net
Is this possible? If so, how ? From reading the documentation of traffic manager service, it looks like you can failover only at DNS level and not at url endpoint level
There are several parts to this.
Firstly, you are right that Traffic Manager works at the DNS level. It doesn't see your HTTP traffic and hence doesn't see the full URL. Since your two services instances have different DNS names, there's no issue here--you configure Traffic Manager with both names as separate 'endpoints', and Traffic Manager will direct traffic to those endpoints by providing one or other in each DNS response.
Secondly, you want to hide the URL paths. Since Traffic Manager works at the DNS level, it doesn't see your HTTP traffic and hence doesn't see the URL, only the domain name. Therefore this is something you have to handle at the application level (just as you would for a single-instance service that doesn't use Traffic Manager).
The only thing to be careful of is to make sure you configure the correct URL port and path in the Traffic Manager endpoint monitoring configuration. Just make sure that Traffic Manager shows your endpoints as 'Online', and you're good.
Jonathan