A great SAP architecture on Azure starts with a solid foundation built on four pillars:

Security

Performance and scalability

Availability and recoverability

Efficiency and operations

Designing for security

Your SAP data is likely the treasure of your organization’s technical footprint. Therefore, you need to focus on securing access to your SAP architecture by way of secure authentication, protecting your application and data from network vulnerabilities, and maintaining data integrity through encryption methods.

SAP on Azure is delivered in the Infrastructure-as-a-Service (IaaS) cloud model. This means security protections are built into the service by Microsoft at the physical datacenter, physical network, physical host level, and the hypervisor. Therefore, for those areas above the hypervisor (e.g. the guest operating system for SAP), you need to undertake a careful evaluation of the services and technologies you select to ensure you are providing the proper security controls for your architecture.

In terms of authentication, you can take advantage of Azure Active Directory(Azure AD) to enable single-sign-on (SSO) to your S/4HANA Fiori Launchpad. Azure AD can also be integrated with the SAP Cloud Platform (SCP) to provide single-sign-on to your SCP services which can also be run on Azure.

Network Security Groups (NSG) allow you to filter network traffic to and from resources in you virtual network. NSG rules can be defined to allow or deny access to your SAP services, for instance, allowing access to the SAP Application ports from on-premises IP addresses ranges and deny public Internet access.

With regards to data integrity, Azure Disk Encryption helps you encrypt your SAP virtual machine disks where both the operating system and data volumes can be encrypted at rest in storage. Azure Disk Encryption is integrated with Azure Key Vault which controls and manages your encryption keys. Many of our SAP customers choose Azure Disk Encryption for their operating system disks and transparent DBMS data encryption for their SAP database files. This approach secures the integrity of the operating system and ensures database backups are also encrypted.

To dig further into topics of interest in the security area, you can refer to our Azure Security documentation.

Designing for performance and scalability

Performance is a key driver for digitizing business processes, and having a performant SAP application is crucial for end users to work efficiently without frustration. Therefore, it is important to undertake a quality sizing exercise for your SAP deployment and to right-size your Azure components – compute, storage, and network.

SAP Note #1928533 details the SAPS value for Azure Virtual Machines supported to run SAP Applications, and within the links below you can attain the network and storage throughput per Azure VM type:

The agility of Azure allows you to scale your SAP system with ease, for example, increasing the compute capacity of the database server or horizontally scaling through the addition of application servers when demand arises. This includes temporarily beefing up the infrastructure to accelerate your SAP migration throughput and reduce the downtime.

Use Premium Storage Managed Disks for the SAP database server to benefit from high-performance and low-latency I/O. Be mindful, that you may need build a RAID-0 stripe to aggregate IOPS and throughput to meet your application needs. In the case of SAP HANA workloads, we cover storage best practice within our documentation, “SAP HANA infrastructure configurations and operations on Azure.”

ExpressRoute or VPN facilitates connectivity for on-premises SAP end users and application interfaces connecting to your SAP applications in Azure. For production SAP applications in Azure, we recommend ExpressRoute for a private, dedicated connection which offers reliability, faster speed, lower latency, and tighter security. Be mindful of latency sensitive interfaces between SAP and non-SAP applications, you may need to define migration “move groups” where groups of SAP applications and non-SAP applications are landed on Azure together.

Designing for availability and recoverability

Operational stability and business continuity are crucial for mission critical, tier-1 SAP applications. Designing for availability ensures that SAP application uptime is secured in the event of localized software or hardware failures. In the case of productive SAP applications, we recommend the virtual machines which run the SAP single points of failure, such as the system central services A(SCS) and database are deployed in Availability Sets or Availability Zones, to protect against planned and unplanned maintenance events. This also applies to the SAP Application servers where a few smaller servers are recommended instead of one larger application server. Operating system cluster technologies such as Windows Failover cluster or Linux Pacemaker would be configured on the guest OS to ensure short failover times of the A(SCS) and DBMS. DBMS synchronous replication would be configured to ensure no loss of data.

Designing for recoverability means recovering from data loss, such as a logical error on the SAP database or from large scale disasters, or loss of a complete Azure region. When designing for recoverability, it is necessary to understand the Recovery Point Objective (RPO) and Recovery Time Objective (RTO) of your SAP Application. Azure Regional Pairs are recommended for disaster recovery which offer isolation and availability to hedge against the risks of natural or man disasters impacting a single region.

On the DBMS layer, asynchronous replication can be used to replicate your production data from your primary region to your disaster recovery region. On the SAP application layer, Azure-to-Azure Site Recovery can be used as part of an efficient, cost-conscious disaster recovery solution.

It is essential to carefully consider both availability and recoverability within the design of the SAP deployment architecture. This will protect your business from financial losses resulting in downtime and data loss.

Designing operations and efficiency

Your move to Azure also presents an opportunity to undertake an SAP system rationalization assessment. Do you need to move all SAP systems or can you decommission those which are no longer used? For example, Microsoft-IT decommissioned approximately 60 virtual machines as part of our SAP migration to Azure.

In terms of efficiency, focus on eliminating waste within your SAP on Azure deployment. Post go-live, review the sizing. Can you reduce the size of your virtual machine based on utilization? Can you drop disks which are not being used?

Establishing infrastructure manually for each SAP deployment can be tedious and error prone, often costing hours or days if multiple SAP installation are required. Therefore, to improve efficiency it makes sense to automate your SAP infrastructure deployment and software installation as much as possible. Embrace the DevOps paradigm using infrastructure-as-code to build new SAP environments as needed, such as in SAP project landscapes. Below, some links to give you a head start on automation.