S/4HANA on AWS: Complete Sizing Guide (r8i Instances, Memory & IOPS)

Sizing S/4HANA on AWS — where most projects go wrong

Wrong sizing is the #1 cause of S/4HANA budget overruns. Oversize and you pay for idle compute for 3 years. Undersize and performance tanks during peak month-end runs.

Step 1: Size the HANA database from real data

The only reliable input is your actual production database. For our real customer with a 1.8 TB database, we sized:

• Memory: 1,024 GB HANA (r8i.32xlarge) — HANA requires the working set in memory
• vCPU: 128 cores (r8i.32xlarge) for high concurrency
• Storage: gp3 for data + io2 Block Express for redo logs at the right IOPS

Step 2: Pick the right AWS instance

For S/4HANA, use the r8i family (memory-optimized). A common production sizing:

| Workload | Instance | vCPU | Memory | |

|

|

|

| | Small production | r8i.4xlarge | 16 | 512 GB | | Medium production | r8i.12xlarge | 48 | 768 GB | | Large production | r8i.32xlarge | 128 | 1,024 GB |

Step 3: Plan HA and DR from day one

High availability is not optional for ERP:

• HA: a synchronous HANA replica in a second Availability Zone — if one server fails, no downtime
• DR: an asynchronous copy in a second region for disaster recovery
• Backups: point-in-time EBS snapshots plus S3-based log archiving

Step 4: Validate with rehearsals, not spreadsheets

Sizing models are estimates. The real proof is running the conversion. We rehearsed the migration twice before go-live — measuring exact downtime, exactly as production would behave.

The result in numbers

For a 1.8 TB database:

• r8i.32xlarge production with sync HA replica
• 26 hours total downtime over one weekend
• 0 lost production days
• Within the customer's original 3-year budget allocation

📘 Read the full case study book with architecture diagram

Need sizing help? WhatsApp +91 93197 07938 or contact@krizia.in.