# 17 – Evaluate SAP architecture patterns for cost efficiency
**How do you incorporate cost considerations into the evaluation of SAP architecture patterns?** Ensure that when there is a decision to be made on architecture, that the cost implications are fully understood as part of design considerations.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/wellarchitected/latest/sap-lens/design-principle-17.html)
# Best Practice 17.1 – Evaluate your use of SAP managed service offerings
Per the AWS shared responsibility model, the customer has the responsibility of managing their SAP workloads on AWS. Optionally, a service provider can be used to manage your SAP workloads on AWS. When evaluating a service provider, the responsibility of both upfront and ongoing cost management should be delegated appropriately and should be treated as an ongoing process.
**Suggestion 17.1.1 – Evaluate and understand available managed service offerings **
A number of AWS and SAP partners provide services for the deployment and operation of your SAP landscape. The scope and maturity of services provided varies across partners. These types of services can provide efficiencies, for example, centralized support, bundled licenses, or automated deployment services. These can reduce your overall costs and should be evaluated based on your specific business requirements. Evaluate partners for AWS competencies including those with the [AWS SAP Competency](https://aws.amazon.com/sap/partner-solutions/) or belonging to the AWS Partner Network (APN).
SAP offers [RISE with SAP](https://www.sap.com/products/rise.html), a single-tenant, SAP-managed S/4HANA solution that also includes SAP Business Technology Platform (BTP) and other SAP software in a single contract. AWS supports customer choice and hosts many customers on the SAP RISE platform. SAP RISE can be hosted on AWS and combined with SAP BTP on AWS and other AWS workloads. When choosing AWS for RISE and BTP, you have options to simplify the architecture, improve connectivity, improve security, and reduce costs.
+ AWS Blog: [Your ERP environment, your choice: RISE with SAP presents another ERP modernization path for AWS customers](https://aws.amazon.com/blogs/awsforsap/your-erp-environment-your-choice-rise-with-sap-presents-another-erp-modernization-path-for-aws-customers/)
+ AWS Blog: [How to connect SAP solutions running on AWS with AWS accounts and services](https://aws.amazon.com/blogs/awsforsap/how-to-connect-sap-solutions-running-on-aws-with-aws-accounts-and-services/)
**Suggestion 17.1.2 – Understand the roles and responsibilities related to cost control**
Different managed service offerings have different cost models to cover infrastructure, licensing, and services. Decide where the responsibility for cost control lies. The following questions can be asked as part of this process.
+ Are the costs from the provider:
+ Based on a percentage of infrastructure spend?
+ Based on an agreed total cost of ownership (TCO)?
+ Variable (both up and down) according to changed business conditions?
+ T-shirt sized (small, medium, large)? Is there an appropriate change control process in place to ensure that costs are controlled and understood?
+ Is there sufficient visibility and transparency of the infrastructure costs?
+ Does cost governance limit innovation and flexibility?
**Suggestion 17.1.3 – Agree on an approach to cost management and optimization with all parties**
When evaluating the different managed service offerings available, understand the managed services partner’s approach to cost management. How can you work together to drive on-going cost optimization for your organization?
This evaluation should include a regular review process. It might also benefit from incentives, such as a shared reward model, that encourage the partner to take ownership so that both parties financially benefit from the cost savings achieved.
# Best Practice 17.2 – Evaluate the cost characteristics of your SAP application architecture pattern
As you develop the architecture of your SAP landscape, consider the cost of the number of infrastructure components in addition to their size and location. By establishing the business requirements of the solution, acknowledging risk, and finding opportunities to optimize, you can realize significant cost savings
**Suggestion 17.2.1 – Review your selected SAP installation patterns**
For each SAP application, define a deployment pattern, such as standalone, distributed, or high availability (HA). Select the architectural pattern that best balances the cost and reliability characteristics to meet your business requirements. A useful approach is to quantify the cost of an outage to your business and work backwards from that. Balance the risk of an individual failure impacting availability against the cost of reducing that risk.
Additionally, consider whether your architecture has the flexibility for right sizing. There can be cost savings with operating system licensing, storage, and managing multiple application servers on a single host. For the application tier, instance sizes are available with fine granularity for CPU and memory, with near linear pricing in the supported instance families. Deploying multiple smaller instance sizes can provide more options for instance reuse and workload-based scaling.
Evaluate logical groupings and consider the effect of combining components, systems (SIDs), or landscapes. Would these activities increase operational complexity and decrease reliability?
+ AWS Documentation: [Architecture Guidance for Availability and Reliability of SAP on AWS](https://docs.aws.amazon.com/sap/latest/general/architecture-guidance-of-sap-on-aws.html)
+ SAP Lens [Reliability]: [Reliability design principles](reliability.md)
+ AWS Well-Architected Framework [Reliability]: [Reliability Pillar](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html)
**Suggestion 17.2.2 – Evaluate exceptions for the use of multitenancy or hosting multiple databases in a single host**
For most databases, size each system independently and take advantage of flexible instance sizing to match requirements for those systems. In some cases, it might make sense to deviate from that recommendation in the interest of cost. For example:
+ When a HANA-based component requires less memory than the smallest EC2 instance size available, consider the use of [SAP HANA Multitenant Database Containers](https://help.sap.com/viewer/6b94445c94ae495c83a19646e7c3fd56/2.0.05/en-US/623afd167e6b48bf956ebb7f2142f058.html). Hosting with other components allows for efficient use of the compute resources.
+ Core-based database licensing models for relational databases, including Oracle and SQL Server
+ Applications that are, or can be, tightly coupled for uptime requirements and version dependencies. This includes management tools (for example Solution Manager and SAP HANA Cockpit) and some SAP NetWeaver Gateway Deployment options (Fiori and ECC).
**Suggestion 17.2.3 – Evaluate the use of the single host installation pattern for systems that do not require resiliency and scalability**
For individual applications or environments, you should consider the advantages of a single host model. This can help save operating system costs, storage duplication, software license costs, and managed service costs. Common architectural options, particularly for non-production landscapes, include:
+ Co-hosting database, application, and SAP central services
+ Separate database (to minimize database licensing). Refer to [Cost Optimization]: [Best Practice 18.3 - Evaluate licensing impact and optimization options](best-practice-18-3.md).
+ Combined application and SAP Central Services
**Suggestion 17.2.4 – Choose the most cost-effective Region that meets your requirements**
The primary drivers for SAP Region selection are proximity, data residency, and service availability. For deployments where a choice exists, be aware that each AWS Region offers pricing based on local market conditions. AWS service pricing is therefore different in each Region. Review any price differences and their potential impact.
**Suggestion 17.2.5 – Use architectures that can be scaled in the event of a failure**
Recovery mechanisms and the elasticity of the cloud allow for a design where redundant resources do not need to be active and at 100% capacity. If your business requirements allow for a more flexible RTO or RPO, consider the following.
For the database:
+ If your recovery point objectives allow, consider a secondary or standby database node that does not require equivalent compute capacity to apply changes from the primary. With an awareness on the recovery time impact, consider the cost advantages of deploying a smaller or shared instance for your secondary, and scale up only when required. Use of a smaller instance maintains the 1:1 relationship between primary and secondary system instances. A shared instance architecture pools the secondary database with a non-replicated system database onto a single instance. In the event of a failure, the non-replicated system must be stopped before a takeover can occur. This will increase the RTO.
+ If using a smaller instance for the secondary SAP HANA database, turn off memory preload to accommodate a smaller memory footprint on the standby and reduce cost. SAP estimates the memory requirements in the help document for [Secondary System Usage](https://help.sap.com/viewer/4e9b18c116aa42fc84c7dbfd02111aba/2.0.05/en-US/9d62b8108063497f9d6aab08902b2e04.html).
+ SUSE Documentation: [SAP HANA System Replication Scale-Up - Cost Optimized Scenario \$1 SUSE](https://documentation.suse.com/sbp/all/html/SLES4SAP-hana-sr-guide-CostOpt-12/index.html)
+ If your recovery time objective and resiliency requirements allow, consider data and log backup approaches that use Multi-AZ storage (such as Amazon FSx, Amazon EFS, or Amazon S3). These approaches allow for geographic protection of data without requiring redundant secondary resources. In the event of failure, secondary resources can be created on demand and quickly restored from cross-location backups and log storage.
+ SAP on AWS Blog: [How to use snapshots to create an automated recovery procedure for SAP ASE databases](https://aws.amazon.com/blogs/awsforsap/how-to-use-snapshots-to-create-an-automated-recovery-procedure-for-sap-ase-databases/)
For the application:
+ [AWS instance recovery](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html) uses a CloudWatch alarm to monitor an Amazon EC2 instance. It automatically recovers the instance if it becomes impaired due to an underlying hardware failure. Evaluate if the failure scenarios covered provide sufficient protection.
+ For scenarios in which an application server needs to be quickly recreated, options include EC2 instances that are provisioned but not running, templated AMIs, storage replication using common staging servers, or infrastructure as code (IaC).
**Suggestion 17.2.6 – Consider the cost of minimum compute capacity during a failure**
Distributing SAP components across Availability Zones can reduce the costs incurred for capacity reservations in the event of failure. By distributing components across Availability Zones, you avoid the need for excess capacity because you already have part of your workload geographically spread. This minimizes the scope of impact in the event of an AZ failure.
For example, if 100% capacity is an availability requirement for failure scenarios including the loss of an Availability Zone, instead of provisioning 200% capacity across two Availability Zones, provision 150% capacity across three.
![\[SAP production account with three availability zones, each hosting application and database instances.\]](http://docs.aws.amazon.com/wellarchitected/latest/sap-lens/images/example-three-availability-zone-architecture.png)
**Suggestion 17.2.7 – Evaluate the use of storage-only based recovery options**
In general on AWS, we recommend database replication over storage replication to ensure protection from the broadest range of failure scenarios. For the application layer or for less critical instances, a DR solution that uses storage replication without the need for compute can reduce costs. It also minimizes the complexity associated with managing change.
+ AWS Documentation: [AWS Elastic Disaster Recovery - Amazon Web Services](https://aws.amazon.com/disaster-recovery/)
+ AWS Documentation: [ Creating backup copies across Regions - AWS Backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/cross-region-backup.html)
**Suggestion 17.2.8 – Understand networking-related costs**
SAP customers often require a secure connection between their on-premises network and Amazon VPC. Using an appropriately sized Direct Connect, a VPN connection, or both, it is possible to meet performance and reliability requirements while minimizing cost.
Data transfer costs will be impacted by Region, VPC, and Availability Zone design. Evaluate how the distribution and replication of your SAP components can be optimized without compromising reliability.
For example, if two systems that transfer large amounts of data are in separate locations, consider the impact on data transfer costs.
+ AWS Documentation: [EC2 On-Demand Instance Pricing – Amazon Web Services](https://aws.amazon.com/ec2/pricing/on-demand/)
+ AWS Documentation: [Architecture Patterns - General SAP Guides](https://docs.aws.amazon.com/sap/latest/general/arch-guide-architecture-patterns.html)
Further guidance can be found in the Cost Pillar of the Well-Architected Framework Review [Plan for Data Transfer - Cost Optimization Pillar](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/plan-for-data-transfer.html).
# Best Practice 17.3 – Understand business requirements to make cost-optimized design decisions per environment
Optimize the cost of each system or environment individually based on its differing characteristics. Consider capacity, performance, reliability and operating hours to match business requirements. For environments or applications that are less critical for the experience of end users or business processes, minimize storage, compute, and operating hours to reduce cost. Balance the cost savings of a reduced configuration with operational requirements for testing or support.
**Suggestion 17.3.1 – Evaluate if non-production environments need a full copy of production data**
Having full copies of production data in non-production will greatly impact your storage and compute costs. Consider minimizing the number of copies of production data while still meeting your testing requirements. Options to minimize costs of non-production environment data storage include:
+ Using less storage capacity for development and test systems.
+ Using data slicing tools to carve out a smaller subset of test data in non-production systems.
+ Consider the use of temporary production copies. These copies can be created on-demand and then quickly decommissioned, or archived, after the business need or test has passed.
+ Evaluate if the SAP recommendation for SAP HANA databases of 50% working memory is required in non-production systems.
**Suggestion 17.3.2 – Evaluate if non-production environments always need to have the same performance as production**
Non-production systems and some support systems are likely to have a smaller set of users, handle significantly lower transaction volumes, or have flexible response time requirements. Consider the following:
+ Reducing the SAP Application Performance Standard (SAPS) for your workload by using smaller EC2 instance types.
+ Using fewer application servers.
+ Using lower cost Amazon EBS storage types, for example, `gp3` instead of `io2` .
+ Using reduced performance characteristics for non-production systems volumes, for example, 3,000 IOPS instead of 10,000 IOPS.
+ The elasticity of the cloud means that you can scale up your non-production testing resources that require production-like performance, such as load or scaling tests.
**Suggestion 17.3.3 – Evaluate if non-production environments need the same operating hours as production**
Non-production environments like test, training, and sandbox systems, might have reduced operating hours compared with production. Consider time zones and the working hours of your support teams to determine whether all systems are required 24 x 7. Use this information to select the lowest pricing model.
For example, running your SAP training system for 40 hours a week with an on-demand pricing model (\$123% uptime) will be cheaper than running it always on at 100% with a 3-year Reserved Instance or Savings Plan.
**Suggestion 17.3.4 – Evaluate if non-production environments consistently need the same reliability as production**
Choose the most cost-effective architecture to match each system’s individual reliability requirements. See [Reliability]: [Best Practice 10.1 - Agree on SAP workload availability goals that align with your business requirements](best-practice-10-1.md). Further guidance can be found in the [Reliability Pillar](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html) of the AWS Well-Architected Framework.
Where a production-like architecture exists solely for testing purposes, consider how often it needs to mirror production. If database high availability is needed in a non-production environment for reliability or performance testing, you can choose to shut down or scale down the secondary instance outside of these testing windows to save cost.
Cost benefits can be realized through the use of automation and by using on-demand pricing for environments that don’t need production-like performance at all times.
**Suggestion 17.3.5 – Evaluate the business requirements for non-core systems including support and legacy systems**
If environments exist for reference purposes only, or have a less critical business role, evaluate the uptime, performance, and reliability requirements needed compared to your core production systems.
For example, a legacy ERP system might require being kept for reference purposes from a prior application conversion or business restructure. Costs for this system can be optimized by running the EC2 instances only when required, thus only paying for Amazon EBS storage. A more cost-effective solution could be archiving the system via backup to Amazon S3 and Amazon S3 Glacier.
# Best Practice 17.4 – Review the size, granularity, and latest available EC2 instances for SAP components
Smaller EC2 instances provide greater cost flexibility in SAP workloads. They introduce options for horizontal scaling that allow for compute to be switched off when not in use or scaled up only during peak loads. Adopting a consistent EC2 instance size at the application tier will help you maximize the benefits of Reserved Instance and Savings Plans commitments across all workloads. Take into account the latest available AWS SAP certified instances. The operational impact, license costs, support, sharing and reusability for each component should also be evaluated.
**Suggestion 17.4.1 – Evaluate the cost benefits of multiple smaller application servers to provide flexibility**
For many SAP workloads, application servers can be designed to be immutable. Having a standard application server configuration, which is scaled horizontally by replicating the base unit, gives options for consistent repeatable units. The advantages are reusability, compute utilization, reservations, and automation. Per-unit requirements, such as operating system licensing, storage duplication, and management costs, should be factored into the evaluation.
Consider the following:
+ SAP on AWS Blog: [DevOps for SAP – Driving Innovation and Lowering Costs](https://aws.amazon.com/blogs/awsforsap/devops-for-sap-driving-innovation-and-lowering-costs/).
+ SAP on AWS Blog: [Using AWS to allow SAP Application Auto Scaling](https://aws.amazon.com/blogs/awsforsap/using-aws-to-enable-sap-application-auto-scaling/)
**Suggestion 17.4.2 – Evaluate the cost benefits of an SAP HANA scale-out configuration where supported**
SAP OLAP workloads can be deployed in both [scale-up and scale-out](https://help.sap.com/viewer/6b94445c94ae495c83a19646e7c3fd56/2.0.05/en-US/a165e192ba374c2a8b17566f89fe8419.html) configurations. SAP recommends to scale-up before scaling out to reduce operational complexity. However, scale-out implementations might be applicable for larger analytical or native SAP HANA workloads, which require significant compute (SAPS).
In certain cases, S/4HANA also supports scale-out configuration but with restrictions. See SAP Note: [2408419 - SAP S/4HANA - Multi-Node Support](https://launchpad.support.sap.com/#/notes/2408419) [Requires SAP Portal Access].
When considering scale-up vs. scale-out consider the following:
+ [Certified EC2 instance sizes](https://www.sap.com/dmc/exp/2014-09-02-hana-hardware/enEN/#/solutions?filters=iaas;ve:23;v:105) available for scale-up and scale-out
+ The cost per GiB of EC2 memory for each instance family. Larger EC2 instances typically have a higher cost per GiB than smaller instances.
+ The added complexity and operational overhead of managing data distribution in scale-out deployments. See SAP Note: [2081591 - FAQ: SAP HANA Table Distribution](https://launchpad.support.sap.com/#/notes/2081591) [Requires SAP Portal Access]
# Best Practice 17.5 – Consider using on-demand capacity to improve cost efficiency
The on-demand pricing model is suitable for SAP workloads needing reduced operating hours, short-term projects, experimentation, or expanded capacity for small periods of time (for example, performance testing). Determine where you can use on-demand pricing in your SAP architecture.
**Suggestion 17.5.1 – Evaluate the use of on-demand for SAP systems needing less than 24/7 operating hours**
Based on the break-even point between the use of on-demand and other pricing models. (See [Reliability]: [Best Practice 18.1 - Understand the payment and commitment options available for Amazon EC2](best-practice-18-1.md) ), evaluate if on-demand will provide the lowest cost. As part of this evaluation, consider the overall Savings Plan commitment.
Common use cases include non-production systems that are not needed outside of extended business hours or short-term business experiments, such as trial upgrades and proofs of concept (POCs).
+ SAP on AWS Blog: [Automate Start or Stop of Distributed SAP HANA systems using AWS Systems Manager](https://aws.amazon.com/blogs/awsforsap/automate-start-or-stop-of-distributed-sap-hana-systems-using-aws-systems-manager/)
**Suggestion 17.5.2 - Evaluate scheduled or dynamic scaling options for peak loads**
On-demand capacity is commonly used in SAP workloads for peaks where capacity requirements spike for a short period of time. Consider the following:
+ Use schedule-based SAP application server scaling for known usage pattern peaks such as period, month-end, year-end, or seasonal peaks.
+ Use dynamic scaling of the application tier where peaks are less certain and need to be scaled based on real-time user load. Explore mechanisms which are SAP-aware and provide the required governance and controls.
**Note:** When evaluating dynamic scaling of the application tier, consider the impact on user connections and batch jobs if an SAP application server is shut down due to the stateful nature of SAP components. AWS, SAP, and APN partner-developed tools can help address this requirement.
+ AWS Documentation: [Systems Manager Automation actions reference](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-actions.html)
+ SAP Documentation: [SAP Landscape Management](https://www.sap.com/products/landscape-management.html)
+ SAP on AWS Blog: [Using AWS to enable SAP Application Auto Scaling](https://aws.amazon.com/blogs/awsforsap/using-aws-to-enable-sap-application-auto-scaling/)
# Best Practice 17.6 – Evaluate cost benefits and impact of shared services and solutions
Where the same function is required by multiple SAP systems, it can be a cost-effective option to centralize the management and costs by using existing solutions, sharing components, or both. Monitoring, backups, and connectivity are common functions that can be managed either within an AWS account boundary or in a dedicated account. Standardization, reducing duplication, and reducing complexity reduces cost.
Find appropriate ways to share resources for cost reduction while still maintaining appropriate isolation and without introducing dependencies that might impact operations.
**Suggestion 17.6.1 – Evaluate the cost benefit of a 1-to-1 versus a 1-to-many setup for each shared service**
A standard pattern for SAP landscapes is to isolate non-production and production workloads in separate accounts as part of a multi-account strategy. This can be a logical boundary for some services. Consider complexity and operational costs for each scenario including management boundaries which enforce segmentation, and any data transfer cost impact across Regions, AZs, VPCs, or accounts.
In a multi-account design, some AWS services can be hosted centrally and accessed by several applications and accounts in a hub and spoke design to save cost. Such services include:
+ Dedicated VPC with NAT gateway for all outbound traffic from spoke VPCs
+ Centralized model for load balancers and Web Dispatchers
+ Shared Amazon EFS or Amazon FSx for transports and other file sharing needs
**Suggestion 17.6.2 – Evaluate where reuse of existing services can reduce costs**
This suggestion applies across a number of levels:
+ Where AWS provides services, these often minimize overhead and work with consumption-based pricing. Some examples include Amazon EFS, AWS Backint Agent for SAP HANA, and AWS Backup.
+ Your business might have an enterprise-wide standard for some functions (for example, enterprise backup) which should be used for operational consistency and economies of scale.
+ AWS Partner solutions might be available through the AWS Marketplace or BYOL (bring your own license) based on your specific business requirements.
+ License-included AWS Marketplace machine images might help reduce upfront costs. Licensing restrictions should be considered in this scenario as they could impact solution flexibility by restricting portability to different instance types.
**Suggestion 17.6.3 – Understand the impacts of using build vs. buy vs. open source approaches**
Whether this is AWS or APN partner solution, there are varying degrees of build it yourself vs. open source vs. off the shelf product. Examples include backup solutions, high availability (HA) solutions, and shared storage solutions.
When considering a build-it-yourself approach or the use of an open source solution, you should consider the following:
+ Service level agreements
+ Required skills to build and maintain
+ Business impact of a service outage
You should also evaluate the available commercial models for any solutions you intend to buy based on your specific business requirements and functionality each solution provides. Consider the terms of any commercial model, for example, the right to use vs. pay per use charges and how any such charges are calculated.
# Best Practice 17.7 – Evaluate the cost benefits of automation
The benefits of adopting automation in AWS can include improved efficiency and productivity, which can translate into lower costs for your organization.
**Suggestion 17.7.1 – Evaluate build automation efficiencies**
Automation of the build process by using infrastructure as code has cost efficiencies which can improve your time to market and productivity. The advantages of quality, consistency, repeatability, and recoverability that DevOps best practices can introduce need to be balanced against a higher upfront investment in the development of automation.
Working with AWS Professional Services or an AWS Partner can reduce the overall effort by leveraging their experience.
AWS Launch Wizard for SAP can accelerate SAP deployments with automation. It’s a service that guides you through the sizing, configuration and deployment of SAP HANA applications on AWS following SAP best practice. The service is available at no additional cost, with support provided by AWS.
+ AWS Documentation: [Infrastructure as Code](https://docs.aws.amazon.com//whitepapers/latest/introduction-devops-aws/infrastructure-as-code.html)
+ AWS Documentation: [CloudFormation](https://aws.amazon.com/cloudformation/)
+ AWS Documentation: [AWS Launch Wizard for SAP ](https://docs.aws.amazon.com/launchwizard/latest/userguide/what-is-launch-wizard-sap.html)
+ SAP on AWS Blog: [AWS for SAP DevOps](https://aws.amazon.com/blogs/awsforsap/category/devops/)
**Suggestion 17.7.2 – Evaluate automation efficiencies for operations**
Reduce the cost and manual effort of repeatable tasks by investigating how AWS and third-party tools could be used to automate the running and monitoring of operations. Consider the following:
+ AWS Service: [AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/what-is-systems-manager.html)
Further guidance can be found in [Operational Excellence] [Best Practice 3.6 - Use automation to perform SAP landscape operations](best-practice-3-6.md).