Compute and storage options for SAP workloads are the specific types of virtual servers and storage volumes you choose to run your SAP applications and databases in the cloud. Getting this choice right determines whether your SAP system runs fast, stays reliable, and does not waste money. For the PAS-C01 exam, you must know exactly which EC2 instance types and which storage services fit different SAP workloads, because every scenario question will test your ability to match a business requirement (like "needs high memory for an in-memory database") to the correct AWS service.
Jump to a section
A simple way to picture Compute and Storage Options for SAP Workloads
A massive department store in the middle of a busy city. It has everything: clothes, electronics, furniture, groceries, each in its own dedicated section. The store is famous for having exactly the right space and setup for every type of product — delicate items need cold shelves, heavy items need reinforced floors, and hot food needs heat lamps.
Now, imagine you are a large event planner. You need a temporary shop to handle a huge pop-up sale for a single weekend. You do not build a new store from scratch. Instead, you walk into the department store and rent space. For the pop-up, you need a section with heavy-duty power outlets for computers, a walk-in freezer for perishable goods, and security cameras for the expensive jewellery. The department store has all these pre-built sections. You just pick the one that matches your needs.
In the cloud, SAP workloads are like your pop-up event. AWS is the department store. The "sections" are EC2 instance types. You choose a memory-optimised instance (the walk-in freezer) when your SAP database needs lots of fast memory. You choose a compute-optimised instance (the heavy-duty power outlets) when your application is doing complex calculations. The storage options — EBS, FSx, S3 — are like different shelving options: solid shelves for heavy data (EBS), shared shelves for teamwork (FSx), and deep warehouse storage for archival (S3). The key is matching the right rented section to the specific needs of your business event.
When you run SAP on AWS, you are essentially running software on a computer that lives in a data center owned by Amazon. But you do not own that computer you rent a slice of it. The two primary choices you make are: what kind of virtual computer (EC2 instance) to run, and what kind of hard drive (storage) to attach to it.
EC2 stands for Amazon Elastic Compute Cloud. It is a service that lets you rent virtual servers, called instances. Each instance type is a predefined combination of CPU (the brain), memory (the short-term workspace), and networking (the speed of data transfer). For SAP, AWS has specially designed instance types, known as SAP-certified instances, which have been tested and approved by SAP and AWS together to run SAP software properly.
There are two main categories of EC2 instance types for SAP:
memory-optimised instances: These are built for workloads that need massive amounts of fast memory (RAM). SAP databases like SAP HANA are "in-memory databases" which means they keep all data in RAM rather than on a slow disk. So they need huge amounts of memory. Memory-optimised families include the r5, r5a, and x1e types. For example, an r5.24xlarge instance has 768 GB of RAM. You would choose this when your SAP HANA database needs to hold hundreds of gigabytes of data in memory to respond instantly.
compute-optimised instances: These have a higher ratio of CPU to memory. They are for SAP application servers (like SAP S/4HANA apps) that do lots of calculations and number crunching but do not need to store all the data in memory. The c5 family is a common choice for SAP application servers. You use these when you need fast processing power for things like running reports or handling many users.
Storage is where your data lives even when the computer is off. For SAP, you have three main storage services:
Amazon EBS (Elastic Block Store): This is like a virtual hard disk that you plug into your EC2 instance. It is block-level storage, which means the operating system sees it as a regular hard drive. You choose different EBS volume types based on performance: gp3 for general purpose (good balance of cost and speed), io1 or io2 for high-performance databases (very low latency, high IOPS). For SAP HANA, you often need io2 volumes because the database is very sensitive to storage speed.
Amazon FSx for NetApp ONTAP or FSx for Windows File Server: This is a "file storage" service. Instead of a hard drive you plug into one computer, it is like a network drive that many computers can access at the same time. SAP systems often need shared file systems for things like transport directories (where updates to SAP code are stored) or for storing attached documents. FSx gives you that shared storage without managing your own file server.
Amazon S3 (Simple Storage Service): This is object storage. Think of it like a giant limitless warehouse where you dump files (objects). It is cheap but slow to access compared to EBS. You use S3 for backup archives, long-term storage of old logs, or storing large media files that are not accessed frequently. For SAP, a common use is storing database backups after they have been taken, because S3 is very cheap and durable.
Why do these options exist? Before the cloud, companies had to buy physical servers and storage arrays. If they needed more memory, they had to order hardware and wait weeks. In the cloud, you can change instance types in minutes. If you need faster storage, you can switch EBS volumes without physically changing a cable. This flexibility is the whole point of the cloud for SAP.
A key concept is IOPS (Input/Output Operations Per Second). This is a measure of how many reads and writes your storage can handle per second. SAP databases, especially HANA, are very demanding on IOPS. If your storage cannot keep up, the database slows down, and users get frustrated. Memory-optimised instances paired with high-IOPS EBS volumes (like io2) are the solution for high-performance SAP systems.
Another concept is throughput (measured in MB/s). This is how much data can flow per second. For large batch jobs or backups, throughput matters more than IOPS. You balance IOPS and throughput based on your specific SAP workload.
In summary, for the exam you need to memorise a few rules of thumb:
SAP HANA database: always memory-optimised instance, always high-performance EBS (io2 or gp3 with high IOPS), never S3 for live data.
SAP application server (like S/4HANA apps): compute-optimised instance, general-purpose EBS (gp3) usually fine.
Shared file storage for SAP system: FSx for NetApp ONTAP or FSx for Windows.
Backups and archives: S3.
The exam will give you a scenario with requirements like "200 users, high transaction volume, SAP HANA database" and ask you to pick the right EC2 and storage. You must know which instance family has the memory, which storage type gives the IOPS, and which is cheapest for backups.
Identify the SAP workload component
First, determine whether you are sizing for a database (like SAP HANA) or an application server (like SAP S/4HANA apps). This drives the instance type and storage choice.
Choose the EC2 instance family
For a database, pick a memory-optimised family (e.g., r5, x1e). For an application server, pick compute-optimised (e.g., c5) or general-purpose (e.g., m5).
Select the specific EC2 instance size
Within the family, choose the size that gives enough RAM for your database size. For example, an r5.24xlarge provides 768 GB RAM. Cross-check against AWS's SAP-certified instance list.
Choose the primary storage (EBS) for database data
For SAP HANA data and log volumes, select io2 EBS volumes with high IOPS (e.g., 40,000 for data, 10,000 for log). For application servers, gp3 with moderate IOPS is usually sufficient.
Set up shared file storage
Create an Amazon FSx for NetApp ONTAP or FSx for Windows file system to host the SAP transport directory, so all instances can access the same files.
Configure backup storage
Set up automated backups of the database to Amazon S3, using AWS Backup or similar, because S3 is durable and cost-effective for archival data.
Monitor and verify performance
After deployment, monitor the IOPS and throughput metrics in CloudWatch to ensure the instance and storage are performing as expected, adjusting if necessary.
An IT professional tasked with moving an SAP system to AWS has to go through a series of concrete decisions. Let us walk through a realistic scenario for a mid-sized company, GlobalRetail Corp, that uses SAP S/4HANA.
First, the team identifies the SAP system landscape: a production database server, a development server, a quality assurance server, and a backup repository. Each has different needs.
For the production database server running SAP HANA, the team must pick an EC2 instance. They know HANA is in-memory, so they need a memory-optimised instance. They estimate the database size is 1 TB (including overhead). They choose an r5.24xlarge instance with 768 GB of RAM. But they also need to match the specific HANA certified instance list from AWS, because not every memory-optimised instance is SAP-certified for HANA. They cross-check the AWS website for HANA-certified instances and pick one that is listed and matches their budget.
Next, storage. The HANA database needs very fast storage for data and log volumes. They choose two EBS volumes: one for data (say 2 TB of io2 Block Express with 40,000 IOPS) and one for log files (say 1 TB of io2 with 10,000 IOPS). They attach these to the EC2 instance using the AWS console. They also need a shared file system for the SAP transport directory, which all servers (development, QA, production) need to access. They set up Amazon FSx for NetApp ONTAP, create a volume, and mount it on each EC2 instance.
For the development and QA servers, the needs are lighter. They choose compute-optimised c5 instances because those servers are doing more calculation work (running reports, testing code) rather than storing massive datasets in memory. They use gp3 EBS volumes with lower IOPS to save money, because if a dev server is a bit slow, it is tolerable.
Now the exam intersection: the team also needs to consider backup. They configure automated backups of the HANA database to Amazon S3, using a tool like AWS Backup or a script. Why S3? Because it is durable and cheap. They do not need super-fast restore, so S3 works perfectly.
What else does the IT professional do? They set up monitoring in CloudWatch to track IOPS and CPU usage, so they can right-size later. They test the restore process regularly. They also ensure the servers are in a VPC with proper security groups (firewall rules) so only authorised people can access the SAP system.
The key takeaway for someone studying: the real-world work is not just picking services from a menu. It is about matching specific performance requirements (memory size, IOPS, throughput, cost) to specific AWS offerings, and knowing which AWS services are officially SAP-certified. The PAS-C01 exam tests exactly this kind of decision-making.
The PAS-C01 exam tests your knowledge of compute and storage for SAP workloads in two main ways: scenario-based questions and comparison questions. Here is exactly what you need to know.
First, you must be able to pick the right EC2 instance type for a given SAP workload. The exam loves to give you a scenario with a specific SAP product and ask which instance type is appropriate. - SAP HANA database: always memory-optimised. The exam will list instance families like r5, r5a, r6i, x1e, x2idn. You need to remember that memory-optimised families (letters like 'r', 'x', 'z') are for HANA, while compute-optimised families (like 'c5', 'c6i') are for application servers. - SAP application servers (NetWeaver, S/4HANA app layer): compute-optimised or general-purpose. The exam might mention "SAP Business Suite" or "SAP S/4HANA application server" and expect you to pick a c5 or m5 instance.
Second, storage selection is a frequent trap. The exam will present options including EBS (gp3, io1, io2, st1, sc1), FSx, and S3. Here are the patterns:
If the scenario says "database with high transaction rate, low latency needed" -> choose io2 EBS volume (high IOPS).
If the scenario says "shared file system needed for multiple instances" -> choose Amazon FSx (Windows or NetApp ONTAP depending on context).
If the scenario says "backup or archive" -> choose S3.
If the scenario says "cost-effective general-purpose storage" -> choose gp3.
Third, the exam tests the concept of "SAP certified instances." AWS has a list of instances that SAP has approved for running its software. The exam might present an instance that is memory-optimised but not SAP-certified, and the correct answer will be to choose the one on the certified list.
Fourth, the exam tests IOPS and throughput. You may be given a scenario with a certain number of users or transactions per second, and you need to calculate or recommend a storage solution that provides enough IOPS. For example, if a question says "1000 users generating 5000 transactions per second on an SAP HANA database", you need to know that io2 volumes with high IOPS (like 40,000) are needed.
Fifth, the exam sometimes throws in a distractor about using S3 for live database files. This is always wrong. S3 is object storage, not block storage, and cannot be used as a live database volume. The correct choice for live data is EBS (block storage) or FSx (file storage) depending on access pattern.
Sixth, the exam tests the concept of "memory vs compute optimised" for SAP workloads. A common trap question: "Which EC2 instance type is best for SAP HANA when cost is a concern?" The correct answer is still a memory-optimised instance, but they might list a cheap compute-optimised instance as a distractor. Never sacrifice memory for cost with HANA.
Lastly, the exam sometimes asks about EBS volume types for specific SAP components: data volumes (high IOPS needed), log volumes (high throughput needed), and backup volumes (cheap, low performance). Know that io2 is for data and log, while gp3 is acceptable for less demanding workloads.
Memorise:
SAP HANA = memory-optimised + io2 EBS
SAP application servers = compute-optimised + gp3 EBS
Shared files = FSx
Backups = S3
The exam expects you to apply these rules to unfamiliar scenario descriptions without hesitation.
SAP HANA databases require memory-optimised EC2 instances, never compute-optimised ones.
Only SAP-certified EC2 instances are approved for production SAP workloads.
Live SAP database data must use EBS block storage, not S3 object storage.
Amazon FSx provides shared file systems needed for SAP transport directories and central file storage.
EBS io2 volumes provide the high IOPS that SAP HANA databases require for consistent performance.
S3 is the correct storage service for SAP backups and archival data, not for live data.
Compute-optimised EC2 instances (c5, c6i) are ideal for SAP application servers, not databases.
Always match the storage type to the access pattern: block for databases, file for sharing, object for archives.
These come up on the exam all the time. Here's how to tell them apart.
Memory-Optimised Instances (e.g., r5)
Designed for in-memory databases like SAP HANA. High RAM per vCPU.
Typically more expensive per vCPU due to large memory.
Used for database servers, not for application logic.
Compute-Optimised Instances (e.g., c5)
Designed for compute-heavy tasks like application servers.
Lower price per vCPU, but less memory.
Used for SAP S/4HANA application servers, not for HANA databases.
EBS io2 (High Performance)
Very high IOPS (up to 256,000). Suitable for mission-critical databases.
Lower latency for small random reads and writes.
More expensive per GB than gp3.
EBS gp3 (General Purpose)
Moderate baseline IOPS (3,000), can be increased at extra cost.
Good balance of performance and cost for non-database workloads.
Often used for SAP application servers and development systems.
Amazon FSx (File Storage)
Shared file system accessible by multiple EC2 instances simultaneously.
Higher latency than EBS due to network traversal.
Best for shared transport directories, home drives, and centralised files.
Amazon EBS (Block Storage)
Block storage attached to a single EC2 instance for low-latency access.
Supports high IOPS and throughput needed for databases.
Used for live database data and application data on a single server.
S3 (Object Storage)
Store data as objects with a unique key. No hierarchical directory structure.
Higher latency and lower IOPS; not suitable for live database use.
Very cheap and durable; ideal for backups, archives, and static content.
EBS (Block Storage)
Store data as a raw block device that the OS can mount as a drive.
Very low latency and high IOPS for demanding database workloads.
More expensive per GB than S3; used for primary data storage.
Mistake
You can use any EC2 instance for SAP HANA as long as it has enough RAM.
Correct
Only SAP-certified EC2 instances are allowed for production HANA workloads. Not all memory-optimised instances are certified.
AWS and SAP have a formal testing process. People assume if an instance has enough memory, it works, but SAP must confirm compatibility with their specific kernel and patches.
Mistake
S3 is fine for storing live SAP HANA database files because it is durable.
Correct
S3 is object storage with high latency; it cannot support the low-latency reads and writes needed for a live database. You must use EBS block storage for live data.
Beginners see S3's high durability and cheap cost and think 'why not?'. They do not understand the difference between block storage (low latency, mountable as drive) and object storage (high latency, accessible via API).
Mistake
All EBS volume types perform the same; you just choose by size.
Correct
EBS volume types differ significantly in IOPS and throughput. io2 is for high-performance databases, gp3 is general purpose, and st1/sc1 are for throughput or cold data.
New learners think storage is just a hard drive. They do not realise that IOPS and throughput are separate dimensions that critically impact database performance.
Mistake
FSx is only for file storage and cannot be used for SAP database logs.
Correct
FSx is for shared file systems, not for database data or logs. Database logs must be on EBS block volumes attached directly to the database instance for low latency.
The word 'file' in FSx makes people think it can replace EBS for databases. But shared file systems add network overhead and latency, which is unacceptable for database logs.
Mistake
Compute-optimised instances are cheaper, so they should be used for both application and database servers.
Correct
Compute-optimised instances lack the memory capacity for HANA. Using them for the database would severely degrade performance or crash the system. They are only for application servers.
Cost-conscious beginners prioritise price over performance, not realising HANA is entirely memory-dependent. The exam punishes this trade-off.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
No. SAP HANA requires memory-optimised instances (like r5 or x1e) because it runs entirely in memory. General-purpose instances have less memory and are not SAP-certified for HANA.
gp3 is a general-purpose volume with baseline performance you can increase. io2 is a high-performance volume designed for critical databases, with much higher IOPS and lower latency. io2 is recommended for SAP HANA.
S3 is object storage with high latency and does not support low-latency block-level reads/writes that databases need. It is designed for backups, archives, and static files, not for live database operations.
Not necessarily, but most SAP systems need a shared file system for transport directories and central file storage. FSx is the easiest managed service for that shared functionality in AWS.
The instance will not have enough memory to hold the database in RAM, causing severe performance issues, crashes, or inability to start the SAP system. You must always pick a memory-optimised instance.
AWS publishes a list of SAP-certified instances on their documentation pages. The exam expects you to know that memory-optimised families like r5 and x1e are commonly certified, but you should always verify against the current list.
You've finished Compute and Storage Options for SAP Workloads. Continue through the PAS-C01 study guide to build a complete picture of the exam.
Done with this chapter?