AWS Cloud Financial Management

Recap of Cloud Financial Management (CFM) Customer Engagement on 2022 AWS Summits

Thank you for those who came out and chatted with us about your CFM journey during the last few AWS Summits. Nothing beats a real customer conversation. The experience you shared with us allows us to reflect upon how we can better work together to solve your CFM needs. I thought it’d be helpful to share some commonly asked questions as a recap.

We witnessed a surge for a specific AWS service cost, e.g. S3, RDS, Redshift, what should we do?

To understand the cause of the spike, one thing you can do is to visualize the cost trend and driver in AWS Cost Explorer. Filter by the service in question in Cost Explorer, so you can see the growth trend of the service usage over time, and spot the turning point where the spike started.  You can further investigate the cost spike using the “group by” feature, and dive deeper via a few dimensions, e.g. “Region”, “Linked account”, “Tag” to get more details on whom you can work with to find out the reasons behind the cost increase. If you are currently playing catch up with your tagging practices and need to add tags to multiple resources at once, you can use “Tag Editor” under “AWS Resource Groups”. You can check the user guide “Resource types you can use with AWS Resource Groups and Tag Editor” for resource types that support “Tag Editor” and the user guide to understand the services that support the Resource Groups Tagging API.

Once you validate the cause of the cost spike, the next thing you can do is to find out whether you can optimize your resource usage to lower your cost. For example. use Amazon S3 Intelligent-Tiering that can automatically move your data to a more appropriate storage tier, when data access patterns change. Use Cost Explorer Rightsizing recommendations to monitor your instance utilization (e.g. CPU, and memory metrics if you enabled CloudWatch agent) and select the instance size that fits your usage pattern.

As services are billed differently at AWS, e.g. Amazon EC2 and Amazon Elastic Block Store (EBS) volumes are billed by the time they are provisioned, so even if you don’t use them, you will still be billed for the time they’re provisioned. Stop/terminate your EC2 instances, detach and delete your EBS volumes, when you no longer need them to stop the charge. Turn off or pause the services that you don’t need to use to prevent unnecessary spend.  For instance, use the pause and resume feature to suspend on-demand Redshift billing when a cluster is not in use.

You pay less as your volume increases with volume-based discounts, e.g. Amazon S3, Data Transfer. Leverage the consolidated billing so you can aggregate usage across member accounts to qualify for more volume-based discounts. There are various pricing programs for you to choose from.  Bid for Spot instances for your fault-tolerant compute usage. Commit to Reserved Instances or Savings Plans for predictable workload in exchange for cost reduction. Reserved Instances (launched in 2009) are available for Amazon EC2, Amazon RDSAmazon ElastiCacheAmazon OpenSearch ServiceAmazon Redshift, and Amazon DynamoDB. Savings Plans, as a newer purchase program (launched in 2019), has now three options: Compute, EC2, and Amazon SageMaker.

We are evaluating AWS Reserved Instances (RI) and Savings Plans.  What are the differences?  How can we lower the risk of overcommitting? 

AWS RI and Savings Plans are two AWS purchase options that reward you with discount off On-Demand prices, when you select a one- or three- year program. You commit to a specific hourly amount of usage with RI, and a specific amount of hourly spend with Savings Plans.  Currently, these two purchase options cover different services: Reserved Instances (Amazon EC2, Amazon RDS, Amazon Redshift, Amazon ElastiCache, Amazon OpenSearch, Amazon DynamoDB) and Savings Plans (Compute, Amazon EC2, Amazon Sagemaker). We’ll use the purchase programs that are applicable to compute services as a comparison.


If you are weighing the potential “investment risk” versus cost savings, a couple of things you can consider. A more flexible option, albeit more costly, offers room for changes. For instance, with convertible RIs, you can change instance family, if your workload requires you to do so.  Savings Plans, compared with their RI counterparts, are a more flexible purchase option. But keep in mind that there are also advantages between RIs and Savings Plans.  As you can see from the table above, most of the changes with Savings Plans are automatically applied, therefore you will need minimal resources to manage these.  A lot more flexibilities, e.g. Regions, Compute services (EC2, EKS, Fargate, Lambda), that will come with the Compute Savings Plans. However, Standard RIs allow you to sell your unused RIs in marketplace, reserve capacity with Zonal RIs.  And at this moment, RIs cover more services.

Another way for you to minimize the investment risk is to start with a shorter commitment time frame (1 year versus 3 years), stagger the purchase of your commitment plans, for instance purchasing several Savings Plans on a rolling basis and each with a portion of your target commitment level. We’ll share more details on how you can consider staggering of your commitment plans in the future blog.

Savings Plans and Reserved Instances recommendations are available in Cost Explorer in the Cost Management console.  AWS provides you with these recommendations based on your past 14 days of usage. There are several options for you to adjust your Savings Plans commitment: payer/linked account level, payment terms, payment options, and the time range of the historical data input, to generate the recommendations at your desired level.  There is an upcoming CFM Talk webinar in September that will share tips around how you can best leverage the RI/SP recommendations.

How can I share Savings Plans benefits and costs across accounts? 

When purchasing Savings Plans for an AWS organization, you can share discounts across accounts within the organization, as long as you enable the Savings Plans discount sharing option. When you purchase SP at the payer/management account level, discounts will be applied to the usage for the biggest discount first. When you purchase SP at the linked/member account level, that account will have the priority for discount benefit.

In terms of allocating the Savings Plans cost across member accounts, there are a few ways you can consider. You can charge back all Savings Plans costs (upfront fees and recurring fees) to the account that purchased it, or proportionally allocate the costs to the accounts that have used the Savings Plans benefit. In your AWS Cost & Usage report file, you can use “SavingsPlanEffectiveCost (column)” of the “SavingsPlanCoveredUsage (line)” data as the indicator to distribute the SP costs. You can also create custom line items in AWS Billing Conductor and charge back the SP costs to a specific billing group. You can also create a Cost Category “Savings Plans Costs” and allocate costs to a few Cost Category values with the dimension of “charge type: Savings Plan Upfront Fee” and “charge type: Savings Plan Recurring Fee” and use them as the “source”, and create a few Cost Category values with the dimension of “account” and use them as the “target”. You can then use the “split function” of Cost Categories to share the costs of the “source” Cost Category values among the “target” Cost Category values.

Is there an easier way to manage our team’s AWS spend, if we don’t yet have the information to explicitly set the spend limit for us?

To avoid cost surprises, there are several ways you can do to get alert notifications. With AWS Budgets, you can customize your budget with a specified time frame (Daily, Monthly, Quarterly, or Annually) and set your budget at an all-up level, or set up your budget at the granular level via a dimension of your choice, e.g. Service, Linked account, Tag, or any dimensions you usually use in AWS Cost Explorer. You can set the spend limit with a fixed dollar amount, or add in a growth % so each budget can be calculated across the time frame of your choice.  The latest feature launch “Auto-adjusting budget” (Feb.2022) is another great way for AWS to set your budget for you based on your spending and usage pattern in a specified historical time range. Once you have customized your budgets, you will be alerted, when your spend has exceeded or is forecasted to exceed your budget limit. In addition to AWS Budgets, we’d also recommend leveraging AWS Cost Anomaly Detection.  You can create a monitor with the four dimensions: Services, Linked Account, Cost Category, and Cost Allocation Tag. With CAD, you do need to specify the spend amount for which you will receive alert. The benefit of this is that you can find every anomaly detected in the detection history tab. To help you pin-point potential cost drivers, Cost Anomaly Detection provides root causes analysis per detection. The root cause analysis includes account ID, the service that is responsible for the anomaly, Usage type, Region, severity, duration, and total cost impact.

How can I get myself more familiarized or certified with AWS CFM tooling and best practices, or AWS in general?

Some of you asked about the training courses that you can get yourself more familiarized with all the terminologies, best practices, and tools available at AWS to manage your cloud finance with AWS. There are currently two training courses available, depending on your job role and interest. You can take the CFM training designed for finance, and/or for engineering professionals.

If you are part of the AWS Partner Network (APN), offering solutions for AWS customers to manage their cloud spend. You can look into the Cloud Management Tools Competency and understand the process in order to be validated by the program to become a specialized partner in the CFM area.

For the overall training and certification opportunities, you can benefit from a wide range of AWS certification programs, ranging from the Cloud Practitioner certificate for fundamental understanding of AWS, to Solutions Architect for designing and operating in AWS, to the more specialized certificates in the domains such as networking, data, security. You can find different training materials and tutorials online to help you study and practice for these exams.

Conclusion

I am sure I did not capture information from all the great discussions that have happened in the past few weeks. As always, please continue to share feedback on how we can better work with you. You can either reach out to your contact person at AWS, or join our upcoming CFM events.

I’d like to use this opportunity to thank Matt Berk (Enterprise Support Lead), Larry Im (Sr. Solutions Architect for ISV), Scottie Enriquez (Commercial Architect), and Kyle T. Blocksom (Sr. Solutions Architect), who are an integral part of the successful CFM presence at these summits.  It’s a wrap for our summit-related effort.  We look forward to seeing you at this year’s re:Invent.  More information on that will be shared in the next few weeks.