Virtual Network Service
Why a Virtual Network Service?
A virtual network allows resources to communicate with other resources. The other resources may be within the same virtual network, but could also be on-premise or on the internet. All cloud resources need a virtual network, which makes a virtual network service essential.
A virtual network service provides virtual networks to application teams.
A virtual network service has two inputs:
a cloud tenant for the virtual network
an IP address range, often in CIDR notation, which can either be provided by a Network Engineer or automatically by an IP address management tool (IPAM)
A virtual network service creates the virtual network in the cloud tenant. If necessary it registers the IP address range in the organization's IP address management tool (IPAM) thus taking the burden away from application teams.
Given the security implications, networking services must be provided centrally for most Landing Zones. The virtual network service forms the basis for the networking offering.
Cloud-native Service Marketplace
Implement enterprise-wide distribution of cloud infrastructure services via a service Marketplace.Learn more →
Proven Patterns When Implementing Virtual Network Services
Implement a Hub & Spoke Approach
Defining a central hub with e.g. configured access to on-prem network is a very common approach for a scalable network architecture. If Cloud Tenants (e.g. Azure Subscriptions) need access to On-Prem, a Spoke network is deployed into the tenant and connects it to the Hub.
Organizations should strive to make applications go full cloud-native on networking (L7, APIs) or provide strongly centralized services (L3 networking like on-premise).
Embrace Cloud Paradigm Shift
On-premise used L3 connectivity and often no authN/Z on the application layer. The cloud moves this to L7. Network zones are the most difficult to implement as they have a lot of shared responsibilities and interfaces.
Shift Your View on Networking
On-premise networks are mostly flat, whereas in the cloud we can do micro-segmentation and networks become very hierarchical with application teams having a lot of autonomy over their subnets
Provide It as a Landing Zone Module
Virtual network services can be modules for Modular Landing Zones (see Modular Landing Zones).
Make It Compatible with Adjacent Services
Virtual networks are most useful in combination with
External IP addresses
Most applications need to connect to resources outside the virtual network than their own. The following services need a virtual network as input:
Utilizing a Hub and Spoke architecture is a very common choice when working with Networks. Hub and Spoke can be used to allow traffic between multiple resources. It can connect Virtual Networks to each other or to your On-Premise Networks. Here are the basic steps to create a Hub and Spoke Network
Create a Hub Virtual Network that contains services that will be shared across all Spoke Networks. Each Spoke Network will be peered to the Hub by a Gateway connection.
Create Spoke Virtual Networks or gather information about your On-Premise networks. Make sure none of the networks are sharing the same CIDR address ranges.
Create a connection to allow traffic between a Spoke Network (VNet or On-Premise) and the Hub. Create Route Tables for each Spoke to direct traffic. This will allow traffic to securely flow between Spokes as needed.
The Hub Network can hold resources that can be shared and accessed by the Spoke Networks. Some things that your Hub can handle are gateways to securely connect networks, central location of logs for each Spoke, diagnostics to analyze and alert on events in the logs, load balancers, configuration metadata and a central Firewall to apply policies to all Spokes among other things.
Azure has two options for creating a Hub and Spoke Virtual Network Service: Customer-Managed infrastructure components or a Microsoft-Managed infrastructure with Azure VWAN.
Managing your own Hub and Spoke Network provides some benefits including
Overcoming subscription limits
Can be customized to specific team requirements
You can find detailed information about how Azure handles Hub and Spoke network topology here
Here is information on how to create a Customer Managed Hub and Spoke Network
Microsoft-Managed Infrastructure with VWAN
Azure VWAN has benefits as well
Integrated connectivity solutions in Hub and Spoke
Automated Spoke setup and configuration
Security features maintained by team of Microsoft engineers
Here is more information on what VWAN is, how it works and an overview of how to create a Hub and Spoke design with it
Here is information on how to use Azure VWAN to create Point to Site (P2S) connections. This allows users to connect to virtual resources inside of Azure.
AWS also offers Customer-Managed or AWS-Managed Infrastructure. To get started, you can create multiple virtual networks called Virtual Private Clouds (VPCs) that contain EC2 instances, Relational Database Service (RDS) instances or any other number of other services offered by AWS.
If you want to utilize the Customer-Managed approach, you can connect your VPCs using a Transit Gateway. Transit Gateway is an AWS service that acts as a network transit hub and connects your AWS Virtual Private Clouds (VPCs) and your on-premises networks.
You can find more information about what a Transit Gateway is and how it works here
You can find some best practices when working with Transit Gateway here
You can follow the guide to setting up a basic Hub and Spoke network using Transit Gateway here
If you want to utilize an AWS-Managed network, you can set up Cloud WAN. Cloud WAN is a managed service that can be used to build, manage, and monitor a unified global network that connects resources running across your cloud and on-premises environments. The Cloud WAN consists of a Global Network with a Core Network inside of the Global Network.
A Global Network is a single, private network that acts as a high-level container for your network objects. It can contain Transit Gateways and other AWS Cloud WAN Core Networks and can be managed in the Network Manager console.
A Core Network is the part of the Global Network managed by AWS and includes Regional Connection Points (VPNs, VPCs, Transit Gateway Connects).
You can find more information about what a Cloud WAN is and how it works here
And you can find information on how to create a Cloud WAN including a Global Network and Core Network here
VPC Network Peering
VPC Network Peering allows for secure communication between resources over Google’s internal network using private IP addresses. Each spoke VPC network in this architecture has a peering relationship with a central hub VPC network as well as a Cloud NAT Gateway for outbound communication with the internet.
Some of the benefits of VPC Network Peering include
Lower Network Latency because internal traffic never traverses the public internet
Increased Network Security because service owners do not need to have their services exposed to the public internet
Lower Network Costs for traffic between networks that are peered and using internal IP addresses to communicate
There are some constraints when working with VPC Networking Peering. The peering connections between the spoke VPC networks and the hub VPC network don't allow transitive traffic; that is, inter-spoke communication through the hub is not possible. Resources such as GKE private nodes and Cloud SQL instances that have private IP addresses require a proxy for access from outside their VPC network. You are also limited to a maximum of 25 connections to a single VPC instance.
Cloud VPN allows you to overcome some of the constraints of VPC Network Peering. Cloud VPN allows for traffic to flow between Spokes and does not have a limit to the amount of connections to a single VPC instance. This allows your network to be more flexible and scale more easily.
To allow inter-Spoke traffic, you will need to initialize a Cloud VPN service in a Spoke Network and connect it to a VPN Gateway on your Hub Network.
Google Cloud offers two types of Cloud VPN gateways: HA VPN and Classic VPN. However, certain Classic VPN functionality is deprecated.
HA VPN is a high-availability (HA) Cloud VPN solution that lets you securely connect your on-premises network to your VPC network through an IPsec VPN connection in a single region. HA VPN provides an SLA of 99.99% service availability.
You can find more information about HA VPN here.
All Cloud VPN gateways created before the introduction of HA VPN are considered Classic VPN gateways. Google recommends upgrading any Classic VPN services to HA VPN and has a guide on how to do that here.
Classic VPN gateways have a single interface, a single external IP address, and support tunnels that use static routing (policy-based or route-based). You can also configure dynamic routing (BGP) for Classic VPN, but only for tunnels that connect to third-party VPN gateway software running on Google Cloud VM instances.
You can find more information about Classic VPN here.
- meshStack building blocks - Azure
This building block can create a virtual network in azure. For more information please refer to building-blocks github repositoryLearn More
- GCP Fabric FAST
Offers sophisticated virtual network setups based on the “hub and spoke” design. One can choose the type of connectivity between the hub and spokes, which are: VPC Peering, Network Virtual Appliances (NVA), or VPNLearn More
- GCP CFT - Example Foundation
Offers sophisticated virtual network setups. One can choose the type of connectivity between Dual SVPC or Hub & Spoke.Learn More
- GCP Setup Checklist
Separate networks per environment are created and some basic firewall rules are applied. That way you can have the connectivity within one environment (e.g. all production services can talk to each other securely via a VPC). Advanced options like configuring peering or VPN approaches are not provided.Learn More
- Azure LZ accelerator - ES
Can deploy Hub and spoke with Azure Firewall, Hub and spoke with your own third-party NVA, Virtual WAN (Microsoft managed)Learn More
- Azure LZ Terraform module - ES
By adding deploy_connectivity_resources = true to the module’s input parameters, the module sets up a hub network with a firewall and gateway subnets. These can be further customized by tweaking some networking settingsLearn More
- Azure CAF Terraform Modules
It can be implemented by running different modules in Level2/connectivity . Modules contain AZ firewall, hub and spoke, vWan, private DNS,…Learn More
- AWS Control Tower with Account Factory
CT creates a default VPC with 3 subnets in the management account per availability zone. You can edit VPC configurations for new provisioned accounts with the account factory. For example, you can allow internet access for created subnets, which will lead to the creation of a NAT Gateway. When provisioning a new account, CT automatically deletes the default VPC and creates a new VPC configured by CT.Learn More
- AWS Control Tower with AFT
Similar to normal account factory, with addition to AFT customization framework that allows you to include additional terraform resources.Learn More
- AWS Landing Zone Accelerator
It provides a reasonable default network setup in the network-config.yaml. Additionally the default config contains a lot of additional options as commented code. You just have to active them and adapt to your needs.Learn More
With UniPipe you can easily provide a Virtual Network Service to e.g. grant on-prem connectivity or to integrate all your company’s productive applications into one network. All you need for this is a Terraform Module that sets up the networking inside the target tenant as needed.Learn More