India’s Leading Domain & Web Hosting Provider
Support
Domain & Login
Blog
SAP S/4HANA on AWS: Migration, HANA High Availability and DR
SAP on AWS is running SAP ECC, S/4HANA, BW/4HANA and related systems on SAP-certified Amazon EC2 instances and EBS storage that you control, rather than in your own data centre. NTSPL migrates and operates these landscapes for Indian manufacturers and exporters, building Pacemaker-based HANA high availability across Mumbai Availability Zones and tested disaster recovery to Hyderabad.
AWS services in scope
The Problem SAP-certified Amazon EC2 memory-optimized instances and Amazon EBS io2 Block Express and gp3 Solve
Indian SAP customers face a hard calendar. SAP ECC 6.0 mainstream maintenance ends in 2027, with optional extended maintenance to the end of 2030, and many on-premises landscapes run on Oracle or DB2 on servers that are themselves five to seven years old. A HANA appliance refresh means committing crores to hardware sized for a peak the business may never reach, plus a DR site that is rarely tested. Meanwhile month-end closing, MRP runs and GST e-invoicing loads keep growing, and Basis teams spend weekends on hardware rather than on the S/4HANA programme.
NTSPL separates the infrastructure move from the functional transformation where it reduces risk. We size HANA from actual memory usage and growth, not appliance catalogues, use Launch Wizard for SAP to build consistent, SAP-supported deployments, and design HA and DR before the first production cutover. Brownfield conversions use SUM DMO with system move to combine the AWS migration and S/4HANA conversion in one downtime window. Every go-live is preceded by a HANA takeover test and a Hyderabad DR drill.
When to Run SAP on AWS Infrastructure You Control (and When RISE or Staying Put Fits Better)
Signals that point to sap on aws on AWS
- Your HANA appliance or Oracle database servers reach end of support within 18 months and refresh quotes exceed INR 2 crore.
- You plan an ECC to S/4HANA conversion before 2027 to 2030 maintenance deadlines and want to avoid buying hardware for a transient landscape.
- Month-end or MRP runs take more than 6 hours and are bound by hardware you cannot scale.
- Your SAP DR site has not completed a full failover test in the last 12 months.
- Non-production SAP systems run 24x7 on owned hardware but are used only during working hours.
- Acquisitions left you with multiple SAP landscapes hosted by different providers under different contracts.
When a different approach is better
- If you want SAP to be the single contracting party for software, infrastructure and basic technical operations, RISE with SAP may suit better, accepting less control over instance sizing, maintenance windows and DR design; NTSPL can still help with integration and surrounding AWS services.
- If your SAP system is small, stable and on recently purchased hardware with ECC support through 2030, moving now may not pay back; plan the move with the S/4HANA programme instead.
- If plant-floor systems need sub-10 ms deterministic interaction with SAP from remote sites without reliable connectivity, keep that integration local with SAP Digital Manufacturing edge components or a plant-level MES, and connect to SAP on AWS asynchronously.
SAP Platform Building Blocks: Certified EC2 Memory Instances, EBS io2 and gp3, Launch Wizard and Backint
| Service | Role in the architecture | Choose it when |
|---|---|---|
| SAP-certified Amazon EC2 memory-optimized instances | Run SAP HANA on certified families such as R7i and R6i for smaller databases, X2idn and X2iedn for up to about 4 TB, and U7i High Memory instances for multi-terabyte scale-up HANA, with application servers on general-purpose or compute instances. | You need HANA memory sized to real usage with the ability to resize in hours rather than buy a larger appliance. |
| Amazon EBS io2 Block Express and gp3 | Provide HANA data and log volumes: gp3 striped across volumes to meet SAP's storage KPIs for most systems, and io2 Block Express where sub-millisecond latency and very high IOPS per volume are needed. | HANA savepoints, log writes or startup load times are bottlenecked by storage, or you need predictable performance independent of volume size. |
| AWS Launch Wizard for SAP | Deploys SAP HANA, NetWeaver and S/4HANA systems, including Pacemaker high-availability configurations across Availability Zones, following AWS and SAP best practices from a guided or template-driven input. | You want repeatable builds for sandbox, QA and production instead of hand-built servers that drift from each other. |
| AWS Backint Agent for SAP HANA and AWS Backup | The SAP-certified Backint agent streams HANA data and log backups directly to Amazon S3, while AWS Backup can orchestrate HANA backups registered through AWS Systems Manager for SAP. | You want to retire backup servers and tape for HANA, and keep backups in S3 with lifecycle and cross-Region copy. |
| Pacemaker clustering with SAP HANA System Replication | SUSE Linux Enterprise Server for SAP or Red Hat Enterprise Linux for SAP with HA clusters manage HSR takeover and ASCS/ERS failover across Availability Zones, using an overlay IP moved via route table update. | Production SAP needs automatic recovery from an instance or Availability Zone failure within minutes. |
| AWS Elastic Disaster Recovery | Replicates SAP application servers, ASCS hosts and interface servers to Hyderabad for fast recovery, complementing HANA System Replication for the database. | You need cross-Region DR for the non-database SAP tier without maintaining running standby application servers. |
Multi-AZ SAP S/4HANA with Pacemaker HSR in Mumbai and async DR to Hyderabad
Multi-AZ SAP S/4HANA with Pacemaker HSR in Mumbai and async DR to Hyderabad
Users and interfaces reach SAP through Direct Connect or VPN, then SAP Web Dispatcher and application servers in two Mumbai Availability Zones, with ASCS/ERS and the HANA primary and secondary clustered by Pacemaker. HANA System Replication runs synchronously between AZs and asynchronously to a Hyderabad secondary, while Backint streams backups to S3 and Elastic Disaster Recovery replicates application hosts.
Select any component
Multi-AZ SAP S/4HANA with Pacemaker HSR in Mumbai and async DR to Hyderabad: click any of its 9 components to see its role and the design choice NTSPL makes for it, or trace the 7-step primary path.
SAP Engineering Decisions: HANA Instance Sizing, Storage Layout, HA Topology and Cross-Region DR
HANA sizing from real memory, not appliance T-shirts
We size HANA from the current database's actual used memory, or from SAP sizing reports for conversions, plus 18 to 24 months of growth and data aging. An ECC on Oracle at 4 TB on disk often lands at 1 to 1.5 TB in HANA after compression and archiving. Choose the smallest certified instance that fits with headroom; on AWS you can resize to a larger certified instance in a planned window, so overbuying memory for year five is unnecessary.
Storage layout and volume type
For most HANA systems up to a few terabytes, striped gp3 volumes meet SAP's storage KPIs, since gp3 IOPS and throughput are provisioned independently of size. Use io2 Block Express for log volumes or very large, write-intensive systems where latency consistency matters. Separate data, log, shared and backup volumes; never put HANA log on the same volume as data. Validate with SAP's HANA hardware and cloud measurement tools before go-live.
HA topology inside Mumbai
Production runs HANA primary and secondary in two Availability Zones with HSR in SYNC or SYNCMEM mode; inter-AZ latency in Mumbai is low enough for synchronous replication. Pacemaker with fencing through the EC2 API avoids split-brain, and an overlay IP outside the VPC CIDR gives clients a stable address across AZs. ASCS/ERS uses ENSA2 in its own cluster. A single-AZ deployment with auto-recovery is acceptable for QA, not production.
Cross-Region DR to Hyderabad
For the database, HSR in ASYNC mode to Hyderabad typically achieves an RPO of seconds to a few minutes; Elastic Disaster Recovery covers application servers and interface hosts. Check that your chosen certified instance types are offered in ap-south-2 before committing the design, and reserve capacity for large memory instances if DR depends on them. Three-tier HSR, Mumbai AZ-a to AZ-b to Hyderabad, or multi-target replication are both valid; we pick based on HANA version and operational familiarity.
Customer-managed SAP on AWS or RISE with SAP
RISE bundles S/4HANA subscription, infrastructure and technical operations under an SAP contract, which simplifies procurement but limits your control over sizing, maintenance windows, DR topology and adjacent AWS integrations. Customer-managed SAP on AWS keeps existing licences, lets you resize and schedule freely, and integrates directly with your data lake and security tooling. Organizations with a capable Basis team or partner and significant AWS usage usually favour customer-managed; those wanting one SAP contract favour RISE.
How NTSPL Moves an SAP Landscape to AWS and Proves HA and DR
Landscape and sizing baseline
Capture SIDs, database sizes, memory usage, SAPS, interfaces and batch peaks from EarlyWatch reports and OS metrics, and run SAP sizing for S/4HANA conversions.
Landing zone and SAP network
Build SAP accounts, VPCs per environment, Direct Connect and Transit Gateway, and security groups per tier, with Hyderabad networking pre-built for DR.
Launch Wizard builds and storage validation
Deploy sandbox and QA with Launch Wizard for SAP, then run SAP storage KPI checks and HANA startup timing before building production.
Migration rehearsals
Run at least two mock migrations with SUM DMO with system move or HANA backup and restore, measuring downtime against the agreed cutover window.
HA takeover and DR drill
Test Pacemaker takeover by stopping the primary instance, fail ASCS over, then run a Hyderabad DR drill with HSR takeover and Elastic Disaster Recovery launches.
Production cutover and hypercare
Execute cutover in the agreed window, run four weeks of hypercare with daily HSR, backup and performance checks, and hand over runbooks to the Basis team.
What you receive
Hardening SAP on AWS: Network Segmentation, HANA Encryption, Privileged Basis Access and Backup Isolation
SAP holds finance, payroll, pricing and supplier data, and Basis accounts with OS and HANA SYSTEM privileges are the crown jewels. Threats include over-broad network access to HANA ports from user subnets, unencrypted backups on shared storage, and Pacemaker cluster roles with excessive EC2 permissions. We segment SAP tiers tightly, encrypt HANA at the volume and backup level, scope cluster IAM roles to the specific instances and route tables they manage, and isolate backups from Basis administrators.
- Security groups allowing HANA SQL ports only from application servers and named admin hosts per SID
- KMS encryption for EBS volumes plus HANA native data and log volume encryption
- Pacemaker IAM role limited to stop, start and describe on cluster instances and the specific route table
- Session Manager for OS access by Basis, replacing shared root SSH keys
- Backint target bucket with Object Lock and a KMS key outside Basis administrator control
SAP on AWS Pricing: Memory Instance Commitments, Non-Production Scheduling, EBS Choices and Backup Storage
SAP on AWS cost is dominated by memory-optimized EC2 hours for HANA, then application server hours, EBS volumes and S3 backup storage. SAP licences are brought as-is in customer-managed deployments. Production HANA runs 24x7, so commitment pricing matters most; non-production runs only when needed. Cross-Region DR adds standby instance hours and inter-Region transfer for HSR and backup copies.
- 3-year EC2 Instance Savings Plans or Reserved Instances for production HANA and central services
- Stop sandbox, development and QA systems nights and weekends with Systems Manager schedules, often 50 to 65 percent fewer hours
- gp3 instead of io2 wherever storage KPIs are met, sized by throughput rather than capacity
- Smaller HANA DR secondary with preload disabled, resized only on takeover
- HANA data aging and archiving before migration to reduce memory and instance size
RISE with SAP vs customer-managed SAP on AWS vs on-premises HANA refresh: which is right?
Compare control, contract model and five-year cost. RISE with SAP gives one SAP subscription covering software, hyperscaler infrastructure and technical operations; it suits firms wanting fewer vendors, but limits choice of instance sizes, maintenance windows, DR design and direct AWS integration. Customer-managed SAP on AWS retains your existing licences, gives full control of sizing, HA and DR, and lets SAP data feed your AWS data lake and AI services directly; it requires a strong Basis team or partner. An on-premises HANA refresh suits firms with recent data-centre investment and stable workloads, but buys peak capacity upfront and leaves DR testing on you. For most Indian mid-size manufacturers with an AWS footprint, NTSPL finds customer-managed SAP on AWS the best balance of control and cost.
Key facts about sap on aws on AWS
SAP on AWS on AWS in Practice
3 sap on aws scenarios from Automotive components, Textiles and apparel export, Cement manufacturing: the starting position, the services chosen, the architecture, the rollout and the measured outcome.
Auto-ancillary maker converts ECC to S/4HANA on AWS inside a 48-hour downtime window
Textile exporter consolidates three SAP landscapes from three hosts onto one AWS platform
Cement manufacturer adds HANA high availability and Hyderabad DR to S/4HANA on AWS
SAP on AWS on AWS: Frequently Asked Questions
What does running SAP S/4HANA on AWS cost per month?
For a mid-size landscape with a 1 to 1.5 TB production HANA, Pacemaker HA, three non-production systems and Hyderabad DR, infrastructure typically lands between INR 12 and 25 lakh per month with three-year commitments on production and scheduled non-production. SAP licences are separate and unchanged. Our sizing workshop produces a five-year model comparing this with an appliance refresh.
Should we move ECC to AWS first or convert to S/4HANA during the move?
It depends on your timeline and change appetite. If hardware is ending support soon, move ECC first, often onto HANA with a database migration, then convert to S/4HANA on AWS. If the S/4HANA programme is already funded, SUM DMO with system move combines the database migration, AWS move and conversion in one downtime window, avoiding two cutovers.
Can SAP on AWS meet Indian data residency and GST e-invoicing needs?
Yes. Production runs in ap-south-1 and DR in ap-south-2, so SAP data, backups and replicas remain in India. GST e-invoicing and e-way bill integrations call government IRP and GSP endpoints from AWS like from any data centre, usually through a NAT gateway with fixed Elastic IPs that you allowlist with your GSP.
How long does an SAP HANA failover take on AWS?
Within Mumbai, a Pacemaker-managed HSR takeover between Availability Zones typically completes in a few minutes, depending on database size and whether column tables are preloaded on the secondary. A cross-Region DR takeover to Hyderabad, including application servers, is usually measured in tens of minutes to a couple of hours, and we establish the actual figure in a drill.
Is SAP supported on AWS for production?
Yes. SAP certifies specific Amazon EC2 instance types for SAP HANA and SAP NetWeaver, listed in SAP's Certified and Supported SAP HANA Hardware Directory and related SAP Notes. Support requires certified instances, supported operating systems and the AWS data provider for SAP installed so SAP support can see infrastructure metrics.
How are SAP HANA backups handled on AWS?
Through the AWS Backint Agent, which is SAP-certified and streams HANA data and log backups directly to Amazon S3, with no backup servers or tape. Backups can also be orchestrated with AWS Backup via Systems Manager for SAP. We add S3 Object Lock, lifecycle rules and cross-Region replication to Hyderabad for ransomware resilience.