#1: An accurate AWS budget reflects specific, predicted business demand

Let’s take a moment to think about your AWS organization and its resources. Not every AWS resource’s usage is dependent on customer usage. For instance, the QA environment has zero interaction with customers.

Yet, most AWS budgets are produced by taking a dollar value of spend from the previous period and multiplying it by a projected customer growth percentage.

That’s ludicrous!

Yes, many of your resources’ utilization with increase with customer growth, but many other resources’ utilization growth will be dependent on different operational variables. Applying a single growth percentage across all AWS resources does not reflect your actual usage of AWS and will create erroneous projections.

Let’s imagine some examples. For example, while the rate of data transfer charges in your production environment increases at a direct rate proportional to your customer count, the usage of on-demand QA testing environments (and all the resources therein) will likely increase as you bring on more QA specialists to the team. And unless you scale dynamically using elastic load mechanisms, much of your EC2 server usage is likely fixed at a set number for your current load, but this will likely need to grow once a threshold business event of customer scale or development operations has passed.

A proper annual AWS budget must create models for spending increase based on the historical usage of each of these resource types in context with the relevant sales or operational growth goals that are projected for that same year.

We describe this process in Chapter 3: Build a world-class AWS operating budget using historical spend analysis if you would like to jump ahead.

#2: A comprehensive AWS budget includes all costs of new initiatives required to meet revenue projections

When the time comes for annual budgeting, your colleagues in sales and marketing are forced to step up and claim responsibility for booking specific revenue numbers for the company – and often times those numbers come from expectations of the release of certain high-demand features or regional expansion, all dependent on engineering meeting its own projections.

(While tangential to this guide, hopefully, this gives you more context for the rage you sometimes receive from sales leaders when huge issues with a project are revealed and the release needs to slip.)

The thing is, while revenue-side budgeting often takes into consideration strategic initiatives, rarely do we see cost-side budgets that balance these initiatives with the commensurate cloud computing resources required to develop and support the ongoing customer usage.

“Not so!” a CFO might say, “We calculate cloud computing cost growth as a percentage of revenue growth!” Well, we all know that the sales team should never sell a product that hasn’t been built yet. The product has to be built and running before anyone can use it and pay for it. As we know, there are a lot of costs there. Not to mention the fact that new products and features will be built on new infrastructure whose cost basis is not known until architecture is complete.

This obvious, glaring omission in the standard budgeting process can result in tens of thousands of unplanned spending, so much so that new initiatives often get shut down before launch due to overspending on unbudgeted line items.

We describe the forecasting process in Chapter 4: Make future plans a reality with well-modeled budget additions if you would like to jump ahead.

#3: A rigorous AWS budget is divided by business purpose

This point is critically important, but often unknown to engineering leaders, so we’re going to break down this issue rather extensively.

First, it’s important to know that a budget and the corresponding income statement (often referred to as a product & loss statement or P&L) are the ultimate financial scorecard of a company’s business efforts. To a financial expert, the departments and functions receiving more funds are perceived as higher priorities for the company, while the departments and functions that spend more than budget are those that need operational improvement.

The suite of corporate financial statements produced by your finance department are the means by which investors and leadership evaluate your company. They drive stock prices, valuations, and sizes of investment checks. They represent the future opportunity of your company, and ultimately drive the opportunities that will come your way as an executive.

Importantly, not all of a single department’s spending gets recorded in the same place on your income statement (or, as you may have heard it said, it doesn’t always ‘hit the P&L’ in the same place). That’s because its business purpose is different.

Any spending that is required to deliver a service to your customers hits the P&L in the ‘cost of goods sold’ (also known as the ‘cost of revenue’ or COGS) section. By assigning spending to COGS, the finance team is stating that the customer could not receive the service they paid for without the company spending this money.

You might wonder how this applies to AWS budgeting? While AWS is a single vendor, sending you a (hopefully) consolidated bill for a single amount due each month, the business purposes of AWS always include development, testing, and production, and for many organizations may also include data analysis for market research, sales demonstrations, customer support issue handling and others in their list of AWS business purposes. Each of these purposes carries a different weight of importance in analyzing corporate financial health.

Because of this wide variety of business purposes served by AWS, finance teams should divide up (or ‘allocate’) AWS spending to the appropriate accounts in both the budget projections and the actual P&L reporting.

Sounds complicated? It gets worse. Many finance teams without experience in cloud computing assume that the full AWS bill is attributable to your production environment and no other business purpose.

The impact? Your investors believe that the entirety of your AWS expenditure is required to deliver your software experience to your clients and your company valuation is driven illogically lower than its actual value without any actual change to your business operations or behaviors.

We describe this process in Chapter 3: Build a world-class AWS operating budget using historical spend analysis if you would like to jump ahead.

#4: A final AWS budget is reverse-engineered for appropriate monitoring

When all is approved for the upcoming year and your CFO returns a copy of the approved budget to you, your company’s annual budget will include an amount of AWS spending expected for each month. It may be broken up into different business purpose categories if the budget meets the requirements in item 3 above, but this doesn’t tell you enough information. As a result, you aren’t at the end of the AWS budget process.

How will you know if you’re staying true to your budget plans during the course of the year?

Let’s say you set your monitoring at the top level, tracking and alerting against an overall budgeted amount for your consolidated AWS bill on a monthly basis. Doing so could hide out-of-budget performance in specific areas of your organization. The more complex your AWS organization and business operational structure, the higher the risk of masking concerning variances in subgroups by monitoring a simple monthly total.

An accountant might suggest that if you’ve accomplished the proper allocation of budget across financial accounts like we mentioned above, you naturally have broken-down numbers easily tracked individually. Clearly, they aren’t familiar with typical AWS organization configurations.

Let’s face it, your account and tagging structure currently reflect the engineering team’s perspective of your company’s operations. Resources are divided up by the teams who need them, not by accounting allocations set by finance – nor should they be!

To get AWS budget monitoring right, it’s the engineering leadership’s job to work with the final numbers from finance and work backward to apply them to trackable AWS account and/or tagging engineering organizational models.

Only after this has occurred are you ready for automated cloud cost monitoring through AWS Budgets, Aimably, or another third-party tool. We describe this process in Chapter 6: Guarantee on-budget performance by implementing these 7 processes if you would like to jump ahead.