Skip to content

Network Topology

Overview

This guide details architectural best practices and guidance for VNET and subnet assignments in the SGS Azure tenant. Standardized governance will be implemented by SGS to maintain a uniform environment and plan for future connectivity to other resources and services. Application and delivery teams are expected to request an available VNET prior to service or subscription deployment. Governance has been created to account for the most common environments and services deployed by SGS. SGS Architecture has also created a network architecture to account for not yet developed services and technologies.

What

Azure uses VNETs as logical combinations of subnets to identify network segments and traffic paths. VNETs are used in combination with network security groups (NSGs) to create logical separation between network layers, or n-tiers. While application architecture and Medicaid Information Technology Architecture (MITA) guidance have moved applications towards a service-oriented architecture (SOA) approach where APIs are used to communicate between network layers and services; standard n-tier separation must still exist between architectural layers of a solution.

Azure requires the same standards for networking as deployed in traditional data center networking. This guidance is not meant to be a full definition of networking standards and communication, however it is used to set governance for VNET and subnet assignments in the SGS Tenant environment.

Networks are traditionally divided into three tiers in an n-tier architecture, the data layer, the business logic layer, and the application (or presentation layer). In a standard data center network architecture, each layer would be divided into subnets. Subnet to subnet communication would be enabled through either a firewall or switch using virtual logical area networks (VLANs) to allow traffic only through certain network ports (services). By dividing a network in this manner, traffic isolation was created to protect the resources at each layer.

Each network requires a separate set of “addresses” commonly referred to as a subnet. A subnet is a group of devices that has direct communication to other devices within the same subnet. Traffic between subnets must be allowed through a communication device or rule. Each network is unique to that network.

For two networks to communicate with each other, there must be a path to the remote network, and the two network address ranges cannot overlap. Another way to think of it is to consider driving to another neighborhood in your city: the street names must be unique, and you must have roads or paths between the streets.

These general networking rules are true not just in data centers but also in Azure. Azure adds elements to networking planning though as there are minimum network requirements per service for scalability.

Why

Defining network standards is required to assure communications between networks and services. It is uncommon that solutions exist within a single network environment. SGS solutions rely on other Optum teams and technologies, SGS shared services and subscriptions, third party SaaS services and a common infrastructure to support environment cohesion. Without a network plan, services and subscriptions may not be able to communicate with each other as intended because services and solutions will be deployed with default settings. All services and solutions must be created with the enterprise infrastructure in mind to allow for future growth and scalability.

When

VNET and subnet design is initially created when an architect is developing a solution for a potential client. VNET and subnet design also must be considered when SGS is developing new solutions or products.

How

SGS Architecture has designed a subnet plan that can be followed by all subscriptions and services. Teams requiring subnets for VNET application can request subnet assignments from operations for application in their environments. SGS Tenant networks have been designed as follows: Private network range for SGS networks: Class B 172.16.0.0-172.31.0.0 /16

Using a class B network allows for 16,384 networks when subnetted to the greatest possible network range. The class B range also isolates SGS away from the two more commonly used private ranges – 10.0.0.0 /8 and 192.168.200.0 /24. As many default settings that may be employed by other Optum or UHG teams may use the more common ranges, SGS’s use of the Class B range will minimize the risk of communication issues later.

Environment and Service Assignments
SGS Architecture has further broken the range down into subnet components to support our core infrastructure, platform, client environments and future growth.

Environments

Only the most common SGS environments have been pre-defined. We have ranges for additional development that can be used if more than four environments are required. These ranges represent the environment only and are further broken down below.

    Dev:           172.16.0.0 – 172.19.255.255
    Test:          172.20.0.0 – 172.23.255.255
    Staging:       172.24.0.0 – 172.27.255.255
    Production:    172.28.0.0 – 172.31.255.255

Infrastructure Ranges

The environments are then divided into ranges to support product, infrastructure and clients as noted here. These are categories of service provided by SGS teams.


Dev         Central Services    172.16.0.0  - 172.16.50.0
            Platform            172.17.0.0  - 172.17.255.0
            Other development   172.16.51.0 - 172.16.255.0
            Customer Space      172.18.0.0  - 172.19.255.0

Test        Central Services    172.20.0.0  - 172.20.50.0
            Platform            172.21.0.0  - 172.21.255.0
            Other development   172.20.51.0 - 172.20.255.0
            Customer Space      172.22.0.0  - 172.23.255.0

Staging     Central Services    172.24.0.0  - 172.24.50.0
            Platform            172.25.0.0  - 172.25.255.0
            Other development   172.24.51.0 - 172.24.255.0
            Customer Space      172.26.0.0  - 172.27.255.0

Production  Central Services    172.28.0.0  - 172.28.50.0
            Platform            172.29.0.0  - 172.29.255.0
            Other development   172.28.51.0 - 172.28.255.0
            Customer Space      172.30.0.0  - 172.31.255.0

Further Subnetting

Within client environments additional subnetting may be required to support Azure services that are being deployed for a particular solution. Common services used by SGS, and their minimum requirements include:

Service Minimum Mask
AKS /21
Firewall /24
App Gateway /24
Site Recovery /24
Traffc Manager /24
Bastion /27
Load Balancer /24
Postgres /24
Data Bricks /20

Due to these minimum requirements a client may be assigned more than a single class C. Data Bricks for example, requires 2 subnets using a /20 mask. SGS should consider Data Bricks as a central service to minimize the impact of the service on network communications should the service be considered for a future project.

Applying Subnet and VNET Assignments

By dividing the network range into both environment and service levels, client accounts will require multiple subnets to comprise their VNET creation. An example is below:

  • Client A Requirements:

    • Platform for AEP
      • AKS
      • App Gateway
    • Virtual servers to support COTS applications
    • Bastion
    • 3 environments

  • Subnet plan: Each environment includes 1 VNET that spans multiple subnets. Peering is not required within the subscription. Peering is required to cross-subscription components for ingress.


Dev
    Client subnets for COTS and Bastion
        172.19.1.1-172.19.1.30 /27      Bastion
        172.19.1.33-172.19.1.254 /26    COTS
    Platform Components
        172.17.20.0 /21                 AKS
        172.19.2.0 /24                  Client specific app gateway
Staging
    Client subnets for COTS and Bastion
        172.26.1.1-172.26.1.30 /27      Bastion
        172.26.1.33-172.26.1.254 /26    COTS
    Platform Components
        172.25.1.0 /21                  AKS
        172.26.2.0 /24                  Client specific app gateway
Production
    Client subnets for COTS and Bastion
        172.30.1.1-172.30.1.30 /27      Bastion
        172.30.1.33-172.30.1.254 /26    COTS
    Platform Components
        172.29.20.0 /21                 AKS

Who

Network design is the responsibility of the Tier 0 team for overall tenant communication between all subscriptions and services. The solution architect and the delivery team need to define the number of networks needed based on the services being deployed. VNETs and subnets will be used by:

  • SGS Architects
  • SGS Engineers
  • Deployment teams
  • Operations teams

VNET and subnet assignments will be tracked by the operations team.