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

Question

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 (mydomain.com) I could setup each appservice as a separate subdomain, each with its own wildcard SSL certificate (*.as1.mydomain.com …) and then have a url for my customers like tenantA.as1.mydomain.com, tenantB.as2.mydomain.com …
Ideally I would like my customers to go to tenantA.mydomain.com, tenantB.mydomain.com … 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.

Answer 1

Routing and certificates does not depend on each other.

My suggestion four your ideal situation:

1. Create 3 web apps ( tenantA.mydomain.com, tenantAB.mydomain.com, tenantC.mydomain.com) with custom domains*
2. Assign the same wildcard certificate to each of them (*.mydomain.com)

*-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.