After you’ve procured a Microsoft Azure subscription, the next step is to determine how you’ll connect Microsoft Azure to your SAP system and how you'll configure the network within the subscription.

Architecture questions to consider include the following:

• How do I connect to Microsoft Azure resources?
• What kind of topology does the Microsoft Azure network need?
• How do multiple virtual networks (VNets) communicate in Microsoft Azure?
• What IP ranges do Microsoft Azure networks have?
• Is there a cost associated with data transfer between multiple networks?
• Does SAP HANA need a different network for client versus storage communication?
• Should there be separate networks for application connectivity and operational activities, such as backups?

Connectivity to Microsoft Azure

ExpressRoute is the preferred way to connect to Microsoft Azure because it supports higher bandwidth and is a private connection. ExpressRoute can take weeks to set up, so during the initial stages, setting a site-to-site Virtual Private Network (VPN) can get you going.

ExpressRoute connects on-premise systems’ resources to the Microsoft Azure subscription via the gateway that’s deployed in a VNet with its own dedicated subnet.

Network Design

The VNet, similar to on-premise networks, is the foundational component of a network inside a subscription. Each VNet is bound to a region and a subscription, and VNets can be divided into smaller parts called subnets.

The factors to consider when determining the number of VNets are security model, available IP ranges (classless inter-domain routing [CIDR]), and cost. Because VNets are isolated by design, when you have multiple networks, you need to connect them using the peering process. VNet peering enables the communication and makes the network space bigger, but it comes at a cost; Microsoft Azure charges for inbound and outbound data transfer between peered VNets.

VNet Peering Isn’t Transitive. If VNet A is peered with VNet B, and B is peered with C, then A isn’t peered with C. If you need communication between A and C, then those VNets should be peered separately.

With cost optimization in mind, minimizing the number of VNets should be the target; however, because each VNet also requires a contiguous IP address range in CIDR format, depending on whether you have the range available, the number of VNets will change. Microsoft recommends using the IP range for private networks as recommended by the Internet Assigned Numbers Authority (IANA):

• 0.0.0–10.255.255.255 (10/8 prefix)
• 16.0.0–172.31.255.255 (172.16/12 prefix)
• 168.0.0–192.168.255.255 (192.168/16 prefix)

In addition, in Microsoft Azure, you can’t use the following ranges because they are reserved by the platform:

• 0.0.0/4 (Multicast)
• 255.255.255/32 (Broadcast)
• 0.0.0/8 (Loopback)
• 254.0.0/16 (Link-local)
• 63.129.16/32 (internal domain name service [DNS])

When you move SAP systems to Microsoft Azure, there are other supporting systems such as DNS, network virtual appliance, identity management systems, domain services, bastion hosts, and so on that may not be exclusively used by SAP systems, or security teams might want more control over those. It may make sense to put those systems in a separate VNet—we’ll call it hub network—that peers with SAP network (or spoke VNets). If you already have a hub network in another subscription, that can be used by peering to the SAP subscription as well. The figure below illustrates this hub and spoke approach.

Following a micro segmentation strategy, you can divide the SAP VNet into application and database subnets. By default, all the subnets (inside a VNet) can communicate with each other using automatically created system routes. If you need to restrict traffic flow in a certain way, you can create custom routes called user-defined routes. You can put further restrictions on subnets, and workload-specific VMs (e.g., databases) using network security groups and application security groups. At the subnet level, network security groups define the access policies for the subnet.

Subnet Sizes for Gateway, Bastion, and Microsoft Azure NetApp Files

Depending on the setup and growth considerations, there are a minimum number of IPs that Microsoft Azure recommends for certain subnets, such as gateway, bastion, Microsoft Azure NetApp Files, and so on (because Microsoft Azure reserves five IPs for each subnet, the number of available IPs need to be considered, not the total as represented by CIDR notation).

The following IPs are reserved by Microsoft Azure:

• x.x.0: Network address.
• x.x.1: Default gateway.
• x.x.2, x.x.x.3: To map the Microsoft Azure DNS IPs to the VNet space.
• x.x.255: Network broadcast address.

At the time of publishing, following are the recommendations from Microsoft:

• GatewaySubnet: /27 or larger
• AzureBastionSubnet: /27 or larger
• Microsoft Azure NetApp Files Subnet: /28 or higher

At the time of publishing, gateway and Microsoft Azure NetApp Files subnets don’t allow network security groups. Bastion subnets allow network security groups but don’t support user-defined routes.

Below shows the architecture we’ve discussed so far for regions, connectivity, and networks (VNet, subnet, network security groups).

SAP HANA Network Zones

SAP HANA components use different logical network zones for communication, that is, client, internal, and storage zone, which can be implemented using subnets in Microsoft Azure. Each zone may have different configurations for performance and security:

• Client zone: This zone includes SAP application servers, browser-based sources, and other data sources (e.g., a business intelligence solution).
• Internal zone: This zone spans communication between hosts for SAP HANA system replication and among nodes for scale-out configuration.
• Storage zone: This zone is important for data write processes in persistent storage, especially when it’s accessed over a network.

The network setups for the different zones are illustrated in this figure.

Database App Connectivity and Management Network

For database servers, traffic segregation is recommended in which you can have a subnet for application connectivity and another for operational activities and management such as backup traffic. You can also apply different security policies to these using network security groups. This can be achieved by creating multiple vNICs for each VM, as shown here.

Perimeter Network

The perimeter network, also called the demilitarized zone (DMZ), enables a secure connection using techniques such as packet sniffing, intrusion detection, policy enforcement, and so on between Microsoft Azure and the Internet.

In the SAP context, systems such as SAP Web Dispatcher (when external facing) and SAPRouter that have connections to and from the Internet should be protected. In addition, you can also use it for security between Microsoft Azure and on-premise systems.

The next figure shows the setup using network virtual appliance (or the Microsoft Azure firewall); it provides a secure network boundary by inspecting all Internet traffic. Network virtual appliance can be a single point of failure as well, so consider putting two network virtual appliances in an AS for a better SLA.

Note: Microsoft Azure doesn’t support the setup with network virtual appliance between SAP application and database servers.

This content was originally posted on the SAP PRESS Blog and has been adapted from a section of the book SAP on Microsoft Azure: Architecture and Administration by Ravi Kashyap. Used with permission of SAP PRESS. All rights reserved.