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
Related
So I'm working on building scripts to deploy Azure resources using the Az modules in PowerShell. I am new to Azure Traffic Manager, so I'm wondering if what we are looking to do is even possible, and if so, how.
We have an API Management Service (APIMS) with a handful of APIs in it that point to a few different web apps within Azure. So the way it works currently is we have a client application that will post to a specific API operation via its APIMS URL.
We are looking at the idea of using Traffic Manager purely for moving traffic from one APIMS to a another in the event that we need to create a new APIMS. I can add the existing APIMS as an endpoint to the Traffic Manager as an external endpoint using its public IP address. But beyond that, here's what I'm unsure of:
How exactly would traffic actually get routed through the traffic manager, through the APIMS, to the specific API post? (as in, what would the client application need to specify as where it's sending its post?). Or would this even work??
If we create a new APIMS, can we then simply add that as a new endpoint to the traffic manager (again, as an external endpoint via its IP address), and then delete the old APIMS endpoint?
I did find this question that's similar, but that answer is using Add-AzureTrafficManagerEndpoint as opposed to New-AzTrafficManagerEndpoint, which is what I'm using and apparently does not support -DomainName as a parameter.
Traffic manager does not route traffic, it only does domain name resolution. You could use TM for that. For your custom domain in traffic manager (say contoso.com) you can add CNAME record pointing to contoso.azure-api.net (it's preferable to use CNAME instead of A and APIM service IP may change in certain scenarios). And add SSL certificate in APIM for contoso.com. What will happen in that setup:
Client wants to make request to https://contoso.com/myapi
Client will perform DNS lookup for contoso.com and see CNAME record pointing to contoso.azure-api.net
Client will perform DNS lookup for contoso.azure-api.net and see APIM IP address
Client will try to open SSL connection to APIM
APIM having SSL certificate available will accept the connection
Client will send request.
All this does not require any special configuration from your client apart from setting it up to use "contoso.com" as a hostname for your API. Later if you want to switch to a different APIM service you could go and update TM. Client will not require any changes.
The one thing to know is that this particular setup does not require TM per se. As all you really need is a custom domain from any DNS provider because all you need to do to switch traffic from one APIM to another is update CNAME record.
I have a Azure cloud service (abc.cloudapp.net) which has authentication enforced using OpenId-Connect. Recently I decided to put it behind a Traffic Manager (abc.trafficmanager.net) for maintenance reasons. After reading about how Traffic Manager works on Microsoft docs, my understanding (as per the flow diagram below) was that when someone hits the TM, it will simply do the DNS look-up for my cloud service and return a 302 with the location as abc.cloudapp.net (or IP may be) and then the client follows the redirect. The documentation clearly says so :
The most important point to understand is that Traffic Manager works at the DNS level. Traffic Manager uses DNS to direct clients to specific service endpoints based on the rules of the traffic-routing method. Clients connect to the selected endpoint directly. Traffic Manager is not a proxy or a gateway. Traffic Manager does not see the traffic passing between the client and the service.
But what I am seeing (through Fiddler/Chrome dev-tools) is that TM seems to be hitting the actual cloud service endpoint causing authentication issues as the redirect URL in my cloud service doesn't match the TM URL and so forth.
Is TM supposed to do this? Or am I missing something crucial here. Below is a related thread.
RequireNonce is 'true' (default) but validationContext.Nonce is null in Azure Traffic Manager , OpenIdConnectAuthentication
Traffic manager operates at DNS level, there is no 302 since it does not operate using HTTP. When a client makes a DNS query for your domain name, traffic manager will send back a DNS reply that the service is over there.
The client will then connect to the Traffic Manager URL/your custom domain using the IP address given by traffic manager.
So the URL the user sees doesn't change, traffic manager just tells them where the service is.
Say, I have two app service (HTTPS only is enabled):
https://myapp1.azurewebsites.net
https://myapp2.azurewebsites.net
I can call both app service endpoints using HTTPS successfully.
Then I created a traffic manager and add above two endpoints to traffic manager, say:
myapps.trafficmanager.net
After the traffic manager is created and endpoint added, the trafficmanger host name myapps.trafficmanager.net is also automatically added into custom domains of two app services. But without SSL binding to traffic manager host name.
Then if I call traffic manager endpoint using HTTPS: https://myapps.trafficmanager.net, I will got untrusted SSL cert error/warning. That is expected.
Since traffic manager just works on DNS level, the real request is actually send to the app service endpoint which has correct SSL cert binding. My question is:
From security point of view, is it safe to call the non-cert binding traffic manager endpopint using HTTPS in my code (say, using .NET HttpClient) but just ignore the cert error?
I recently set one of these up as well and fought with it for a bit. The short answer is that it is probably safe, but it sounds like you may be using the Traffic Manager incorrectly. You shouldn't be using the URL in the Traffic Manager as your end point if you want to use SSL. Instead configure your vanity domain name, mycoolsite.com to point to myapps.trafficmanager.net, using a DNS CNAME record.
If you want to use SSL and a single URL you should configure the custom URL and install an SSL cert at the service level. It should be same custom URL on both app services. This must be configured at in the app service, not in Traffic Manager.
I had to read this a few times to understand how it works under the hood, but it was helpful.
So in summary, to set it up properly, the steps would be:
Configure custom/vanity domain on both app services
Install the SSL cert on both app services
Setup and configure the Traffic Manager
Point the custom/vanity URL to the traffic manager using a DNS CNAME record
There is no need to bind a cert with traffic manager since the server certificate is not validated when using traffic manager health probes via HTTPS. Moreover, the traffic manager works at the DNS level. The clients connect directly to the selected endpoint, not through Traffic Manager.
In this case, you could use HTTPS for endpoints and use health probe via HTTPS. Even you could not bind a cert with traffic manager, you could make sure that the monitoring port is configured correctly in Traffic Manager (e.g. 443 instead of 80) and also your monitoring path points to a valid page for your service.
Another SO answer explains this more details. If you still want to make this warning disappearing, you can get a free SSL from letsencrypt.org and add that to your custom domain with the *.trafficmanager.net.
Question: How do I host an endpoint in azure which allows me to redirect internet traffic at will between azure and aws services?
I am hosting two kubernetes clusters - one in Azure and the other in AWS. I want to be able to:
1. redirect the traffic at will to either aws or azure, whilst retaining the public dns endpoint.
2. fail over manually [and pref automatically too] to the aws cluster. What is the best way to host the endpoint in azure?
Requirements:
The traffic needs to be redirected immediately - no caching issues and stale loads!
Ability to configure failover - i.e. specify that Azure is hot and AWS is the failover service - the traffic should be automatically redirected as soon as Azure goes down.
I have looked at Traffic Manager, Load Balancers and Application Gateway. Not sure which one (if any) of these is best.
traffic manager wont work for you, since its a dns service, so caching will happen (admittedly its the best solution if you set dns cache to 5 seconds or something). application gateway allows you to specify an ip address as an endpoint, load balancers only work when attached to vms inside azure. But application gateways dont allow to failover at will. you would need to block the probe to failover.
Azure Front Door might be the solution for you (like the other answer mentions)
You can have a look into Azure Front Door Service for your usecase.
Look into this https://learn.microsoft.com/en-gb/azure/frontdoor/front-door-overview
I am trying to experiment a little bit the different configuration possibilities in Azure and I am stuck trying to correctly configure SSL custom domains when using more than one Web Site (App Service) behind a Traffic Manager.
Without problem, I was able to:
Attach a custom domain ( subdomain.mydomain.com ) to an Azure App Service ( subdomain1.azurewebsites.net )
Attach a custom domain ( subdomain.mydomain.com ) to an Azure App Service ( subdomain1.azurewebsites.net ) behind a Traffic Manager ( subdomain.trafficmanager.net) (addressed here)
But when I try to add a second App Service behind the Traffic Manager, I get the following issues:
1. Cannot attach my custom domain ( subdomain.mydomain.com ) to the second App Service ( subdomain2.azurewebsites.net ). Error message is:
Failed to update hostname bindings:
The host name subdomain.mydomain.com is already assigned to another Azure website: subdomain1.
I don't understand how SSL will work with the second website if I can't add subdomain.mydomain.com in the list of domains it listens to (and in fact, it doesn't if you don't add it).
2. Cannot add the second App Service to the Traffic Manager's list of endpoints. Error message is:
Failed to save configuration changes to Traffic Manager profile 'mytrafficmanager'.
Error: Some of the provided Azure Website endpoints are not valid: One or more conflicts detected in traffic manager configuration. Multiple domains point to region "West Europe": subdomain1.azurewebsites.net, subdomain2.azurewebsites.net
But when I read the documentation it does seem possible to add more than one endpoint in the same region:
If your profile contains multiple endpoints in the same Azure region, then traffic directed to that region is distributed evenly across the available endpoints (based on the configured endpoint enabled/disabled status and the ongoing endpoint monitoring). If you prefer a different traffic distribution within a region, this can be achieved using nested Traffic Manager profiles.
The example using Traffic Manager and App Service on MSDN's documentation only shows how to do it with one App Service.
Am I doing anything wrong? If yes, what is the right way to add several websites/App Services behind a traffic manager in Azure?
Traffic Manager does support multiple endpoints in the same region. The challenge is that the App Service has restrictions on multiple Apps in the same region sharing the same custom domain. This impacts on Traffic Manager, since the Traffic Manager profile DNS name is automatically added as a custom domain in your apps when adding them to Traffic Manager.
We are in the process of publishing new documentation that covers this exact scenario. Pasting the new text below:
Can I use Traffic Manager with more than one web apps in the same region?
Typically, Traffic Manager is used to direct traffic to applications deployed in different regions. However, it can also be used where an application has more than one deployment in the same region.
In the case of Web Apps, the Traffic Manager ‘Azure Endpoints’ type does not permit more than one Web App endpoint from the same Azure region to be added to Traffic Manager. The following steps provide a workaround to this constraint:
Check that your Web Apps within the same region are in different web app 'scale units', i.e. different instances of the Web App service. To do this, check the DNS path for the <...>.azurewebsites.net DNS entry, the scale unit will look something like ‘waws-prod-xyz-123.vip.azurewebsites.net’. A given domain name must map to a single site in a given scale unit, and for this reason two Web Apps in the same scale unit cannot share a Traffic Manager profile.
Assuming each Web App is in a different scale unit, add your vanity domain name as a custom hostname to each Web App. This requires all Web Apps to belong to the same subscription.
Add one (and only one) Web App endpoint as you normally would to your Traffic Manager profile, as an Azure Endpoint.
Add each additional Web App endpoint to your Traffic Manager profile as an External Endpoint. This requires you to use the ARM experience for Traffic Manager, not ASM.
Create a DNS CNAME record from your vanity domain (as used in step 2 above) to your Traffic Manager profile DNS name (<…>.trafficmanager.net).
Access your site via the vanity domain name, not the Traffic Manager profile DNS name.
Regards,
Jonathan Tuliani, Program Manager, Azure Traffic Manager
Jonathan,
This issue is still confusing when integrating SSL.. I'm not trying to add instances to the same region, but diff regions.
https://azure.microsoft.com/en-us/documentation/articles/traffic-manager-how-traffic-manager-works/#traffic-manager-example
This article does a good job of explaining the routing, but minus the SSL..
From the image. Say this is my configuration.. I have a *.contoso.com wildcard SSL. Of the 3 endpoints, contoso-us, contoso-eu, contoso-asia - which one do I install the SSL? Preferably all 3, but I can't set the all to use the custom domain and the SSL..
What am I missing here?