Better Governance over AWS Costs
Whether you already run your systems in the cloud or are looking to migrate them to the cloud, you want to deliver business value at the lowest price point. But, predicting and managing costs for large deployments can sometimes be overwhelming and because the cloud is elastic, easy to provision, and virtually limitless. It’s easy for your costs to spiral. Understanding billing from AWS and the other cloud vendors and implementing cost controls has proved complex for many. We’ll be looking at these challenges and how to enact better AWS cost governance by controlling and optimizing costs through technology.
You may have seen the cloud adoption curve before. Typically, you’ll start thinking about the cloud and looking at it by running a proof of concept (POC). From there you’ll then generally start to move test and development workloads to the cloud. You may start using the cloud as an extension of your existing infrastructure, for example by using AWS as your disaster recovery (DR) location. You might extend your on-premises storage to the cloud. These are all excellent uses of the cloud and a great way to start. But because it’s easy to start small in the cloud simply using a credit card it’s also super easy for a shadow IT bubble to form as different groups in an organization start using the cloud in an uncontrolled way.
As you start migrating production workloads to the cloud and then enhancing those workloads and adding brand new applications you may find your costs escalating unexpectedly—unless you put in place good governance and financial control. A common cause for unpredicted expenditure is that cost governance for on-premises systems is very different. In the on-premises model you pay for your infrastructure up front and are then constrained by that infrastructure. The cloud is utility based computing—you consume as much as you need and then pay after you use the service. The architecture team typically work within the constraints of what is available in the data centre, on the cloud there are few limits so we see architectural decisions unintentionally leading to spiralling costs.
Good governance and financial controls, which meet your requirements, need to be implemented. AWS acknowledges this thorough its AWS Well-Architected Framework. Cloud computing has opened up the technology space to a whole new world of thinking where constraints we used to have in the traditional environment no longer exist.
The cloud also makes it easier to clearly identify the usage and cost of systems, which then allows transparent attribution of IT costs to revenue streams and individual business owners. This helps measure return on investment and gives system owners an opportunity to optimize their resources and reduce costs. But you have to put these systems in place.
When you consider cost control and optimization, keep the following three themes in mind:
1. Controlling AWS Costs at Scale with Advanced Technology
Densify provides excellent technology that can be used throughout the cloud adoption curve from the migration planning phases to the continuous optimization of large workloads.
2. FinOps & Cloud Spend Analysis
We recommend that this is a monthly process which starts with analysing your spend.
You can do this using spreadsheets and databases to analyse your bill or use AWS Cost Explorer. In my personal bill for the last six months., you can see that most of my cost is in compute, primarily EC2, but in May 2020 I had a large spike in my bill due to use of AWS Workspaces. We find that in most typical workloads compute is the biggest spend, and it’s important to understand your largest costs because this drives where you should focus your efforts. It shows why Densify is so useful, because it concentrates on driving down your compute costs.
Using Cost Explorer, you can look at your bill in a number of different ways, BUT, and this is key, you can only report on the data that AWS holds. In my case I know why I had a spike in Workspaces spend, but if this was your corporate bill how would you track that down? This is why tagging is so important as you can then attribute costs to projects, business units and any other way you might want.
Part of the analysis of your bill is to ensure you are using the most cost effective purchase options for your workloads, for instance reserved and spot instances and savings plans. On a regular basis you should also check if there are any AWS incentives available to you through partners. These typically fall into three categories: proof of concept, modernization and migration. AWS will give you proof of concept credits if you want to try out a new service or technology in a well-defined way, for example a block chain database using AWS Quantum Ledger. The second funding channel is workload modernization, this might for example be moving from SQL Server on an EC2 instance to Amazon Aurora. Modernization will mean that you are putting in effort to making your workloads cloud native and applies even if you are already running your workload on AWS. The final and largest source of funding is associated with migrating complete workloads. Funding here is designed to help offset some of the costs associated with the migration.
Although Cost Explorer is useful, Densify can provide you with more nuanced views of your spend, by using its outliers feature shown here. This can spot cost anomalies both and above a certain threshold above a moving average, alerting you to when spending isn’t what you would expect. In this case you can see a spike which happened on a Friday when the development team did a full volume test prior to a release. This is one of the great things about cloud—that you can run a full production sized environment for testing then, hopefully, spin it down. If the team had left the environment running you could see the damage it would have done.
3. Effective Cloud Cost Governance
I mentioned previously that AWS Cost Explorer works well but isn’t very useful unless you have tagged your resources, indeed Densify also relies on tags. Tagging falls into our third theme—governance. This is about adopting corporate wide strategies for establishing goals, creating a culture of control, measuring and monitoring costs associated with cloud usage.
This is not a complete framework for governance, but we will cover several particular areas and focus on one. Densify enables continuous optimization, but, as an organization you have to govern and mandate its use, as well as setting up a process for reviewing the recommendations the tool produces, evaluating them, and implementing them.
A. The Importance of a Cost-Centric Cloud Design & Architecture Process
Costs for the cloud should be considered up front during your design process, you would have done this when you were running on premises—but as soon as you move to the cloud this does not seem to matter anymore. Not so! During the design stage there should be a cost control exercise which looks to ensure that the most cost effective strategies and services are being adopted for the workload design. Doing cost optimization after a workload is in production is more expensive than ensuring cost control is built in. Other areas in Test and Development to look for are idling development, test, UAT and training workloads which are often left on when not being used.
B. AWS Cloud Budgeting
Another good governance practice for cost control is to establish budgets. AWS let’s you create budgets right inside your account. A budget compares what you spend against your actual spend and you can then create alerts based to notify you when you are exceeding, or forecasted, to exceed the budget. You can set up multiple budgets to track no only your costs, but also usage, however budget information is not updated continuously, and the information is typically eight to 12 hours old.
C. AWS Cost Control through Effective Tagging
Although tags have a range of uses, here we are talking about the use of tags for cost control. Whatever your use of tags, you’ll want to take a considered view towards tagging, which means that you should define a tagging policy that embodies the best practices described here, but also considers such things as naming conventions for your tags. This is doubly important because tags are not hierarchical, and the tag universe is effectively flat. In this example you can see that I have two tags that we use for cost control a line of business and a cost centre. In the names you can see we have used a two letter prefix for our organization. This is useful for a number of reasons, first if any third party tools or services you use create tags you won’t clash with them and secondly if your organization acquires or merges with another you’ll more easily be able to bring your tagging systems together. We know this having acquired two companies in the past year!
After you have your policy you can start to tag your resources, make sure that you tag everything that gets created, in fact for some of managed services customers we have automated procedures in place that will destroy any resources created without tags. Having said that don’t overdo it and have 40 different tags for every resource, each tag should justify itself.
When you apply tags, apply them consistently. If you intend to use tags for specific use cases, you will need to rely on the consistent use of tags and tag values. If a significant portion of your AWS resources are missing tags used for cost allocation, your cost analysis and reporting process will be more complicated and time-consuming, and less accurate. Likewise, if resources are missing a tag that identifies the presence of sensitive data, you may have to assume that all such resources contain sensitive data, as a precautionary measure.
When you begin tagging start with a smaller set of tags that you know you will need rather than over specifying an overabundance of tags that you think you might need in the future. You may already have an authoritative source of tagging information in a corporate CMDB, if you do then consider integrating that into your resource creation.
Finally, and this is important, when we talk about cost allocation: tags are not retroactive. As a result, when you introduce a new cost allocation tag it takes effect starting from that point in time. The new tag will not apply to past cost allocation reports.
AWS Cost Governance Case Studies & the Progressive Impact of AWS Cost Control
It’s worthwhile looking at two case studies. In both examples the clients opted for the service after running with us for some time. In the first example, the customer’s AWS spend was on an upwards trajectory when they opted for the service.
AWS cost governance adoption generally kicks off with an initial cost optimization exercise, which is why you generally see a good drop in spend in the first month. However, some cost optimization techniques may need a lot of time to put into effect. For example, the cost optimization may need some replatforming to a more cost-effective platform, such as moving a database off EC2 to RDS, hence the AWS spend should continue to fall over time as the optimizations are implemented. In this case you can see at the end of the year the customer was spending 25% less, monthly, than before optimization.
A second example shows a similar pattern. In this case you see a significant drop in August, this is when we implemented business hours use of staging and test environments, rather than having them on all the time.
Adopting AWS Cost Governance in Your Enterprise
If you take away only one thing from this presentation, it should be that cost optimisation is a holistic topic, that shouldn’t be seen as a point in time exercise but as a way of working and controlling your workloads over the long term to achieve the best value from your spend.
Together, Densify and our partner, HeleCloud, are uniquely positioned to help you anaylze and reduce your AWS spend, wherever you are on your journey. Request a 30-minute discovery meeting to discuss your particular use case and see how we can help you reduce the you AWS bill. Please contact us to arrange your personalized session.