I'm deploying isolated systems for customers in their chosen Azure regions, and these systems don't need user internet access like web browsing or email. The only outbound connectivity I need is for specific scenarios such as Microsoft Updates and certain system integrations. Currently, I haven't implemented any Network Virtual Appliances (NVA) because the outbound traffic is minimal and non-interactive.
I have two options I'm considering:
**Option 1: Azure Firewall at a Central Hub**
I have a centralized hub in one region connected to the standalone systems via VNet peering. I'm thinking of deploying an Azure Firewall there to manage all outbound traffic. The pros are centralized control, easier management, and leveraging shared infrastructure. However, there is potential latency from cross-region peering, which might still be acceptable due to the traffic type.
**Question:** My standalone setup has an application gateway with web servers. If I use a User Defined Route (UDR) to send all traffic [0.0.0.0/0](http://0.0.0.0/0) through an NVA, will my web servers send their responses back through the NVA? I'm concerned that this approach may not work well due to added latency.
**Option 2: NAT Gateway for Each Standalone Environment**
Alternatively, I could deploy a NAT Gateway in each isolated environment, providing local outbound access. This would minimize latency but comes with higher costs due to the separate charge for each NAT Gateway and resource duplication across environments.
I'd love to hear anyone's insights, experiences, or any pitfalls to avoid while making this decision! Thanks!
4 Answers
Using a NAT Gateway is definitely the way to go here. NVAs can get complicated, and for your use case, they seem like overkill. Just treat each environment as standalone with a NAT Gateway and some good NSGs, and you should be all set!
You're right! The web server response won't be routed through the Azure Firewall if you set the routes like that. Going with the second option of a NAT Gateway per region sounds like a better fit. It reduces latency since everything will stay local, and you won't have to deal with the costs of inter-region traffic.
I totally get the appeal of the NAT Gateway. It's designed for simplicity, but I have to wonder why they’ve limited it to zones instead of allowing for more flexibility across regions. Maybe it's something they'll revisit later? Also, good catch noticing the locked v2 SKU—hopefully, that’ll roll out to everyone soon!
You could also explore using a shared NAT option in the hub if you want a simpler setup without intricate inspection and filtering. It might not be common practice yet, but it could work for your scenario!
Right, but remember that routing through peering is a no-go for NAT gateways, which might limit that approach.
Exactly! Setups with a shared NAT in a hub can be tricky, especially if you're peering. Better to keep it simple and localized.