AWS SAP SAP HANA EC2 migration

SAP HANA on EC2: services won't come up after cutover to AWS

Fix SAP HANA startup on EC2 after migrating to AWS: diagnose hdbnsutil services, IOPS/throughput throttling on the data and log volumes, choosing a certified instance class, and memory sizing.

Jerzy Kopaczewski · 2026-09-12

The SAP migration to AWS got through the data-copy stage, the EC2 instance came up, but HANA won't bring its services online - `sapcontrol` shows processes in GRAY/YELLOW, the indexserver won't start, or the database starts and then falls over on disk throttling. The SAP application is down and the cutover window is shrinking. This runbook shows how to diagnose and fix the HANA startup on EC2 after a migration.

This runbook covers troubleshooting the SAP HANA startup on EC2 after migrating to AWS. For the full guide to the migration itself, see SAP to AWS Migration Guide. For SAP-on-AWS architecture and cutover planning, book a consulting session.

Symptoms

The EC2 instance is running, but HANA doesn’t reach the “all services green” state. Typical signals:

# HANA process status (as <sid>adm)
sapcontrol -nr 00 -function GetProcessList
# Typical:
#   hdbnameserver   GREEN
#   hdbindexserver  GRAY/YELLOW  <- won't start or restarts in a loop
#   hdbcompileserver, hdbpreprocessor ...

# Database startup log (the key lines)
tail -n 80 /usr/sap/<SID>/HDB00/<hostname>/trace/nameserver_*.trc
tail -n 80 /usr/sap/<SID>/HDB00/<hostname>/trace/indexserver_*.trc

# Typical messages:
# "topology mismatch" / "hostname ... not found in landscape"     -> hdbnsutil
# "insufficient memory" / "global allocation limit"               -> memory sizing
# "disk full" / "log volume ... write error"                      -> volumes/IOPS
# "I/O ... throttled" / long fsync in perftop                     -> EBS throughput

HANA processes don’t reach GREEN, the indexserver won’t start or restarts in a loop, or the database starts and falls over under I/O load.

Cause

A failed HANA startup on EC2 after migration usually has one of four causes:

Topology/hostname mismatch (hdbnsutil): after moving to a new host, HANA still holds the old hostname/landscape in its configuration. The nameserver starts, but the indexserver can’t map the topology - typical right after a rehost or a restore from backup onto a different machine.
IOPS/throughput throttling on the data and log volumes: gp3 volumes with the default 3000 IOPS / 125 MB/s aren’t enough for production HANA. The log volume starves on throughput, fsync stretches out, and the database falls over or runs extremely slowly. A common mistake in a “1:1” migration without tuning EBS.
Uncertified or poorly chosen instance class: HANA is only supported on certified types (memory-heavy families, e.g. r5/r6i/x2/High Memory). Running on an uncertified or memory-undersized instance ends in a memory allocation error or a refusal to start during the support check.
Wrong memory sizing relative to the instance: the global_allocation_limit parameter or the actual database size exceeds the instance memory chosen “by eye”. HANA keeps data in RAM - too small an instance means insufficient memory when loading columns.

Fix

A) Determine whether it’s topology, memory, or I/O:

# Quick triage from the startup logs - which class of problem
grep -Ei 'topology|landscape|hostname' /usr/sap/<SID>/HDB00/*/trace/nameserver_*.trc | tail
grep -Ei 'insufficient memory|allocation limit'   /usr/sap/<SID>/HDB00/*/trace/indexserver_*.trc | tail
grep -Ei 'disk full|write error|I/O|throttl'       /usr/sap/<SID>/HDB00/*/trace/*.trc | tail

# Instance memory vs HANA expectations
free -g
cat /usr/sap/<SID>/SYS/global/hdb/custom/config/global.ini | grep -A2 memorymanager

B) Topology mismatch - remap the hostname (hdbnsutil):

# As <sid>adm - stop HANA, update the topology to the new host
HDB stop
hdbnsutil -convertTopology                 # when the host changed after migration/restore
# or explicitly rename the host in the landscape:
hdbnsutil -renameSystem \
  --source=<OLD_HOST>:<SID>:00 \
  --target=<NEW_HOST>:<SID>:00
HDB start
sapcontrol -nr 00 -function GetProcessList  # the indexserver should reach GREEN

C) I/O throttling - tune the EBS data and log volumes:

# Raise IOPS and throughput on the log volume (gp3) - the log is the most sensitive
aws ec2 modify-volume \
  --volume-id vol-log0123456789 \
  --iops 16000 \
  --throughput 1000        # MB/s

# Data volume - IOPS/throughput by database size (for large databases consider io2 Block Express)
aws ec2 modify-volume --volume-id vol-data0123456789 --iops 20000 --throughput 1000

# Verify at the OS level that the filesystem sees the new performance (XFS recommended for HANA)
iostat -xm 5 3
# Check that /hana/log and /hana/data are on separate volumes - sharing them is a common mistake.

D) Instance class and memory sizing - choose a certified type:

# Change the type to one certified for HANA (example: r6i.4xlarge; for large DBs x2idn/High Memory)
aws ec2 stop-instances  --instance-ids i-0hana...
aws ec2 modify-instance-attribute --instance-id i-0hana... --instance-type r6i.4xlarge
aws ec2 start-instances --instance-ids i-0hana...

# Align global_allocation_limit with the instance memory (as <sid>adm), e.g. ~90% of RAM:
hdbparam --paramset memorymanager.global_allocation_limit=<MB>
# Rule: the instance must have RAM >= in-memory data size + buffers + operating system.
# Verify type certification in the SAP Note / AWS before changing - an uncertified type is not supported.

Prevention: size the instance and volumes at the planning stage based on the real HANA sizing (HANA sizing report / in-memory data), not “1:1” from on-prem. Separate /hana/data and /hana/log onto distinct volumes with headroom on IOPS/throughput. Run a trial start and load test a few days before cutover - topology and throttling errors are easier to fix without the pressure of the window. Use only HANA-certified instance types.

Validation

# 1. All HANA processes in GREEN
sapcontrol -nr 00 -function GetProcessList
# Expected: hdbnameserver, hdbindexserver, hdbcompileserver, hdbpreprocessor = GREEN

# 2. The database accepts connections and answers a control query
hdbsql -n localhost:30015 -u SYSTEM -p '<password>' \
  "SELECT SERVICE_NAME, ACTIVE_STATUS FROM SYS.M_SERVICES"
# Expected: all services ACTIVE = 'YES'

# 3. No I/O throttling under load (log and data)
iostat -xm 5 3
# Expected: log volume %util does not sit at 100%, await low and stable

# 4. Memory allocation fits within the limit, no "insufficient memory" in the trace
hdbsql -n localhost:30015 -u SYSTEM -p '<password>' \
  "SELECT HOST, ROUND(USED_PHYSICAL_MEMORY/1024/1024/1024) AS used_gb, ROUND(ALLOCATION_LIMIT/1024/1024/1024) AS limit_gb FROM SYS.M_HOST_RESOURCE_UTILIZATION"
# Expected: used_gb < limit_gb with headroom

If all HANA processes are GREEN, the database accepts connections, there’s no I/O throttling under load, and memory fits within the limit, the system is ready to switch over the SAP application layer. Run a load test representative of production before the actual cutover.

HANA that won't start after migration halts the entire SAP landscape - the application layer has nothing to connect to, and on a minimal-downtime migration that's a direct risk of slipping the deadline. The more dangerous scenario is a database that starts on undersized volumes and only falls over under production load - after cutover, once the on-prem system is switched off. That's why instance and EBS sizing and the load test are done before switchover, not after.

SAP HANA won't start after migrating to EC2?

Book a free 30-minute call. We'll review your HANA topology, instance sizing and volume configuration, and get the SAP migration to a clean cutover.

Book a call