In on-premise networks, you (usually) control the cabling so you can decide where traffic can flow and which routers, switches, and network devices the traffic has to go through. In Public Clouds like Microsoft Azure, the physical network is out of your reach, and networking happens in an abstracted software layer. Knowing networking still plays a big role and creating network topology that scales defines how the organization is able to grow their cloud environments. Many organizations will by default have a Hybrid Cloud Environment, either with many different cloud vendors or with on-premise and cloud. For most Enterprises, it is a necessity that network packages can flow between the different Datacenter locations in an efficient and secure way.
For Enterprises the discussion of following established standards or doing everything with Cloud Native Technologies is a healthy one. Not all solutions that are great for on-premise are by default great in a Public Cloud Environment. Some are and some should be changed. Besides the technology itself, Enterprises have skilled resources knowing some technologies and solutions better than others. Therefore choosing a new technology that may be better for the cloud than existing technology may become the preferred choice.
The Azure Hub & Spoke Setup
The idea is that you have one central network where you then would put your vital networking hardware like a Firewall. This is the Hub network. To this network you add other networks, they will then be the spokes. To ensure that the networks talk to each other you use network peering which combines the networks to “one network.” In Azure, a network is called VNET (Virtual Network).
If you on all the spoke networks add a Route Table you can define that all traffic by default has to go to the Firewall in the Hub Vnet
Above I have tried to visualize what I described in a drawing on a piece of paper. The spokes can exist in different subscriptions as long as they are owned by the same organization.
These are the limitations you need to be aware of.
- Virtual Networks 1000
- Subnets per virtual network 3000
- Peering per virtual network 500
However, with some planning there should be no problem navigating these limitations.
Now as all the traffic hits the Firewall Cluster we can use this to define access to resources and allow traffic to move in our out of the Cloud Environment. How you connect to on-premise networks can be either over Express-routes or over VPN connections. You can also use the Firewall Cluster to control the publishing of services to the public internet.
