What if we told you that most organizations are making simple AWS cost optimization mistakes that lead to surprising monthly cloud bills and unnecessary overspend? As an engineer, you’d probably be relieved to know that many of your organization’s AWS spending spikes are within your team’s control, given access to the right data.
Site reliability engineers (SREs) are the glue between “Dev” and “Ops,” ensuring that software engineering expertise is applied to operations challenges. SREs naturally focus on making systems more reliable, efficient, and scalable. If you’re an SRE yourself, you’re already deeply familiar with these ideas.
If you’re a CFO or finance leader at a company that uses public cloud services like AWS, chances are you’ve had a bill cross your desk that may seem confusing. You or your team of financial analysts may have frequent conversations with engineering about how AWS services are allocated across different engineering initiatives.
If you're running in the cloud and ever struggle to predict, report on, or attribute your cloud costs, you may want to consider a new kind of role: A Financial Cloud Operations Manager. While a traditional cloud operations manager may sit on the DevOps team or report to an engineering lead, a financial cloud ops manager’s reporting structure is slightly different.
These days, a major part of most IT budgets is the cloud bill. But unlike server-bound infrastructure budgeting, cloud bills can be unpredictable and highly variable from month to month. However, if organizations embrace cloud cost optimization to regulate cloud bills and avoid surprises, they’ll find themselves with considerable found money that can be reinvested into other areas.
The typical AWS bill, otherwise known as the AWS Cost and Usage Report, includes line items that are useful to both finance and DevOps. However, many of the metrics that are within engineers’ and cloud architects’ control aren’t so simple to discover. To make cost a first-class operational metric for DevOps, teams need visibility into the data that’s relevant to engineering activity.
Recent headlines surrounding big-name IPOs, such as that of Slack and Lyft, have highlighted the very real costs of operating in the cloud. Companies like these are on the hook to pay AWS and other public cloud vendors tens or hundreds of millions of dollars every year, just to run their services.
When it comes to cloud strategy, companies rank “cutting costs” as their top priority for 2019, according to a recent Datamation survey. That’s not to say that they plan to cut back on cloud spending in general; in fact, those budgets are very much expected to grow. Rather, companies are looking for ways to reduce unnecessary costs and optimize cloud spend.
DevOps is a very data-driven practice. After the right cultural changes take place within an organization to adopt DevOps, teams often rely heavily on monitoring, measurement, and continuous improvement to keep their projects on track. The best teams use KPIs to benchmark their performance and report up to management. However, there’s one metric your DevOps team might not be tracking: The cloud cost of their engineering decisions.
If you’re a cloud architect or engineering lead, chances are you’ve had a defensive conversation with finance about the AWS bill. Maybe it looked a little something like this… Unfortunately, this scenario is all too familiar, yet understandable from Finance Frank’s point of view. He’s just trying to do his job, but has zero context into which engineering activities are costing the organization so much (or why these costs are variable on a month-to-month basis).
