You design a virtual network (VNet) topology with the following characteristics:
* web subnet: 3 web front-end virtual machines (VMs)
* app subnet: 3 application server VMs
* data subnet: 3 database server VMs
The client requires that inter-subnet network traffic be strictly controlled with network security groups (NSGs).
You need to design a solution that minimizes NSG rule creation and maintenance.
What should you do?
You should define ASGs that align to each application tier. ASGs allow you to target inbound or outbound NSG security rules to workloads. For instance, you could create an ASG that includes the three web servers, a second ASG for the three application servers, and a third ASG that includes the three database servers. You then reference the ASG tags in your NSG rules. This simplifies network administration in Azure and makes rule maintenance more straightforward. For example, if you add a fourth web server to the VNet subnet, then all you have to do is include that new server to your ASG definition.
You should not enable the built-in rules in each NSG because none of these rules meets the requirements. The three Azure-provided default NSG rules do the following:
* Allow all inbound and outbound VNet traffic.
* Allow an Azure load balancer to send health probes through the NSG.
* Deny any traffic for which a prior rule does not match.
You should not employ the VirtualNetwork NSG service tag in each NSG. Service tags do make it easier to write NSG security rules and thereby control traffic. However, the best application of service tags for this use case is to create ASGs that map to the client's three infrastructure-as-a-service (IaaS) workloads.
You should not bind a route table to each subnet. Route tables are used in conjunction with network virtual appliances (NVAs) to customize inter-subnet routing. However, the tables on their own increase complexity and represent an incomplete configuration.