Design principles of the cost optimization pillar - Amazon Web Services (AWS) Tutorial

- [Instructor] Considering the term cost optimization in the construct of the well-architected framework. What we're really talking about is how to architect our workloads with the most effective use of Amazon-managed services and available resources to have the business outcome that we want and the lowest price point as cheaply as possible. So optimizing your application and its hosting is certainly doable, but it's a long term procedure. Everybody has to be on board. In order to achieve a desired business outcome that everybody on the application team is happy with while minimizing those costs is not something that you can do in a single day, because you're going to start, for example, with your application and ensure that it works in a development environment. Well, the pricing that you're using for your development systems is probably not going to be the same pricing used for something that is in production because the application scale and test versus production is going to be different. Therefore, it's going to be much cheaper. However, development environments could be much cheaper if they were turned off every night. So there's a lot of different areas for costs that you may not consider that may add up over time. We want to maximize your return on investment, whether it's the development investment or the investment in architecture to ensure your application is always available as required. The next task is to implement company-wide or team-wide, a financial management strategy for what you're doing in the cloud. The time and the people resources, both of these have to be allocated for proper financial management success. Just saying, well, we're going to keep costs down isn't really going to help us much. We have to know about the cost factors and how Amazon actually calculates costs. So this will take some time to acquire. You probably have to take some training. You have to look at the monthly bills. You have to do a little bit of discovery. After all, operating in the cloud for a lot of companies, it's pretty new, probably four or five years and operating it at scale. That is your application is really new because the potential for being able to scale up your application as required is great, but it costs you to scale. So we have to look at the scaling aspect of maybe scaling back down to save money, saving up to keep customers, somewhere in there is a balance. So understanding all of the technologies that you're using, storage, compute, monitoring, management services and how Amazon charges and how you use it, is going to take some time, but it's time well spent. Otherwise you'll never get your costs down. You have to adopt a consumption model for your application stack and pay for just the resources that you consume. With compute, you probably have heard about scaling up and down, turning off resources which aren't used right now, but this doesn't apply to say DNS services or database servers, but maybe the database server can be scaled down to a smaller one automatically in the middle of the night. Amazon has a MySQL database or Postgre compatible database that can scale up and scale down. It's called Aurora. The increasing or decreasing of the usage might also be looked at as a cost factor. What are your requirements for development? 24/7 or can you turn off the development cycle say after 10 hours? Is production on 24/7? Probably. But how much resources is being used? Have you looked at exactly how much you're consuming, what times you're consuming and what times you're not. You might discover that your resources are underutilized at certain times. Certainly development and test environments could be shut down when not in use. Take a look at the timeframe. Do you want to pay for 40 hours or do you want to pay for 168 hours? Especially if a lot of those hours aren't being utilized. One of the biggest changes for coming to the cloud for most companies is moving over and using a service provided by the cloud provider, typically called a management service. Let Amazon provide the management services for storage, for compute, for monitoring, for compliance. Let Amazon do the heavy lifting. The operational burdens should be removed wherever possible. Otherwise you need administrators managing resources, which are offered by Amazon and will be cheaper if you do a price comparison. Stop focusing on managing the IT infrastructure. That's Amazon's job. We want to manage our application stack, the application, the coding of it, the performance of it, the costing of it and the data. We have to identify and analyze the expenditures that are costing us money. The only way to identify anything in the cloud is to monitor what's going on. Monitoring your storage, looking at reports on compliance, looking at reports on scaling up and scaling down and figuring out what is the cost. We have to measure that return on investment and make sure that we're not operating in the cloud and everybody's happy, but it's costing us an arm and a leg. And we don't know what that is until we start actually identifying the expenditures 24/7. Once I optimize the resources, which will take time, this will reduce the overall costs. Because if I can reduce the footprint of my application stack, if I can reduce the number of snapshots that are being stored and not being utilized, I can save myself potentially quite a lot of money.