# 20 – Manage costs with visibility, planning, and governance
**How do you practice Cloud Financial Management (CFM) to ensure cost optimization and awareness?** From inception to operation, how do you establish control over your SAP cloud infrastructure budget and continue to optimize its usage aligned with your business requirements.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/wellarchitected/latest/sap-lens/design-principle-20.html)
# Best Practice 20.1 – Plan consumption model and environment usage during project phases
During projects, including but not limited to migration or implementation projects, there is often a phased approach to how you deploy systems. There is also a stabilization period where you establish the sizing and usage profile. Take advantage of the flexibility and On-Demand Instance capabilities to minimize your costs during this period.
**Suggestion 20.1.1 – Plan to deploy systems only as required**
Reduced lead times should give you options to deploy systems only as required. For short lived project systems, use On-Demand Instances to build project systems for the duration of the requirement.
**Suggestion 20.1.2 – Evaluate pricing options according to expected duration and usage profile**
Project duration and working hours influence the pricing model. An on-demand pricing model is often the default choice at the beginning of a project. Ensure that a budget is defined and evaluated to adapt to cheaper options when appropriate.
**Suggestion 20.1.3 – Plan to suspend or decommission systems when not in use**
When projects are no longer active or have achieved their objectives, consider the cost savings from shutting down instances, in addition to the storage savings from decommissioning. Typically, a project will make multiple copies of a system during migration. Remember to shut down systems when they are not being used.
# Best Practice 20.2 – Establish a multi-year planned cost model taking advantage of different pricing approaches
Establish a multi-year plan of your capacity requirements to ensure that you are taking full advantage of pricing models to maximize any discounts available from AWS. Baseline and track your costs. Cloud pricing models provide flexibility that allows you to elastically match your infrastructure to changing business requirements. Before making commitments to long-term Savings Plans or Reserved Instances, understand and plan your expected SAP system usage over at least a 3-year horizon. Use testing, SAP Quick Sizer outputs, and growth forecasts to inform a commitment plan and take advantage of the maximum discounts for your workload.
**Suggestion 20.2.1 – Establish a capacity estimate with understanding of your key business events**
SAP workloads are generally stable, with known usage patterns and hours of operation. Establish a well understood steady state capacity baseline for your SAP systems. This can be done through performance testing and monitoring your production environment during the initial weeks of your deployment.
Extend your steady state capacity estimate to at least a three-year horizon, considering the following:
+ Major business events, such as mergers, acquisitions, and divestment
+ Regulation change that might affect data storage requirements or business process frequency
+ Data growth due to normal business operations (particularly important for in-memory databases like SAP HANA as data affects compute sizing in addition to storage sizing)
+ Major system upgrades, system replacement, or decommissioning
**Suggestion 20.2.2 – Evaluate whether 1-year or 3-year commitments are appropriate**
Evaluate how much of your SAP workload could take advantage of three-year committed compute and maximize available discounts by using your capacity estimate. Consider the following:
+ Can you consider a three-year commitment for all compute needs of your SAP workload?
+ Can you consider a three-year commitment for a subset of your needs which you are confident will not change? For example, SAP primary application servers or database primaries.
+ Is your SAP workload part of a broader AWS Organization which could use excess compute commitments when changes in your SAP capacity requirements reduce the need for compute at a future point in time?
+ Is your SAP workload part of a broader AWS Organization and could share compute commitments for non-production environments which do not need to be operating 24/7?
+ For medium term capacity changes, does the benefit of committing to a 3-year compute plan out-weigh any excess or unused capacity wastage (for example, the break-even point versus a shorter-term commitment is in month 20)?
+ Can you consider shorter term commitment (one year) for applications likely to be affected by major business changes or replacement in the short term?
+ Are currency fluctuations a concern you need to consider? AWS pricing (with the exception of AWS China) is in US dollars (USD). If a fixed exchange rate is desirable, you might want to consider All Upfront pricing models, if possible.
Establish a plan to match workload capacity requirements with commitment duration to maximize discount.
![\[Timeline showing SAP workload capacity allocation over 3 years with different commitment types.\]](http://docs.aws.amazon.com/wellarchitected/latest/sap-lens/images/example-timeline-of-planning-sap-on-aws-compute-commitments.png)
**Suggestion 20.2.3 – Evaluate whether fixing compute types for greater discounts is appropriate**
SAP workloads generally only use a limited set of AWS compute types and thus you should consider whether committing to specific compute families or specific instance types is appropriate for your workload to maximize discount. The two highest discount pricing approaches for compute are EC2 Instance Savings Plans and Standard Reserved Instances.
Consider the following:
+ Identify frequently used compute types in your landscape and consider purchasing specific EC2 instance Savings Plans or Standard Reserved Instances for these. For example, if you are using `m5.xlarge` for your application servers across multiple SAP applications. This is a good candidate for an EC2 specific savings plan or Standard Reserved Instance as it is highly likely that you will always be using this commitment.
+ Identify compute components which are highly likely to change EC2 families due to growth workloads or business events. Consider purchasing more generic compute savings plans or Convertible Reserved Instances for these items. For example, if you have an SAP HANA database which needs to move between an EC2 `r5` and `x1e` compute family due to a size increase after only 6 months. This is a good candidate for a short-term Convertible Reserved Instance or compute savings plan.
+ Identify break-even points for general compute vs. specific compute pricing and take this into account when choosing your commitment type. For example, it might be cheaper to purchase a Standard Reserved Instance for three years rather than choose a 3-year Convertible Reserved Instance if your sizing change is in year 3. You might also consider selling the residual Reserved Instance value on the AWS Reserved Instance Marketplace.
+ Before changing instance types, identify use of AWS Marketplace seller private offer or annual subscription software. This will avoid incurring additional software costs. Both plans offer savings by allowing you to commit to running software products on an Amazon EC2 Instance for specified duration. For example, the purchase of an annual subscription for software to run on an `r4.xlarge` instance. You decided to change the instance type to `r5.xlarge` . The annual subscription is no longer linked to the instance but is still active. This results in additional on-demand pricing for the software on the `r5.xlarge` . Consider waiting for the annual subscription to expire before changing the instance size.
**Suggestion 20.2.4 – Evaluate whether Savings Plans, Reserved Instances, or both are more appropriate**
Choose a mixture of both Savings Plans and Reserved Instances, to obtain benefits from the different models, if appropriate for your SAP workload. Determine your commitment periods and compute requirements holistically and then select your pricing model.
Further information on the differences between Savings Plans and Reserved Instances can be found in [Cost Optimization]: [Best Practice 18.1 - Understand the payment and commitment options available for Amazon EC2](best-practice-18-1.md) and in [Compute Savings Plans and Reserved Instances](https://docs.aws.amazon.com/savingsplans/latest/userguide/what-is-savings-plans.html#sp-ris).
Consider [Reliability]: [Best Practice 10.2 - Select an architecture suitable for your availability and capacity requirements](best-practice-10-2.md). It discusses the capacity reservation differences and tradeoffs between Savings Plans and Reserved Instances.
**Suggestion 20.2.5 – Convert your capacity plan into a cost model for budgeting and tracking purposes**
Convert your Savings Plans, Reserved Instance choices, and on-demand budget into a cost plan that estimates your AWS spend for your SAP landscape over at least three years. Combine your compute estimate with other AWS costs to finalize your SAP workload cost model for budgeting and tracking purposes.
When estimating your SAP costs, remember to include the following:
+ Compute-attached storage costs (such as Amazon EBS volumes)
+ Shared file storage costs (such as Amazon EFS, and Amazon FSx)
+ Backup storage costs (such as Amazon S3, and Amazon S3 Glacier)
+ Network and VPC costs (such as Elastic Load Balancers, NAT gateways, Transit Gateways, Network outbound costs, Direct Connect, and VPN)
+ Management and governance service costs (such as CloudWatch detailed metrics, AWS CloudTrail, and AWS Config)
+ Security service costs (such as AWS WAF, Amazon GuardDuty, and AWS Shield)
+ AWS Support Costs (Business or higher)
+ Consider enterprise discount programs or volume discounts that you might be eligible for (speak to your AWS account manager for further details)
+ Currency: Be aware that AWS prices are in US dollars (USD). You can choose a billing currency and your bills will be computed in USD and converted to your preferred currency at a competitive exchange rate
# Best Practice 20.3 – Establish a budget and mechanisms for cost allocation and tracking including anomaly detection
There are [guidelines](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/expenditure-and-usage-awareness.html) in the Well-Architected Framework for implementing financial management. Set expectations around cloud costs with annual, quarterly, monthly, or even daily budgets depending on your business needs. Adjust forecasts regularly to align with usage, and identify patterns and anomalies. Establish mechanisms for cost allocation using account and tagging strategies.
**Suggestion 20.3.1 – Use cost and billing tools to gain spend visibility**
SAP systems are often static in their usage patterns once established. If you use an on-demand pricing model, either on a permanent basis or during project phases, you might see a fluctuation in Amazon EC2 costs. If data volume management strategies are not put in place, Amazon EBS and Amazon S3 costs might be higher than expected.
AWS provide a suite of [Cloud Financial Management Services](https://aws.amazon.com/aws-cost-management/) including the following:
+
+ [AWS Billing Conductor](https://aws.amazon.com/aws-cost-management/aws-billing-conductor/) allows you to construct a cost allocation strategy that aligns with your business logic.
+ [AWS Budgets](https://aws.amazon.com/aws-cost-management/aws-budgets/) can be used to set custom budget based on your expected usage and notify you when a threshold is exceeded.
+ [AWS Cost Anomaly Detection](https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/) uses advanced machine learning (ML) technologies to identify anomalous spend and root causes.
+ [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/?track=costop_bottom) provide tools for visibility and analysis.
Further guidance can be found in the Well-Architected Framework [Cost Optimization]: [Expenditure and Usage Awareness](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/expenditure-and-usage-awareness.html).
**Suggestion 20.3.2 – Analyze and allocate spend using tags**
You can create [cost allocation tags](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html#allocation-what) that help identify pricing of AWS resources based on individual accounts, resources, business units, and SAP environments. These tags are then visible within the AWS billing reports and can be analyzed using Cost Explorer. You can use cost allocation tags to determine the costs associated with individual SAP environments. They help inform if action should be taken to reduce or remove costs associated with specific environments, such as temporary environments or project environments that are no longer required. You should have a process to identify resources that do not have cost allocation tags attached. Implement the actions required to add cost allocation tags to these resources.
+ SAP on AWS Blog: [Tagging recommendations for SAP on AWS](https://aws.amazon.com/blogs/awsforsap/tagging-recommendations-for-sap-on-aws/)
# Best Practice 20.4 – Establish cost-related procedures and controls
It might be necessary to adapt traditional cost assessment processes to be cloud ready. Gain familiarity with how to implement the right financial practices and policies by reviewing the [AWS Cloud Financial Management Guide](https://aws.amazon.com/executive-insights/content/cloud-financial-management-reference-guide).
**Suggestion 20.4.1 – Educate administrators on cost implications**
Introduce mechanisms to assign accountability and provide incentives for cost optimization.
**Suggestion 20.4.2 – Only allow certain users the ability to provision instances using IAM controls**
Use IAM policies aligned with resource type and job function within account boundaries to ensure cost control. For example, you might allow additional small-scale systems in a sandbox account to be controlled within a project team but have an additional approval process and restricted access for larger instances in a production account.
# Best Practice 20.5 – Review usage for opportunities to optimize
Review your SAP workload periodically to identify opportunities to optimize cost. Regular reviews should focus on: minimizing the differences and anomalies found between your AWS bill and your SAP workload budget, checking that all your SAP cloud resources are appropriately sized and not over-provisioned, and understanding any new AWS service releases or cost reductions that could improve the cost effectiveness of your SAP workload.
**Suggestion 20.5.1 – Minimize additional cost where your usage has been higher than initially planned**
Your cloud usage might have grown outside of your estimated cost model due to unplanned business events or additional performance required. Analyze these changes with a view to optimizing the new cost. Consider additional Savings Plan commitments or Reserved Instances if this is a sustained change.
Where additional capacity is required for only short periods, consider horizontal scaling mechanisms (for example, additional SAP application servers) using automatic scaling or scheduled On-Demand Instance capacity to minimize cost further.
**Suggestion 20.5.2 – Review SAP workload usage metrics and further right-size where possible**
Regularly review the components supporting your SAP system to ensure they are right-sized. Use CloudWatch metrics to consider:
+ Is the SAP EC2 compute the right size? Is CPU or memory utilization low? Could you move to a smaller EC2 instance size?
+ Is SAP storage the right size? Is there excess space provisioned but unused? Could you reduce volume sizes?
+ Is SAP storage appropriately performant? Is there excess IOPS or MBPS provisioned which could be reduced?
+ Are backup and snapshots being managed appropriately? Do you have too many backup copies on S3 Standard which could be archived to Amazon S3 Infrequently Accessed or Amazon Glacier?
+ Use tools such as [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/) and [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/) to identify additional areas for optimization. Be aware of SAP specific compute and storage restrictions as per SAP note: [1656099 - SAP Applications on AWS: Supported DB/OS and Amazon EC2 products](https://launchpad.support.sap.com/#/notes/1656099) [Requires SAP Portal Access].
Use your findings to continually right-size your SAP workload components on a regular basis and maximize your use of Savings Plans and Reserved Instances.
**Suggestion 20.5.3 – Understand new AWS services and plan to implement where further cost optimization can be achieved**
AWS regularly releases new services and periodically reduces prices. Review new SAP on AWS service announcements and plan to take advantage of these in your architecture at a minimum every 12 months. If you have a technical account manager (TAM) as part of an Enterprise Support agreement with AWS, they can assist you in a regular new service briefing and optimization discussion.
Subscribe to the [SAP on AWS blog](https://aws.amazon.com/blogs/awsforsap/) and the [What’s New](https://aws.amazon.com/new/) feed for the latest announcements and news.
See [Operational Excellence]: [Best Practice 4.4 - Perform regular workload reviews to optimize for resiliency, performance, agility, and cost](best-practice-4-4.md) for further information on continued optimization of your SAP workload.