India’s Leading Domain & Web Hosting Provider
Support
Domain & Login
Blog
SAP S/4HANA Infrastructure Built as Code on Certified Cloud Capacity
SAP S/4HANA infrastructure is the compute, storage, network and operating system layer that hosts the HANA database, ASCS/ERS central services, application servers and Web Dispatcher for an S/4HANA landscape. NTSPL builds it as code on SAP-certified AWS, Azure or Google Cloud capacity, validates storage with SAP's measurement tools and hands Basis teams a repeatable platform for every environment.
Delivered on
In scope
What S/4HANA Demands from Cloud Infrastructure That ECC Did Not
S/4HANA puts far more weight on the database tier than ECC ever did. HANA expects sub-millisecond log writes, a predictable /hana/shared filesystem and an operating system tuned with SAP-specific kernel parameters. Teams that reuse a general-purpose VM template usually find the problems on the first mock conversion: log volumes that miss throughput targets, application servers spread across zones adding round-trip latency to every dialog step, and development, quality and production built by hand so no two match.
NTSPL builds S/4HANA infrastructure from a parameterized Terraform or provider-native template per SAP system ID. Instance types come from the certified HANA directory, volumes follow the provider's published HANA storage layout, and SLES for SAP or RHEL for SAP images are hardened and pinned. Before Basis installs anything, HANA hardware and cloud measurement tools are run against the volumes, and results are filed as acceptance evidence for that environment.
When a Purpose-Built S/4HANA Platform Build Is Needed
Signals you need SAP S/4HANA Infrastructure
- An S/4HANA conversion or greenfield implementation needs sandbox, development, quality, pre-production and production built within 8 to 12 weeks.
- Existing cloud HANA VMs were built manually and log-volume write latency exceeds 1 ms during month-end postings.
- Different environments run different OS patch levels or kernel parameters, and transports behave differently in quality and production.
- The landscape must be rebuilt in a second Indian region for DR and nobody can reproduce the original build.
- SAP Basis wants system copies and refreshes on demand but each new VM takes a week of tickets.
When to choose something else
- You are taking RISE with SAP, where SAP provisions and runs the infrastructure; NTSPL's role there is integration and conversion support.
- The landscape is a single small ECC on SQL Server with no HANA plans; a standard VM migration is simpler and cheaper.
- The main open question is HANA scale-up versus scale-out or tenant design; settle that in HANA architecture first.
Components NTSPL Builds for Each S/4HANA System ID
HANA database hosts
Certified memory-optimized instances with /hana/data, /hana/log, /hana/shared and backup volumes sized for throughput, plus OS tuning per SAP notes for the chosen distribution.
Central services and application tier
ASCS and ERS hosts on ENSA2, primary and additional application servers sized in SAPS, and a shared /sapmnt and transport directory on a managed file service.
Web Dispatcher and Fiori entry
SAP Web Dispatcher pair behind an internal load balancer for Fiori launchpad traffic, with TLS certificates managed outside the VM.
Network placement
Dedicated subnets per tier, proximity or placement controls to keep app servers close to HANA, and DNS names that survive host replacement.
Build automation
Terraform modules and configuration playbooks per SID so each environment is created, resized or rebuilt from version-controlled parameters.
Reference Layout: Web Dispatcher to HANA Volumes in One Zone
S/4HANA Single-Zone Reference Layout from Web Dispatcher to HANA Volumes
User and interface traffic enters through Web Dispatcher and the ABAP message server, application servers process work in the same zone as HANA, and HANA writes to separately sized data, log and shared volumes. Shared SAP directories and transports sit on a managed file service so app servers stay stateless.
Select any component
S/4HANA Single-Zone Reference Layout from Web Dispatcher to HANA Volumes: click any of its 8 components to see its role and the design choice NTSPL makes for it, or trace the 7-step primary path.
S/4HANA Build Tooling on AWS, Azure and Google Cloud
Launch Wizard or NTSPL Terraform builds HANA and NetWeaver tiers in Mumbai, with log volumes on io2 Block Express where latency targets demand it and /sapmnt on EFS.
Azure Center for SAP solutions or Terraform deploys the landscape in Central India, with proximity placement groups and Premium SSD v2 or Azure NetApp Files sized per HANA volume.
NTSPL deploys from Terraform in Mumbai, uses Hyperdisk for HANA volumes and runs Workload Manager evaluations to catch OS and configuration drift after build.
Infrastructure Choices That Decide S/4HANA Performance
Block storage versus NFS for HANA
Use provider block storage when HANA is under about 6 TB and snapshots are not the primary backup method. Choose a certified NFS service such as Azure NetApp Files or FSx for NetApp ONTAP when you want application-consistent snapshots for backup and fast system copies, or when the same volumes must be resized frequently. Do not mix both for one database.
Application server count and size
Start with at least two application servers in production, each sized so the other can carry 70 percent of peak dialog load during maintenance. Keep dialog and batch work-process distribution identical across servers unless a batch-heavy month-end justifies a dedicated server. Scale out by adding servers, not by moving to very large instances.
Single zone first, or zonal HA from day one
Place production HANA and app servers in one zone close together if HA is not yet funded, but build ASCS and ERS as separate hosts on ENSA2 and keep IP and DNS abstractions so a second zone can be added later. Retrofitting zonal HA onto a single-host central services design usually needs a rebuild.
OS distribution and subscription model
Standardize on one distribution, either SLES for SAP or RHEL for SAP, across the landscape so Pacemaker, saptune or tuned profiles and patch cycles are uniform. Choose bring-your-own-subscription only if you already hold enterprise agreements; otherwise pay-as-you-go images simplify audits and include the SAP-specific extensions.
From Template to Basis Handover in Six Weeks
SID parameter design
Define instance types, volume sizes, subnets and tags per SID and environment from the readiness sizing sheet.
Landing zone extension for SAP
Create SAP subnets, routing, DNS zones, key vaults or KMS keys and shared file services inside the existing landing zone.
Sandbox and development build
Deploy the first two SIDs from code, apply OS hardening and run storage measurement before Basis installation.
Quality and production build
Promote the same modules with production sizes, run HCMT, and record acceptance evidence for each environment.
Basis handover and runbook
Hand over hosts with build documentation, rebuild instructions and the change process for resizing.
What you receive
Acceptance Thresholds for an S/4HANA Platform
| KPI | Typical target |
|---|---|
| HANA log volume write latency at 4 KB and 16 KB blocks | Within SAP HCMT KPI thresholds on every production host |
| Time to provision a new non-production SID | Under 4 hours from approved request |
| Configuration drift between quality and production | Zero unexplained differences in quarterly comparison |
| App server to HANA network round-trip | Under 0.5 ms within the zone |
Build Mistakes That Surface During Mock Conversions
| Risk | How NTSPL prevents it |
|---|---|
| Log volumes meet capacity but miss throughput, causing slow commits at month-end | Volumes are sized for throughput first and validated with HCMT before installation, with results attached to the acceptance record. |
| App servers land in a different zone from HANA after an autoscaling or rebuild event | Placement constraints and zone pinning are in the Terraform module, and a weekly check flags any SAP VM outside its intended zone. |
| Hand-made fixes on production drift from code | Production changes are made only through pull requests and the pipeline reports drift every week to the platform owner. |
Azure Center for SAP solutions or AWS Launch Wizard versus Terraform for S/4HANA builds?
Provider tools such as Azure Center for SAP solutions and AWS Launch Wizard for SAP are the fastest way to a correct first deployment: they encode the provider's reference layout and can install SAP software too. Their limits appear later, when you need identical rebuilds across regions, custom tagging, or integration with an existing landing zone pipeline. Terraform modules take two to three weeks longer to build but give full control and drift detection. NTSPL's usual answer is to use the provider tool to generate a validated reference, then codify that layout in Terraform for every environment after sandbox.
Key facts: SAP S/4HANA Infrastructure
SAP S/4HANA Infrastructure in Practice
2 SAP S/4HANA Infrastructure scenarios, from Specialty steel and Tiles, plus related platform case studies.
Specialty steel maker builds five S/4HANA tiers from code in 19 days
Ceramic tiles maker fixes slow S/4HANA month-end postings by rebuilding storage tiers
Auto-ancillary maker converts ECC to S/4HANA on AWS inside a 48-hour downtime window
API manufacturer moves a GxP-validated SAP landscape to Azure without re-validation delays
SAP S/4HANA Infrastructure: Frequently Asked Questions
What does an S/4HANA infrastructure build cost?
For a five-tier landscape of one S/4HANA production system with sandbox, development, quality and pre-production, build effort is typically 30 to 50 consultant-days over five to six weeks. Cloud consumption during build is separate and is minimized by building production last and scheduling non-production shutdowns from week one.
Can S/4HANA production run in a single Indian region?
Yes. AWS Mumbai, Azure Central India and Google Cloud Mumbai all have multiple availability zones, so HA can stay within one region. A second region such as Hyderabad, Chennai or Delhi is then used for disaster recovery, keeping data in India for DPDP Act 2023 and sectoral regulator expectations.
Do you install SAP software or only the infrastructure?
Both options exist. NTSPL can hand over hosts at OS level to your Basis team or an SAP partner, or install HANA, ASCS, ERS and application servers with Software Provisioning Manager. The handover point is fixed in the RACI before work starts so acceptance criteria are clear.
How do you size application servers for S/4HANA?
We start from SAPS derived from current workload data in the readiness assessment and add headroom for S/4HANA's different load profile, especially for Fiori traffic. Production gets at least two servers so one can be patched while the other carries load.
Which operating system should we choose?
SLES for SAP and RHEL for SAP are both supported on all three clouds. Choose based on existing skills and support contracts. Standardizing one distribution matters more than which one, because cluster agents, tuning tools and patch processes differ between them.
How are system refreshes handled on this platform?
Refreshes use HANA backup and restore or storage snapshots onto hosts built from the same Terraform module. Because the target host is code, a quality refresh no longer waits on infrastructure tickets; Basis runs post-copy steps and the system is back in a day.