This article answers the following questions:
1. Can there be multiple static web sites hosted on the same storage account behind the front door in different containers?
2. Can there be different domains associated with each of the static websites?
3. Will the routing and caching change when navigating directly to that path or via domain?
4. Will there be a need to divert traffic on path basis or keep it at apex level for each static website.
Answers:
1. With or without the use of an FD, a storage account can host multiple static websites but the organization differs significantly. The most straightforward approach is to create separate storage accounts for each static website as called out by 1 and 2 in the references
2. Website can be reached via $web if the static website setting is enabled: on the storage account. All paths to any assets in $web can be reached directly via the primary endpoint shown in the screenshot above. This makes it convenient to share assets across different usages and even websites if they make a web request to the same endpoint and path for that asset. Treat this just like permalink for assets that must not change location for many callers.
3. Dedicated websites that differ in purpose must be separated as website1 and website2 folders. In this case, they can both be nested in the $web container but their respective folders will become part of the path. This becomes an acceptable solution even without fd so long as the primary endpoint can be tolerated to be the same for both websites and to have the website1 and website2 as static path and part of url. This completes the built-in support for one or more static websites with just a storage account.
4. Many applications want to avoid path qualifiers in the url simply because it reflects the actual location to a caller who could have been given that asset with an alias so that it is easy to move around the actual location for planned or unplanned reasons.
5. It is at this point that FD comes helpful because 1. you have the luxury to use as many aliases to separate your business usages. Since $web is default, even a single alias can hide the actual storage account while leveraging /website1 and /website2 as earlier because fd has no knowledge about those paths and doesn't do any routing other than to the $web as a backend member that it refers to as origin. 2. you can nest your website anywhere in the storage account without regard to $web.
6. Aliases aka subdomains are also inexpensive and having them reflect the environment or business purpose makes it easy to tell apart any traffic without a lookup. By adding separate origins to send traffic from separate aliases keeps the routing and caching with default values which prevents unexpected behaviors when they are set with custom settings. More than routing, custom caching settings also called cdn settings in fd routes often give a different response for the same request at different times unless the caller leverages purging either on flushed/ad-hoc basis or the built-in scheduled basis. So keeping everything simple naturally moves to having different storage accounts for different purposes/environments.
7. FD also has sophistications for routing and caching that should also be called out because they are simply not possible with a storage account. For example, An FD can allow a static website to be hosted in any container outside the $web as well because it treats that as a path within the origin. The change to the routing is that FD has a rewrite functionality similar to an app-gateway where specifying a path qualifier such as /site1 can be replaced with a full path list /path/to/site1 while leaving the rest of the unmatched parts of the url including the endpoint and the individual asset file with query parameters intact. A sample screenshot is included for this purpose.
8. This successfully helps to translate moniker urls that do not have actual location such as https://foo.optum.com/site1/ to actually translate to "https://foo.optum.com/path/to/index.html" where foo.optum.com automatically reaches the destination storage account without relying on the internal support of that storage account leveraging $web. When testing with this option the following limitations were observed and appear to noteworthy:
a. the pattern match including wild card characters is very tricky to capture all edge cases where callers may or may not include a slash at the end of their url.
b. the only other option to rewrite that helps with routing to multiple websites is redirect and that significantly introduces a whole new set of issues.
The conclusion from the above two in terms of the features available with app gateway indicate that FD has poor support for path based routing but a rich support for mapping 1 apex to 1 origin. In fact, the combination of these two limitations forces deployments of fd to separate origins to different origin groups. while it is easy to leverage priority and weight to distribute of all the traffic specificed by a route to more than one origin in the origin group, such activity is only for load balancing and not for user traffic splitting to different websites.
9. The caching settings include a checkbox and drop down on each route. There are default settings for this that work well with the scheduled purges of the FrontDoor but customizations based on compression and query parameter allow to target different asset types and associated key-values in the urls. If there are further relays before the fd and to the caller, these can introduce significant complexity.
10. The ability to have the TLS work for each alias because the certificate automatically renews elsewhere and is not stored on the front door or in a key vault allows the convenience that each apex level can work independently and maintenance-free which is why it directly shows how many days before the certificate expires on the fd itself but automatically rolls over.
References:
1. https://learn.microsoft.com/en-us/answers/questions/254127/hosting-multiple-static-websites-on-azure-blob-sto
2. https://learn.microsoft.com/en-us/azure/storage/blobs/storage-blob-static-website
3. https://1drv.ms/w/c/d609fb70e39b65c8/EboOa84huEROjJO7OPF1GwkBFo7QmjvquCoNm_YmLzzJ1w?e=ciAlDa
#codingexercise: CodingExercise-03-06-2025.docx