We are looking for a Global Router Solution for Billing-Sensitive API Use Cases and we worked with multiple parts of Azure support (namely Front Door, Azure API Management or APIM, as well as Networking) to check whether our use case is supported.

We found out, working with multiple support teams that such use case is not really supported right now and we were strongly encouraged to submit this idea as soon as possible on this feedback forum for potential review by the global community and the respective Microsoft teams. (Initially submitted on this forum, as of 7/21/2020)

In current model as of July 21, 2020. rules blocked by WAF in Azure Front Door charge the inbound rate even if the WAF rule blocked it. This is because the request is passing through Azure Front Door + WAF as one single unit for the purposes of billing. This is similar to how Azure CDN and all other global Layer 7 routing solutions Azure has currently works and bills when they are at the global level. This is confirmed by Azure Support as of 7/21/2020.

Either by changes or features in Azure Front Door, or via another way, this idea submission requests the implementation of a global router functionality that does not charge for inbound traffic that is blocked at the "edge" or perhaps a better term with be the "rules" level. In other words, functionality to support rules that if/when they define a block or deny state, that inbound ingress (especially) is not charged, and preferably not the egress either if possible for the blocked traffic triggered in this way (perhaps with option of a mode whether to respond to the connection, which would incur a small charge, or not respond at all, which would incur no charge. This idea submission is focused more on just the version that would not respond to the connection at all, as existing functionality in current products already processes and bills all requests and returns responses already all the time as-is – however, this nuance is mentioned in case it could still be relevant for this kind of functionality to offer the option of the two at that level of the rule ).
Also, we would prefer not charge by how many times the rule was triggered per period, instead we would rather prefer to pay for each definition of these kinds of rules themselves on a per rule per hour basis or something like that (however, hopefully a reasonable pricing either way).
The preferred way of blocking this kind of traffic would be to have the option to simply hang the connection and not return a response if possible (sort of like NSG's can do at the Virtual Network level, except to apply this at the top global level somehow), since existing functionality already can block and return a response e.g. APIM policy, even to some extent Front Door rules, etc. It is desired that this specific kind of "blocking" actually be somewhat similar to perhaps the way NSG's block traffic on Virtual Networks (for example) that don't match an NSG allow rule or that matched an NSG deny rule - the infrastructure just doesn't return any response at all and there is nothing that processes the request directly when the rule doesn't match. This is for purposes of only high level illustration and this specific example may or may not be based on exact specific working models of current Azure products, and we do not necessarily imply a specific implementation methodology in this idea submission, this specific paragraph would be intended more as a general conceptual reference and there could be likely more than one approach here.

There is more to this idea but it exceeds the description max length - the full idea is attached here as a text file.

Thanks for considering this idea.

I would like to inquire about an issue in the CSP portal.
For an end customer with the Self Service and Password Write Back feature enabled in Azure AD, the correct helathy status is being showed up as working,, this is only being displayed when the tenant is accessed directly through the Azure Portal (portal.azure.com), form the end user perspective.
If the customer environment is accessed from the partner portal, the same features are being showed as "not working".

This will undoubtedly cause issues for engineers that are trying to essentially fix an issue that is not really broken.
And the CSP are going to notice their customers on a false alarm.

Is there any feature for the CSP portal that can be created in order to track the healthy of these products? Or can this be fixed?

Thanks.

I tried the new Azure Static Web Apps preview for a Gatsby project of mine. I was really amazed by the simplicity of the deployment process and the speed of the web site. There was a deal breaker, though.

What really kept us from switching from Netlify to Azure Static Web Apps was the lack of control over HTTP headers. I need to be able to for example set the cache-control header on a per-file as well as per-directory basis. The same thing goes for the link header, although that would not break the website. There also needs to be an option to set other headers arbitrarily, for example security headers.

I do know, that most of those things could be done with a CDN and we have tried that. The problem with that option is, the limitation of the maximum number of rules and the number of actions per rule. It is impossible to set all appropriate security headers, while still keeping the fine grained control of caching that we need.

If or when Azure Static Web Apps gains the ability to set headers on the same level of detail as Netlify does, it will become a serious competitor to the market leader on the JAM-stack.

Here is a reference to the Netlify way of doing things. I think it is excellent in it's simplicity and could be used as an inspiration for Azure Static Web Apps.
https://docs.netlify.com/routing/headers/