Networks
Hub and Spoke Topology
Communication between all virtual networks occurs through a Hub and Spoke
topology. The Connectivity subscription contains a VNET where all internal
traffic flows. To enable this, there is a default route (0.0.0.0/0) which
will send all traffic that is not internal to the VNET.
Virtual Networks
Our virtual networks follow a traditional 3-tier architecture. We have a public tier for public facing load balancers or other resources that need a public IP or need to be open to the internet. The protected tier is where applications such as services in kubernetes live. The final tier is the isolated tier where any data storage lives. To ensure we have good isolation of all of the tiers, there are some subnet security group rules in place.
The public tier can communicate with the internet. By default the only accepted internet traffic is from Azure Load Balancers. This can be configured.
The public tier and protected tier have bi-directional communication allowed.
All public traffic to the protected tier must pass through a resource in the public tier
The protected tier is allowed to egress to the internet.
The isolated tier is allowed bi-directional communication with the protected tier.
The isolated tier is allowed no other communication apart from what is already stated above.
A visualization of the network segmentation and default rules of a 10.10.0.0/16 VNet can be viewed below.
Firewall + NAT Gateway
All traffic from all VNETs protected subents that are connected to the HUB will egress to the internet through a Firewall and then a NAT Gateway to get to the internet. This allows for full inspection and traffic blocking/filtering on all traffic before internet bound traffic exits through a limited set of public IPs. Isolated subnets have no connectivity outside of being able to communicate with services in the protected layer so this is not applicable. Public subnets require open communication to the internet.
Firewall rules are configurable and as the DNS resolution for all VNETs occurs in the firewall, it is possible to block/whitelist based on domain name.
Firewall rules are managed using Infrastructure as Code and should be added or removed by submitting a request to PGT to make the changes permanent.
CIDR Breakdown Strategy
When creating a Virtual Network in Azure, we usually create it with a /16 range (65536 IPs). The reason for this is to give scope for expansion and to allow for assigning Dedicated Subnets in the applicable tier. It is good practice to leave space for the future in any subnet division. Each tier gets a /18 range (16382 IPs) with a /19 range (8190 IPs) for resources that do not need a dedicated subnet, such as kubernetes nodes and pods. There is then a /19 range (8190 IPs) left available for Dedicated Subnets in each tier.
There is one final /18 range left available in this breakdown strategy to allow some level of future proofing and flexibility with new requirements or to allow for using new services/techniques of connecting environments. The usage of this spare /18 range is not a decision lightly taken.
Azure does not yet have the concept of assigning a subnet to a specific availability zone. Instead, each resource specifies the zones it should be deployed into. This allows the ranges above not to be subdivided yet for each availability zone that is used.
An example breakdown for a network of 10.0.0.0/16
Public
10.0.0.0/19
Public Dedicated
10.0.0.32/19
Protected
10.0.0.64/19
Protected Dedicated
10.0.0.96/19
Isolated
10.0.0.128/19
Isolated Dedicated
10.0.0.160/19
Spare
10.0.0.192/19
Spare
10.0.0.224/19
Dedicated Subnets
Azure has a concept of requiring dedicated subnets for particular resources if you want to have them be a part of your own virtual network. We take the /19 range (8190 IPs) available for dedicated subnets and divide them as necessary based on the resources and the recommended subnet division for that resource.
Last updated
Was this helpful?