Abhishek Jain
Tenerity India
Power schedule refers to the time for which the cloud resources should be available to serve the users. Power schedule adherence refers to the practice of adhering to predefined schedules, such as automated starting, stopping, or modifying the power state of virtual machines (VMs) or other cloud resources and the rate of adherence is measurable.
Cloud Service Providers (CSP) offer the ability to control the power state of these resources, allowing users to conserve resources, reduce costs, and optimize performance by dynamically adjusting their availability based on demand of the user. This playbook describes how to measure the power schedule adherence rate in Amazon Web Service (AWS).
This playbook can be used by Engineering & Operations, Finance or Product/Business.
To effectively use this playbook you must have an operational power schedule in place. Below are the tools, people, and information required to successfully execute this playbook.
This section should outline each Persona responsible for the activities and processes encapsulated by this Playbook. It should also designate whether they are a Driver, Decider, Contributor or Informed. Ideally, every activity captured in this section should be associated with one of the FinOps Phases (Inform, Optimize, Operate).
Links to tools, utilities and templates to use during the playbook.
Note: This playbook can be used for computing the KPI for the whole organization’s cloud resources, for a business unit, for a team, for an application or system, etc depending on your requirement. This can be used for all the resources which can be stopped/started and not applicable to resources which cannot be stopped/started after creation. You will need to define the scope for which you wish to calculate this KPI (whole organization, or a fraction) and decide for which resources and services before proceeding with the below steps.
To identify the duration for which a resource is billed, query the CUR data in Athena. Use the below query:
SELECT
sum(date_diff('hour', line_item_usage_start_date, line_item_usage_end_date,))
FROM <cur_database>.<cur_table>
WHERE
line_item_product_code = '<product_code>'
AND resource_tags_user_<customer_tag_key>='<customer_tag_value>'
AND product_product_family = '<product_family>'
AND line_item_usage_start_date >= timestamp '<start_date>'
AND line_item_usage_end_date >= timestamp '<end_date>';
Note: the query can be changed based on how to identify the resource(s) in an organization.
Replace <cur_database> with the CUR Database, <cur_table> with CUR table name, <product_code> with the value of line_item_product_code of the resource for which this is being calculated like ‘AmazonRDS’, <customer_tag_key> with the key of the tag used for identification of resource, <customer_tag_value> with the value of the key, <product_family> with the family of product (e.g. Database Instance, Compute Instance, etc), <start_date> with the start date of period of billing, <end_date> with the end date of the period of billing. The <start_date> and <end_date> should be of the format YYYY-MM-DD.
Additional WHERE clause columns could be – product_region, line_item_usage_account_id, etc.
The above query will give you the number of hours for which the resource was billed in a period.
Taking an example, an RDS instance is required to be stopped over the weekends from Saturday 12 AM UTC to Monday 12 AM UTC.
The total number of hours it needs to be stopped is 48 hrs in a week as per the power schedule.
Consider the month of August 2023: there are 4 weekends so total number of hours the RDS instance is supposed to be stopped = 4 x 48 = 192 hours.
Total number of hours (in August) = 31(number of days) X 24(number of hours in a day) = 744 hours.
Total number of hours the RDS is required to run = 744 – 192 = 552 hours.
OR
Consider the example in step 3, assuming the RDS instance was billed for 600 hours in August 2023, the calculation will look like:
OR
After the playbook is executed, the user of this playbook should discuss the outcome with the engineering/IT operations to provide visibility of any optimization opportunity and action items, with business/product teams so they can derive the cost efficiency of their applications/workloads and with finance to estimate waste spend reduction once optimization is done.
We’d like to thank the following people for their work on this Playbook:
We’d also like to thank our supporters, Laura Mills, David Lambert, Taylor Houck , Brian D’Altilio , and Guido L Fiamengo.
Workload Optimization