How the nOps SDK helps determine impact on cloud cost before you commit your IAC files to master and break the budget.
Cloud cost management encompasses a variety of processes, practices, and tools to which the overall goal is to achieve optimal cost for required usage. Here at nOps, we are on a crusade to discover and implement best in class ideas, which enable practitioners to get the maximum ROI for their investment. In this blog post, I am excited to share with you the recently released projection pricing feature of the nOps SDK. This pricing feature is envisioned as an automation tool that will promote better decision making before deploying cloud infrastructure changes through IAC platforms, such as Terraform or AWS CloudFormation.
nOps SDK Cloud Cost Management Tool Integration: Pricing Projection for your Terraform Changes
The impact of a given IAC infrastructure change-set on cost is not transparent at the time of applying it. While a DevOps engineer in a small organization may be able to make reasonable cost estimates from experience, things tend to get out of hand as the number of infrastructure resources used and stakeholders involved in managing costs grows. This effectively prevents decision makers from evaluating and approving a change-set before deployment. As any financial planner will tell you, buying something without having a good idea of what it costs is never a good idea.
The pricing projection feature of the nOps SDK helps achieve 2 things: know the cost impact of a change-set within your preferred time-horizon and make it visible for all interested parties. For this purpose, the SDK exposes the pricing module and particularly the CloudCost class, which provides a generic interface for making cost projections. In order to make pricing projections, the module needs to know only the following:
- The types of operations in a given change-set (i.e. creating, updating and/or deleting resources)
- The specification of resources involved in each operation (e.g. a general purpose t2.large linux EC2 instance)**
Provided this information, the nOps SDK is able to fetch price information from the nOps API and assign each resource a relevant unit price. While the format of the input is a simple list of dictionaries with each specifying an operation, the CloudCost class will automatically parse these dictionaries into corresponding objects and populate their cost fields. After prices are loaded, it is possible to create cost projections for a given time period via the compute_cost_effects method. This will compute and persist the cost projections on the relevant objects.
Once cost effects are computed, what you do with this information is entirely up to you. You could, for example, output a simple terminal report via the output_report method. Or, you could email the list of operations and their cost impact to others. Even better, you could post the cost projection as a comment on your PR so as to allow your teammates to understand cost changes before they approve it.
In fact, nOps itself provides automation tools that ease the integration of the pricing feature. An instance of this comes via the nOps pre-commit CLI tool, which can be configured to run as a pre-commit hook and parse your terraform file changes into the format required by the nOps SDK and output the cost impact before you commit your code. The nOps SDK acts as a dependency of the CLI tool.
As you can see, using the nOps SDK is designed to help analyze and understand cost insights and projections from your AWS environment. This makes it infinitely easier when trying to fully predict what the changes to your infrastructure have on the AWS spend at the end of the month. These predictions help teams ensure that they are staying under budget before pushing the changes to production and having the added benefit of reducing invoice surprises at the end of the month!
If you are interested in seeing how to integrate this feature into your workflows you can sign up for a free trial at www.nops.io – we are always here to help and we would love to hear your feedback!
*We now support AWS EC2 and RDS resources!
**Please refer to SDK Documentation for interface details.