Cost optimization for FinOps

Reduce cloud spend without slowing down developers

Overview

With Resourcely, FinOps and Cloud Economics teams can control their cloud spend without slowing developers down. Follow along with this guide to get started reducing your cloud costs.

Resourcely Blueprints and Guardrails can help you guide developers while governing the cost-related decisions they are making. Put controls in place for expensive parameters or properties like:

• VM instance size or type

• Storage type

• Monitoring and logging

• DR/backup

• Region and availability

Sign up for Resourcely

Log in or sign up for Resourcely at https://portal.resourcely.io.

Types of cost optimization guidance

We'll walk through creating different levels of guidance.

Guidance Level	Use
Basic	Blueprint descriptions, defaults
Intermediate	Guardrails with exception approval
Advanced	Guardrails without exceptions, Context-driven Guardrails, Hard-coding variables

Basic cost guidance: Adding descriptions and defaults to an EC2 Blueprint

We’ll start by giving a developer light guidance with a description and default on a cost-sensitive field. Consider an AWS EC2 instance created using Terraform:

AWS EC2 instance (Terraform)

resource "aws_instance" "my-ec2-instance" {
  ami           = "ami-005e54dee72cc1d00" # AMI from AWS docs
  instance_type = "t3.micro"
}

Turn this Terraform into a Resourcely Blueprint with the addition of {{ variables }}. Copy the below Blueprint into Foundry to see the form that is created.

In the resulting form on the Developer Experience tab, you can see that instance type is exposed as a choice to a developer. This is a potentially impactful choice, especially given the cost of 16xlarge instance sizes. We have added a default instance type, and a description to give developers more information to help them make a decision.

Blueprint code

---
constants:
  __name: "{{ name }}_{{ __guid }}"
---

resource "aws_instance" "{{ __name }}" {
  ami           = "ami-005e54dee72cc1d00" # AMI from AWS docs
  instance_type = "{{ instance_type | default: "t3.micro" | desc: "AWS instance type. Best practice is to use .micro instances unless in production." }}"

// This is for demonstration purposes only

Developer Experience

A description and default to give the developer light guidance.

We are not yet restricting input values at all, and is an example of giving light guidance to developers. Save your Blueprint and add some metadata, to make it available for future use.

Intermediate cost guidance: Adding Guardrails

Let’s increase our level of guidance by utilizing the following Guardrail:

GUARDRAIL "Prevent Large AWS instance sizes"
  WHEN aws_instance
    REQUIRE instance_type NOT MATCHES "*large*"
  OVERRIDE WITH APPROVAL @default

Navigate to Foundry, create a new Guardrail, and copy the above code into the editor. Add metadata and save it. Navigate back to the Blueprint to see the following, with the Guardrail added:

This Guardrail is exposed within your developer form.

The populated instance type list has been restricted to remove any instance types of size large or greater.

Developers can “unlock” the Guardrail to choose an instance type that violates our policy. However, this PR will be blocked as part of our CI process:

Guardrails like the above allow FinOps teams to review and approve (or reject) any potentially costly infrastructure changes, even if they are changes that happen outside of Resourcely.

Advanced cost guidance: Making our guidance strict or contextual

It is possible to make our guidance even more custom:

Hardcoding our golden patterns

Sometimes a team will want to allow only a single parameter, without giving teams the ability to make changes. Hardcoding a value in a Blueprint will not expose it to developers. In the below Blueprint example, only a name variable will be exposed. This allows cost-sensitive companies to mandate cost-reducing parameters without giving developers the ability to deviate.

---
constants:
  __name: "{{ name }}_{{ __guid }}"
---

resource "aws_instance" "{{ __name }}" {
  ami           = "ami-005e54dee72cc1d00" # AMI from AWS docs
  instance_type = "t3.micro" # We hardcoded our instance type value here
}

// This is for demonstration purposes only

Context-driven Guardrails

Guardrails can be optionally applied using context, which allows for branching logic. Let’s say you want to only allow (expensive) enhanced monitoring on a database when the environment is production. Otherwise, when the environment is not production, we want to not allow enhanced monitoring.

GUARDRAIL "Disallow enhanced monitoring for non-prod environments"

    REQUIRE monitoring_interval = 0

When the environment is test, a Guardrail is enabled and enforced on our form and during CI. Developers can’t choose a monitoring_interval ≠ 0, and if they do it will fail during their pipeline. This saves us the cost of enhanced monitoring for inconsequential applications:

User does not choose production, and the Guardrail is applied

When environment is production, our Guardrail disappears and developers are free to choose a monitoring_interval (therefore enabling enhanced monitoring):

User chooses production, and the Guardrail isn't applied

Try them out for yourself

Cost optimization is of growing importance at companies who find their cloud spend increasing. Resourcely gives FinOps, Cloud Economics, and other spend-concious teams the ability to govern cloud spend without slowing developers down or causing unnecessary friction.

You can improve your cloud spend posture with Resourcely, free! Sign up at https://portal.resourcely.io, and take advantage of these pre-built cost optimization resources:

Blueprints

<links to self serve>

Guardrails

<links to self serve>