Whats happening with 'legacy' Virtual Network Gateways?
So the documents all describe 'Basic', 'Standard' and 'High Performance' SKUs as being 'Legacy'.
I'm assuming this means that they are no longer being actively maintained and are likely to be made obsolete in the near future?
If so, why is 'Basic' contained amongst the new Gateways on the pricing page? https://azure.microsoft.com/en-gb/pricing/details/vpn-gateway/
There is a huge price difference between 'Basic' and 'VpnGw1'. Im comfortable paying for 'VpnGw1' in my production environment but not comfortable spending that much for my test environments.
So if I want to maintain consistency and eliminate variables between my environments I just have to pay for it, which leaves me with a bitter taste.
Can you offer a lower VpnGw0 offering for the same price as Basic? Then I can be happy that my test and production environments are using the same 'generation' of VNG technology, just with different performance levels.
We dont plan to have a separate SKU for testing purposes that supports all the GW features that we announce and is priced much less than our current SKUs. Your best option is to use the VpnGw1 SKU which is least priced and supports all the features.
p l commented
Yeah, I kind of agree with the original question. What ever happened to Azure's philosophy of start small grow insanely big? Offering different products at different price points effectively negates the value of cloud.
My guess is that this is driven by per connection licensing costs underneath the covers and there is no clean way to offer a less expensive low use option. In other words, bandwidth is not the driving cost factor.
Oliver Tomlinson commented
In response to the 'Declined' Comment. Using VpnGw1 is a poor option as it is too expensive to have provisioned 24/7 for a test environment, and even if we tore it down every night to save on financial cost, we would incur a time cost re-integrating the VNGs public IP into our on-prem firewalls every morning.
As it stands we are going to have to run Basic in Test and VpnGw1 in prod - Different technology = zero certainty between environments.
I can pre-empt the RCA/'5 whys' already -
"Why were we running different VPN technology between Dev and Prod?" Because like-for-like was too expensive and there was no viable alternative"
Oliver Tomlinson commented
@Aanand If the only difference was performance then yes I would totally be fine with running Basic in DevTest and VpnGw1 in production. But this isn't the case as the feature sets are different.
The whole point of a test environment is that we can run a 'like-for-like' environment that matches production in every way, apart from performance. The Legacy and New VNGs are different families of technology, so any time we spend gaining confidence on Basic SKUs in our test environment is wasted as that confidence is based on technology that we are not using in production (VngGw1/2/3 etc)
It is highly likely that I will be wanting to use active-active configuration that is only supported in the new VNGs. How can I gain confidence in my configuration without running it in my DevTest environment for any length of time? The only way I can do this is if I'm prepared to pay over a £100 a month for it. I can't simply tear down the VNG at the end of the business day to save cost, as every time the VNG gets recreated (which would be every business day) I get a new IP address which then I must get my Tech Ops team to update our firewall configuration every morning which is unfeasible as its such a costly operation in terms of time and effort.
I recommend creating a VpnGw0 tier that has a highly reduced bandwidth with the same feature set that we can truly use for DevTest and isn't going to cost an absolute fortune.
Aanand Ramachandran commented
Basic will stay and hence you find it on the pricing page. Basic GWs will not go away. The purpose of Basic is just to setup a simple P2S connection. For production deployments we recommend using VpnGw1/2/3 and they replace the Std and HiPerf GWs. If you want to use something for testing and then move to higher performing SKUs for prod then you start with Basic GWs in your test environment.