This is a continuation of previous articles on IaC shortcomings and resolutions. With the example of Azure Front Door, we were explaining the use of separate origin groups for logical organization of backend. This section talks about organization of endpoints.

An endpoint is a logical grouping of one or more routes associated with domain names. Each endpoint can be assigned a domain name either built-in or custom.  A Front Door profile can contain multiple domains especially when they have different routes and route paths. They can be combined into a single endpoint when there is a need to turn on or off collectively.

Azure Front Door can create managed certificates for custom domains even when the dns resolution occurs outside Azure. This makes https for end to end SSL easier to setup as the signed certificate is universally validated.

The steps taken to create endpoints is similar on both the frontend and the backend. The origin should be viewed as an endpoint for the application backend. When an origin is created in an origin group, Frontdoor requires to know the origin type and host headers. For an Azure app service, this could be contoso.azurewebsites.net or a custom domain. FrobtDoor validates if the request hostname matched the host name I’m the certificate provided by the origin.

Thus, separate endpoints, routing and host header all play a role in determining the responses from the Azure Front Door.

Previous articles: https://1drv.ms/w/s!Ashlm-Nw-wnWhO4RqzMcKLnR-r_WSw?e=kTQwQd