Why SAP S/4HANA Landscape Design Impacts Cloud TCO More Than Compute Costs

Introduction: Beyond Compute Prices

When migrating or running SAP S/4HANA on AWS, many organizations fixate on EC2 instance prices and assume that choosing the cheapest instance types will yield the biggest savings. In reality, cloud TCO is heavily impacted by landscape design choices, how many environments you run, how they’re sized, how data is managed and what auxiliary services you use. Cutting cloud costs isn’t just about shrinking VM sizes it’s about architecting an efficient SAP landscape. As one SAP FinOps guide notes, focusing only on instance sizing addresses symptoms, not causes. True cost optimization asks Is the SAP landscape design efficient? Are you running unnecessary SAP instances, and can workloads consolidate onto fewer systems?. In other words, a thoughtful landscape architecture often yields larger savings than a simple per-server cost reduction.

Understanding an SAP S/4HANA Landscape on AWS

A typical S/4HANA landscape consists of multiple tiers and environments. You might have separate DEV, QA, Staging and Production systems each a full SAP stack with its own HANA database and application servers. On AWS, that could translate to dozens of EC2 instances, along with associated storage and network infrastructure. Each additional environment or system copy multiplies costs for compute, Amazon EBS storage, Amazon EFS shared file systems, backup retention, and so on. Landscape design decisions such as how many parallel systems to run or whether every environment needs high availability can quickly outweigh the cost of an individual EC2 instance.

Right-Sizing Compute Resources

Right-sizing is the practice of matching instance types and sizes to actual workload needs. SAP S/4HANA is resource-intensive, so it’s critical to choose the appropriate EC2 instance families and sizes for each component. AWS offers SAP-certified instance families. Avoid the temptation to oversize just in case use monitoring tools like AWS CloudWatch and SAP’s EarlyWatch reports to gauge real utilization. If a QA system never exceeds 30% CPU and 50% memory, you might run it on a half-sized instance compared to production. Many companies set policies such as development instances must not exceed 50% of production capacity and QA 70%. This ensures non-production systems are proportionally smaller and cheaper.

In Terraform, you can parameterize instance sizes by environment to enforce right-sizing. A production vs. dev HANA server might be expressed as:

# Example Terraform: Use smaller instance type for non-production
variable "env" { default = "prod" }

resource "aws_instance" "sap_hana" {
  ami           = "ami-0abcdef12345..."          # SAP HANA Linux AMI
  instance_type = var.env == "prod" ? "r6i.8xlarge" : "r6i.2xlarge"
  # ... (other configuration like VPC, subnet, security groups)
  tags = {
    Name        = "${var.env}-hana"
    Environment = var.env
  }
}

In this snippet, a development environment could be launched with -var env=dev to automatically use a smaller instance, whereas production uses r6i.8xlarge. Right-sizing combined with flexible IaC lets you avoid paying for capacity you don’t need while still meeting SAP performance requirements.

Beyond instance selection, leverage cost-saving options for compute:

• Savings Plans or Reserved Instances: If your SAP workloads run 24/7 in prod, commit to a one- or three-year Savings Plan to get discounts up to 72%.
• Auto-stop Non-Prod Instances: Schedule stops for dev, QA, training servers during off-hours. AWS Systems Manager Automation or AWS Instance Scheduler can start/stop instances on a cron schedule. By only running non-prod when needed, you save significantly on compute.
• Auto Scaling for SAP App Servers: SAP application servers can often scale horizontally. In AWS, you might use an Auto Scaling Group with a schedule or target utilization policy for app servers. This way, you run minimal servers during light load and scale out for peak times.

Consolidation and Landscape Efficiency

An inefficient SAP landscape one with too many duplicate systems or low-utilization servers will rack up cloud costs regardless of instance pricing. Cloud gives us flexibility to consolidate and optimize:

• Eliminate Unnecessary Systems: Audit your SAP instances are there old project systems or unused sandboxes running? It’s not uncommon to find forgotten test systems left on. Retire or shut down what isn’t truly needed.
• Consolidate Workloads: Where possible, consolidate multiple workloads on a single instance or platform. If you have separate SAP S/4HANA instances for different business units that are lightly used, consider consolidating them into one S/4HANA tenant or system. Fewer HANA databases means fewer high-memory instances to pay for. SAP HANA supports multi-tenant databases, so multiple schemas can reside in one HANA system this can be a way to run dev and QA on one HANA VM as separate tenants, rather than two separate VMs.
• Shared Services: Some landscape components can be shared across environments. For instance, a single SAP Solution Manager or central SAProuter can serve the entire landscape rather than one per environment. Fewer supporting servers equals lower cost.
• Right-Size Every Environment: Even within a consolidated landscape, differentiate the sizing. We mentioned limiting dev/QA to a fraction of prod. Also consider if every environment needs the same number of app servers maybe prod has 4 app nodes for high throughput but QA can do with 2 and dev with 1. This scaling down translates directly to cost savings in EC2 hours and licenses.

Keep in mind that consolidation should not compromise testing realism or performance SLAs for production. It’s a balance consolidate and downsize where you safely can and use cloud tooling to isolate or simulate full scale only when necessary.

Storage and Data Management Costs

For SAP workloads, storage costs are often as significant as compute. A single S/4HANA instance may have terabytes of data on EBS volumes. Now multiply that by multiple environments, plus backups storage can eclipse compute costs if not managed. AWS provides multiple storage options using the right one for the right purpose is key:

• Use EBS Efficiently: Provision EBS volumes that meet performance needs without over-provisioning IOPS or size. AWS now recommends gp3 SSD volumes for SAP HANA over older gp2, as gp3 offers better price/performance. Only use expensive io2 volumes if you truly need ultra-high IOPS and durability for critical workloads, otherwise gp3 suffices in most cases. Always enable the delete on termination flag for temporary volumes and clean up unattached EBS volumes so you’re not paying for leftover storage.
• Offload Backups to S3: Don’t keep backup files on EBS or EFS longer than necessary. AWS offers the Backint agent for SAP HANA which lets HANA back up directly to Amazon S3. This bypasses the need for large intermediate disk space and leverages cheaper object storage. S3 is significantly cheaper per GB than EBS for data at rest. Design a backup strategy for each environment and send those to an S3 bucket. From there, apply lifecycle policies to move older backups to colder storage classes like Glacier for further savings. For example, you might keep 7 days of recent backups in S3 Standard, then transition older ones to S3 Glacier or Deep Archive after 30 days.
• Plain Text

   

  # Example Terraform: S3 bucket for SAP HANA backups with lifecycle policy
  resource "aws_s3_bucket" "sap_hana_backup" {
    bucket        = "my-sap-hana-backups"
    force_destroy = true  # allow auto-cleanup if destroying infra
    versioning {
      enabled = false  # disable versioning for backup objects to save space
    }
    lifecycle_rule {
      id      = "MoveOldBackupsToGlacier"
      enabled = true
      transition {
        days          = 7
        storage_class = "GLACIER"        # move backups to Glacier after 7 days
      }
      expiration {
        days = 180                      # delete backups after 6 months
      }
    }
    tags = {
      Purpose = "SAP HANA Backups"
    }
  }

  
  

Terraform snippet: The above S3 bucket is configured to automatically transition objects older than 7 days to Glacier and delete anything older than 180 days. This kind of policy ensures your S3 storage costs stay low by archiving cold data. In practice, set the timing according to your retention requirements. Also consider enabling MFA Delete or Vault Lock on critical backup buckets for safety, instead of versioning.

• Use EFS for Shared Files, but Lifecycle Manage It: SAP applications often use shared file systems for transports (/usr/sap/trans), global SAP mounts (/sapmnt), and archives. Amazon EFS is ideal for this shared storage it’s managed NFS and can be mounted by multiple EC2 instances. However, treat EFS space as premium (especially the default Standard storage class). Enable EFS Lifecycle Management (Intelligent-Tiering) so that files not accessed for 30 days move to the lower-cost Infrequent Access tier automatically. For example, old transport files or archived data can sit in EFS IA at a much lower cost per GB. Also, clean up EFS after major projects. Deleting those or moving them to S3 after the project frees up costly EFS space.

  Plain Text

   

  # Example Terraform: EFS file system with lifecycle policy for infrequent access
  resource "aws_efs_file_system" "sap_shared_fs" {
    creation_token   = "sap-shared-fs"
    performance_mode = "generalPurpose"
    throughput_mode  = "bursting"
    lifecycle_policy {
      transition_to_ia = "AFTER_30_DAYS"  # move files to Infrequent Access after 30 days
    }
    tags = {
      Name = "sap-shared"
    }
  }

  
  

The above EFS definition will automatically tier off files not touched for 30 days. Mount this EFS on your SAP application EC2s to use for common directories. This way, you get the convenience of shared storage without continuously paying full price for cold data. Always review and delete any unattached or unused EFS file systems as well.

• Archive and Purge Data: A broader data strategy can greatly reduce TCO. If your S/4HANA database is bloated with years of transactional data, consider using SAP data archiving to move old data to cheaper storage. Storing infrequently accessed data in S3 is far cheaper than keeping it in memory on HANA. Also, use Amazon S3 for storing large interface files or logs rather than keeping them on EBS/EFS, and enable lifecycle policies for those as well. Every GB you offload from expensive storage to S3/Glacier or delete entirely is money saved.

Network and Infrastructure Considerations

Often overlooked in cost planning are networking and auxiliary infrastructure costs:

• Networking: Within a VPC, data transfer is free between instances in the same AZ, but costs can incur across AZs or out to the internet. If your SAP landscape replicates data, you’ll pay for cross-AZ data transfer. This is usually worth the HA benefit, but be aware. More straightforwardly, NAT Gateway costs catch people by surprise if each environment VPC has its own NAT and heavy internet egress, costs add up. Mitigation: use VPC endpoints for S3 and other services so traffic stays internal and avoids NAT usage.
• Backups and DR Infrastructure: If you maintain a warm standby environment or Disaster Recovery site, treat it as another environment in your cost planning. To save costs, you can keep DR systems mostly powered off, or use lower-performance instance types there, and only scale up if a failover is needed. AWS Backup can help here by storing snapshots that you can restore in a DR region on demand. Using lower-tier storage in the DR region for backups is a cost-effective strategy.
• AWS Managed Services: Consider using services like AWS Backup to automate backup retention policies across your SAP instances. This can ensure snapshots or EBS backups follow a schedule and transition to cold storage after a set time, reducing manual oversight and accidental cost bloat. Also leverage tagging and AWS Cost Explorer to allocate and track costs by environment or system this transparency can help identify which landscape components are most expensive and need optimization.

Environment Strategy and Automation

Your environment strategy should align with actual business usage patterns. Not every SAP environment needs to run 24/7 at full scale:

• For development, testing, training, use on-demand principles. If developers work 8am-6pm, there’s no reason to run dev systems all night. By shutting down servers during off hours, companies save 50-65% on those environments’ costs without any impact on users.
• Use Infrastructure-as-Code to spin up temporary environments. Create a Terraform module for a full S/4HANA stack and instantiate it for a short-term project or testing, then destroy it when done. This ensures you pay only for the time actually needed. Automating system copies/refreshes from production backups can populate these ephemeral environments with realistic data when needed.
• Plan fewer, well-utilized environments rather than many underutilized ones. Each additional landscape brings overhead of compute, storage and management. Wherever possible, combine roles.
• Enforce governance around provisioning new SAP systems. Implement approval processes that consider cost impact. Some organizations formalize this with policies so that cloud spend doesn’t sprawl uncontrolled.

Conclusion

The bottom line: optimizing your SAP S/4HANA landscape design is often the biggest lever for reducing cloud TCO, even more than shaving off a few percent on instance prices. AWS provides a rich toolkit various EC2 instance types, EBS/EFS storage classes, S3 tiers and management services that enable a high degree of cost control if used wisely for your SAP architecture. By right-sizing servers, turning off or consolidating what you don’t need, and leveraging services like S3, EFS lifecycle policies and AWS Backup, you tackle the true cost drivers in an SAP environment. 

In practice, companies that take this holistic approach have seen significant savings in their AWS bills for SAP, all while maintaining performance and reliability. The cloud’s promise is agility and efficiency with a practical engineering mindset and Infrastructure-as-Code automation, you can achieve an efficient SAP landscape that delivers on that promise, ensuring your cloud spend is as optimized as your SAP operations.