Deploy a migration infrastructure

This article shows how the fictional company Contoso prepares its on-premises infrastructure for migration, sets up an Azure infrastructure in preparation for migration, and runs the business in a hybrid environment. When you use this example to help plan your own infrastructure migration efforts, keep the following considerations in mind:

  • The provided sample architecture is specific to Contoso. Review your own organization's business needs, structure, and technical requirements when making important infrastructure decisions about subscription design or networking architecture.
  • Whether you need all the elements described in this article depends on your migration strategy. For example, if you're building only cloud-native apps in Azure, you might need a less complex networking structure.


Before Contoso can migrate to Azure, it's critical to prepare an Azure infrastructure. Generally, there are six broad areas Contoso needs to think about:

  • Step 1: Azure subscriptions. How will Contoso purchase Azure, and interact with the Azure platform and services?
  • Step 2: Hybrid identity. How will it manage and control access to on-premises and Azure resources after migration? How does Contoso extend or move identity management to the cloud?
  • Step 3: Disaster recovery and resilience. How will Contoso ensure that its apps and infrastructure are resilient if outages and disasters occur?
  • Step 4: Networking. How should Contoso design a networking infrastructure, and establish connectivity between its on-premises datacenter and Azure?
  • Step 5: Security. How will it secure the hybrid/Azure deployment?
  • Step 6: Governance. How will Contoso keep the deployment aligned with security and governance requirements?

Before you start

Before we start looking at the infrastructure, you might want to read some background information about the Azure capabilities we discuss in this article:

On-premises architecture

Here's a diagram showing the current Contoso on-premises infrastructure.

Contoso architecture

  • Contoso has one main datacenter located in the city of New York in the Eastern United States.
  • There are three additional local branches across the United States.
  • The main datacenter is connected to the internet with a fiber metro ethernet connection (500 Mbps).
  • Each branch is connected locally to the internet using business class connections, with IPSec VPN tunnels back to the main datacenter. This approach allows the entire network to be permanently connected, and optimizes internet connectivity.
  • The main datacenter is fully virtualized with VMware. Contoso has two ESXi 6.5 virtualization hosts, managed by vCenter Server 6.5.
  • Contoso uses Active Directory for identity management, and DNS servers on the internal network.
  • The domain controllers in the datacenter run on VMware virtual machines. The domain controllers at local branches run on physical servers.

Step 1: Buy and subscribe to Azure

Contoso needs to figure out how to buy Azure, how to architect subscriptions, and how to license services and resources.

Buy Azure

Contoso is enrolling in an Enterprise Agreement (EA). This agreement entails an upfront monetary commitment to Azure, entitling Contoso to earn great benefits, including flexible billing options and optimized pricing.

  • Contoso estimated what its yearly Azure spend will be. When it signed the agreement, Contoso paid for the first year in full.
  • Contoso needs to use all commitments before the year is over, or lose the value for those dollars.
  • If for some reason Contoso exceeds its commitment and spends more, Microsoft will invoice them for the difference.
  • Any cost incurred above the commitment will be at the same rates as those in the Contoso contract. There are no penalties for going over.

Manage subscriptions

After paying for Azure, Contoso needs to figure out how to manage Azure subscriptions. Contoso has an EA, and thus no limit on the number of Azure subscriptions it can set up.

  • An Azure Enterprise Enrollment defines how a company shapes and uses Azure services, and defines a core governance structure.

  • As a first step, Contoso has defined a structure known as an enterprise scaffold for Enterprise Enrollment. Contoso used the Azure enterprise scaffold guidance to help understand and design a scaffold.

  • For now, Contoso has decided to use a functional approach to manage subscriptions.

    • Inside the enterprise, it will use a single IT department that controls the Azure budget. This will be the only group with subscriptions.
    • Contoso will extend this model in the future, so that other corporate groups can join as departments in the Enterprise Enrollment.
    • Inside the IT department Contoso has structured two subscriptions, Production and Development.
    • If Contoso requires additional subscriptions in the future, it needs to manage access, policies, and compliance for those subscriptions. Contoso will do that by introducing Azure management groups, as an additional layer above subscriptions.

    Enterprise structure

Examine licensing

With subscriptions configured, Contoso can look at Microsoft licensing. The licensing strategy will depend on the resources that Contoso wants to migrate into Azure and how Azure virtual machines (VMs) and services are selected and deployed.

Azure Hybrid Benefit

When deploying VMs in Azure, standard images include a license that will charge Contoso by the minute for the software being used. However, Contoso has been a long-term Microsoft customer, and has maintained EAs and open licenses with Software Assurance (SA).

Azure Hybrid Benefit provides a cost-effective method for Contoso migration, by allowing it to save on Azure VMs and SQL Server workloads by converting or reusing Windows Server Datacenter and Standard edition licenses covered with Software Assurance. This will enable Contoso to pay a lower base compute rate for VMs and SQL Server. Learn more.

License Mobility

License Mobility through SA gives Microsoft Volume Licensing customers like Contoso the flexibility to deploy eligible server apps with active SA on Azure. This eliminates the need to purchase new licenses. With no associated mobility fees, existing licenses can easily be deployed in Azure. Learn more.

Reserve instances for predictable workloads

Predictable workloads are those that always need to be available with VMs running. For example, line-of-business apps such as an SAP ERP system. On the other hand, unpredictable workloads are those that are variable, such as VMs that are on during high demand and off when demand is low.

Reserved instance

In exchange for using reserved instances for specific VM instances must be maintained for large durations of time, Contoso can get both a discount and prioritized capacity. By using Azure Reserved Instances together with Azure Hybrid Benefit, Contoso can save up to 82% off regular pay-as-you-go pricing (April 2018).

Step 2: Manage hybrid identity

Giving and controlling user access to Azure resources with identity and access management (IAM) is an important step in pulling together an Azure infrastructure.

  • Contoso decides to extend its on-premises Active Directory into the cloud, rather than build a new separate system in Azure.
  • It creates an Azure-based Active Directory to do this.
  • Contoso doesn't have Office 365 in place, so it needs to provision a new Azure AD.
  • Office 365 uses Azure AD for user management. If Contoso was using Office 365, it would already have an Azure AD tenant, and can use that as the primary directory.
  • Learn more about Azure AD for Office 365, and learn how to add a subscription to an existing Azure AD tenant.

Create an Azure AD

Contoso is using the Azure AD Free edition that's included with an Azure subscription. Contoso admins set up a directory as follows:

  1. In the Azure portal, they navigate to Create a resource > Identity > Azure Active Directory.

  2. In Create directory, they specify a name for the directory, an initial domain name, and region in which the Azure AD directory should be created.

    Create Azure AD


    The directory that's created has an initial domain name in the form The name can't be changed or deleted. Instead, they need to add its registered domain name to Azure AD.

Add the domain name

To use its standard domain name, Contoso admins need to add it as a custom domain name to Azure AD. This option allows them to assign familiar user names. For example, a user can sign in with the email address, rather than needing

To set up a custom domain name they add it to the directory, add a DNS entry, and then verify the name in Azure AD.

  1. In Custom domain names > Add custom domain, they add the domain.

  2. To use a DNS entry in Azure, they need to register it with their domain registrar.

    • In the Custom domain names list, they note the DNS information for the name. It's using an MX entry.
    • They need access to the name server to do this. They log into the domain, and create a new MX record for the DNS entry provided by Azure AD, using the details noted.
  3. After the DNS records propagate, in the details name for the domain, they select Verify to check the custom domain name.

    Azure AD DNS

Set up on-premises and Azure groups and users

Now that the Azure AD is up and running, Contoso admins need to add employees to on-premises Active Directory groups that will synchronize to Azure Active Directory. They should use on-premises group names that match the names of resource groups in Azure. This makes it easier to identify matches for synchronization purposes.

Create resource groups in Azure

Azure resource groups gather Azure resources together. Using a resource group ID allows Azure to perform operations on the resources within the group.

  • An Azure subscription can have multiple resource groups, but a resource group can only exist within a single subscription.
  • In addition, a single resource group can have multiple resources, but a resource can only belong to a single resource group.

Contoso admins set up Azure resource groups as summarized in the following table.

Resource group Details
ContosoCobRG This group contains all resources related to continuity of business (COB). It includes vaults that Contoso will use for the Azure Site Recovery service, and the Azure Backup service.

It will also include resources used for migration, including Azure Migrate and Azure Database Migration Service.
ContosoDevRG This group contains development and test resources.
ContosoFailoverRG This group serves as a landing zone for failed over resources.
ContosoNetworkingRG This group contains all networking resources.
ContosoRG This group contains resources related to production apps and databases.

They create resource groups as follows:

  1. In the Azure portal > Resource groups, they add a group.

  2. For each group, they specify a name, the subscription to which the group belongs, and the region.

  3. Resource groups appear in the Resource groups list.

    Resource groups

Scale resource groups

In future, Contoso will add other resource groups based on needs. For example, they could define a resource group for each app or service, so that they can be managed and secured independently.

Create matching security groups on-premises

  1. In the on-premises Active Directory, Contoso admins set up security groups with names that match the names of the Azure resource groups.

    On-premises Active Directory security groups

  2. For management purposes, they create an additional group that will be added to all of the other groups. This group will have rights to all resource groups in Azure. A limited number of Global Admins will be added to this group.

Synchronize Active Directory

Contoso wants to provide a common identity for accessing resources on-premises and in the cloud. To do this, it will integrate the on-premises Active Directory with Azure AD. With this model:

  • Users and organizations can take advantage of a single identity to access on-premises applications and cloud services such as Office 365, or thousands of other sites on the internet.
  • Admins can use the groups in Active Directory to implement Role Based Access Control (RBAC) in Azure.

To facilitate integration, Contoso uses the Azure AD Connect tool. When you install and configure the tool on a domain controller, it synchronizes the local on-premises Active Directory identities to Azure AD.

Download the tool

  1. In the Azure portal, Contoso admins go to Azure Active Directory > Azure AD Connect, and download the latest version of the tool to the server they're using for synchronization.

    Download Azure AD Connect

  2. They start the AzureADConnect.msi installation, with Use express settings. This is the most common installation, and can be used for a single-forest topology, with password hash synchronization for authentication.

    Azure AD Connect Wizard

  3. In Connect to Azure AD, they specify the credentials for connecting to the Azure AD (in the form or

    Azure AD Connect Wizard

  4. In Connect to AD DS, they specify credentials for the on-premises Active Directory (in the form CONTOSO\admin or\admin).

    Azure AD Connect Wizard

  5. In Ready to configure, they select Start the synchronization process when configuration completes to start the sync immediately. Then they install.

Note the following:

- Contoso has a direct connection to Azure. If your on-premises Active Directory is behind a proxy, read this [article](

- After the first synchronization, on-premises Active Directory objects are visible in the Azure AD directory.

    ![On-premises Active Directory in Azure](./media/contoso-migration-infrastructure/on-prem-ad-groups.png)

- The Contoso IT team is represented in each group, based on its role.

    ![On-premises Active Directory members in Azure](./media/contoso-migration-infrastructure/on-prem-ad-group-members.png)

Set up RBAC

Azure role-based access control (RBAC) enables fine-grained access management for Azure. Using RBAC, you can grant only the amount of access that users need to perform tasks. You assign the appropriate RBAC role to users, groups, and applications at a scope level. The scope of a role assignment can be a subscription, a resource group, or a single resource.

Contoso admins now assign roles to the Active Directory groups that they synchronized from on-premises.

  1. In the ControlCobRG resource group, they select Access control (IAM) > Add role assignment.

  2. In Add role assignment > Role, > Contributor, they select the ContosoCobRG group from the list. The group then appears in the Selected members list.

  3. They repeat this with the same permissions for the other resource groups (except for ContosoAzureAdmins), by adding the Contributor permissions to the account that matches the resource group.

  4. For the ContosoAzureAdmins group, they assign the Owner role.

    On-premises Active Directory members in Azure

Step 3: Design for resiliency

Set up regions

Azure resources are deployed within regions.

  • Regions are organized into geographies, and data residency, sovereignty, compliance, and resiliency requirements are honored within geographical boundaries.
  • A region is composed of a set of datacenters. These datacenters are deployed within a latency-defined perimeter, and connected through a dedicated regional low-latency network.
  • Each Azure region is paired with a different region for resiliency.
  • Read about Azure regions, and understand how regions are paired.

Contoso has decided to go with the East US 2 (located in Virginia) as the primary region, and Central US (located in Iowa) as the secondary region. There are a couple of reasons for this:

  • The Contoso datacenter is located in New York, and Contoso considered latency to the closest datacenter.
  • The East US 2 region has all the service and products that Contoso needs to use. Not all Azure regions are the same in terms of the products and services available. You can review Azure products by region.
  • Central US is the Azure paired region for East US 2.

As it thinks about the hybrid environment, Contoso needs to consider how to build resilience and a disaster recovery strategy into the region design. Broadly, strategies range from a single-region deployment, which relies on Azure platform features such as fault domains and regional pairing for resilience, through to a full Active-Active model in which cloud services and database are deployed and servicing users from two regions.

Contoso has decided to take a middle road. It will deploy apps and resources in a primary region, and keep a full copy of the infrastructure in the secondary region, so that it's ready to act as a full backup if a complete app disaster or regional failure occurs.

Set up availability

Availability sets:

Availability sets help protect apps and data from a local hardware and networking outage within a datacenter.

  • Availability sets distribute Azure VMs across different physical hardware within a datacenter.
  • Fault domains represent underlying hardware with a common power source and network switch within the datacenter. VMs in an availability set are distributed across different fault domains to minimize outages caused by a single hardware or networking failure.
  • Update domains represent underlying hardware that can undergo maintenance or be rebooted at the same time. Availability sets also distribute VMs across multiple update domains to ensure at least one instance will be running at all times.

Contoso will implement availability sets whenever VM workloads require high availability. Learn more.

Availability zones:

Availability zones help protect apps and data from failures affecting an entire datacenter within a region.

  • Each availability zone represents a unique physical location within an Azure region.
  • Each zone is made up of one or more datacenters equipped with independent power, cooling, and networking.
  • There's a minimum of three separate zones in all enabled regions.
  • The physical separation of zones within a region protects applications and data from datacenter failures.

Contoso will deploy availability zones as apps call for scalability, high-availability, and resiliency. Learn more.

Configure backup

Azure Backup:

Azure Backup allows you to back up and restore Azure VM disks.

  • Azure backup allows automated backups of VM disk images, stored in Azure storage.
  • Backups are application consistent, ensuring backed up data is transactionally consistent and that applications will boot up post-restore.
  • Azure Backup supports locally redundant storage (LRS) to replicate multiple copies of your backup data within a datacenter if a local hardware failure occurs.
  • If a regional outage occurs, Azure Backup also supports geo-redundant storage (GRS), replicating your backup data to a secondary paired region.
  • Azure Backup encrypts data in-transit using AES 256. Backed-up data at-rest is encrypted using Storage Service Encryption (SSE).

Contoso will use Azure Backup with GRS on all production VMs to ensure workload data is backed up and can be quickly restored if an outage or other disruption occurs. For more information, see the Overview of Azure Backup.

Set up disaster recovery

Azure Site Recovery:

Azure Site Recovery helps ensure business continuity by keeping business apps and workloads running during regional outages.

  • Azure Site Recovery continually replicates Azure VMs from a primary to a secondary region, ensuring functional copies in both locations.
  • In the event of an outage in the primary region, your application or service fails over to using the VM instances replicated in the secondary region, minimizing potential disruption.
  • When operations return to normal, your applications or services can fail back to VMs in the primary region.

Contoso will implement Azure Site Recovery for all production VMs used in mission-critical workloads, ensuring minimal disruption during an outage in the primary region. Learn more

Step 4: Design a network infrastructure

With the regional design in place, Contoso is ready to consider a networking strategy. It needs to think about how the on-premises datacenter and Azure connect and communicate with each other, and how to design the network infrastructure in Azure. Specifically Contoso needs to:

  • Plan hybrid network connectivity. Figure out how it's going to connect networks across on-premises and Azure.
  • Design an Azure network infrastructure. Decide how it will deploy networks over regions. How will networks communicate within the same region, and across regions?
  • Design and set up Azure networks. Set up Azure networks and subnets, and decide what will reside in them.

Plan hybrid network connectivity

Contoso considered a number of architectures for hybrid networking between Azure and the on-premises datacenter. For more information, see Choose a solution for connecting an on-premises network to Azure.

As a reminder, the Contoso on-premises network infrastructure currently consists of the datacenter in New York, and local branches in the eastern half of the US. All locations have a business class connection to the internet. Each of the branches is then connected to the datacenter via an IPSec VPN tunnel over the internet.

Contoso network

Here's how Contoso decided to implement hybrid connectivity:

  1. Set up a new site-to-site VPN connection between the Contoso datacenter in New York and the two Azure regions in East US 2 and Central US.
  2. Branch office traffic bound for virtual networks in Azure will route through the main Contoso datacenter.
  3. As Contoso scales up Azure deployment, it will establish an ExpressRoute connection between the datacenter and the Azure regions. When this happens, Contoso will retain the VPN site-to-site connection for failover purposes only.

VPN only:

Contoso VPN

VPN and ExpressRoute:

Contoso VPN/ExpressRoute

Design the Azure network infrastructure

Contoso's network configuration must make the hybrid deployment secure and scalable. Contoso is taking a long-term approach to this, designing virtual networks (VNets) to be resilient and enterprise ready. Learn more about planning VNets.

To connect the two regions, Contoso will implement a hub-to-hub network model:

  • Within each region, Contoso will use a hub and spoke model.
  • To connect networks and hubs, Contoso will use Azure network peering.

Network peering

Azure network peering connects virtual networks and hubs. Global peering allows connections between virtual network or hubs in different regions. Local peering connects virtual networks in the same region. Virtual network peering provides several advantages:

  • Network traffic between peered VNets is private.
  • Traffic between the VNets is kept on the Microsoft backbone network. No public internet, gateways, or encryption is required in the communication between the VNets.
  • Peering provides a default, low-latency, high-bandwidth connection between resources in different VNets.

Learn more about network peering.

Hub-to-hub across regions

Contoso will deploy a hub in each region. A hub is a virtual network (VNet) in Azure that acts as a central point of connectivity to your on-premises network. The hub VNets will connect to each other using global VNet peering. Global VNet peering connects VNets across Azure regions.

  • The hub in each region is peered to its partner hub in the other region.

  • The hub is peered to every network in its region, and can connect to all network resources.

    Global peering

Hub and spoke model within a region

Within each region, Contoso will deploy VNets for different purposes, as spoke networks from the region hub. VNets within a region use peering to connect to their hub, and to each other.

Design the hub network

Within the hub and spoke model that Contoso has chosen, it needs to think about how traffic from the on-premises datacenter, and from the internet, will be routed. Here's how Contoso has decided to handle routing for both the East US 2 and Central US hubs:

  • Contoso is designing a network that allows traffic from the internet as well as from their corporate network using a VPN to Azure.
  • The network architecture has two boundaries, an untrusted front-end perimeter zone and a back-end trusted zone.
  • A firewall will have a network adapter in each zone, controlling access to trusted zones.
  • From the internet:
    • Internet traffic will hit a load-balanced public IP address on the perimeter network.
    • This traffic is routed through the firewall, and subject to firewall rules.
    • After network access controls are implemented, traffic will be forwarded to the appropriate location in the trusted zone.
    • Outbound traffic from the VNet will be routed to the internet using user-defined routes. The traffic is forced through the firewall, and inspected in line with Contoso policies.
  • From the Contoso datacenter:
    • Incoming traffic over VPN site-to-site (or ExpressRoute) hits the public IP address of the Azure VPN gateway.
    • Traffic is routed through the firewall and subject to firewall rules.
    • After applying firewall rules, traffic is forwarded to an internal load balancer (Standard SKU) on the trusted internal zone subnet.
    • Outbound traffic from the trusted subnet to the on-premises datacenter over VPN is routed through the firewall, and rules applied, before going over the VPN site-to-site connection.

Design and set up Azure networks

With a network and routing topology in place, Contoso is ready to set up Azure networks and subnets.

  • Contoso will implement a Class A private network in Azure This works, since on-premises it currently has a Class B private address space, so Contoso can be sure there won't be any overlap between address ranges.
  • Contoso will deploy VNets in both the primary and secondary regions.
  • Contoso will use a naming convention that includes the prefix VNET and the region abbreviation EUS2 or CUS. Using this standard, the hub networks will be named VNET-HUB-EUS2 (East US 2), and VNET-HUB-CUS (Central US).

Virtual networks in East US 2

East US 2 is the primary region that Contoso will use to deploy resources and services. Here's how Contoso will architect networks within it:

  • Hub: The hub VNet in East US 2 is considered their primary connectivity to the on-premises datacenter.
  • VNets: The spoke VNets in East US 2 can be used to isolate workloads if necessary. In addition to the Hub VNet, Contoso will have two spoke VNets in East US 2:
    • VNET-DEV-EUS2. This VNet will provide the development and test team with a fully functional network for dev projects. It will act as a production pilot area, and will rely on the production infrastructure to function.
      • VNET-PROD-EUS2. Azure IaaS production components will be located in this network.
    • Each VNet will have its own unique address space, with no overlap. Contoso intend to configure routing without requiring NAT.
  • Subnets:
    • There will be a subnet in each network for each app tier.
    • Each subnet in the Production network will have a matching subnet in the Development VNet.
    • In addition, the Production network has a subnet for domain controllers.

VNets in East US 2 are summarized in the following table.

VNet Range Peer

Hub and spoke model in the primary region

Subnets in the East US 2 Hub network (VNET-HUB-EUS2)

Subnet/zone CIDR **Usable IP addresses
IB-UntrustZone 251
IB-TrustZone 251
OB-UntrustZone 251
OB-TrustZone 251
GatewaySubnets 251

Subnets in the East US 2 Dev network (VNET-DEV-EUS2)

The Development VNet is used by the development team as a production pilot area. It has three subnets.

Subnet CIDR Addresses In subnet
DEV-FE-EUS2 1019 Front-ends/web-tier VMs
DEV-APP-EUS2 1019 App-tier VMs
DEV-DB-EUS2 507 Database VMs

Subnets in the East US 2 Production network (VNET-PROD-EUS2)

Azure IaaS components are located in the Production network. Each app tier has its own subnet. Subnets match those in the Development network, with the addition of a subnet for domain controllers.

Subnet CIDR Addresses In subnet
PROD-FE-EUS2 1019 Front-ends/web tier VMs
PROD-APP-EUS2 1019 App-tier VMs
PROD-DB-EUS2 507 Database VMs
PROD-DC-EUS2 251 Domain controller VMs

Hub network architecture

Virtual networks in Central US (secondary region)

Central US is Contoso's secondary region. Here's how Contoso will architect networks within it:

  • Hub: The hub VNet in Central US is considered their secondary point of connectivity to the on-premises datacenter, and the spoke VNets in Central US can be used to isolate workloads if necessary, managed separately from other spokes.
  • VNets: Contoso will have two VNets in Central US:
    • VNET-PROD-CUS. This VNet is a production network and can be thought of as a secondary hub.
    • VNET-ASR-CUS. This VNet will act as a location in which VMs are created after failover from on-premises, or as a location for Azure VMs that are failed over from the primary to the secondary region. This network is similar to the production networks, but without any domain controllers on it.
    • Each VNet in the region will have its own address space, with no overlap. Contoso will configure routing without NAT.
  • Subnets: The subnets will be designed in a similar way to those in East US 2.

The VNets in Central US are summarized in the following table.

VNet Range Peer

Hub and spoke model in paired region

Subnets in the Central US Hub network (VNET-HUB-CUS)

Subnet CIDR Usable IP addresses
IB-UntrustZone 251
IB-TrustZone 251
OB-UntrustZone 251
OB-TrustZone 251
GatewaySubnet 251

Subnets in the Central US Production network (VNET-PROD-CUS)

In parallel with the production network in the primary East US 2 region, there's a production network in the secondary Central US region.

Subnet CIDR Addresses In subnet
PROD-FE-CUS 1019 Front-ends/web-tier VMs
PROD-APP-CUS 1019 App-tier VMs
PROD-DB-CUS 507 Database VMs
PROD-DC-CUS 251 Domain controller VMs

Subnets in the Central US failover/recovery network in Central US (VNET-ASR-CUS)

The VNET-ASR-CUS network is used for purposes of failover between regions. Site Recovery will be used to replicate and fail over Azure VMs between the regions. It also functions as a Contoso datacenter to Azure network for protected workloads that remain on-premises, but fail over to Azure for disaster recovery.

VNET-ASR-CUS is the same basic subnet as the production VNet in East US 2, but without the need for a domain controller subnet.

Subnet CIDR Addresses In subnet
ASR-FE-CUS 1019 Front-ends/web-tier VMs
ASR-APP-CUS 1019 App-tier VMs
ASR-DB-CUS 507 Database VMs

Hub network architecture

Configure peered connections

The hub in each region will be peered to the hub in the other region, and to all VNets within the hub region. This allows for hubs to communicate, and to view all VNets within a region. Note that:

  • Peering creates a two-sided connection. One from the initiating peer on the first VNet, and another one on the second VNet.
  • In a hybrid deployment, traffic that passes between peers needs to be visible from the VPN connection between the on-premises datacenter and Azure. To enable this, there are some specific settings that must be set on peered connections.

For any connections from spoke VNets through the hub to the on-premises datacenter, Contoso needs to allow traffic to be forwarded, and transverse the VPN gateways.

Domain controller

For the domain controllers in the VNET-PROD-EUS2 network, Contoso wants traffic to flow both between the EUS2 hub/production network, and over the VPN connection to on-premises. To do this, Contoso admins must allow the following:

  1. Allow forwarded traffic and Allow gateway transit configurations on the peered connection. In our example, this would be the VNET-HUB-EUS2 to VNET-PROD-EUS2 connection.


  2. Allow forwarded traffic and Use remote gateways on the other side of the peering, on the VNET-PROD-EUS2 to VNET-HUB-EUS2 connection.


  3. On-premises they'll set up a static route that directs the local traffic to route across the VPN tunnel to the VNet. The configuration would be completed on the gateway that provides the VPN tunnel from Contoso to Azure. They use RRAS for this.


Production networks

A spoked peer network can't see a spoked peer network in another region via a hub.

For Contoso's production networks in both regions to see each other, Contoso admins need to create a direct peered connection for VNET-PROD-EUS2 and VENT-PROD-CUS.


Set up DNS

When you deploy resources in virtual networks, you have a couple of choices for domain name resolution. You can use name resolution provided by Azure, or provide DNS servers for resolution. The type of name resolution you use depends on how your resources need to communicate with each other. Get more information about the Azure DNS service.

Contoso admins have decided that the Azure DNS service isn't a good choice in the hybrid environment. Instead, they will use the on-premises DNS servers.

  • Since this is a hybrid network, all the VMs on premises and in Azure need to be able to resolve names to function properly. This means that custom DNS settings must be applied to all the VNets.

  • Contoso currently has DCs deployed in the Contoso datacenter and at the branch offices. The primary DNS servers are CONTOSODC1 ( and CONTOSODC2 (

  • Once the VNets are deployed, the on-premises domain controllers are configured as DNS servers in the networks.

  • If an optional custom DNS is specified for the virtual network, the virtual IP address for the recursive resolvers in Azure must be added to the list. To do this, Contoso configures DNS server settings on each VNet. For example, the custom DNS settings for the VNET-HUB-EUS2 network would be as follows:

    Custom DNS

In addition to the on-premises domain controllers, Contoso will implement four more domain controllers to support the Azure networks, two for each region. Here's what Contoso will deploy in Azure.

Region DC VNet Subnet IP address

After deploying the on-premises domain controllers, Contoso needs to update the DNS settings on networks on either region to include the new domain controllers in the DNS server list.

Set up domain controllers in Azure

After updating network settings, Contoso admins are ready to build out the domain controllers in Azure.

  1. In the Azure portal, they deploy a new Windows Server VM to the appropriate VNet.

  2. They create availability sets in each location for the VM. Availability sets do the following:

    • Ensure that the Azure fabric separates the VMs into different infrastructures in the Azure Region.
    • Allows Contoso to be eligible for the 99.95% SLA for VMs in Azure. Learn more.

    Availability group

  3. After the VM is deployed, they open the network interface for the VM. They set the private IP address to static, and specify a valid address.

    VM NIC

  4. Now, they attach a new data disk to the VM. This disk contains the Active Directory database, and the sysvol share.

    • The size of the disk will determine the number of IOPS that it supports.
    • Over time the disk size might need to increase as the environment grows.
    • The drive shouldn't be set to Read/Write for host caching. Active Directory databases don't support this.

    Active Directory disk

  5. After the disk is added, they connect to the VM over Remote Desktop, and open Server Manager.

  6. Then in File and Storage Services, they run the New Volume Wizard, ensuring that the drive is given the letter F: or above on the local VM.

    New Volume Wizard

  7. In Server Manager, they add the Active Directory Domain Services role. Then, they configure the VM as a domain controller.

    Server role

  8. After the VM is configured as a DC and rebooted, they open DNS Manager and configure the Azure DNS resolver as a forwarder. This allows the DC to forward DNS queries it can't resolve in the Azure DNS.

    DNS forwarder

  9. Now, they update the custom DNS settings for each VNet with the appropriate domain controller for the VNet region. They include on-premises DCs in the list.

Set up Active Directory

Active Directory is a critical service in networking, and must be configured correctly. Contoso admins will build Active Directory sites for the Contoso datacenter, and for the EUS2 and CUS regions.

  1. They create two new sites (AZURE-EUS2, and AZURE-CUS) along with the datacenter site (ContosoDatacenter).

  2. After creating the sites, they create subnets in the sites, to match the VNets and datacenter.

    DC subnets

  3. Then, they create two site links to connect everything. The domain controllers should then be moved to their location.

    DC links

  4. After everything is configured, the Active Directory replication topology is in place.

    DC replication

  5. With everything complete, a list of the domain controllers and sites is shown in the on-premises Active Directory Administrative Center.

    Active Directory Administrative Center

Step 5: Plan for governance

Azure provides a range of governance controls across services and the Azure platform. For more information, see the Azure governance options.

As they configure identity and access control, Contoso has already begun to put some aspects of governance and security in place. Broadly, there are three areas it needs to consider:

  • Policy: Azure Policy applies and enforces rules and effects over your resources, so that resources stay compliant with corporate requirements and SLAs.
  • Locks: Azure allows you to lock subscriptions, resources groups, and other resources, so that they can be modified only by those with authority to do so.
  • Tags: Resources can be controlled, audited, and managed with tags. Tags attach metadata to resources, providing information about resources or owners.

Set up policies

The Azure Policy service evaluates your resources, scanning for those not compliant with the policy definitions you have in place. For example, you might have a policy that only allows certain types of VMs, or requires resources to have a specific tag.

Policies specify a policy definition, and a policy assignment specifies the scope in which a policy should be applied. The scope can range from a management group to a resource group. Learn about creating and managing policies.

Contoso wants to begin a couple of policies:

  • It wants a policy to ensure that resources can be deployed in the EUS2 and CUS regions only.
  • It wants to limit VM SKUs to approved SKUs only. The intention is to ensure that expensive VM SKUs aren't used.

Limit resources to regions

Contoso uses the built-in policy definition Allowed locations to limit resource regions.

  1. In the Azure portal, select All services, and search for Policy.

  2. Select Assignments > Assign policy.

  3. In the policy list, select Allowed locations.

  4. Set Scope to the name of the Azure subscription, and select the two regions in the allowed list.

    Policy allowed regions

  5. By default the policy is set with Deny, meaning that if someone starts a deployment in the subscription that isn't in EUS2 or CUS, the deployment will fail. Here's what happens if someone in the Contoso subscription tries to set up a deployment in West US.

    Policy failed

Allow specific VM SKUs

Contoso will use the built-in policy definition Allow virtual machines SKUs to limit the type of VMs that can be created in the subscription.

Policy SKU

Check policy compliance

Policies go into effect immediately, and Contoso can check resources for compliance.

  1. In the Azure portal, select the Compliance link.

  2. The compliance dashboard appears. You can drill down for further details.

    Policy compliance

Set up locks

Contoso has long been using the ITIL framework for the management of its systems. One of the most important aspects of the framework is change control, and Contoso wants to make sure that change control is implemented in the Azure deployment.

Contoso is going to implement locks as follows:

  • Any production or failover component must be in a resource group that has a ReadOnly lock. This means that to modify or delete production items, the lock must be removed.
  • Nonproduction resource groups will have CanNotDelete locks. This means that authorized users can read or modify a resource, but cannot delete it.

Learn more about locks.

Set up tagging

To track resources as they're added, it will be increasingly important for Contoso to associate resources with an appropriate department, customer, and environment.

In addition to providing information about resources and owners, tags will enable Contoso to aggregate and group resources, and to use that data for chargeback purposes.

Contoso needs to visualize its Azure assets in a way that makes sense for the business, such as by role or department. Note that resources don't need to reside in the same resource group to share a tag. Contoso will create a tag taxonomy so that everyone uses the same tags.

Tag name Value
CostCenter 12345: It must be a valid cost center from SAP.
BusinessUnit Name of business unit (from SAP). Matches CostCenter.
ApplicationTeam Email alias of the team that owns support for the app.
CatalogName Name of the app or ShareServices, per the service catalog that the resource supports.
ServiceManager Email alias of the ITIL Service Manager for the resource.
COBPriority Priority set by the business for BCDR. Values of 1-5.
ENV DEV, STG, and PROD are the allowed values. Representing developing, staging, and production.

For example:

Azure tags

After creating the tag, Contoso will go back and create new policy definitions and assignments, to enforce the use of the required tags across the organization.

Step 6: Consider security

Security is crucial in the cloud, and Azure provides a wide array of security tools and capabilities. These help you to create secure solutions, on the secure Azure platform. Read Confidence in the trusted cloud to learn more about Azure security.

There are a few aspects for Contoso to consider:

  • Azure Security Center: Azure Security Center provides unified security management and advanced threat protection across hybrid cloud workloads. With Security Center, you can apply security policies across your workloads, limit your exposure to threats, and detect and respond to attacks. Learn more.
  • Network security groups (NSGs): An NSG is a filter (firewall) that contains a list of security rules that, when applied, allow or deny network traffic to resources connected to Azure VNets. Learn more.
  • Data encryption: Azure Disk Encryption is a capability that helps you encrypt your Windows and Linux IaaS virtual machine disks. Learn more.

Work with the Azure Security Center

Contoso is looking for a quick view into the security posture of its new hybrid cloud, and specifically its Azure workloads. As a result, Contoso has decided to implement Azure Security Center starting with the following features:

  • Centralized policy management.
  • Continuous assessment.
  • Actionable recommendations.

Centralize policy management

With centralized policy management, Contoso will ensure compliance with security requirements by centrally managing security policies across the entire environment. It can simply and quickly implement a policy that applies to all of its Azure resources.

Security policy

Assess and action

Contoso will take advantage of the continuous security assessment that monitors the security of machines, networks, storage, data, and applications; to discover potential security issues.

  • Security Center analyzes the security state of the Contoso compute, infrastructure, and data resources, and of Azure apps and services.
  • Continuous assessment helps the Contoso operations team to discover potential security issues, such as systems with missing security updates or exposed network ports.
  • In particular Contoso wants to make sure all of the VMs are protected. Security Center helps with this, verifying VM health, and making prioritized and actionable recommendations to remediate security vulnerabilities before they're exploited.


Work with NSGs

Contoso can limit network traffic to resources in a virtual network using network security groups.

  • A network security group contains a list of security rules that allow or deny inbound or outbound network traffic based on source or destination IP address, port, and protocol.
  • When applied to a subnet, rules are applied to all resources in the subnet. In addition to network interfaces, this includes instances of Azure services deployed in the subnet.
  • Application security groups (ASGs) enable you to configure network security as a natural extension of an app structure, allowing you to group VMs and define network security policies based on those groups.
    • Application security groups mean that Contoso can reuse the security policy at scale, without manual maintenance of explicit IP addresses. The platform handles the complexity of explicit IP addresses and multiple rule sets, allowing you to focus on your business logic.
    • Contoso can specify an application security group as the source and destination in a security rule. After a security policy is defined, Contoso can create VMs, and assign the VM NICs to a group.

Contoso will implement a mix of NSGs and ASGs. Contoso is concerned about NSG management. It's also worried about the overuse of NSGs, and the added complexity for operations staff. Here's what Contoso will do:

  • All traffic into and out of all subnets (north-south), will be subject to an NSG rule, except for the GatewaySubnets in the Hub networks.
  • Any firewalls or domain controller will be protected by both subnet NSGs and NIC NSGs.
  • All production applications will have ASGs applied.

Contoso has built a model of how this will look for its applications.


The NSGs associated with the ASGs will be configured with least privilege to ensure that only allowed packets can flow from one part of the network to its destination.

Action Name Source Target Port
Allow AllowInternetToFE VNET-HUB-EUS1/IB-TrustZone APP1-FE 80, 443
Allow AllowWebToApp APP1-FE APP1-APP 80, 443
Allow AllowAppToDB APP1-APP APP1-DB 1433
Deny DenyAllInbound Any Any Any

Encrypt data

Azure Disk Encryption integrates with Azure Key Vault to help control and manage the disk-encryption keys and secrets in a Key Vault subscription. It ensures that all data on VM disks are encrypted at rest in Azure storage.

  • Contoso has determined that specific VMs require encryption.
  • Contoso will apply encryption to VMs with customer, confidential, or PPI data.


In this article, Contoso set up an Azure infrastructure and policy for Azure subscription, hybrid identify, disaster recovery, networking, governance, and security.

Not every step taken here is required for a cloud migration. In this case, Contoso planned a network infrastructure that could handle all types of migrations while being secure, resilient, and scalable.

With this infrastructure, Contoso is ready to move on and try out migration.

Next steps

After setting up their Azure infrastructure, Contoso is ready to begin migrating workloads to the cloud. See the migration patterns and examples overview section for a selection of scenarios using this sample infrastructure as a migration target.