Stop/Start Virtual Network Gateway - to don't pay when it not in use
There are two charges related to the Azure VPN service: the compute resource charge at $0.05/hour, and the egress data volume charge. Both are based on resource consumption, Unfortunately, even if the VPN tunnels are not connected, the gateway compute resource is still being consumed and will cost ~$38 monthly!
This is not really "Pay only for what you use".
Need functionality to “STOP” (and of course "START") a gateway if the customer is certain that the gateway will not be in use.
We’ve moved this ask to the backlog due to technical challenges in reserving Public IP addresses during stop state.
Mike S commented
Seems like it might be better to spin up your own "VPN gateway" some other way than pay for this money sucking pig. Maybe go pay for a 5 dollar per month VM on digital ocean and add an NSG that only allows tunnels from there. It also seems to me like it needs some capability to issue client certs and revoke them. I may be doing it wrong but for my use case it it seems right. Why is this so expensive, it should actually be free,
Hello, any update on this functionality? This is becoming far too expensive!!!
Erick Correa commented
This is a problem that I have since the beginning of the creation of virtual machines, so far I pay 150 dollars per month for 733 hours, this I have for 6 months.
Please add this option, thanks
Ho hum...still waiting...still paying M$ wasted dollars for this.
Yes please on this!
Agreed, it makes VNG a non-starter for a P2S test link for WfHome. I'll have to continue with Heath Robinson until the Start/Stop functionality is in place. :(
Yes please on this. I just setup a VPN gateway to get access to my DevNet and the VPN is eating up most of my dev money.
Update on this?
Brian Mather commented
@azurenetworkingteam any further update on this?
Please give option to disable otherwise it makes no sensefir us.
Option should be there to Stop and Start VPN Gateway. Created High Availability instance with SQL Always On with DR as secondary replica. Will Start and Stop the VMs whenever testing is required, but unfortunaltely no option for VPN gateways and ending up in paying 20k/month.
Completely agree, I use resources for development and test, I would shut down resources when not in use and don't pay for them. The only exception is storage, anyway I feel I should be able to shut down storage (eg ssd) and pay only for a backup fee. When I need it, I may move to ssd and pay premium.
Upvoted. The single most expensive component of my test VM environment is the VNG. I would like to add that Azure forces you to use an expensive VNG to connect generic App Services to Virtual Machines. This could be accomplished using routing tables over the Azure backbone, but NO, you need to build a VPN to connect the two. I have no other VPN need other than connecting App Services to VMs, so all the other functionality is purely overhead.
ALSO, the VPN connection that had been working for years suddenly stopped because MS decided to change how Cisco ASA's connected to Azure. NO ADVANCED NOTICE. Buyer beware!
@AzureNetworkingTeam - It's been nine months since you claimed this was "planned." When are you going to stop shoving Azure down people's throats and start making this an affordable and useful platform. I'm ready to shut down everything in Azure and move it back on-premise. Azure is a waste of money, time, and resources. This is a PRIME example of the bait-and-switch promises MS makes to get you in Azure. Once you're in Azure or VSTS, it's nearly impossible to move back On-Premise. I'm ready for the challenge after the problems we've had.
John Payawal commented
Brian Douglas commented
ETA on this??
p l commented
Folks, this is most likely because somewhere in the service infrastructure there is a cost per connection licensing fee. Might be to an outside hardware vendor, or the way the underlying network infrastructure cost is calculated. It's probably the fixed cost of each connection that is expensive, and it has nothing to do with bandwidth, CPU, etc.
This generally happens when a product has to be built and provided quickly. You rely on outside vendors or other internal teams to help you build the service and they nickle and dime you with per item connection costs or you feel you need to recover the initial investment in something.
Or, I guess it could be something even dumber. Maybe there's a metric or goal around a fixed number of $$'s per connection. And this would be the only way to get there.
Or something completely different. But either way, it's clearly not been designed as a grow on demand, fully scale-able, kind of service.
Whatever it is, it's clearly a "cut your nose off to spite your face" short sighted kind of mentality. And you won't get a fully scale-able service until they fix the real underlying problem.
Daniel Klemm commented
Ouch, I just got stung by the standby rate assuming I was just paying when connected. Annoyed becuase it took make 4 hours to set the thing up not I need to remove :-\