Put all future projects on the table

At the conclusion of Chapter 3: Building a world-class AWS operating budget using historical spend analysis, you might think your draft AWS budget for the next fiscal year is complete. Certainly, if you plan to make no changes at all to your AWS infrastructure, that could be true. Yet, a robust AWS budget must include all future spending anticipated from new projects as well. That means you’re not done yet.

Which projects should be considered as additional costs in your budget? Clearly, any new products and feature initiatives expected for the year must be considered. Additionally, and somewhat less obvious, all infrastructure plans should be considered. Perhaps you might have a ticket in your backlog that recommends introducing a new service into your infrastructure (such as a caching database, for instance), or maybe your sales engineering team wants to migrate their workloads to AWS? These efforts need to be reflected in the comprehensive AWS budget as well, lest you discover yourself saddled with unplanned cost increases.

Your responsibility, as the architect of the AWS budget, is to capture each of these initiatives independently, scope out their monthly cost impact and chart them onto the total AWS budget for consideration by the full executive team. Doing so will allow the team to greenlight certain initiatives while pressing pause on others, especially once the revenue impact of these projects is well understood.

Before constructing the cost models, you must review the known company-level proposed strategic initiatives (remember we mentioned this back in Chapter 2: Beginning budgeting for CTOs, not dummies?), gather potential engineering department-level architecture initiatives and search out any AWS-impactful initiatives in any other department with access or interest. Leave no stone unturned, as the addition of an unbudgeted project to your AWS bill can spell future cost-cutting for your core projects.

Create a practice of architecture consultation

Look, if you need an estimated infrastructure cost for each upcoming project, we could throw a number at the wall for fun to see if it sticks. Or, we could develop an educated estimate based on a series of assumptions. And if you really need an educated basis to estimate from, the architects on your team need to get involved. In fact, the only way to actually model the cost of any upcoming project in AWS is to form an opinion on how the project might get built.

This is not to say that the implementing team six months from now is required to build the project exactly to meet the specifications proposed by your architects during the budget cycle, but it is to say that final architecture decisions can and should be evaluated for their cost impact in comparison to the architecture direction selected in the budgeting process.

It’s time to introduce an architecture consultation phase into your budgeting cycle, where you set aside the proper ideation and discovery time for your senior architects to serve the needs of all proposed projects prior to the submission of a draft AWS budget. During this dedicated period, architects can take the proper time to understand the business demands of the proposed solution and translate this into infrastructure solutions that can be priced into a real model, taking into consideration proprietary AWS services that can be leveraged, overall compute requirements, storage techniques, and expected traffic and load.

From these technical proposals, you can leverage the exact same techniques of dividing usage demands into fixed, expandable, and scaling categories as you did in Chapter 3: Building a world-class AWS operating budget using historical spend analysis. You’ll use these to overlay expected customer usage into real data inputs.

Don’t forget development demands

Most software companies do not regularly budget for the infrastructure expense to build a project, focusing simply on the costs of operating it once it is revenue-generating. While there exist whole industries (like pharmaceuticals or aeronautics) devoted to years of million-dollar spending before any product reaches the market, with such comparatively short development time cycles, rarely do software companies properly account for AWS spending during the development phase of a new project.

That being said, when you’re evaluated for your budget performance by your board and investors, I don’t recommend blaming your overspending by telling them that’s how everyone else does it. It’s really best to apply a best practice of planning for research and development infrastructure costs as part of the budget process.

If you are to properly set your team up for accurate spending expectations, it’s crucial that every new project is reviewed and estimated for the complexity of development environments and lead time. Will the project mimic the production environment exactly in infrastructure? Might it need to be even larger or smaller? For how long will we be developing and testing before the first revenue arrives?

Keep in mind that any plan estimates should be rough and should allow for the natural variation that occurs in agile development workflows. This is not a recommendation to move back towards a fully-specified, waterfall model. Yet, some sort of estimate is required in order to properly budget. A decent estimate is far superior to no estimate at all.

Establish a plan for each project, now.

The AWS Pricing Calculator is excellent, when used correctly

When it comes to your options for predicting costs for projects where a known architectural solution exists, there is no better tool than the AWS Pricing Calculator. In order to best leverage this tool to build your per-project new AWS budget inputs, we have a few suggestions for its best use.

#1: Leverage the Groups feature heavily

The AWS Pricing Calculator offers a feature called Groups, which gives you the flexibility to pull together a wide variety of cost sources and attribute them to a single project. The resulting estimates provided in the pricing calculator can therefore be sliced and diced by each project you consider, including when comparing architecture alternatives or breaking out expectations for development needs vs. production needs.

Here at Aimably, we encourage teams to consider building separate groups for different environments or regional clusters for the same project, not just one per project. It’s highly likely that each of these sub-groups may start to incur charges at different times. For example, you may plan to launch in North America six months before your European launch. A budget should reflect this.

#2: Model the first real month of load in detail

One often-overlooked limitation of the AWS Pricing Calculator is that it is incapable of predicting cost over time. That’s because it is limited to producing a single price estimate per group, based on your inputs. As a result, if you’d like to create a monthly spending budget for a proposed project, you might need to run twelve different calculations, one for each month, which can take a large project and turn it into an insurmountable one.

While AWS spending is rarely stable and tends to grow over time as influencing factors in the business (such as customer count) grow, we don’t recommend attempting to run individual models for each month. Instead, we suggest focusing your usage of the AWS Pricing Calculator on the first month of real load.

What exactly is the first month of real load? It’s one with enough usage that is similar in behavior to the intended purpose of the infrastructure. At that point, we can model what scaling usage and expanding system rates may be, and how they get influenced by operational variables. 

For example, if you intend to build a feature to direct-mail widgets to customers after they submit a form on your website, and that the feature will launch in May, with an expected 100 customers by July, we can use the July month as our starting point for estimation.

Once you have a complete estimate for the first month of real load, you can work forward using the same formulas outlined in Chapter 3: Building a world-class AWS operating budget using historical spend analysis to model future months’ usage. Similarly, you can work backward to identify the base systems in place prior to any usage at all.

#3: Include ALL sources of cost

As we mentioned above, the techniques you learned in Chapter 3: Building a world-class AWS operating budget using historical spend analysis will be critical for you to build out the full year of spending in your budget, specifically the designation of fixed systems, expandable systems, and scaling usage. When starting from scratch, your proposed architecture will help you easily assign these designations from the start.

However, it can be very easy to overlook many sources of scaling usage costs. When working with the AWS Pricing Calculator, your few initial steps are rather easy. Selecting the resource types and quantities allows you to load up your estimate group with useful information. The challenge comes from the extensive list of additional charges that might be incurred. For example, you might have an estimate for total S3 storage quantity by tier, but you must also ensure you have added costs for all request types and quantities of data returned from certain storage tiers.

Before you present your estimates, it’s important to run line-by-line through the entire pricing calculator to ensure no stone is unturned as a potential source of cost. Additionally, always remember to take another look to ensure that you’ve included all environments and regions that will be necessary over time. You wouldn’t want to arrive at the beginning of a testing phase without money in the budget for the test environment.

#4: Leave cost optimization out of the equation

It seems rather helpful that, during price calculation, AWS offers multiple methods (such as the selection of a Reserved Instance to the proposed architecture) to discount costs in the planning phase. We strongly recommend that you resist the temptation to include these discounts in your modeling at this phase.

To explain why it’s helpful to think about AWS billing as akin to a mobile phone billing structure. You can pay as you go for a higher per-transaction cost, or you can enter into a cell phone contract that offers specific flat rates or pricing structures in exchange for agreements of functional limitations. When it comes to selecting the right contract and negotiated discounts for your whole family, it simply isn’t prudent to decide on a different contract for each of the phones on your family plan. Instead, you select a single strategy that covers the aggregate usage of all devices.

Just like with the mobile phone plan, your cost optimization strategy for AWS will produce the best results for your company when you take into consideration the entire projected spending in the upcoming year, once your pay-as-you-go budget is finalized. In fact, we will go into this process in detail in Chapter 5: Select the cost optimization techniques that best suit your unique infrastructure and business goals.

Structure your budget draft for flexibility

At this stage, now that you’ve generated 12 months of budget estimates for each of your proposed projects, based on recommended architecture, customer scale impacts, and build-phase requirements, it’s time to pull together a first draft budget for your own review.

It should come as no surprise to any experienced engineer that your first draft will be extraordinarily expensive, as it contains the completely unrealistic full wish list of next year’s projects, so we don’t recommend structuring the budget as a lump sum, to begin with.

Instead, you need to be able to add and remove projects as well as adjust impact operational variables (such as projected customer count or departmental headcount) on the fly while in discussion with other executives. We suggest simplifying the historical budget from Chapter 3, as well as the various projects being added in this chapter into a single spreadsheet with dependency formulas built-in for rapid adjustment. The flexibility and recalculation time savings that an approach like this offers far outweighs the time spent to build a spreadsheet capable of making these changes instantly.