I've been struggling with adding a custom domain to one of my sites because it's already in use on another site. I have these:
TMProfile1 tm profile
+EastUSAppServicePlan1 app service plan S2
+eus-x-com.azurewebsites.net app service
+x.com custom domain
+WestUSAppServicePlan1 app service plan S2
+wus-x-com.azurewebsites.net app service
+x.com custom domain
These sites both have a custom domain of x.com set up. Both these sites are in the same traffic manager profile and the DNS points x.com -CNAME-> tmprofile1.trafficmanager.net. All is good
I've created another app service plan (this time an S1) called EastUsAppServicePlan2 and I created a new app service inside of it called eus2-x-com.azurewebsites.net. Even though this new app service is in a different app service plan to the two that already exist, I'm trying to add the same x.com custom domain to this new app service:
x.com custom domain is already assigned to website eus-x-com.azurewebsites.net
I always thought that an app service plan is analogous to an instance of IIS, and that every app service plan would have a unique IP address but it seems not. If I nslookup eus-x-com.azurewebsites.net (a site in EastUsAppServicePlan1) I get an IP of 12.34.56.78 and if I nslookup eus2-x-com.azurewebsites.net (the site in the new EastUSAppServicePlan2) I get the same IP of 12.34.56.78
It seems to be then, that it is region that determines IP; even if I create different app service plans in the same region, they will all have the same IP address? (It might explain some of the other issues I'm having)
By pulling the definition from the Microsoft documentation, we have:
Azure App Service is a multi-tenant service, except for App Service
Environments. Apps that are not in an App Service environment (not in
the Isolated tier) share network infrastructure with other apps. As a
result, the inbound and outbound IP addresses of an app can be
different, and can even change in certain situations.
So, even in same region you may have scenarios that your apps, using different service plans, have same inbound ip addresses, or different. That's managed by Azure, so you have no control over it, unless you have a scenario that you want to use a dedicated static inboud ip address to your apps, then you can leverage the IP-based SSL binding feature to have the same ip address for them.
Related
Let me get this out of the way, I am not that familiar with DNS setup. But I am wondering if I can have this setup. I cannot test this right now because I control the our Azure portal but not the domain name provider.
We will have 2 subdomains. For example, api.contoso.com and app.contoso.com
We currently have a single Azure App Service Plan with two apps inside. One is the frontend SPA, and the other is the backend.
Checking the IP address and Custom Domain Verification ID of the two services, they are the same! So I am wondering if the setup of the two subdomains is possible. If not I'll consider moving out one of the App Service to its own App Service Plan or maybe Just map a single custom domain to the frontend. Any tips or suggestion?
Yes this is completely possible and a very standard setup. You will use CNAME records in your DNS setup which means you won’t use the IP address of the VM that your app service plan is on. Instead a CNAME DNS record maps your custom domain to another domain - in this case the domain name of an app service.
You will configure a different custom domain on each app service (and ideally a certificate to protect it).
E.g. your DNS might look like this:
app.contoso.com CNAME myapp.azurewebsites.net
api.contoso.com CNAME myapi.azurewebsites.net
I.e. when a request is made for a domain on the left it will be forwarded to the domain on the right.
When a request is made for either of your custom domains the custom domain will be in the host header. This request will be routed to the app service gateway which will look at the host header in order to know which VM to route the request to and once on the correct VM which app service to serve the actual request.
Once you have the above setup you can query the DNS system to see the complete route that a request would take, e.g.:
nslookup app.contoso.com
may return:
Name: waws-prod-xyz-123-1234.uksouth.cloudapp.azure.com
Address: 99.99.99.99
Aliases: app.contoso.com
myapp.azurewebsites.net
waws-prod-xyz-123-1234.uksouth.cloudapp.azure.com
With this command you'll see the actual VM that your app service plan is on (I've made up the IP and VM name here!).
Playing with Azure App Service, I instantiated a simple web app. I tried to identify its IP address and found one in the properties of my app. It was described as 'virtual IP address'.
Trying to ping it or put it in my browser, it doesn't work and I can't find if it's an Azure configuration or a principle of virtual IP addresses... To be more precise, if I type '40.79.130.128' in my search bar, I crash on a 404 page, instead of my website page.
I read a bit on the topic, mainly what it is used for, but I don't understand if I can just reach it in my browser, because just typing it in my search bar is no use. What am I missing?
The Virtual IP address under your App Service on the blade Settings->Properties is the Shared IP.
The way IP address work in App Service is different. App Service app runs in an App Service plan, and App Service plans are deployed into one of the deployment units in the Azure infrastructure which is internally called a webspace and each of the deployment unit is assigned up to five virtual IP addresses, which includes one public inbound IP address and four outbound IP addresses.
All App Service plans in the same deployment unit, and app instances that run in them, share the same set of virtual IP addresses which means many App Services is behind same IP address hence you need to configure Custom Domain on your App Service to get it to work.
For configuring Custom domain refer to this link:
https://learn.microsoft.com/en-us/azure/app-service/app-service-web-tutorial-custom-domain
Please refer to below articles for details:
Inbound and outbound IP addresses in Azure App Service
App Service networking features
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.net so 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.com on 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.net app 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?
As far as I know, either the DNS name of Traffic Manager or App service is globally unique. We can not have the same custom domain to use for two different app services. Read ICANN.
So you still need a load balancer to route upper DNS level incoming traffic for your backend app services when you want to use the same custom domain. I also don't think you can switch DNS for app services in Azure without traffic manager. If you want to route traffic to app services in the same region, you could use nested Traffic Manager profiles. Read this answer for more details.
I have an azure website that I can access by
myname.azurewebsites.net
In Azure dashboard, the IP is 104.214.237.135
When I try to access my website by IP I have a 404 error
I don't understand. My plan App Service is S1
Regards
Azure App Service is a multi-tenant service, except for App Service Environments. Apps that are not in an App Service environment (not in the Isolated tier) share network infrastructure with other apps. As a result, the inbound and outbound IP addresses of an app can be different, and can even change in certain situations.
App Service Environments use dedicated network infrastructures, so apps running in an App Service environment get static, dedicated IP addresses both for inbound and outbound connections.
Azure AppService IP addresses are shared between tenants and not guaranteed to be static. Your app is bound to the hostname, not the IP address. Unless you are using App Service Environment, you cannot use a static / dedicated IP address with Azure AppServices. You can add additional custom hostnames to your app.
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?