Phase 5: Advanced & Multi-Cloud

Rate optimization, usage optimization & commitment management

Advanced ~3 min read
Think of it this way A friendly analogy. Read this if the technical version feels dense. Show Hide

Imagine you're baking your favorite cake. The first step to being a smart baker who doesn't waste anything is called usage optimization. This means making sure you use just the right amount of everything. Do you really need a gigantic mixing bowl for a small cupcake? Probably not! Are you leaving the oven on for hours after the cake is done? That wastes electricity. Usage optimization is about using only the ingredients and tools you absolutely need, nothing more, nothing less. It's like checking your recipe carefully, measuring your flour and sugar perfectly, and turning off the oven once your cake is ready. Wasting ingredients or energy here just makes your cake more expensive. Cloud Architects help companies make sure their computer "kitchens" are running just as efficiently, so no digital ingredients are wasted.

Once you’ve mastered using exactly what you need, the next step is rate optimization. This is like finding the best deals for those perfectly measured ingredients. You know you need two cups of flour. Now, where can you buy those two cups of flour for the cheapest price? Maybe your local grocery store has a sale, or buying a slightly larger bag is cheaper per cup because you know you'll use it all. You're not buying extra flour you don't need (because you already did usage optimization!), you're just getting the best price for the flour you do need. This is how you save even more, once you're already efficient.

The biggest secret to great rate optimization is called commitment management. This is like telling your grocery store, "Hey, I bake a cake every single week, and I promise to buy all my flour, sugar, and eggs from you for the next year." Because you're committing to buying from them regularly over a long time, the store might offer you a special, lower price for those ingredients than someone who just buys them one week at a time. It’s a win-win: the store gets a guaranteed customer, and you get a fantastic discount. Cloud Architects help companies make these "promises" to cloud providers (the online stores for computers) to get a much better price for their digital "ingredients" over a long period.

So, when you think about how companies run their computer programs online, remember these ideas. First, make sure you're not wasting anything, just like baking with the perfect amount of ingredients. Second, get the best possible price for those perfectly measured ingredients. And third, if you know you'll be using something for a long time, make a deal to get an even bigger discount. This means companies can make sure their computer "kitchens" are not only running perfectly but also saving lots of money, which they can use to build even cooler things.

Cost efficiency in the cloud begins with a relentless focus on usage optimization. This isn't merely about cutting costs, but ensuring every dollar spent delivers maximum business value. It encompasses technical practices such as rightsizing virtual machines and databases to meet actual demand, optimizing storage tiers for cost-effectiveness, implementing auto-scaling for dynamic workloads, and leveraging serverless computing for event-driven functions. The primary goal here is to eliminate waste stemming from idle resources, over-provisioning, and inefficient architectural patterns. Without optimizing usage, any subsequent rate reductions will be applied to an inflated baseline, significantly diminishing their impact. This phase is predominantly an engineering and operations challenge.

Once your usage footprint is lean and efficient, the focus shifts to rate optimization, which centers on securing the best possible price for the resources you genuinely need. The most impactful lever in this domain is commitment management. This involves strategically purchasing long-term commitments like AWS Reserved Instances (RIs) and Savings Plans, Azure Reservations, or Google Cloud Committed Use Discounts. These mechanisms offer substantial price reductions (often 30-70% compared to on-demand rates) in exchange for committing to a certain level of resource usage (e.g., compute power, database instances) over a 1-3 year period. Effective commitment management requires meticulous analysis of historical usage data, accurate forecasting of future needs, and an understanding of your organization's financial risk appetite. The key is to balance potential savings with the flexibility to adapt to evolving workload demands, actively working to avoid "reservation waste" where you pay for committed capacity that goes unused.

These three areas are not discrete tasks but integral components of a continuous, cyclical FinOps practice. Usage optimization provides the essential clean baseline that allows for truly effective rate optimization, which in turn is heavily influenced by smart commitment management. As a Cloud Architect, your role extends beyond technical design; it involves guiding the creation of inherently cost-efficient systems, collaborating closely with FinOps and procurement to secure optimal pricing, and advising on strategic commitment purchases. This demands seamless cross-functional synergy between engineering, finance, and operations teams to align technical decisions with financial objectives, ensuring the organization maximizes cloud value while maintaining stringent cost controls.

Key Takeaways

  • Usage First: Prioritize optimizing resource consumption (e.g., rightsizing, auto-scaling, eliminating waste) before committing to lower rates.
  • Commitments are Key: Leverage long-term commitment programs (e.g., RIs, Savings Plans, Reservations) for significant rate reductions.
  • Data-Driven Decisions: Base all commitment purchases on robust historical data and accurate future forecasts to prevent reservation waste.
  • Continuous & Collaborative: FinOps is an ongoing, iterative process requiring strong synergy across engineering, finance, and operations teams.

Code Example

python
import boto3
from datetime import datetime, timedelta

def get_underutilized_ec2_instances(threshold_cpu=5, lookback_days=7, region='us-east-1'):
    client_cw = boto3.client('cloudwatch', region_name=region)
    client_ec2 = boto3.client('ec2', region_name=region)

    underutilized_instances = []
    response_ec2 = client_ec2.describe_instances(Filters=[{'Name': 'instance-state-name', 'Values': ['running']}])

    for reservation in response_ec2['Reservations']:
        for instance in reservation['Instances']:
            instance_id = instance['InstanceId']
            response_cw = client_cw.get_metric_statistics(
                Namespace='AWS/EC2',
                MetricName='CPUUtilization',
                Dimensions=[{'Name': 'InstanceId', 'Value': instance_id}],
                StartTime=datetime.utcnow() - timedelta(days=lookback_days),
                EndTime=datetime.utcnow(),
                Period=3600 * 24, # Daily average
                Statistics=['Average']
            )

            if response_cw['Datapoints']:
                avg_cpu = sum([dp['Average'] for dp in response_cw['Datapoints']]) / len(response_cw['Datapoints'])
                if avg_cpu < threshold_cpu:
                    underutilized_instances.append(f"Instance ID: {instance_id}, Avg CPU over {lookback_days} days: {avg_cpu:.2f}%")
    return underutilized_instances

# Example usage (requires AWS credentials configured):
# print(get_underutilized_ec2_instances())

How this code works

This code identifies Amazon EC2 instances that are consistently underutilized, serving as a key step in FinOps rate optimization by highlighting potential cost savings. It begins by setting up connections to AWS services using boto3 for cloudwatch (to get performance metrics) and ec2 (to list instances). The get_underutilized_ec2_instances function then retrieves all currently running EC2 instances. For each instance, it queries cloudwatch to fetch CPUUtilization data over a specified lookback_days period, measured from datetime.utcnow().

The core of the analysis involves client_cw.get_metric_statistics, which gathers average CPU usage. A subtle but important detail is the Period parameter, set to 3600 * 24 seconds, instructing CloudWatch to provide daily average Statistics. This ensures a meaningful long-term average instead of raw, hourly data points, giving a better picture of sustained underutilization. If the calculated average CPU across all Datapoints falls below the defined threshold_cpu, the instance is flagged as underutilized and added to a list for further action. The code implicitly handles cases where no data points are returned for an instance.

Related Articles

Hand-picked reads to go deeper on finops.

Back to Cloud Architect Roadmap