HTTP -> HTTPS redirect routing shouldn't count in the price
The current pricing of Azure Front door service is $0.03 per hour per routing rule (~27$ per month per routing rule). Adding a rule for simple HTTP -> HTTPS redirect immediately increases the cost by $27 per month.
Who am I to suggest prices, but I think it would be nice if a simple HTTP -> HTTPS redirect didn't count in pricing.
I agree on the cost per route pain. Especially for dev/test where we have no usage but lots of routes. I don’t mind paying in prod where there is lots of usage.
Victor Bergamin Marques Roque commented
Can't we have one more option in the "Accepted protocols" menu like "Redirect HTTP to HTTPS"? It makes a lot more sense.
Ken Sykora commented
In general the pricing structure is somewhat painful. Having an hourly cost per-route seems like an arbitrary model to us. Why is the cost per route and not just purely based on traffic served?
For our use case, we have a number of front end applications and want to route them through a single custom domain. Each of these applications incurs that $27/mo cost even if they only have a few users. Whereas we have a few applications that have many, many users and drive 90% of our traffic, which would make sense that we might pay more for those.
Carl-Johan Blomqvist commented
A complementary suggestion would be to not have redirects in general cost as much, or change pricing somehow so that this doesn't cause this type of unfortunate issues. I assume redirects aren't in the same ballpark as expensive to handle for Azure as proper forwarding, thus it seems reasonable that redirects are very cheap. ~$27/redirect/month is quite expensive, for something you can put in your web.config and more or less have for free (I'd prefer to keep such redirects as above in front door though).
Anyway, some thoughts...