I'm managing seven active projects on Azure, each with its own environments like development and production. Most of them require a database and an Azure function. To enhance security, I want to eliminate public database access by placing the databases inside a Virtual Network (VNET). My proof of concept confirmed that the Azure function can access the database through VNET integration. However, I regularly check these databases, and so do others. I've realized that using a VPN Gateway is an option, but it's pretty expensive—over $20 per month for each VNET. Given that different team members have varying access levels, I need to keep the infrastructures strictly separated, meaning I can't consolidate projects into a single VNET. This leads me to the conclusion that I'd require one VPN Gateway for each environment, which totals around $200 a month. Am I overlooking something? Is there a more affordable method for connecting to VNETs from our local machines (we're all using MacBooks) that keeps everything secure and separate?
5 Answers
Using a VPN Gateway for each VNET isn't the best strategy unless there's a strong justification for it. As mentioned, implementing a hub-and-spoke design with a gateway in the hub could be better, or you could look into having a simple jump host without a gateway. It all depends on what your exact requirements are.
As highlighted, go for a hub-and-spoke model: one hub VNET with a VPN Gateway and DNS resolver, plus a spoke VNET for each environment. This setup allows for as many subnets as you need, with appropriate network security groups and private endpoints tailored for each project.
Another alternative could be setting up your connectivity hub with a P2S VPN Gateway. Properly configured, you could incorporate an Azure Firewall for both DNS proxy and routing traffic, allowing VNET peerings from all your DBA environments to the hub. Ensure your developers' access is managed at the database level, so even if they have network access, they'd still need proper authentication for their granted access. Just keep in mind the DNS setup, since clients need to resolve the private endpoint IPs properly—using static routes can work, but it's not the best practice. A DNS resolver would likely be more reliable.
If you absolutely need to keep the environments isolated, consider setting up your own VPN appliances on cost-effective VMs. One upside is the ability to start and stop those VMs, which could save some money. But honestly, it might not be worth the effort unless you're really running tight on budget; the time spent on setting that up could negate any financial benefits. If you can be flexible, I'd recommend going with the single access point solution mentioned earlier.
You might want to consider having a single access point VNET with the VPN gateway attached. You can set up private links from that VNET to the private endpoints of your databases in their respective VNETs. Also, don't forget to configure private DNS rules in that access VNET. Another route is to establish VNET peering between all the VNETs, but that requires careful management of internal IP addressing to avoid conflicts. The private link approach could help simplify things a bit.
I appreciate the advice! I'll look into the hub-and-spoke configuration.
Yeah, setting up a single VPN VNET with private links sounds smart, but a DNS resolver is essential.
I mainly want the developers to be able to query the databases from their local machines without hassle.