SAP HANA and In-Memory Database Technologies on AWS

Let’s start with what ‘in-memory database’ actually means. In traditional databases (like Oracle or Microsoft SQL Server), data lives on a hard drive or solid-state drive (SSD) — slow storage that can take milliseconds to retrieve a single row. When you run a query, the database engine has to locate the file on disk, read it into memory, process it, and then return the result. This works fine for small datasets, but when a business has billions of rows of sales data, those milliseconds add up to hours. An in-memory database, by contrast, stores all data in the computer’s main memory — RAM (Random Access Memory). RAM is the ultra-fast workspace your computer uses to hold what you are working on right now — open browser tabs, a running video game, or the document you are typing. It is about 100,000 times faster than reading from a hard drive. SAP HANA is designed from the ground up to live entirely in RAM. When you load data into HANA, it compresses and stores it in memory in a column-oriented format — meaning each column of a table (e.g., ‘Sales Amount’) is stored together, not each row (e.g., ‘Order 1: date, customer, amount’). This columnar approach makes it extremely fast for analytical queries (like ‘sum all sales for January’) because only the relevant column needs to be scanned.

Now, where does AWS come into this? SAP HANA cannot run on just any laptop. It needs enormous amounts of RAM — often terabytes — and certified hardware. AWS offers specific EC2 instance families that are certified by SAP to run HANA. The key ones are:

- ‘x1e’ instances: Up to 4 TB of RAM, designed for large production HANA deployments. - ‘x2idn’ and ‘x2iedn’ instances: Newer, faster instances with up to 4 TB of RAM and better networking. - ‘u-6tb1’, ‘u-9tb1’, ‘u-12tb1’ instances: Bare metal servers with 6, 9, or 12 TB of RAM for the largest HANA workloads. They are called ‘bare metal’ because you get the physical server entirely to yourself — no virtualisation layer. You must choose the right instance size during deployment. This is called ‘sizing’. If you pick an instance with too little RAM, HANA will crash. If you pick too much, you waste money. AWS provides a tool called the ‘AWS SAP HANA Sizing Tool’ that takes your on-premises database size (the total amount of data you currently store) and estimates how much RAM you need on AWS (typically 2 to 3 times the compressed data size).

Performance optimisation on AWS involves three major areas: instance choice, storage configuration, and network setup. HANA relies on persistent storage for logs and backups. You attach Amazon Elastic Block Store (EBS) volumes — virtual hard drives in the cloud — to your EC2 instance. For HANA, you must use ‘io1’ or ‘io2’ EBS volumes (provisioned IOPS SSD) because they guarantee a consistent number of I/O operations per second (IOPS). You also use ‘Amazon Elastic File System (EFS)’ for shared file storage if you have a multi-node HANA setup (a scale-out cluster).

Let’s talk about sizing more concretely. Suppose your on-premises SAP HANA database is 3 TB uncompressed. SAP says that HANA compresses data by about 2.5x to 5x, so your working memory footprint might be 600 GB to 1.2 TB. You then add overhead for the operating system, HANA processes, and temporary space — SAP recommends 1.5x the compressed data size. So ‘sizing’ might lead you to pick an x1e.32xlarge instance with 4 TB RAM. On the exam, they will give you a scenario where a company has a 2 TB SAP HANA database running on-premises and ask you to choose the correct EC2 instance. The trap is that you must first estimate the compressed size, not just use the raw 2 TB number.

Another critical concept is ‘HANA memory management’. HANA reserves memory for different purposes: the column store (the actual data), row store (for metadata and small tables), and the redo log buffer (for crash recovery). If the redo log buffer fills up because the EBS volume’s IOPS is too low, HANA pauses and writes data to disk slowly — this is called ‘log flushes pending’ and is a common performance bottleneck. To fix this, you increase the IOPS of the ‘/hana/log’ EBS volume. On the exam, you will see questions where the HANA system is slow and you diagnose the issue by looking at CloudWatch metrics for ‘DiskQueueLength’ or ‘Average Write Latency’ being high. The correct answer is almost always to increase the EBS volume IOPS or switch to a faster instance type.

Imagine you are a cloud architect at a retail company called ‘GlobalMart’. They run SAP S/4HANA on-premises, but the board has mandated moving everything to AWS within six months. The SAP system handles real-time inventory, pricing, and financial reporting. Every Monday morning, the CFO runs a profit-and-loss statement for all 50 countries, which currently takes three hours. The CEO wants it in under five minutes.

You start by assessing the current on-premises HANA server. It has 2 TB of RAM and is 80% utilised. You use the AWS SAP HANA Sizing Tool (a simple web form) to input the current database size (2 TB raw uncompressed). The tool estimates a compressed size of 500 GB and recommends an x1e.32xlarge instance with 4 TB of RAM. Next, you need to choose storage. SAP HANA on AWS requires at least three separate EBS volumes for performance:

- ‘/hana/data’: for the column store data. Needs high IOPS (at least 1 IOPS per GB of data). - ‘/hana/log’: for the redo logs. Needs even higher IOPS (at least 5 IOPS per GB of redo log size). - ‘/hana/shared’: for shared binaries (only needed for scale-out). You choose io2 EBS volumes with 10,000 IOPS for data and 5,000 IOPS for logs. Then you configure the EC2 instance: you select an Amazon Linux AMI (the base operating system) that is SAP-certified, install the HANA database software from an Amazon S3 bucket, and use AWS Systems Manager to run the installation script.

After deployment, you notice the system performs poorly during end-of-month reporting. You check Amazon CloudWatch metrics and see that ‘Average Write Latency’ on the /hana/log volume is consistently above 10 milliseconds, and the HANA alerts log shows ‘Log Flush Pending’. This is a classic exam scenario. You increase the provisioned IOPS on the /hana/log volume from 5,000 to 10,000, and the latency drops to 1 millisecond. The reporting jobs now finish in under two minutes.

You also set up high availability using a ‘HANA System Replication’ (HSR) architecture — a second EC2 instance in a different Availability Zone (AZ) that continuously receives data from the primary. If the primary fails, AWS Route 53 (the DNS service) redirects traffic to the secondary. You use Amazon Elastic Block Store (EBS) snapshots for daily backups, stored in Amazon S3 for long-term retention. Finally, you enable ‘Multitenant Database Containers (MDC)’ — a feature that lets you run multiple separate HANA databases (one for each subsidiary) on a single HANA system, each isolated in its own tenant. This reduces costs because you share the same EC2 instance and EBS storage.