EC2 Instances for SAP Workloads on AWS

The course is part of this learning path

EC2 Instances for SAP Workloads on AWS

This course discusses EC2 instances for SAP workloads on AWS.

Learning Objectives

Our learning objectives for this course are to:

  • Get an understanding of what EC2 instances are recommended for SAP HANA workloads
  • Learn the ways we can scale out these instances
  • And finally talk about how to migrate to high memory instances

Intended Audience

I would recommend this course for anyone attempting to create an SAP based architecture.


You should have a decent understanding of cloud computing and cloud architectures, specifically with Amazon Web Services. You should also have some background knowledge related to SAP HANA.


One of the main hurdles for creating your SAP systems within the cloud is trying to figure out which of the EC2 instance types would be best for your solution. Well, like most things in life, best is kind of subjective and comes down to what your goals are. There is some good news, however, that will help you narrow down the decision of which there are almost 400 different instances you can choose from. That good news comes in two forms. 

The first is that SAP and AWS have worked together to verify and certify which instance types are suitable for SAP workloads. This certification is non-specific but it does guarantee that SAP can run on these instances and won't have any major issues. Not all instance types work well for SAP workloads and that is why it's important to check which EC2 instances are actually certified SAP instance types. AWS mentions that you can run any non-production workload on any EC2 instance type, but the best practice is to use a certified instance type for any production workloads. 

These instance types have an SAP performance rating tied to them and can help guide you into which instances fit your requirements. Personally, I would go straight with the certified options and not use any of the others. This way you're already set up for success. Instances can be broken down into three categories; general-purpose, compute-optimized, and memory-optimized. The general-purpose instances are good for a burstable performance and general-purpose uses. 

They are pretty non-specific and therefore, are the jack of all trades kind of instance. The compute-optimized instances are very good for compute-intensive workloads and applications that are compute-limited. And the memory-optimized instances work well for workloads that process large data sets like HANA, for example. Additionally, AWS has implemented a new naming convention for the instance types that will help distinguish what type of processor they are running. The new naming schema follows the following format of family, generation, processor. For example, you might now see an instance of M6I. This would be an instance of type M, generation 6, and running an intel processor. 

This format follows for AMD processors which are designated with an A and Graviton processors which are followed up with a G. Another important addendum to add here is that any of the instances with an N in their name mean they're network optimized instances. So, you could have something like a C6gn, which should be a C-type instance of the sixth generation, running on a graviton processor that has been network optimized. You might also see other letters like B which stipulates this instance has been further memory-optimized and has greatly increased EBS storage performance. When looking over the memory-optimized instances which are good for HANA, we will want to take specific care to look into the U-type instance category. 

They were specifically built to run large in memory databases. Those are particularly good for production workloads of HANA. These U type instances come in two flavors; virtual and bare metal. The price is about the same when comparing the 6, 9, and 12-Terabyte versions when purchased as a one year reserved or a three year, reserved instance. The one upside to the virtual instances is that you can run them on demand instead so you can shut them down when they're not in use. This will of course cost more on a minute-to-minute basis but you can regain that cost quickly by shutting them down and not using them when unneeded. This might be the case if you're sandboxing or still developing out your systems.


About the Author

William Meadows is a passionately curious human currently living in the Bay Area in California. His career has included working with lasers, teaching teenagers how to code, and creating classes about cloud technology that are taught all over the world. His dedication to completing goals and helping others is what brings meaning to his life. In his free time, he enjoys reading Reddit, playing video games, and writing books.