In a bid to reduce our Azure costs we are looking to remove unused resources.
We have an app service that is part of a traffic manager setup, reachable when users type x.com in their browser. Two app services exist:
eus-x-com.azurewebsites.net
wus-x-com.azurewebsites.net
These are added to a traffic manager profile, and when they were added to TM they were configured to have custom domains to both be x.com
DNS for x.com points to x-com.trafficmanager.net, the name of the traffic manager endpoint that manages these two sites.
This means there is now:
//sites under Traffic Manager control of x.com
EastUS App Service Plan 1
eus-x-com.azurewebsites.net (with custom domain x.com -> x-com.trafficmanager.net)
WestUS App Service Plan 1
wus-x-com.azurewebsites.net (with custom domain x.com -> x-com.trafficmanager.net)
//sites not assigned to a traffic manager
EastUS App Service Plan 2
y-com.azurewebsites.net (with custom domain y.com -> y-com.azurewebsites.net)
z-com.azurewebsites.net (with custom domain z.com -> z-com.azurewebsites.net)
After some years it seems that eus-x-com.azurewebsites.net has never failed and it's not used much, so we're looking at having East US Service Plan 2 host one instance of x.com, plus the other sites it hosts and getting rid of the traffic manager, and the east/west service plan 1 leaving just service plan 2
The idea was to:
- create a new app service in EastUS App Service Plan 2 called
x-com.azurewebsites.net - deploy the code to it so it will work
- give it a custom domain of x.com (i.e. the equivalent of adding a host header in IIS)
- change DNS to point to
x-com.azurewebsites.netso that traffic gradually starts coming to the new web app as DNS servers around the world update - delete the whole TM infrastructure at some point
I hit a problem: even though I can validate DNS domain ownership I come up against a restriction that two different app services, even in different app service plans, cannot have the same custom domain setting unless they're part of a traffic manager setup. I get a "x.com custom domain is already in use on an app service eus-x-com.azurewebsites.net" when trying to add a custom domain of x.com to x-com.azurewebsites.net
This is a bit annoying as I foresee no reason why it should be technically impossible to have the same custom domain on two app services in different plans, if all it is (in old IIS terms) is a host header/binding; which app service is actually in use depends on which IP address traffic arrives at based on DNS. The custom domain binding is a routing mechanism to know which app service to pass traffic to when it arrives at an IIS hosting multiple sites. While I think it sensible that azure prevents multiple app services within the same plan from having the same custom domain assigned, I cannot see how it is logical to prohibit app services in different app service plans from having the same custom domain setting
Instead I looked at doing:
- create a new site in EastUS App Service Plan 2 called
x-com.azurewebsites.net - deploy the code to it so it will work
- add it to the traffic manager so that I can then set the custom domain of
x.comon it (because it's allowed to re-use custom domains if sites are on the same traffic manager profile) - change DNS so that traffic gradually starts coming to the new web app directly, bypassing TM
- delete the whole TM infrastructure at some point
This is where I get another problem:
Two app services in the same region (regardless of whether they're on a different app service plan) cannot belong to the same traffic manager profile. Even though these sites are on different app service plans, those plans are in the same region (EUS) and the error message in the portal is:
Traffic manager configuration is not valid because one or more domains do not belong to subscription 'xxx'
A github discussion from an MSFT employee said that this is a bogus error message that should be interpreted as "you can't have two app services in the same region be part of the same TM". You can have it if one of them is an external endpoint, but then it doesn't add the custom domain for you, which is the only thing I wanted out of adding the new site to TM
I then found out that I can, instead, edit the TM and change where the endpoint points to:
//existing setup
TM
east-us-x-endpoint -> eus-x-com.azurewebsites.net
west-us-x-endpoint -> wus-x-com.azurewebsites.net
//proposed setup
TM
east-us-x-endpoint -> x-com.azurewebsites.net //edit it to point to the new x-com
//delete the west US one
I've done this, and edited the endpoint to target a different app service. Though the portal says the change has been made there are problems:
- the traffic manager is definitely still sending traffic to the old app service, because the site works even though the new app service doesn't have any code on it yet
- stopping the old
eus-x-com.azurewebsites.netapp service (not configured in any TM endpoint any more) causes the web site to stop working with HTTP 503
Things might have worked out if I hadn't deleted west us already. Though not ideal because it was slower (database in East US) I could probably have deleted eus-x-com out of TM and let wus-x-com take the load, then added x-com (which is in EUS) to TM and made it priority 1, it would have got a custom domain, all good.. except there is no west us setup any more. I might have to add it back
I'm now stuck; I basically need two app services, in the same region, on different service plans, to have the same custom domain for a while so I can switch over the DNS then dismantle one of them. Or I need another way to set up a new app service so that it ready to take traffic, get all traffic to start going to it, and then remove the old setup
What steps can I take to get a new app service up and running, give a custom domain to it and then switch DNS over so that all traffic goes to the new site, without causing any downtime?
