Welcome to the engine room of modern enterprise IT! Anyone planning large cloud migrations in major corporations in 2019 cannot ignore one topic: relocating monolithic SAP landscapes to the public cloud. Amazon Web Services (AWS) has established itself as the absolute pioneer here. The old dogma that SAP HANA must strictly run on heavy "Big Iron" in your own data center has finally fallen.
As a Senior SAP Technology Consultant, today I am taking a detailed look at the architectural foundations of SAP on AWS. We will clarify the myths surrounding certified instances, dissect the network design, and show how High Availability (HA) truly functions in the cloud.
The Heart: AWS EC2 Instances for SAP HANA
Not every virtual machine is allowed to host an SAP database. SAP follows the strict TDI concept (Tailored Datacenter Integration), which also applies to cloud providers. AWS extensively certifies its EC2 instance families with SAP to guarantee the required KPI values (CPU throughput, memory latency).
In 2019, architects must fundamentally distinguish between two database types when scaling:
-
Scale-Up (OLTP - S/4HANA & Business Suite): Growth takes place within a single, massive instance.
-
R4/R5 Instances: Perfect for smaller workloads and test systems (Memory-to-vCPU ratio of 8:1, up to 768 GB RAM).
-
X1 and X1e Instances: The absolute workhorses for large S/4HANA systems. The
x1e.32xlargedelivers an incredible 4 TB RAM (equipped with four Intel Xeon E7 8880 v3 processors). -
High Memory Instances (Bare Metal): For the absolute giants. Since late 2018, AWS has offered dedicated hosts with 6 TB, 9 TB, and 12 TB RAM seamlessly integrated into the Virtual Private Cloud (VPC).
-
Scale-Out (OLAP - SAP BW/4HANA): Here, multiple EC2 instances are interconnected to form a cluster. AWS supports scale-out architectures with up to 50 terabytes of total memory (e.g., by bundling several 2 TB or 4 TB instances).
Storage Architecture: IOPS Are the New Gold
A HANA database in RAM is fast, but without performant persistent storage for the Transaction Log (/hana/log), there is a threat of data loss or a massive performance drop during asynchronous writes (savepoints).
In AWS, we use Amazon EBS (Elastic Block Store) for this. The classic 2019 architecture design looks like this:
-
OS and SAP Binaries (
/usr/sap): Cost-efficient SSD volumes of the gp2 (General Purpose SSD) type are sufficient here. -
HANA Data (
/hana/data): Frequently also gp2, as read operations primarily occur in RAM. -
HANA Log (
/hana/log): Sub-millisecond latencies are mandatory here! Architects strictly rely on io1 volumes (Provisioned IOPS), where the I/O operations per second (IOPS) are hard-guaranteed and can be allocated independently of storage capacity.
Network and High Availability (HA) Beyond the Data Center
In a classic data center, High Availability is often solved via Layer 2 networks and floating IPs via Gratuitous ARP. In the AWS Virtual Private Cloud (VPC), broadcast routing on Layer 2 does not work this way. So how do we build a Pacemaker cluster across two data centers?
AWS offers the concept of Availability Zones (AZs) – physically separated data centers connected via highly performant fiber optics within a region (e.g., eu-central-1 in Frankfurt).
The Overlay IP Concept:
We place the primary HANA instance in AZ-A and the secondary instance in AZ-B (HANA System Replication in SYNC mode). The SUSE Linux Enterprise Server (SLES) Pacemaker cluster monitors the nodes.
If Node A fails, Node B takes over. Since Node B resides in a different IP subnet, the cluster resource agent utilizes the AWS API. It dynamically rewrites the VPC routing table so that traffic directed to the database's virtual "Overlay IP" is immediately routed to the EC2 instance in AZ-B. Ideally, the SAP application server (ASCS / DIA) notices almost nothing of this failover at the network level.
🚀 SAP & AWS News Ticker (As of: May 2019)
To keep track of the rapid evolution of cloud technologies, from now on, I will summarize the most important architectural news for you:
-
New Bare-Metal Giants: In April 2019, AWS announced the availability of new Amazon EC2 High Memory instances with 18 TB and 24 TB RAM. A massive milestone for the migration of extremely large, monolithic ERP systems previously trapped on-premise.
-
SAP Cloud Platform (Neo vs. Cloud Foundry): SAP is driving openness forward. More and more services of the SAP Cloud Platform (today BTP) are now directly available in AWS data centers, drastically minimizing the latency between S/4HANA (hosted on EC2) and SAP SaaS services.
-
AWS Transit Gateway: Introduced in late 2018, this feature is becoming the de-facto standard for complex SAP landscapes in 2019. It replaces chaotic VPC peering with a central hub-and-spoke architecture, massively simplifying routing between SAP Dev, QA, and Prod VPCs.
Conclusion
Migrating SAP to AWS is not merely moving virtual machines. It requires a profound rethinking of architectural principles. Anyone who knows the specifications of X1e instances, masters the difference between io1 and gp2 storage, and knows how to span Pacemaker clusters via Overlay IPs across AWS Availability Zones holds the key to the IT of the future. The cloud is definitively enterprise-ready in 2019.