So, I’m solving “the January problem” today at my current employer, except that here it’s a February-March problem. To refresh our memory, this happens when you have a long term commitment with a cloud vendor that contains a provision for some kind of promotional credits to be applied to your bill. I’m not a fan of these credits but I understand why they exist and also that nobody cares what FinOps thinks about the arrangement. I’ve experienced this with two vendors so far - AWS and GCP - and they tend to make it rain on your bill to varying extents that can appear to zero out the cost of your bill on a cash basis. It looks basically like this:

This was not a hot button issue for me until lately when - yes, it can happen to you too! - some members of the engineering staff started asking me why some numbers they were looking at weren’t there for the last several days. I blamed Google but then a few days later remembered that it was that magical time of year.

I hacked around the missing data to get the reporting back up for a minute while I circled back to the real solution to this problem, which is to amortize those credits back into the bill. Here’s the general idea.

Rough methodology

It’s not really that tricky, but if you’ve never been an infrastructure person telling the Finance team how this is going to go, it can feel a little awkward at first. Here’s the methodology I recommend, at least as a conversation starter.

These credits are probably delivered to you on some kind of annual cycle (check your contract). This means that a 12 month amortization window is a reasonable choice. So here’s what might you do -

• Sum up all of the promotional credits that you received at a monthly granularity going back as far as you’re able. Calculate a 12 month moving average of this number OR just divide this number by 12.

• Sum up all of your costs excluding those credits at the same monthly granularity.

• Divide the 12 month moving average by the monthly cost number to arrive at the “credit discount percentage”.

• Discount your costs by that number monthly, et voila

Some visual examples, to make this a little more tangible.

Let’s say you have $600k in annual credits, and an average annual spend of $12M. That would zero out roughly 2 weeks of cloud costs, and otherwise inflate the remaining costs by approximately 5% over what they should actually be.

After amortizing that credit forward, and applying a discount percentage to your list cost you get a truer, smoother representation of the actual cost of your resources. Put another way - the yellow bars are the very spiky credits, where as the purple area is the 12 month average - 12m MA. In effect, the 12m MA is what you subtract from your monthly costs, and you put the transient credit data to the side. This resulting metric is what I call the “effective cost” around here.

To the SQL

We’ll use the GCP bill as the example here, since that’s what I’m working with. I handle this in two separate models, though you could conceivably handle this in a CTE in your GCP billing model. Ours is … voluminous, so I materialize all these queries as tables in DBT.

WITH source AS (
    SELECT
        invoice.month AS invoice_month,
        seller_name,

        -- The base charge before any credits are applied
        cost,

        -- Promotional credits only (annual service credits, BDR credits, POC credits, etc.)
        -- These are the lump-sum credits we want to smooth out via amortization
        (
            SELECT SUM(CAST(amount AS NUMERIC))
            FROM UNNEST(credits)
            WHERE type = 'PROMOTION'
        ) AS credit_promotion_amount,

        -- All other credits (CUDs, SUDs, discounts) — kept separate because these
        -- reflect real negotiated pricing and should NOT be amortized away
        (
            SELECT SUM(CAST(amount AS NUMERIC))
            FROM UNNEST(credits)
            WHERE type != 'PROMOTION'
        ) AS credits_total_less_promotions

    -- GCP billing export is pinned (each row lives in exactly one partition),
    -- so a plain full-table scan is correct — no deduplication needed
    FROM `your-billing-data.table`
),

monthly AS (
    SELECT
        invoice_month,

        -- Flip to positive: credit amounts are negative in the export
        ABS(SUM(COALESCE(credit_promotion_amount, 0))) AS monthly_promotional_credit,

        -- Operational cost = what we'd pay Google without any promotional credits.
        -- Formula: cost (net of all credits) + non-promo credits added back
        -- = gross cost minus only the CUD/SUD/discount credits = pre-promo spend.
        --
        -- Third-party sellers (Marketplace) are excluded because they
        -- never receive promotional credits, so including them would dilute the
        -- discount factor and make it look smaller than it really is for Google spend.
        SUM(
            CASE
                WHEN COALESCE(seller_name, 'Google') = 'Google'
                THEN cost + COALESCE(credits_total_less_promotions, 0)
                ELSE 0
            END
        ) AS monthly_operational_cost

    FROM source
    GROUP BY invoice_month
),

final AS (
    SELECT
        PARSE_DATE('%Y%m', invoice_month) AS invoice_month,
        monthly_promotional_credit,
        monthly_operational_cost,

        -- Rolling sum of promotional credits over the trailing 12 months
        SUM(monthly_promotional_credit)
            OVER (ORDER BY invoice_month ROWS BETWEEN 11 PRECEDING AND CURRENT ROW)
            AS promotional_credit_trailing_12m_total,

        -- Amortized monthly share: always divide by 12 (not the actual window size)
        -- so that early months with a partial window aren't over-weighted
        SUM(monthly_promotional_credit)
            OVER (ORDER BY invoice_month ROWS BETWEEN 11 PRECEDING AND CURRENT ROW)
            / 12.0 AS avg_monthly_promotional_credit_trailing_12m,

        -- Sanity-check: amortized credit as a % of that month's operational cost
        ROUND(
            SAFE_DIVIDE(
                SUM(monthly_promotional_credit)
                    OVER (ORDER BY invoice_month ROWS BETWEEN 11 PRECEDING AND CURRENT ROW) / 12.0,
                monthly_operational_cost
            ) * 100, 4
        ) AS promotional_credit_pct_of_operational_cost,

        -- The multiplier to apply downstream:
        --   amortized_cost = operational_cost * credit_adjustment_factor
        -- A factor of 0.91 means ~9% of gross spend is covered by amortized credits
        ROUND(
            1 - SAFE_DIVIDE(
                SUM(monthly_promotional_credit)
                    OVER (ORDER BY invoice_month ROWS BETWEEN 11 PRECEDING AND CURRENT ROW) / 12.0,
                monthly_operational_cost
            ), 6
        ) AS credit_adjustment_factor

    FROM monthly
)

SELECT * FROM final
ORDER BY invoice_month

And the entire routine, including the preceding query as a CTE:

WITH amortization AS (
    -- Trailing 12-month average of promotional credits as a fraction of spend.
    -- This smooths lump-sum credits (e.g. the ~$1.3M annual service credit applied
    -- every Feb/Mar) evenly across all months so no single month looks artificially cheap.
    SELECT
        PARSE_DATE('%Y%m', invoice_month) AS invoice_month,
        ROUND(
            1 - SAFE_DIVIDE(
                SUM(ABS(SUM(COALESCE(credit_promotion_amount, 0))))
                    OVER (ORDER BY invoice_month ROWS BETWEEN 11 PRECEDING AND CURRENT ROW) / 12.0,
                SUM(SUM(CASE
                    WHEN COALESCE(seller_name, 'Google') = 'Google'
                    THEN cost + COALESCE(credits_total_less_promotions, 0)
                    ELSE 0
                END)) OVER (ORDER BY invoice_month)
            ), 6
        ) AS credit_adjustment_factor
    FROM (
        SELECT
            invoice.month AS invoice_month,
            seller_name,
            cost,
            (SELECT SUM(CAST(amount AS NUMERIC)) FROM UNNEST(credits) WHERE type = 'PROMOTION')
                AS credit_promotion_amount,
            (SELECT SUM(CAST(amount AS NUMERIC)) FROM UNNEST(credits) WHERE type != 'PROMOTION')
                AS credits_total_less_promotions
        FROM `your-billing-data.table`
    )
    GROUP BY invoice_month
),

billing AS (
    SELECT
        PARSE_DATE('%Y%m', invoice.month)                           AS invoice_month,
        seller_name,
        service.description                                         AS service_description,
        sku.description                                             AS sku_description,
        cost,
        (SELECT SUM(CAST(amount AS NUMERIC)) FROM UNNEST(credits))
                                                                    AS credits_total,
        (SELECT SUM(CAST(amount AS NUMERIC)) FROM UNNEST(credits) WHERE type != 'PROMOTION')
                                                                    AS credits_total_less_promotions,
        cost_at_list
    FROM `your-billing-data.table`
)

SELECT
    b.invoice_month,
    b.service_description,
    b.sku_description,

    -- What Google charges before any discounts
    SUM(b.cost_at_list)                                             AS list_cost,

    -- What we actually pay after CUDs, SUDs, and enterprise discounts
    -- (but BEFORE promotional credits are applied)
    SUM(b.cost + COALESCE(b.credits_total_less_promotions, 0))     AS operational_cost,

    -- Operational cost spread across 12 months of promotional credit value.
    -- Use this for COGS and unit cost calculations.
    SUM(
        (b.cost + COALESCE(b.credits_total_less_promotions, 0))
        * a.credit_adjustment_factor
    )                                                               AS effective_cost,

    -- What actually appeared on the invoice (all credits applied, no smoothing)
    SUM(b.cost + COALESCE(b.credits_total, 0))                     AS billed_cost

FROM billing b
LEFT JOIN amortization a USING (invoice_month)
WHERE COALESCE(b.seller_name, 'Google') = 'Google'
GROUP BY 1, 2, 3
ORDER BY b.invoice_month, effective_cost DESC

The net result

Here is the result of smoothing those credits out - the big spikes are how they arrive and the purple area is how we incorporate them into our bill.

In closing

The January problem, regardless of when it visits your org, is really just a data quality problem in a finance costume. The credits and their savings are real, but the mismatch between when and how they land, and when you consume resources over the source of a year can wreck your reporting (once people actually start looking at it).

Amortization is not one they typically teach in technical curricula, but it’s a fact of life in Finance. Once you've had that conversation with Finance and gotten alignment on the methodology, you'll never have an engineering lead asking you why the numbers disappeared again.

Cloud discount instruments fall into two main categories: tactical tools available to all customers, and strategic agreements for high-volume users. Understanding both is essential for effective FinOps management, as these instruments can deliver substantial savings but also create long-term commitments that affect operational flexibility.

This guide covers the spectrum from basic reservations through enterprise discount programs, explaining how each works, their benefits, and their potential drawbacks.

Tactical Instruments: Reservations and Savings Plans

These discount mechanisms are available to all cloud customers and typically focus on compute resources and compute-adjacent services like managed databases. They represent the most visible tools in the FinOps toolkit, offering significant discounts in exchange for usage commitments.

Resource-Based Discounts (The First Generation)

AWS and Azure: Called "Reservations"
GCP: Called "Committed Use Discounts" (CUDs)

These original discount instruments work by "reserving" specific instance types or families. You commit to using a particular configuration for one or three years, with three-year commitments typically offering discounts up to 70% off on-demand pricing.

The fundamental challenge with resource-based discounts becomes apparent at scale. You're essentially managing a complex inventory matching system where thousands of virtual machines must align with specific reservation configurations. If you need to upgrade an instance type, your existing reservation becomes invalid, creating a double penalty where you pay both for the new on-demand instance and the unused reservation.

Amazon attempted to address this with "convertible reservations," but these still required constant management of both resource inventory and reservation inventory, making them impractical for dynamic environments.

Spend-Based Discounts (The Evolution)

AWS and Azure: Called "Savings Plans"
GCP: Called "Flex CUDs"

The industry evolved toward spend-based commitments to solve the inventory management problem. Instead of committing to specific instance types, you commit to an hourly spend amount for one or three years.

For example, if you consistently spend $100 per hour on compute resources, you can purchase a three-year Savings Plan that discounts that spend by approximately 50%, reducing your effective hourly cost to $50. Crucially, this discount applies regardless of which specific instance types you use, as long as your total eligible spend meets the commitment level.

The advantages of this approach are significant. You eliminate the chronic mismatch problem where you're simultaneously paying for unused reservations and on-demand instances. You're now managing a single pool of committed spend rather than hundreds of individual resource reservations. Additionally, you're free to upgrade to newer, more efficient instance types without losing your discount, which benefits both your performance and the cloud provider's hardware refresh cycles.

Payment Structure and Financial Considerations

Both reservation types offer payment flexibility that requires collaboration between FinOps and Finance teams. Most cloud providers allow you to pay zero, fifty, or one hundred percent of your commitment upfront, with deeper discounts available for full upfront payment.

The financial calculation becomes a time-value-of-money analysis. In low-interest-rate environments, paying upfront for deeper discounts makes sense. In higher-interest-rate environments, you must weigh the additional discount against the opportunity cost of tying up that capital.

If you choose partial or no-upfront payment, you'll have recurring charges equal to your commitment minus any upfront payment, billed hourly throughout the commitment term.

The Optimization Paradox

Commitment-based discounts create an interesting challenge in optimization-focused environments. During growth phases, expanding commitments is straightforward. However, when business priorities shift toward efficiency and cost reduction, these commitments can become constraints.

If you successfully optimize your infrastructure and reduce resource usage, you may find yourself paying for committed capacity you no longer need. This creates a situation where optimization efforts improve resource efficiency but potentially increase per-unit costs due to unused commitments. The key is coordinating capacity planning with commitment management to avoid this trap.

Strategic Instruments: Enterprise Discount Programs (EDPs)

Once annual cloud spend crosses significant thresholds - typically around $1 million - organizations should explore enterprise discount programs. These function similarly to enterprise sales relationships in other industries, offering deeper discounts in exchange for larger, longer-term commitments.

Comprehensive Discount Coverage

The primary attraction of EDPs is their breadth. While tactical instruments mostly cover compute resources, EDPs typically offer discounts across your entire cloud bill. This includes storage, networking, data transfer, managed services, and all the ancillary costs that accumulate in cloud environments.

These discounts are substantial - often 10-15% across everything—and stack with existing savings plans and reservations. For compute resources already discounted 50% through savings plans, an additional EDP discount can bring total savings to 60% or more off list prices.

Credits and Additional Benefits

Most EDP agreements include annual credit allocations that function like prepaid account credits. These credits can represent an additional 3-7% savings on annual spend when applied strategically. However, credits require careful management as they typically expire annually and must be consumed within specific timeframes.

The Commitment Structure

EDPs require substantial annual spending commitments, typically structured as minimum annual targets over multi-year periods. These commitments are designed to be achievable only for organizations in consistent growth mode, which aligns with the cloud provider's revenue goals but can create challenges when business priorities shift.

The total contract value usually exceeds the sum of annual minimums, creating additional financial obligations. A four-year agreement with $5 million annual minimums might have a $25+ million total contract value, effectively increasing the true annual commitment.

Shortfall Mechanisms and Their Implications

When organizations fail to meet annual spending targets, providers typically invoice the shortfall amount. However, this often functions as an accounting mechanism rather than a pure penalty. The shortfall payment is usually applied back to the account as credits, but these credits can create a problematic cycle.

Credits reduce your billed usage, which counts toward your commitment target. If you're already struggling to meet spending minimums, receiving credits actually makes it harder to reach future targets, potentially creating a downward spiral of shortfalls and additional credit accumulation.

Cash Basis Accounting and Strategic Timing

EDPs operate on cash basis accounting, meaning upfront payments for savings plans and reservations count toward annual commitment targets in the year they're paid, not when the underlying usage occurs. This creates opportunities for strategic financial management.

Organizations can time large upfront payments to coincide with challenging commitment years, effectively borrowing spending credit from future years. However, this requires careful coordination between FinOps and Finance teams to manage cash flow and ensure commitments remain achievable across the entire contract term.

Strategic Considerations and Risk Management

Both tactical and strategic discount instruments require careful balance between savings optimization and operational flexibility. The key considerations include:

Growth Planning: Commitments should align with realistic growth projections, not optimistic scenarios that may not materialize.

Optimization Impact: Consider how efficiency initiatives might affect committed spending levels and plan accordingly.

Contract Timing: Stagger commitment expirations to maintain flexibility for renegotiation or strategic changes.

Multi-Cloud Consistency: Ensure discount strategies work coherently across multiple cloud providers rather than optimizing each in isolation.

The ultimate goal is maximizing savings while maintaining the operational agility that makes cloud computing valuable in the first place.

The FinOps Open Cost and Usage Specification (FOCUS) was designed to help with the first problem by providing a common billing data format that attempts to accommodate all subscription software vendors - cloud, SaaS, you name it. More importantly, it allows you to build FinOps data infrastructure once, correctly, with patterns that scale as your organization grows. And that's exactly what we're going to do.

The Market Problem: Vendor Extraction at Scale

Before we dive into FOCUS, let's acknowledge what's happening in the FinOps tooling market.

I’d tried to avoid all that work in the intro. I went through sales loops with a couple of FinOps tooling vendors because I knew how much work it would be to build up all the expertise to produce the reporting my employer needed. They all had a pricing scheme that was a percentage of our cloud bills though, essentially an additional tax on our cloud bills just to know where to get started optimizing them. I presented that to my bosses and basically got laughed out of the room. This experience planted a seed within me, and I started building it myself.

Vendors are charging percentage-of-spend pricing to customers who are already struggling with cloud costs. It's a business model that penalizes growth and extracts more revenue as your pain increases. Of course, they’ll sing a perfectly true song that their costs vis-a-vis the amount of data they have to work with essentially grow as your cloud bill grows. But - having spent my time in the mines I can tell you that their margins are dramatically outpacing the growth of their storage and compute bills. It's predatory, and it needs to stop.

Thanks to the wonder of open source, the technology exists to build better alternatives. Open source databases like DuckDB, modern data pipeline frameworks, and standardized formats like FOCUS have matured to the point where building your own FinOps infrastructure isn't just possible - it's practical. By owning this yourself you build expertise in house, avoid vendor lockin down the road, and have the ability to mold exactly the solution that your business needs.

What We're Building Together

This post kicks off a series where we'll build a complete, open source finops visibility platform from scratch. By the end of this series, you'll have:

• Multi-cloud billing ingestion using FOCUS-standardized formats

• Scalable data pipelines built with modern open source tools

• Standardized transformations using dbt to convert any vendor format to FOCUS

• Pre-built dashboards with Metabase for immediate visibility

• Docker/Podman deployment that makes the entire platform installable by anyone with basic technical skills

• Production-ready infrastructure that costs pennies per dollar compared to vendor solutions

Each post will add functionality while documenting the architectural decisions and trade-offs. You'll see working code, real implementation patterns, and honest assessments of what works (and what doesn't).

The goal isn't just education - it's to kill the FinOps vendor tax by making the alternative so accessible that paying vendor premiums becomes indefensible.

Why FOCUS Changes Everything

FOCUS isn't a product - it's a specification that provides "guidance to cloud vendors, practitioners, tooling vendors, and the software engineering community at large" about how billing data should be structured. Think of it as the standardized schema that finally lets you build infrastructure once instead of maintaining vendor-specific transformations forever.

Here's what the architecture looks like before and after FOCUS:

The transformation isn't just about fewer ETL pipelines—it's about fundamentally different infrastructure patterns. With FOCUS, you can:

• Design data models once instead of mapping between vendor vocabularies

• Build reusable components that work across all cloud providers

• Focus on business logic instead of format wrangling

• Scale infrastructure horizontally without vendor-specific complexity

The Technical Foundation: FOCUS Schema Essentials

FOCUS defines a common vocabulary for cloud billing with standardized columns that work across all providers. Instead of learning that AWS calls something `lineItem/UsageAmount` while Azure calls it `Quantity` and GCP calls it `usage.amount` (all with wildly different units of measure, themselves another column elsewhere in the bill), FOCUS gives us a single `UsageQuantity` column.

Here’s a small sampling of some of these columns:

BillingPeriodStart # Something like “invoice month”

UsagePeriodStart # The specific time this charge was generated

ServiceName # What service generated the cost

ResourceId # Specific resource identifier

UsageQuantity # How much was consumed

UsageUnit # Unit of measurement

ListCost # Published price

EffectiveCost # Actual cost after discounts

BilledCost # What appears on your invoice

This isn't just about column naming - it's about designing your data models around concepts that are stable across vendors. When you build your warehouse schema using FOCUS patterns, adding a new cloud provider becomes a configuration change instead of a development project.

Our Technology Stack: Open Source All the Way Down

We're building this with tools that are free, performant, and designed for cloud engineering at scale:

• DuckDB - Our starting point for data processing and transformation. It's a single binary that handles massive datasets and speaks SQL fluently.

• DLT (Data Load Tool) - Modern Python framework for building data pipelines. It handles the boring parts (incremental loading, schema evolution, error handling) so we can focus on business logic.

• dbt - Version-controlled transformations that convert vendor billing formats to FOCUS. We'll build a library of transformations that handles every major cloud provider and billing format.

• Metabase - Pre-built dashboards and analytics that work out-of-the-box with FOCUS data.

• Docker/Podman - Package everything into a deployable platform that works anywhere.

• FOCUS Specification - Our data modeling foundation that ensures everything we build works across cloud vendors.

• Python + SQL - Because you already know these tools, and they're perfect for the job.

Starting with DuckDB might seem humble, but it's strategically smart. We'll prove the patterns work with the simplest possible setup, then show how they scale to production systems (ClickHouse, BigQuery, Snowflake) in later posts.

A Quick Taste: FOCUS Transformation with DuckDB

Let's see how FOCUS-first thinking changes data pipeline design. Here's a snippet that transforms raw AWS billing data into FOCUS format:

-- Transform AWS CUR to FOCUS format

CREATE TABLE focus_billing AS

SELECT

bill_billing_period_start_date as BillingPeriod,

product_product_name as ServiceName,

line_item_resource_id as ResourceId,

line_item_usage_amount as UsageQuantity,

line_item_usage_type as UsageUnit,

line_item_unblended_cost as ListCost,

line_item_net_unblended_cost as EffectiveCost,

line_item_blended_cost as BilledCost

FROM aws_billing_raw;

This same pattern works for Azure and GCP data once they're in FOCUS format. One common pattern for the transformation logic across multiple data sources.

What's Coming Next

The next post will dive into the data pipeline architecture, introducing DLT and designing the CLI interface for our FinOps platform. We'll start with AWS billing ingestion and build the foundation that makes multi-cloud support trivial.

Here's the roadmap:

• Post 2: Data pipeline architecture and CLI design with DLT

• Post 3: AWS billing pipeline implementation

• Post 4: Azure billing integration and multi-cloud refactoring

• Post 5: dbt transformations - building the FOCUS conversion library

• Post 6: Metabase dashboards and visualization layer

• Post 7: Docker packaging and deployment automation

• Posts 8+: Production scaling, cost allocation, and advanced analytics

By the end, we'll have built the FinOps platform that should have existed all along—one that treats data engineering seriously, respects your existing infrastructure, and costs orders of magnitude less than vendor alternatives.

The Path Forward

The choice is "between going fast only to go slow later, or going slow to go fast later." Vendor tools get you to basic visibility quickly, but they can't scale beyond that without vendor lock-in and escalating costs.

We're choosing the second path: building the foundation that lets you scale infinitely while maintaining technical ownership of your FinOps practice. FOCUS gives us the standardized foundation, open source tools give us the implementation power, and this series gives us the roadmap.

The FinOps vendor tax ends here. Let's build something better.

---

The code and configurations from this series will be available in the open-finops-stack repository. Star it now and follow along as we build the alternative the industry needs.

Hello readers. I am two weeks into a new job, the first time I've said that since 2016. This post will be heavy on the prose, as I have left all my data and charting capability with which to illustrate my points behind. One of my first jobs in this new role is to rebuild my powers and thus build my employers capabilities in this area. Stay tuned.

Additionally, I made the decision sometime earlier this year that the focus of my writing here would be for the technical FinOps practitioner, engineer, or data person. This is my background, and so my vocabulary and background has the greatest overlap with technical staff, not Finance staff. I will be explaining basic finance concepts in this blog that will not be useful for the finance professional, and assuming technical background that the typical finance professional shouldn't be expected to have.

With that out of the way, I present to you:

The Income Statement

Being new in a job, it’s a habit of mine to explain my point of view to my new teammates, so that they hopefully understand where I'm coming from someday. Early on my first week I explained to the overall team (I have 3 teams right now) that my mental framework for where to focus our efforts is often informed by thinking about the company's income statement. I didn't go into much detail on that.

Later, I was having a 1:1 with a member of the data team this week, an "AE" in the parlance of our times. We have a couple headcount open that we'll soon begin hiring for and I was voicing my wish to have one of the analyst hires to be focused on FinOps. Somewhere in there I said "COGS" and she said "wait, what?". We got into the structure of how the income statement works and because technical staff are often interviewed on SQL optimization techniques or how to invert a binary tree on a whiteboard, she hadn't been properly introduced to the income statement before.

Today we're going to take it high level and talk about an important topic that informs my conceptual framework for how I do FinOps. The Income Statement.

The topline

I picture the income statement as a funnel diagram. A Sankey will often be used as well, but I think the funnel maps very cleanly to the concepts from top to bottom. At the top of the statement you have your income, also known as revenue also known colloquially as, you guessed it, the "topline".

Because I work in the internet business, most of our industry's topline comes from sales of whatever our product is, or possibly professional services income from support it. If your company has investments in the form of $whatever (cash) earning interest then that'd also go in the topline section, but most of any company's revenue is going to come from selling the $thing that the company exists to sell.

Regardless of where it comes from, this is the money in at the top of the funnel. After/below this, the income statement is mostly an exercise in subtracting various categories of expenses before landing on the "bottom line".

💡 By the way, a very important point: you'll hear people say "P&L" as you work deeper into the business. Income statement == P&L. It's the same thing.

COGS, aka "cost of revenue", aka "cost of sales"

COGS is Cost of Goods Sold and I think of COGS as the sphere of my influence as a FinOps person. COGS is what it says - it's the cost of the things that are required to produce the goods or services that the company sells. You could put aside the funnel metaphor for a moment and think of COGS as the cost of the inputs required to produce the outputs that represent whatever your company sells to its customers.

In the last century this could be the cost of mining and shipping iron ore, and refining that ore into the steel that is ultimately sold for revenue. The next company in line would have the cost of the steel as part of their COGS to building the car that brings in their revenue. In the 21st century a typical company hosting products on a public cloud vendor like GCP or AWS would have (parts of) their cloud bills as the cost inputs to provide the service that nets the resulting revenue output. I'll come back to the "parts of" part later.

Other common COGS inputs are things like your support or professional services staff. Without them handling customers you don't have a sustainable business model, and so if the cost is in any way related to the function of the thing that is sold for revenue at your business, then it fairly belongs in COGS.

Below COGS - gross margin, operating costs, etc

Pull together your COGS, then subtract them from the topline and you arrive at an important metrics called gross margin. Below gross margin you subtract your operating costs - things like R&D, Marketing, Sales, and others - to arrive at your operating margin. R&D and Marketing might seem simple enough, but you'll definitely have things in your cloud bills that belong in these two categories, so you can't just dump the entire cloud bill into COGS and call it a day. "But it all lands at the bottom either way. Why does it matter whether it comes out in this section or that section?" A fabulous question that lives near the borders of my understanding of VC backed company finance.

In a nutshell, because it matters. The various major sections of your income statement are in place because they each tend to have a different relationship with scaling as revenue scales. If you are a cloud-based software provider, it is expected that parts of your operation will scale more efficiently than others as the overall business scales. IOW - as revenue grows your COGS will grow as well, but it will grow with a different slope than say, Marketing or R&D.

The average slope of these various segments within an average company in a given vertical is probably fairly well known by investor analysts, and so they will be able to model out your potential profitability if your income statement is tidy enough. They will be able to model, for example, if you have a 70% gross margin today what optimizations might take place over the next 5 years to land you at a 76% margin with 250MM ARR. These are all metrics and models they use to gauge your company's potential return on their investment.

On the other hand if you have a 65% gross margin today, how does that scale out to result in a vastly less profitable company (that they might pass on investing in)?

So, back to COGS

This is why it's so tremendously important to get the math right, and make sure that what is being allocated to COGS and what is being allocated elsewhere (we'll cover "Opex" eventually) is correct. This will be an extended conversation with your Finance team, because this analysis will require a thorough, transparent, and repeatable process of working with your cloud bills to improve tagging and visibility of the costs within them. This is why proper tagging matters in the first place. It's not just for improving the visibility of these costs, it plays a central role in proper cost allocation all the way down the line.

Zooming back out

The point of going through this is that the income statement can give you a lot of information about your company. Likely you'll need to make good friends with someone in Finance before they let you see it - it's privileged information - but I think it can tell you what to focus on as a data or FinOps person. In data broadly as well as FinOps specifically we are tasked with helping our employer better understand itself, and the income statement provides a framework for what strengths the company has that must be protected as well as its weaknesses that must be further developed. It's a very important map, without which you're missing critical information about the company you're trying to help.

However, even just thinking in this manner puts you ahead of most staff in most companies outside of Finance. After all, finance is a support function, engineering is a major driver of company outcomes.

In closing - understand the business you're in.

💡 This is largely from a previous blog, but this concept has been stuck in my head again lately, so I'm repurposing. The data warehouse that I mention up top is what has formed the foundation of my employer's FinOps visibility effort.

Not sure if I mentioned this in the last post, but what I’m doing right now is essentially building a data warehouse for my employer. It’s from scratch, there was effectively nothing here beforehand, so I get get to/have had to chose everything from the tech stack to the processes to my favorite part of late: naming things.

The name you give to a piece of software, or a command line flag, or a column in a database is an act of asynchronous communication with another human. You are asking them to care about the thing you’ve built. If they chose to work with your tool, you are asking them to understand the choices that you made in its design.

The most selfless thing you can do is think about how much effort it takes for the user who did not design the thing to understand how to use the thing. Name things according to what they are and what they do, make it intuitive. This is what design is. It’s not the parts that most people will never see, it’s the parts that most people will only see.

Where this fits into a FinOps context - and I've probably written about this here before because it's not a new concept to me - is that huge part of the early job of FinOps is taking AWS's terminology and vocabulary and translating it into that of your company. This is how you get engineers to pay attention to costs, by making it easier for them.

All those tags you have on all those resources - make it easy to query them by hoisting the important ones out to their own column. Make the default view of the billing data do this automatically, create a SQL view that performs this drudgery. Are there inconsistencies in the data, different spellings of what should be the same segment of data? Normalize them in that SQL view. This all makes it easier for the person after you to hunt down 1 name, rather than 3 or 300.

The more care you take in naming these constructs that you're unearthing, the more immediately effective they'll be to the person you ultimately want to engage with them.

This is all data work, and the iron triangle that I look at with data work is fast, cheap, scalable.  You're (presumably) trying to get to square 1 of visibility of your spend.  3rd party tooling vendors can get you to square 1 pretty fast but I haven't seen one that I'd consider cheap yet.

Once you get to square 1 though, you are going to see squares 2 and 3 and 4, and that is where I don't feel any 3rd party tool can provide for real scale.  What I mean by scale is connecting it to the other data you will find lying around your org that will enrich the cost data and allow you to take the practice far beyond square 1.

Some more mature tooling vendors will point out that you can import custom datasets in their platform and essentially turn their platform into your personal data warehouse, but consider the time you'll spend building all of that into someone else's platform.  Think of the vendor lock in, and how much those add ons cost.  Also, the speed that you paid for up front is long gone by that point.

Conversely, building your own visibility takes time up front but beyond square 1 the velocity can be so much faster.

So really it's a choice between going fast only to go slow later, or going slow to go fast later.  Don't discount the importance of optics in the early stages of the practice. You have to deliver some wins early in order to build trust and gain more buy-in. This is just a POV from a few years past where you are now.

Even if you buy a tool to deliver some wins early, only sign a 1 year contract and never stop thinking about how you might replace that tool when you need to. Never stop improving the underlying data quality. Never lean on a product feature that lets you shortcut improving the data quality - tagging, specifically.

Building your own may be a luxury some of us can't afford at all times, but I'm convinced it's the only way forward for most companies.

Hello reader. My employer has been in rightsizing mode lately, and I've participating more in that exercise than ever before. As you probably know I'm a data person, and I believe very strongly that the practice of FinOps is a data-heavy practice. I'm continually learning new tricks and lately I'm getting around to the "story telling" portion of a well-rounded data practice. Let me illustrate...

Opportunity knocks

Not terribly long ago we launched a new product feature that allowed us to target development resources that hadn't been used in a few weeks and "power them down" on behalf of our customers. They could power them back up as needed of course, but this had the overall effect of reducing compute usage across a certain tier of our VMs by about 30%.

The chart above shows total CPU time allocated by our container orchestration framework. The underlying VMs are still there, just working that much less. In theory we can remove that much compute capacity from our system, but here's where things get complicated.

At that exact point in time, we were launching a major new product line. The entire engineering org was tied up in shipping this new product line, and this new product line also came with some interesting (and still in flux) changes to the compute profiles that we'd be selling. Nobody had the bandwidth to contemplate what all these competing priorities meant for each other, so we just focused on the hard deliverable and decided to leave this for later. Time goes by...

New product line gets launched, life stuff happens, nobody's fully "in charge" of this capacity planning routine, and the optimization that we made last year also more or less broke our old (clearly not mission critical) reporting. Boss gives me an assignment to rebuild this reporting, what we colloquially refer to as "the overcommit reporting", so that we can start to trim the fat in the system.

to the data..

Our previous iteration of the overcommit reporting gave us the ratio of sold/allocated capacity to actual capacity. Without going into all the details, this ratio is very important for both profitability and the experience of our customers on our platform. We've always taken an approach informed by experience but not necessarily by hard data, and so I've had a hunch that our understanding of this topic wasn't as well developed as it should be.

After some experimentation it occurred to me that the ratio we'd been watching all these years was more of an output metric - it's the outcome we want to watch. The input metric should be something closer to the customer experience - at what point does overcommitting a VM start to noticeably affect performance of our customers' applications? This is one of those topics that sounds really obvious but from my experience, the process of building up the data ecosystem and literacy within an existing company is anything but obvious. This was the real job.

Let's get our hands on the VM usage and utilization data and understanding loading of our platform regions around the world.

Well, as FinOps practitioners, and for as much as we talk about "rightsizing" as being one of the core activities, it's amazingly difficult to get your hands on the proper usage data. Take AWS. The service at play is Cloudwatch. It's not free, and the UI is pretty Byzantine (to me). I have tried to query for all machines of type $whatever in a given region and this is what they give you.

This assumes that you even have access in the first place, which you might not. Also, if you're a multi-cloud shop you already know the pain of learning multiple billing consoles. The pain of learning multiple cloud vendor metrics consoles is equivalent.

I'm very lucky to work in a shop that collects our own cloud-agnostic resource metrics in a central location - BigQuery. Over a couple days I built out a POC of a system-wide infrastructure monitoring setup in Metabase, our BI tool.

💡 One nice thing about SQL in general is the ability to define custom metrics over arbitrary slices of our infrastructure. I start playing with a metric that I call the "heat index" that's essentially a function of the average CPU load across several machines + the Std Dev of CPU load across those same machines. This gives me an idea of how heavily loaded the machines are on average, but also the spread between hottest and coolest machine. A wider spread indicates an unbalanced load.

So one weekend I search "dense time series visualization" and lo and behold, I discover the door to a whole new level of data analysis. I get started on Monday and within a few hours I have a working prototype of a "heatmap" visualization. Let's compare two visualizations of the exact same data. First is a line chart of CPU utilization over 15 hosts worth of data.

So I'm pretty sure this tells me that the region is happy, but I'm not sure how this tells me whether we have too many machines in the region. It looks like the average is between 20% and 40% utilization, the max on the Y axis is 45%. There's a spike up to 50% for one machine for a minute but this does not tell me a story. It most certainly does not tell our engineering and operational staff a story. Let's look at this data another way and see if we get somewhere.

So I shared this with my coworkers in the infrastructure team and within a very short amount of time, we'd begun the plan to reduce some of this capacity where the chart above shows we clearly have some extra to spare. This heatmap viz gives each VM its own row, and I have the ability to manually set the scale between 0% and 100% utilization. Every line chart out there is going to default to setting the scale between min% and max%, which our human brains just don't interpret as cleanly as this heatmap above.

Now, if I may, this is how you FinOps. You don't go to your operational teams and talk about "rightsizing" and why it's important. From their point of view the system is functional which means the customers are happy and they are not getting yelled at and they are not at all wrong. Most infrastructure observability tools are open source, off-the-shelf and setup by operational staff with a few extra hours. They rarely have the time to keep going after they solve their first set of problems, which is how our observability sat for some years.

In chart number 2 though, it's quite clear that we have excess capacity and we can safely shed a few machines. Take them this and everyone can see in an instant that in some places we have an excess of capacity.

The wrap

The more I do it, the more I'm convinced that FinOps is a very specialized, very important BI and Data Science role. The more data access you have as a practitioner, and the more you understand the underlying data terrain in terms of cloud infrastructure, and the more skill you have with extracting insights from all that data, the more you can be useful to your engineering teams. I have other charts that allow us to visualize utilization across the entire fleet, 18 regions worth of 6-8 different machines types, with 3-24 machines of each type. Hotspots - and excess capacity - have never been this easy to spot.

The end result of this work is going to be a relatively tremendous amount of cloud savings, because we can see more clearly.

Get your hands dirty.

💡 Number 2 in a series on Cost Allocation. The first post on data and tooling can be found here. In this post we'll start to get into the nitty gritty, starting with unifying our cloud bills according to the FOCUS spec.

There will be a lot of diagrams in this series, because there are so many steps in this overall pipeline that it's impossible for me to understand them all without being able to visualize the flow between them. For the most part each post in this series will focus on 1 major step in the cost allocation pipeline. Let's start with the very highest level conceptual overview of the job.

Company overview

sankey-beta Cost of Goods Sold aka COGS,Customer A,1 Cost of Goods Sold aka COGS,Customer B,2 Cost of Goods Sold aka COGS,Customer C,5 Cost of Goods Sold aka COGS,Customer N,3

My employer is a B2B and B2C product company. We are a midsized company of about 300 employees and we have customers. We don't have internal business units to which we chargeback cloud hosting, rather our customers run their (typically web-facing) workloads on our platform and we handle the infrastructure for them. They never see the underlying cloud bill, and are free to totally ignore which cloud vendor is actually hosting their workloads.

⚠️ Note: The better you understand the technical architecture and the architecture of your company from the business perspective, the better your cost allocation routine can be. Ideally, the end result will be able to inform strategic discussions on the cost and revenue sides of the business, i.e. engineering and everyone else.

Product line overview

We only have one primary product as far as our customers are concerned, and the base sellable Thing that we sell is called A Project. A Project has a 1:1 relationship with a Git repo, and we operate a platform that handles your DevOps needs for you, i.e. - you git push to us and we handle it from there.

Internally, we have two main COGS centers. The main COGS center by mindshare is the containerized hosting platform, what we refer to internally as "the grid". I like to imagine it in Jeff Bridges' voice. One of the marquee features of the platform is that any Git branch you create in your project will instantly create a new hosting environment for that branch, complete with data cloned from the parent branch and all supporting infrastructure already wired together. This means that containers come and go as Git branches come and go, and we'll account for this in our cost allocation.

The other main COGS center is simply called "dedicated". Dedicated is for customers that want significant resource guarantees for their production workloads. These dedicated "environments" are just another "deployment target" as far as our platform is concerned - a child of a Project. A project can look like this:

First problem - container allocation

Dedicated resources show up in the cloud bill and if properly tagged can be tied directly back to a project and therefore a customer. Containerized resources cannot. Any FinOps practitioner who's dealt with Kubernetes knows this problem - containers are an abstraction. Additionally, a given container can live for 5 minutes or 5 years. It can also move across hosts during the day. We'll go deep on the nuances of container allocation in this series, because there's a lot here.

Second problem - shared costs

Between the containerized segment and the dedicated segment, that accounts for 75-80% of our total hosting costs that are able to be directly tied in some fashion to a customer's workload. The remaining 20+% is shared infra, R&D, and frankly some of it is god-only-knows but it has to be accounted for. We'll go into how we spread these costs.

Third problem - credits from cloud providers, or The January Problem

This is completely hypothetical of course, but picture an alternate dimension where you have a contract with an imaginary cloud provider and that contract includes some yearly credits back to your account as part of your incentives. These credits might land all at once on an annual basis, and might materially discount the cash basis cost of your bill for the month in which they land.

This will make that month appear noticeably cheap in comparison to its temporal siblings on either side of it, and so all your cost allocation work will be operating on data that some might consider artificially depressed. We'll need to account for this and amortize these credits via some schedule, which your bill might not do for you.

Zeroth problem - multi cloud

The above are real cost allocation problems, and none of them can be solved before solving this one: we have multiple bills from multiple cloud providers. We host essentially identical workloads on AWS, Azure, and GCP because reasons. Some of those bills are in USD, some are in Euro. They all use different terminology and names for their VMs, their object storage, their network disk or block storage. We have to normalize these bills together to do anything, and for this we're going to look to the FOCUS project for guidance.

FOCUS makes this entire thing possible in the first place, since any meaningful analysis or allocation has to gather all the costs together in 1 dataset to get started. This is where we'll start in the next post - building out your unified FOCUS dataset.

💡Hello reader 👋, I just got back from FinOps X - the big yearly FinOps conference - and am feeling inspired to tackle a series that's been brewing in my imagination for quite some time on the topic of cost allocation.

Cost allocation is a common FinOps responsibility and while the methodology is particular to each business, I think the general shape of the process is probably similar enough that a few posts about our methodology might be useful to put out there.

Cost allocation is broadly about figuring out "what costs what?" in the vocabulary of your business, rather than the cloud vendor's vocabulary present in the monthly bill. It directly relates to a lot of FinOps visibility work and often builds upon previous allocation work, so let's dive in with a primer discussion on the tools that I use here to manage it all.

Prologue

A recent leg of my career path found me spinning up the data function at my current employer. We'd previously had no holistic treatment of the company's data - minimal BI, minimal data warehousing, and as a result no visibility into several business processes that were starting to present themselves as a strategic problem for the business. I'd spent the previous few years in customer facing management roles, quietly cataloging issues that somebody was going to have to solve someday when we get around to hiring a data person. At some point I started daydreaming about how I’d tackle it myself.

After multiple quarters of staring at the problem I raised my hand and asked if we could do something about this situation, officially, deliberately. They said "sure, go for it" and so I spent the next few months researching the data-tech landscape and revisiting the Kimball et al section of my bookshelf to formulate a plan.

We had some key technical pieces in place already. Google BigQuery was already being used as a semi-structured destination for some data feeds from engineering and the platform side of the business. I picture BigQuery as the bottom layer of the cake. Metabase was already installed as a BI dashboard with a MySQL database as the backend for some data pipelines pulling from our ticketing system and a few other internal sources. Metabase - capable enough to not be the top priority - is where most users will be querying the warehouse and building reports and functions as the top layer of the cake. Without turning this into a series on how to build out a modern data platform, that left us with "the middle layer" - getting all the raw data into BigQuery and then, most importantly, reshaping it to fit the business needs and vocabulary of my employer.

I didn't know how important a piece it would eventually become, but I kept seeing mention of a tool called DBT in all the data job descriptions I was checking out as part of my research. I didn't understand it on first glance, so I'll tell you what it is right now...

DBT

DBT is a framework for building out a data warehouse, in much the same way that Ruby on Rails is a framework for building out a web application. It's a set of conventions, helper functions, and supporting software bits that an open source community has collected together into a software toolkit - a framework.

In short, DBT provides tooling to help with writing SQL queries against raw data in your warehouse, and with managing the resulting tables and views. These queries are rarely finished reports (though they can be). More often they take the form of pulling together raw data from all over your warehouse into 1 location (schema), and cleaning up the data along the way.

Put more simply - you have data all over the place, and most of it is a mess. DBT helps you manage it, refine it, and document it all in one place. It also allows you to manage a large data project more like a large software project - version control, CI/CD automation, some support for testing, etc.

From ETL to ELT

If you've been anywhere near data in a business setting in the last 30 years, you've heard the acronym "ETL" - extract, transform, load, in that order. Well, the paradigm has shifted in the cloud era toward a model of "ELT" - extract, load, transform. Get the data from the source, store it in your cloud warehouse or S3 bucket exactly as it came from the source, and then transform it later.

This approach has the benefit of allowing you to change your mind about the logic in your transformations when you inevitably need to, without reimporting the data all over again. This method largely decouples the constantly evolving data analysis needs of the business from the upstream data engineering teams that are responsible for procuring the data.

flowchart TB a[Raw AWS CUR billing data in your data warehouse]-->b[DBT executes SQL statement, creating a new SQL view or table] b-->c[Your BI tool queries against this cleaned up table] c-->d d[You discover an error in the original SQL transform logic, or you learn more about the underlying data and have a better idea]-->e[You update the logic and recreate the SQL view. Note that you didn't have to reimport any data.] e-->c

DBT is the T step in ELT and you do the transforming with plain old SQL. How about a short example?

-- in models/aws_focus.sql
SELECT 
  `bill/BillingPeriodStartDate` AS BillingPeriodStart,
  `bill/BillingPeriodEndDate` AS BillingPeriodEnd,
  `lineItem/UsageStartDate` AS ChargePeriodStart,
  `lineItem/UsageEndDate` AS ChargePeriodEnd,
  `lineItem/UnblendedCost` AS BilledCost,
  ...
FROM {{ source('billing_data', 'aws_cur_raw') }}
-- this last bit is DBT code that selects the aws_cur_raw table from
-- the billing_data database (or schema).  More on this later.

Suppose you've already done the work of ingesting your AWS bill into your data warehouse. If you finish this SQL statement above with all 43 columns in the current FOCUS spec, you can do dbt run -s aws_focus and DBT will execute this SQL against your data warehouse and create a SQL view - essentially a pre-written SQL query that functions just like a virtual table - that you can query with your BI tool. Congrats, you have just reformatted your historical AWS billing data into the FOCUS spec without any new data pipelines, and without breaking your ability to query historical billing data.

I'll have a lot more cool examples in the next post.

Ok cool, but ... why?

As I have said elsewhere in this blog - it is my opinion that the data part of FinOps is a specific domain of business intelligence, BI. BI done correctly benefits from the additive effects of being able to connect disparate data sources together to derive insights that a single data source alone might not make obvious.

Data and BI become more valuable as you are able to connect together more of your company's data.

If you are able to manage your cloud billing data in the same place as, say, customer support requests, or Stripe transactions, you are more able to build an automated, holistic picture of your company's operations. It's work, but it's possible to build data products specific to your business that no 3rd party FinOps tool could ever accommodate. Even the very best 3rd party tool is going to reach the limits of its capability to integrate with your business' data, and when you reach that limit, you'll be exporting data to a spreadsheet all over again.

Moreover, you likely already have some of these pieces lying around at your company already - a BI dash connected to a data warehouse, for example. That's several sales cycles, procurement, onboarding and all the rest of the baggage associated with a new tool that you can refocus on getting to work on your specific set of questions.

Lastly, if you go the path of technical ownership of your FinOps visibility effort, you will gain unparalleled subject matter expertise and true mastery over the data that forms the foundation of the entire practice of FinOps.

In closing

That's it for today, the next post will be more specific examples of the possibilities of bringing an open source tool like DBT to your FinOps data - we're going to implement the FOCUS spec in SQL.

I attended the FinOps Roadshow in New York back in the late winter, and FOCUS was a large topic. Talking to my friend Dann B after the thing, it became clear that for as much buzz as there is around FOCUS, it's ironically unclear what the deliverable of this project actually is. I hope to bring some clarity here.

The Problem

Billing data is all over the place.

All of these fabulous toys in the technology market generally and the cloud computing market specifically cost money. I don't know how many hundreds of billions of dollars a year it is, but it's probably in the 12 figures order of magnitude.

All of these toys that cost money have to bill their customers, and each of those bills must be legible, auditable, and understandable by the customer who's expected to pay them. This means ultimately that cloud billing is not like a receipt from a grocery store - a finished product you can scan over in 20 seconds - and more like a data source upon which you might build your own reports of the activity within it.

As this whole market has matured and the quantity of billers and the magnitude of their bills have grown, it's become its own job just wrangling and understanding all of this billing data. This may form the largest expense that your company pays, after all. Wrangling and understanding the billing data is one of the fundamental FinOps motions, so that we may facilitate the understanding of our business partners in Finance and Engineering about how to, y'know... make our money go farther.

It's gets knotty though, because every vendor has their own format, delivery method, and vocabulary for their bills. It's almost as if the eventual billing data is NOT the first thing on the engineering team’s mind as they work through the product engineering lifecycle! So begins a mad scramble to figure out a billing format, without the time to consult outside sources or the market in general.

Solution

A common vocabulary for billing data

FOCUS - FinOps Open Cost and Usage Spec - aims to reverse engineer a common billing interface from a handful of pre-existing implementations, namely the major public cloud service providers - AWS, GCP, Azure, Oracle. Put simply, FOCUS is a common vocabulary for billing data. The exact format of each vendor's bill is different, but if you spend time looking at them and understanding their structure you start to see patterns:

• An invoice period, or billing month

• A timestamp for the beginning and end of some period, during which usage of a resource is measured

• A column or two that tell you the SKU, and maybe give you a human readable description of it

• Some columns about usage quantity, and what unit of measure is that usage reported in

• Some columns that tell you the unit price for that SKU

• Another column that multiplies unit price (P) by quantity (Q) to arrive at the cost (C) of that line item.

• User added tags, credits or discounts applied, additional columns describing the service, etc, etc, etc

While there is a lot that is conceptually the same, getting to know just the structure of a cloud vendor's bill is such an enormous job that literally dozens of competing vendors in the FinOps tooling space have sprung up to make it a little easier, especially for customers who utilize more than 1 cloud vendor. A big feature of all these tools is that they will normalize your various bills in some way that allows you to visualize and report on more than 1 at a time.

Into this space steps the FOCUS project, to provide guidance to cloud vendors, practitioners, tooling vendors, and the software engineering community at large that says:

❗Hey, this is a billing format that a LOT of us have gotten together on and discussed and hashed out over the last couple years. We’re pretty confident that it can address almost any billing usecase in the cloud or SaaS market. How about you provide your bill in this format, and you'll make life that much easier for the people who actually pay your bills.

What FOCUS is not

FOCUS is not a product. It does not do anything in and of itself. It's a very intriguing idea to many of us that have to wrangle data, but I answered several people's questions at the FinOps X conference last week about "How can I use it?". I'll be answering that question here in greater depth for quite a while, so stay tuned.

The Finoperator John Grubb

The metrics I have are reporting from Ceph, which is a pooled storage solution that includes replication etc etc, so that the amount of EBS you buy from AWS - say 1024GB - is not what you'll have available to use in Ceph. If you configured Ceph to run with 1 replica then your available storage from that 1024 would actually only be 512GB (tremendously simplifying here).

So, like all things, I turn to my bill to see what it has to tell me about the amount of storage that we've purchased for this $segment.

Now, I logged in to the AWS panel to verify the size of this volume to be 1024GB, so I know that's what I'm working against. My thought process is "how does 1024GB work into 33.03 GB/mo"? Typically I would think I need to multiply the GB/mo by 720 - the number of hours in a 30 day month and my goto for how many hours are in a month, more on this later - and then divide by 24 to land at the size of the volume (assuming it doesn't change). However:

(33.03 * 720) / 24 = 990 hmmm. So wait, what's 1024 / 33.03? To my surprise it's 31, which is odd, and yes there were 31 days in May but wait, what's up with June 1? Zoom out! Enhance!

Oh no. Oh no, no, no, no. Guess what 1024 / 34.13 is? If you guessed "the number of days in the month of June" you are the winner! I'm very surprised to find this out - that they daily usage the same EBS volume actually changes depending on the number of days in the month - but not as surprised as when I add the cost in...

Yes, that's right. The daily cost of your EBS volume also changes depending on the length of the month. So, to borrow a phrase, my mental model for how the world works was wrong and I must now update it. I would also like to point out again where I think Microsoft has chosen such user-friendly standards for the people who pay the bills while building out Azure. A month in Azure is not 720 hours, nor 744, it's 730, which is 24 * 365 / 12 which makes for an extremely logical and predictable experience when trying to figure out what things cost.

I'm still mid-investigation so that's all I have for now, typically if I wait until I've got it totally figured out the shock of it has worn off and I no longer feel like posting. Cheers.

I've never seen this framing before and I can't find it anywhere on the internet so that means one of two things, but here goes...

My employer operates a Platform as a Service, a PaaS. We host "customer workloads", which is to say we run their web apps and anything involved with making it easier for the people building those web apps to deliver them. I imagine that our founder (my boss) started building this platform probably the day after the concept of cgroups was announced on some Linux mailing list, that is to say - we have always been a containerized platform.

My work lately has been allocating costs (from our cloud bills on the left side) out to the tens or hundreds of thousands of containers that make use of the resources we buy (the right side), so I've been deep, deep, deep in the weeds of what resources are being allocated where. Part of the point of containerization (and virtualization in general) involves the capability to allocate more resources to $things than what you actually have on hand. An example:

We purchase a 4CPU VM from a provider, a "host". We then place containerized customer $things on that host and allocate resources to those containers. It's extraordinarily rare that all containers need to use CPU time simultaneously, and so via the magic of containers we're able to allocate a multiple of that 4CPU to the containers on that host, say 40CPU - a 10x "overcommit". We have systems in place in case a host becomes overloaded, but in general this works very, very well for web workloads. They're spiky both in the long term and the short term - big traffic waves come and go, and each individual web request often only requires a relative handful of cycles to fulfill, leaving the CPU otherwise idle. We make use of that otherwise idle time in another container.

This might surprise some folks who are not super familiar with the cloud computing industry, but it occurred to me yesterday that there's an analogy in the world of finance that's been in use for centuries and underpins essentially all of modern life - fractional reserve banking.

In fractional reserve banking, banks are only required to hold a fraction of their customers' deposits as reserves, while the rest can be lent out to other customers. This allows them to create more credit than the cash reserves they actually have on hand. Similarly, in cloud computing, virtualization technology allows providers - us, and AWS before us - to sell more compute resources than they physically have on hand.

🤔

Have you ever really thought about how it is that AWS has extra capacity sitting around doing nothing, making no money prior to you wanting to spin up a new VM?

How virtualization actually works is well covered on the internet, but to torture a different analogy - picture an apartment building where the landlord rents out your apartment to someone else when you go to work each day. They do this throughout the building, and have a very well-oiled understanding of how much "empty apartment" capacity is available at any moment to rent out to someone. That's basically how virtualization works, but the landlord is the OS kernel.

An obvious difference between the two is that fractional reserve banking is a centuries-old practice that has been codified into law and regulation, while cloud computing is a relatively new, opaque, wildly profitable market that is still evolving. However, both involve the creation of resources that are backed by the creditworthiness or trustworthiness of the provider, rather than physical assets.

In both cases, the goal is to create more value than would be possible through physical means alone. By creating virtual resources that can be sold or lent out, providers can generate more revenue and profit than they could through traditional means. However, this also creates the potential for risk and instability, as the value or reliability of these resources can fluctuate based on a variety of factors. In the cloud business, capacity planning is the very serious business of ensuring that if there's a "run on the bank", our customers' apps don't fall over as a result.

Additionally, there are varying levels of "capital reserve requirements" for the various classes of technology resources. Compute is easily leveraged, and this leverage is what I've been thinking of lately as our potential profit margin. Computing is a time-bound activity but once it completes it can move on to the next thing with virtually no penalty. Picture a cook in a diner, knocking out customer orders one after the other. Whether busy or not the cook is getting paid the same, so best to keep them busy (from the capitalist viewpoint).

Storage on the other hand is more complicated as saving state for later is its entire job. It fills up like a filing cabinet, so you have to keep excess capacity on hand lest disks reach 100%. It's possible, but a lot more specialized a practice to make use of any unused disk space. Likewise for bandwidth, as its simply like water flowing through a pipe. There is no way to make it multiply it just because its not being used somewhere else. In fact, it's all being used by definition - unused water doesn't flow through the pipe.

This is a fresh spitball session, but I can't help trying to connect this to something like Bretton Woods, whence the world decided on USD as the global reserve currency, and the platform power that has given the US ever since. Likewise, allowing the marketing teams at AWS to convince us all that "Capex bad, Opex good, nobody's running their own servers anymore" is clever and has spawned countless innovations as well as an entire industry, but bears a closer look as your company (hopefully) scales.

I am also forced to ponder the implications of building on somebody else's platform, and the wisdom and downsides of that once you've proven out your business model. To wit - if your company is too successful in adding value, if the business built in rented space is too successful, what's to stop the landlord from raising your rent? Anyway, this is fresh creative magma so tread carefully..

Until next time.

Hi there, I'm going to try to re-prime the pump with a quick thought today about the overall nature of FinOps as a profession, at least as we practice it at my employer. The background is that my teammate just got her CGEIT certification - Certified in the Governance of Enterprise IT - and is really flying up the ramp of FinOps effectiveness in the last few months.

I've been thinking for months how crazy familiar I am with the inner workings of my employer now via its cloud bills. The cloud bills, once they're really understood, are a paper trail of everything this company does that costs a fraction of a cents. All our main money makers, the growth of our customer base, our tagging hygiene practices - they're all represented in these vendors' bills. Cost of Goods Sold has become so interesting that I'm looking at publicly traded companies' quarterly statements just for fun now. I'm curious to know just how much one can learn about a company's inner workings by looking at where the money goes.

Moreover, because I'm in the interesting position of having the same workloads deployed on multiple providers, I get a glimpse inside the big cloud vendors as well. The same workloads are represented in 3 different ways, which gives you an incredible look at the internal culture of AWS, Azure, and GCP as well.

AWS - the market leader, inventing so many of these concepts from scratch.

Azure - the market follower, with the good sense to borrow what they could from AWS and to improve it in many ways for that most neglected yet still crucial customer segment, the finance team that pays the bills.

GCP - clearly not afraid to reinvent things their own way. It's resulted in some amazing innovations that don't get nearly enough press in the cloud industry in my opinion, but they were clearly built with no thought for the aforementioned folks who need to understand the billing.

So - I have so much to brain dump on that it's impossible to choose which path to walk down first, but topics marinating in my head:

• The FinOps FOCUS project, especially how it's used in my day to day work

• What GCP means when they say "reservations" and how tricky they can be

• Deriving and allocating cost models inside my employer's containerized infrastructure

• Where COGS connects to Finance

• Where COGS connects to Pricing and Product

• The primer I never had on what COGS even is

• Oh, the execs are interested in your work now...

And like a hundred more in the last 6 months, but let's see if I can crack those open first. I promise a mix of real world, this-is-how-you-get-shit-done content and not just weighty thought pieces like this one :P Thanks...

Starting a new tag called "Dancing Lessons", where we'll teach our cloud bills to do tricks you might have suspected they could do, but not known how to get them to do it.

Today we're going to get our AWS CUR to tell us all about Savings Plan and Reservation coverage in the same report.  After we're done with that, we're going to look at how calculate Savings Plan utilization to make sure we're not overpurchasing, or to quantify by how much if we've already made the boo-boo.

I'm sure you've looked at this one a few times - the AWS reservation coverage report back in cost explorer.  This is distinct from the Savings Plan report, which has the exact same shape but lives in a different tab in the cost explorer.  I find this situation a little lacking.  I wanted these two reports in 1 place, so that I could explain to our stakeholders what a job we were doing managing our discount inventory.  See, some years back we decided to stop buying RIs and go all in on SPs, so for years now we've had a blend of the two and keeping an eye on each is a thing.  This required me to write a tiny bit of SQL after understanding how these reports are put together.  

The first bit of SQL, against your AWS CUR -

CASE
    WHEN line_item_type = 'DiscountedUsage' THEN 'Reservation'
    WHEN line_item_type = 'SavingsPlanCoveredUsage' THEN 'Savings Plan'
    WHEN line_item_usage_type LIKE '%SpotUsage%' THEN 'Spot'
    WHEN line_item_type = 'Usage' THEN 'On Demand'
    ELSE NULL
END AS finops_pricing_model,

This gives us a very helpful column in our bill to slice our usage line items by the billing model they are under at the time of usage.  

I have another dimension/column that I can use to explicitly ignore Spot usage and anything not related to hypothetically reservable usage, since I don't really want to report that out in our reservation coverage reporting -

CASE
    WHEN line_item_type IN 
    ('DiscountedUsage', 'SavingsPlanCoveredUsage', 'Usage') AND (
        line_item_usage_type LIKE '%BoxUsage%' OR
        line_item_usage_type LIKE '%EBSOptimized%'
    ) THEN 'Reservable Resource'
    -- this value ^^ allows me to target only usage line items for which
    -- a discount _could_ hypothetically apply.  
    ELSE 'Non-Reservable Resource'
END AS finops_usage_class,

So here's an interesting thing, and why you should really care deeply about the data that you're managing in your FinOps practice.  The chart above shows our coverage daily for the first 3 months of this year, reporting the same way that Amazon reports it - using the "on demand" cost of the resource in question to calculate your coverage.  This method of reporting will make the coverage appear higher versus the following chart, which rolls up the exact same data but reports on a different metrics - the finops_effective_cost metric, which computes what we're actually paying for these resources.

You'll notice the coverage doesn't appear to be quite as complete, even though it is arguably giving you a more realistic version of actual dollars spent.  I want you, reader, to understand my manifesto on this point.

‼️

Whomever best understands the data in a given business area effectively controls that data, and whomever controls the data will most easily control the narrative of what that data represents.

This is why it is absolutely paramount for the FinOps practitioner to have a deeper understanding of the billing data and the technical and business processes that it represents than anyone in their organization.

Now, let's move to the counterpart - savings plan utilization.

Savings plan and reservation utilization

This is one that I'm still learning, and have only come to my current understanding recently.  My early months in the AWS bill were spent largely in the line items that represent Usage of some kind or another.  The SavingsPlan and Reservation line items were to be dealt with later.  Besides, I was able to pull out the cost of our reservations and savings plans in the amortized line item usage columns and get what I needed, but now I find myself in that uncomfortable if inevitable position of being ... overpurchased on Savings Plans.  

Firstly, you'll notice that the Savings Plan and Reservation coverage has a counterpart chart - the utilization reporting.  This is great, but I had no idea what it meant in terms of dollars if the percentage dropped below 100

This exploration was tipped off by my discovery of the savingsPlan/UsedCommitment column, while diving around in the docs.  By the way - I dive around in docs without aim a lot.  Just saying.  You learn a lot that way.  So let's start at the top, with a computed column I call Total Amortized SP cost:

When filtered to only include line items WHERE line_item_type = "SavingsPlanRecurringFee" you get the total cost of your savings plans for that time period, including the amortized upfront payments.  So this is pretty simple now, you go sum(totalSPCost) - sum(SP_used_commitment) and if you wind up with anything more than 0, you have overpurchased your Savings Plans.

Now you can do some relatively simple math to calculate your utilization percentage -

And if you plot both of those metrics together on the same chart -

So ideally you want the blue line stuck to the ceiling and no purple bars at all but here in the real world, when stakeholders start yelling at you about on demand spend as this unequivocal evil to be avoided at all costs, this can happen.  It's super helpful if you already have some reporting like this ready to show them the flip side and to help them understanding that optimizing for this one metric is rarely a good idea in life or business.  Indeed, we've been doing really good this year at strategizing about how we can start optimizing hardware inventories, and after spending Q1 getting the business about our on demand spend, now we have the opposite problem.

Fortunately, SPs are expiring on their own and bringing that overcommit number back down, but I never want to see this happen again.  I share my shame so that hopefully you don't have to.

Reservation Utilization

As you can see from the main image at the top, we chose to start moving out of reservations and into savings plans a little over 3 years ago.  Our inventory has been almost entirely converted at this point, so I don't have a lot to offer on how to monitor reservation utilization.  My hunch is that it's very similar to SP utilization though, I'll update this post when I have time to dig in a little bit.

In the early days of the automobile, aerodynamics were not a huge concern.  "Cars" were basically horse carriages fitted with outboard motors rather than being pulled by horses.  It wasn't until a little later that, as the engines became more powerful and the cars became faster, the shape of the car started to matter in many different ways.  The point of the car hasn't changed since the late 1800s, but the various optimizations on which humans are constantly innovating has not stopped ever since.

I was a web dev once.  I'd be stunned if anyone reading this hadn't heard the old yarn that Amazon once did a study and concluded that every 100ms of additional page load time cost them 1% of total sales.  You know what a web dev does the first time they hear this one?  Well, if it's 2008 or so you go and run your site through Google's PageSpeed test, an evolved version of which lives on to this day.

You know what it told you to do?  It told you to take your 400 javascript files and smush them all into one file and then maybe to do some magic called "minification" and then to GZip them all, and darned if it didn't make your site faster.  You didn't have to rewrite your site and you definitely didn't have to fuss with the functionality, you just made some optimizations to better handle how it physically travels over the wire to your customer.  The automation to handle all this has been an open source commodity for over a decade now.

We are in the early days of cloud computing, and it's analogous to the early days of many new technology paradigms.  People are just trying to get their heads around it for the most part, and transition their old ways of thinking and doing into these new tools and ways of doing.  They bring their preconceptions and previous mental models with them.  This is healthy.

This gives us simple analogies to grab on to when explaining FinOps.

💡

FinOps is performance optimization for your organization's cloud infrastructure. 

Instead of measuring network latencies or CPU or memory utilization, we're zooming out a little bit and looking more broadly at the whole system.  Which parts cost a lot of money?  Should they cost a lot of money?  How can that part be made more cost effective without sacrificing functionality for our users and quality of life for the engineers building it?

Posing the problem this way is especially effective for one of your two primary stakeholders as a FinOps practitioner - the engineering org.  Performance optimization is a fun part of the craft of building things.  Engineers typically have  all manner of debugging and profiling tools available when they want to figure out which parts of the system are (under)performant, but this wealth of tooling and visibility and awareness hasn't completely made it into the area of cloud costs yet.

That is part of our job, as I see it.  We make otherwise inscrutable billing info meaningful by translating it into the language of our engineering orgs.  Once we do that it becomes, essentially, profiling data.  It profiles the efficiencies and inefficiencies of our cloud infrastructure, and then we can start getting creative about how to make them more performant within the same functional footprint.  It allows the process of optimizing your company's cloud infrastructure to start happening on its own, without your needing to push it too much.

Happy Friday, and thanks for reading.

Bare minimum Mondays: wherein we scratch the surface of a topic to be explored further in a future post.

I was sitting around a table of practitioners recently, discussing the "vibe" of the big 3 cloud vendors - AWS, Azure, and GCP.  We all pretty much agreed that they live on a spectrum with "built for engineers" at one end and "built for the folks who pay the bills" at the other.  

<---built for engineers---------------built for finance--->

Azure is, in our unanimous opinion, built first for the folks who pay the bills.  It is the bill that I have spent the least amount of time in so far, primarily because I don't feel like I really needed a ton of effort to figure it out.  They give you two different versions of the bill - the Actual and the Amortized, and after that everything just kind of works. What things cost lives in the one and only column you'd think to look into.  

AWS lives in the middle - a world class technical feature set and obviously many years of hard won experience at play in the engineering of the CUR.

At the far end of the spectrum, in a world where engineers scoff at notions of paying for things and bean counter concepts like amortization lives GCP.

One line item, many pricing models

Whereas in the other two vendors a given line item can be said to be either "on demand" or "reserved" (or .. savings plan'd), on GCP things are a little different.  The gist is that every line has two columns that tell you the world - cost and credits.  Cost can be thought of as the "on demand" cost of the thing, and then you subtract the credits column to arrive at something like the "net cost" of the item.  The trick is that credits is what's known in BigQuery as a "repeated" field.

Because this is bare minimum Monday, I'm not getting into the details here now.  All you need to know is that multiple credits can apply to any given line item.  A line item can and will have charges associated with a CUD, or multiple discreet CUDs, of potentially different types, as well as other random discounts/credits too.

The following is therefore a very common pattern in analyzing your GCP bill.

cost
- sum(credits)
--------------
net_cost

Now, net_cost is not the "true cost" of a resource either, because you're not  yet factoring in the cost of those discounts.  We'll get into lots of specifics in future posts.

BigQuery is a fabulously capable "cloud native" data warehouse product built by our friends at Google Cloud Platform, GCP. It is the foundation of our entire data ecosystem at my current employer and my name has been on the dotted line as internal owner for a few years now. Because our FinOps tooling stack is the same as our internal BI stack, this means that BigQuery (henceforth BQ) is also the foundation of our FinOps data and visibility tooling effort as well.

We have tinkered with various flavors of controlling BQ costs since early 2022 when the Data function began to get some traction here, when we were using their standard on-demand pricing. I am here today to talk about recent innovations to their pricing model and will (try to) save historical story telling for another post.

TLDR - It's a net positive, with caveats.

The good - physical storage pricing

So perhaps you noticed this little SKU switcheroo at the beginning of this year:

This is a view from Metabase, our BI dashboard tool out of which we build our cost reporting. In early January this year, the BQ team suddenly got rid of 2 SKUs: Active Storage and Long Term Storage, and replaced them with Active Logical Storage and Long Term Logical Storage. The meaning of this wasn't explained at the time, but this was the setup for some announcements early this year that they'd be introducing a new storage class - physical storage.

💡

The summary of physical storage is that it really should be called "compressed storage" and is billed at 2x the rate of logical storage after compression.

Whereas logical storage is billed at $X/GB/mo, physical storage is billed at $2X/GB/mo but physical storage measures (I presume) the actual physical size of the data on disk after compression whereas logical must measure the uncompressed size. BQ very helpfully gives you a clue in the details page of a given table, the same section where other table metadata is displayed.

Detailed BQ storage pricing page here.

Here is a query that you can run from the BQ UI in each of your projects where you have storage enough to care about this topic. This runs at the project level, so be mindful of line 18 where you choose your region, and then probably export the results to a G Sheet for actually sharing around. So far these estimates seem within reality for us. Now to that reality.

We are one of Google's petabyte scale customers as all of our platform events flow constantly into BigQuery. Your mileage will most certainly vary, but after several months of waiting for this improvement, I am happy to report that for highly compressable datasets in BigQuery physical storage pricing is an absolute win.

The bad - goodbye to flat rate query pricing

Most of what has been marketed about BigQuery Editions is on this side of the house. They now market "autoscaling", presumably because suits with little to no infrastructure experience absolutely love the sound of that word. This is a shot from Google's internal customer marketing about what the autoscaling experience looks like:

Now, do your data warehouse workloads actually look like this? Because ours look like this:

Maybe the marketing version is over a 60 second timeframe, I don't know. The autoscaler is supposed to work in 1 minute increments, and granted we have a pretty busy warehouse, but the "capacity we're using" and the "capacity we're being charged for" do not fit each other nearly as neatly in the marketing. Possibly the granularity of this report over several hours is not tight enough to let me see the prettier truth, but to find this out I have to go build my own reporting out of the INFORMATION SCHEMA.

The capacity that we've reserved is 100 "baseline slots" with a max of 400 "autoscaled slots". I think this means that we're being charged for 100 slots no matter what we we do with them - your standard reserved capacity model - but that as the autoscaler detects whatever it detects, it will scale our billed-for capacity up to 400 slots - your standard on demand model. In other words, it is the worst of both worlds: we are back to a highly variable cost structure but with a maximum capacity cap in place that ensures that I have to care about both unpredictable costs and poor performance. In all the previous models it was either one or the other, now it's both.

And frankly, the autoscaler doesn't look very good as it autoscales your costs in a way that appears to only somewhat correlate with your actual usage per their reporting.

Here's how it's gone for the year so far:

That big middle finger on the right side? That was a Materialized View that kept failing for a week before I noticed it. If we were on demand it wouldn't even have caused that, as query failures don't register on the TB-billed side of things. It truly is a bummer. Granted, we are not doing any long term commitments yet, primarily because I have no idea how they work. You reserve in chunks of 100 slots, so does that mean that to cover my 400-max workload I have to reserve 400 slots and they are always on and we're back to flat rate pricing at a vastly higher rate? In fairness, I haven't asked our GCP reps yet but I don't know as of today.

In conclusion

The moves that the BigQuery pricing team have made this year have mostly been a net positive for us, as we are heavy users of BQ and store a lot of data there. The new physical storage pricing has been a huge savings for us, but the new Editions pricing on the compute side of the house is pretty annoying. I was blessed with being able to ignore compute costs for the most part for a little bit, but not anymore. Here's the full story from Q2 - present:

Thanks readers, and hopefully this can help some of you better understand these new BigQuery pricing changes for your org.

One of my earliest questions was “what do things actually cost?”  On demand usage was easily available in the unblended_cost column, but if I take all DiscountedUsage line items (ones that are covered by a reservation) and SUM(unblended_cost), it gives me 0.  What??

This is what I learned while figuring this out.

First, the code

CASE
    WHEN line_item_type = 'DiscountedUsage' THEN reservation_effective_cost
    WHEN line_item_type = 'SavingsPlanCoveredUsage' THEN savings_plan_effective_cost
    ELSE unblended_cost
END AS finops_effective_cost,

This is it.  It took me a while wandering in the woods to come up with this simple little case statement.  Let's dig in a bit starting at the bottom.

lineItem/UnblendedCost

The UnblendedCost is the UnblendedRate multiplied by the UsageAmount.

Gee, thanks.  Look, as simply as possible – this is the first column you're going to get to know in this bill when you're first introduced into this job.  If you sum this column up for the entire month, you're going to get a number that matches what the Cost Explorer says you spent that month.  

This number is the number that matters for basically all usage costs except those to which a reservation or savings plan apply.  That is to say – storage, data transfer, anything except those where line_item_type IN ("DiscountedUsage", "SavingsPlanCoveredUsage").

lineItem/LineItemType

For those line items, they've set aside several special columns.

reservation/EffectiveCost

Things get hairy, fast.  You're 30 seconds into my first nuts and bolts post, and we're going to talk about amortization already.  Amortization is actually pretty simple, as are many previously inscrutable finance terms when you learn what they mean.

💡

Amortization is an accounting technique used to periodically lower the book value of a loan or an intangible asset over a set period of time. Concerning a loan, amortization focuses on spreading out loan payments over time. When applied to an asset, amortization is similar to depreciation.

source - Investopedia

Amortization in our case means - we paid a lot, say $360,000 upfront for a 3 year reservation, but since we're using that over a 3 year period, our business is going to be using $10,000 of that reservation a month.  This is amortization.  It takes the otherwise huge swings in your company's expenses (in cash basis accounting) and smooths them out a little (into accrual basis accounting).  More here.

So – AWS helps you out a little with this.  We'll get into the SavingsPlan and Reservation line items in a future post, but we're talking about usage line items for which a reservation is applied here.

There are two components to reservation covered usage:

• The amount that you paid upfront, aka the upfront fee

• The amount that you didn't pay upfront, aka the recurring fee

The recurring fee is pretty simple – you get charged for it every day of the term of that reservation.  It recurs.  The upfront fee is more interesting.  That's the big thing you bought at the beginning of the term.  While you could theoretically account for that giant upfront fee in the month you paid it, your Finance team is almost certainly handling it by amortizing it over the term of the reservation.

AWS helps you by taking that upfront fee and amortizing it for you as well, daily.  For a 3 year reservation with an upfront payment of $360k, they will count up the number of days in that 3 years – either 1095 or 1096 if there's a leap year – and divide 360,000 by that, roughly $330/day.

💵

Important to note – your Finance department probably does not amortize these upfront payments daily, and so your amortized numbers for February will always be lower than January or March, whereas Finance's might be equal payments each month. This is why.

Now here's where it gets really fun.  AWS takes that $330/day and makes it available in a couple of places.  One place is in the RIFee line items in the bill.  Each day you get a number of line items that pertain just to the Reservations, not the actual usage line items.  These are ones where line_item_type = "RIFee". (docs).  In those line items you have the amortized upfront payment for that day and that's pretty much it.  

The “recurring fee for usage” shows up elsewhere - in the usage line items that benefit from the reservation.  This is a little strange to me, but the docs here seem to confirm this: the amortized upfront stuff appears in the RIFee line item, the recurring costs do not.  recurringFeeForUsage docs – it only shows up in DiscountedUsage, the usage line item.

This is a lot, I know, so let's review.  You have:

• amortized upfront reservation costs available in the RIFee line items.  

• Those same costs allocated down into the usage line items that benefit from them.  And finally,

• The recurring cost for that reservation (if not fully paid upfront) that shows up in the usage line items as well (DiscountedUsage, that is).

Now, you can do it yourself but AWS takes those two columns in the DiscountedUsage line items and adds them together to arrive at what we call the “effective cost”.  Effective cost is the amortized upfront cost + the recurring cost.

• AmortizedUpfrontCostForUsage

• + recurringFeeForUsage.

• = effectiveCost  This is the true cost of that resource (according to AWS' daily amortization schedule).

WHEN line_item_type = 'DiscountedUsage' THEN reservation_effective_cost

savingsPlan/savingsPlanEffectiveCost

The same basic logic applies to Savings Plans, but we can get into the nuances here in the future.

WHEN line_item_type = 'SavingsPlanCoveredUsage' THEN savings_plan_effective_cost

In closing

This took me a while to figure out, so hopefully this can help make it a little bit clearer for you as you're learning your way around the CUR.  This “effective cost” column is one that we use here to present the “true” cost of resources that we use for a given billing period.