Hosting SAP workloads on Microsoft Azure has accelerated over the past three years as companies look to reduce cost of ownership of their IT systems and increase flexibility and efficiency.

Whilst the cost of hosting with any public cloud provider will generally be less than hosting on-premises, we still need to keep a watchful eye on the incurred costs to ensure we’re not over-spending and living up to the expectations of the business case that was initially put forward to our peers.

I attended a recent Microsoft Azure webinar “WEWC260 Cost Calculation for SAP on Azure solution” which focused on the topic of Azure costs and how various factors influence the pricing of the various components, e.g.

  1. Virtual Machines (VM)
  2. Storage
  3. Backups
  4. Data Ingress & Egress

I thought it might be useful to share this with you, summarise the important aspects and show how we have supplemented these capabilities with SAP Landscape Management cloud connectivity and automation.

 

Pay As You Go (PAYG)

There are a number of factors affecting how Microsoft charge their customers for consuming the various cloud resources, the majority of which are based on the “Pay as You Go” (PAYG) model; you only pay for what you consume, in the same way we pay for our electricity, for example.

In this model, virtual machines are charged per “running” minute. By this we mean, the VM has been “allocated” resources (CPU/RAM) and is ready for the host operating system to be booted. If the host operating system were to never boot, we would still be charged as the VM is “allocated”. Consequently, when we shut down the operating system and have no intention to restart it, we need to “deallocate” the VM to stop being charged for consuming the associated CPU/RAM.

If we’re not diligent, this can result in high consumption charges for some of the larger M-Series VMs that are required to support SAP HANA, for example. We need to be mindful of this and look to deallocate VMs when no longer required.

 

Azure Advisor

The Azure Advisor is a personalised service that continuously collects data to help you follow best practices to optimize your Azure deployments. Recommendations should be reviewed on a regular basis because there may be a cost saving opportunity presented – one that you may not have considered. For example, if a VM is over-sized or under-utilised, why not consider changing the VM type as discussed below in “VM Right-Sizing”?

Here is an example of the recommendations presented by the Azure Advisor (with sensitive cost saving data redacted):

Of the above, the first recommendation is yielding the biggest saving – buy virtual machine reserved instances, which we discuss further in the next section but in essence, listen to the advisor!

An comprehensive overview of the Microsoft Azure Advisor is available in the Microsoft Documentation – https://docs.microsoft.com/en-us/azure/advisor/advisor-overview.

 

Reserved Instances

Purchasing Azure Reserved Instances (RI) help you save money on your compute spend by committing to a one-year or three-year plan. This commitment allows you to have discounted prices on the resources you use. Using RI can significantly reduce compute costs by up to 72% on pay-as-you-go prices and you can pay for a reservation up-front or monthly to spread the cost.

RI is probably going to work out cost-effective for production systems that most likely have a requirement to be available 24×7 for the majority of the year. But what about non-production systems? SAP projects by their nature tend to have peaks and troughs in the usage of the various non-production environments. For example, testing cycles might occur infrequently and only at strategic times in a project life cycle. It would therefore make sense to shut down the involved SAP systems and deallocate the hosting VMs to reduce Azure spend.

There comes a point where PAYG is more cost-effective than RI. A very quick ROM analysis of a typical D8v3-series VM used to host an SAP application server shows how reducing the uptime of the VM from 24 hours per day per month, to 16 hours per day on weekdays only, makes PAYG more attractive.

 

VM Right-Sizing

Once your SAP workload has been operating in Azure for a period that encapsulates all of your business processes, it would be advisable to gather as much information regarding resource consumption of the virtual machines in your SAP estate to see if there are opportunities to adjust the VM type.

 

Selective Disk Backup Support on Azure Backups

One of our customers had been taking daily Azure VM backups to the Azure Backup vault. This included VMs that hosted database systems, whose data was being backed-up using database methods, thus causing duplication and higher than expected costs.

Until recently, Azure Backup only supported backing up all the disks in a VM together using the Azure VM backup solution;  there was no possibility to exclude certain disks, e.g. the database data and log disks.

In late January of this year, Microsoft announced selective disk backup support for Azure Backup, specifically to address this – https://azure.microsoft.com/is-is/updates/excludediskpreview/.

Needless to say, we’re now working with the customer to review the backup strategy after suggesting they enrolled on the Preview of this functionality.

 

LaMa Scheduling

With the SAP Landscape Management (LaMa) tool, it’s possible to perform operations, such as stop and start, on various elements in your SAP estate – e.g. instances, databases, hosts and custom instances. It is also possible to schedule (automate) these operations at times when your technical teams are not working – e.g. out of working hours and weekends.

With the introduction of SAP LaMa 3.0, SAP introduced cloud connectivity to public cloud providers through “Cloud Manager” definitions. One of the supported Cloud Managers from SAP is Microsoft Azure. The setup of which is described in note 2343511 – Microsoft Azure connector for SAP Landscape Management (LaMa).

Of the supported operations included with this cloud connectivity, we have the ability to activate (allocate) and deactivate (deallocate) Azure virtual machines, and include these operations into a LaMa schedule. As previously mentioned, a virtual machine that is deallocated incurs no compute cost. Therefore, including a power-off of the virtual machine hosting SAP into a shutdown schedule, will reduce the virtual machine running costs. This is very attractive option for non-production systems.

 

LaMa Shutdown including Storage Savings

With SAP Landscape Management 3.0 SP11, SAP introduced an additional option on the “Cloud Managers” configuration – “Change Storage Type to save costs”. This enables you to save costs by changing the storage type of from Managed Disks to “Standard” whilst the VM is deallocated.

Not only will you save on compute whilst VMs are deallocated, but the storage costs of disks attached to the deallocated VMs is switched from “Premium” to “Standard”; a further operating cost is realised. This may not be a huge saving but every little counts – for example, in the West Europe region, the cost of a Standard SSD disks (E-series) is approximately 50% cheaper than the equivalent Premium SSD disk (P-series).

 

Summary

Whilst hosting SAP workload in Azure is a very interesting and attractive, once you’re there you need to be mindful of the ongoing costs and look to achieve further savings with the tools, experience and information that’s out there. This is something we now offer in our new SAP on Azure: Run” service.