Azure storage containers and routing from wildcard root domain - azure

I have a storage account in Azure with a container named clients. Inside the container I have folders for various clients, i.e:
mysite.blob.core.windows.net/clients/one
mysite.blob.core.windows.net/clients/two
I also have my own site set up as a static website, i.e:
mysite.z33.web.core.windows.net
On top of that, I have a custom domain: mysite.com. Is it possible, using Azure CDN or Azure Front Door/Application Gateway to route traffic like so (in a way that doesn't require further configuration per client):
one.mysite.com -> mysite.blob.core.windows.net/clients/one
two.mysite.com -> mysite.blob.core.windows.net/clients/two
mysite.com -> mysite.z33.web.core.windows.net
So far I have tried doing this with Azure CDN but I don't think it's possible, it has a rules engine that seems quite flexible but I don't think they support wildcard domains, unless I'm (hopefully) wrong. Ideally I'd like it to be done in some sort of wildcard way, so that is maps:
<client>.mysite.com -> mysite.blob.core.windows.net/clients/<client>
I don't really want to have to add more rules or configuration every time I have a new client.

In fact, you could use an alias record to add a root domain as the custom domains in your CDN endpoints if you use Azure CDN to host your DNS zone. In this case, you need to set up multiple endpoints for each custom domain. See this document for more details. But Pointing a zone apex to CDN endpoints for Azure CDN from Akamai is currently not supported. You can use other CDN price tier.
If you use the Azure application gateway, you may configure multiple sites listener to receive different incoming host traffic and use path-based URL rules to route the traffic to the backends. It looks like a complex configuration and hard to troubleshoot the app gw related issue.
The azure front door should also do this trick, it supports onboard a root domain on your Front Door also allows wildcard domains. The route path is also easy to configure. See path matching for more details.
Hope this information could help you.

Related

Azure Firewall Routing to multiple backends

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

Map a specific Web App Service Path to a Custom Domain

I am looking for a way in Azure to map Web App Service paths to domain names I own.
For example
Map xyz.com to .azurewebsites.net/Views?id=xyz
Map abc.com to .azurewebsites.net/Views?id=abc
Is this possible ?
I know I can map xyz.com to .azurewebsites.net and use the custom domain feature to do so.
You can do this, just not with straight DNS. Easiest way in Azure to do this, in my opinion is to create a Front Door - which is a really easy-to-configure and fully-featured HTTP load balancer (note I call out HTTP here, as this is the level on which Front Door works - if you need lower-level protocol support you'll need another solution).
Front Door allows you to register custom domains ("front end") addresses and then map them to different web apps ("back end services") using routing rules. Those routing rules allow you to either forward (which would act similarly to a reverse proxy) or redirect to your desired path.

Azure front door to support multiple web app by path under same domain

I have a question about azure front door potential for this. So I have 2 web site running by Azure App Services and I need then under same domain name but different path of URL like this:
App Service A -> www.something.com
App Service B -> www.something.com/b-product
I'm not sure this is possible to use Azure front door or I should use another service to solve this problem.
Do somebody can suggestion to me?
Yes you can do this fairly easily, when you create your routing rule you have the option tom specify patterns to match, there you can specify /foo and have this forwarded to pool A where app service A lives
Then you create a different routing rule with /bar pattern to match and forward that to pool B
Then you can repeat this until you get what you need.
you can also have one routing rule match the / domain as per your example you don't have to use a /foo pattern you can also do /* but I always found it easier to use /foo/* and /bar/* to keep the same URL structure
As suggested by Junnas , you can use the front door rules engine
Alternatively , you can use application gateway listeners
If you want all of your requests (for any domain) to be accepted and forwarded to backend pools, choose basic. Learn how to create an application gateway with a basic listener.
If you want to forward requests to different backend pools based on the host header or host names, choose multi-site listener, where you must also specify a host name that matches with the incoming request. This is because Application Gateway relies on HTTP 1.1 host headers to host more than one website on the same public IP address and port. To learn more, see hosting multiple sites using Application Gateway.

Unable to access CDN endpoint via custom subdomain

my team and I are currently exploring using Azure static site blobs and CDN endpoints to host several web apps.
We have successfully deployed our static files to the blog storage and our entire test app loads on both the primary (name.abc.web.core.windows.net) and CDN (name.azureedge.net) endpoints. When it comes to mapping a custom subdomain via the “cdnverify” temporary step, however, I am unsuccessful.
I have very carefully followed and quintuple-checked all steps in the support doc "Tutorial: Add a custom domain to your Azure CDN endpoint" (here).
This is my current DNS config (via Namecheap).
When I skip the cdnverify step, e.g. assign the azureedge CNAME value directly to a host called “v2”, and add that as a custom domain in my Azure portal CDN blade, the subdomain begins loading the CDN endpoint and can even have a CDN-managed HTTPS cert deployed with no manual verification. A dig command to this host (v2.ourdomain.org) finds an expected response (view here).
Here's the rub, though. If I assign a CNAME host of “cdnverify.static” to “cdnverify.name.azureedge.net.” and add it as a custom domain in the portal’s CDN blade, however, this secondary subdomain never loads our endpoint, and cannot deploy an HTTPS cert. The Azure portal verified this host when added to the endpoint and a dig command to “cdnverify.static.ourdomain.org” shows this answer, which looks good.
A dig command to “static.ourdomain.org” returns no answer and a ping command says “unknown host”. This is expected since I’ve not created such a record yet, and so I am wondering how we’re meant to ensure this subdomain is verified as per the “Verify the custom domain” section in the above-mentioned doc.
It’s very important for us that the cdnverify host works and can be assigned a certificate before we permanently re-locate our domains as these apps are already in production. At this point, I am at a loss over what to try next. If possible, I’d love to know what step(s) I am missing, or what can further be done to diagnose the issue.
Many thanks to anybody who might have some advice!
The cdnverify subdomain is to create a temporary CNAME mapping to avoid interruption of web traffic. With this method, users can access your domain without interruption while the DNS mapping occurs. If you have not any existing web app work, you can skip the cdnverify step.
From your description, "a dig command to cdnverify.static.ourdomain.org shows this answer, which looks good." It indicates that the cdnverify host works and you have verified that. You just need to associate the custom domain with your CDN endpoint.
In this step, you enter your custom domain like static.ourdomain.org, including the subdomain. Do not use the cdnverify subdomain name.
After you have added the custom domain static.ourdomain.org successfully in the CDN endpoint.
At this point, your custom domain has been verified by Azure, but
traffic to your domain is not yet being routed to your CDN endpoint.
After waiting long enough to allow the custom domain settings to
propagate to the CDN edge nodes (90 minutes for Azure CDN from
Verizon, 1-2 minutes for Azure CDN from Akamai), return to your DNS
registrar's web site and create another CNAME record that maps your
subdomain to your CDN endpoint. For example, specify the subdomain as
www or cdn, and the hostname as .azureedge.net. With
this step, the registration of your custom domain is complete.
After you have completed the registration of your custom domain, verify that custom domain references your CDN endpoint.
Finally, you could freely remove the cdnverify CNAME record in your domain provider as it was necessary only as an intermediary step..
Ref: https://github.com/uglide/azure-content/blob/master/articles/cdn/cdn-map-content-to-custom-domain.md#how-to-map-custom-domain-to-content-delivery-network-cdn-endpoint

How to replicate SSL Certificates for a custom domain in different regions

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.

Resources