Best suitable approach to configure multi-tenant subdomains and their SSL certificates with multiple AppServices on Azure

RJD 21 Reputation points

I have a .Net Core web application running on Azure Appservice connected to Azure SQL DB (Elastic Pool). The application is multi-tenant with tenant identification using subdomains.
I want to setup multiple Appservices in different regions in order to deliver optimal performance to customers. I'm currently not thinking about load-balancing across regions with mirrored databases etc. A customer/tenant is linked to one appservice which has its own database server and pool.
I want to understand how to configure this with regards to wildcard-subdomain SSL certificates and the url for the tenant.

If I have 3 appservices (as1, as2, as3) on my domain ( I could setup each appservice as a separate subdomain, each with its own wildcard SSL certificate (* …) and then have a url for my customers like,
Ideally I would like my customers to go to, … and then have them routed to the correct Appservice which means I would only need 1 wildcard SSL certificate.

So, should I keep it simple for now and go for the url-per-appservice with an SSL certificate per appservice subdomain or choose the more elegant approach of having 1 url for all appservices (which I don't know how to configure :) I know about Front Door and App Gateway but not sure if these are what I'm looking for.

Should I even worry about setting up in multiple regions? The application is basically data-entry with API's for importing and exporting data.

Azure App Service
Azure App Service
Azure App Service is a service used to create and deploy scalable, mission-critical web apps.
6,532 questions
0 comments No comments
{count} votes

Accepted answer
  1. Evgeny Grishchenko 486 Reputation points

    Routing and certificates does not depend on each other.

    My suggestion four your ideal situation:

    1. Create 3 web apps (,, with custom domains*
    2. Assign the same wildcard certificate to each of them (*

    *-you have to claim them (a proper CNAME record is required, for example)

    If you would need more high availability and more advanced routing (GEO, ...), then the solution would be different.

0 additional answers

Sort by: Most helpful