Global Router Solution for Billing-Sensitive API Use Cases
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.