Most conversations about migrating to the cloud start with cost savings. Although, in reality, it's not the most compelling reason to move to the cloud, it's definitely the first thing on the minds of executives who are making the decisions and writing the checks. In an environment where you can spin up thousands of new resources in minutes at the click of a button, you can just as easily run up a high bill if you aren't careful.
Study the cost optimization pillar of the AWS Well-Architected Framework to learn how to be careful.
If you have just started researching a move to the cloud and you have done a few simple back-of-the-napkin calculations, you may be scratching your head and wondering where the reported cost savings of the cloud are coming from. Optimizing an infrastructure for costs is not something that comes easily, just like it's not easy to create a compelling and useful application that users enjoy. It takes continuous effort and diligent study of all the options available to you, and you will need to move beyond simply doing a lift-and-shift of your on-premises applications to EC2 instances by administrators who have only a superficial understanding of AWS.
In the Performance efficiency section, we reviewed the different EC2 instance families. As we know, choosing the right one will make a huge difference in your costs. But there are more than 140 services now offered by AWS, and EC2 is only one of them! Learning the service landscape and finding components that you can offload from instances is where the real cost savings start to happen. And for applications that still require EC2, learning about how purchasing reserved instances or bidding on spot instances can save you significant amounts of money is crucial.
When calculating your Total Cost of Ownership (TCO) in the cloud, don't forget to add human resources to the cloud resources you have provisioned. Some roles change, some go away, and some are replaced by completely new functions that you need to understand in order to paint the entire picture when it comes to the money you are spending to support a workload.
Use automation to shut down resources that you don't need, especially if you have parts of your application that are not in use 24 hours per day. A perfect example of this is development environments and servers that are used for testing. When a developer creates a web-based IDE using AWS Cloud9, the environment is configured to automatically hibernate after it has gone unused for a specified amount of time. If you use AWS CodeBuild as your build environment, containers are only in use for the amount of time that it takes to complete the build. This is a huge advantage over on-premises development environments, where all of those resources require a big upfront investment and continuous maintenance.
It's possible to categorize your AWS resources using tags. You can use resource tags to allocate costs to various departments. Ideally, you should implement some sort of chargeback system so that business owners are responsible for their portion of the cloud infrastructure.
Make use of AWS Trusted Advisor to identify areas where you are spending money on underutilized resources. Upgrade to a Business Support contract on all production accounts so that you can enjoy the full benefits that the Trusted Advisor has to offer. Support is one service you definitely don't want to skimp on. The Cost Optimization screen in Trusted Advisor is worth its weight in gold. If you don't have a Business Support contract, valuable information is not available to you, as shown in the following screenshot:
Do your best to estimate your future charges on AWS, but in the end, the only way to know exactly what an actual, running workload will cost is to test it. With automation features such as Infrastructure as Code (IaC) offered by AWS CloudFormation, you can quickly spin up a test environment, run it for a short period of time to test your applications and gauge your costs, and then tear it down just as quickly.