Now that we've seen the CSPs and how RIs and savings plans are a key part to controlling costs in the Cloud, let's look at some of the other ways of controlling costs that you should consider. In your organization, encouraging a DevOps team to be trained to be cost-conscious will be a huge benefit to your goal of controlling cost. This next section of the module is really geared towards education. The biggest component of cost savings or controlling costs in public Cloud is making sure that your individuals that are using the public Cloud are aware of what they're spending. More times than not, groups will just create a Cloud account, and spin up a bunch of resources, and not know exactly what it's costing the company. In order to avoid cost explosion in public Cloud, it's really best to build Cloud-native deployment. Many companies have found that the lift and shift model of just picking up your enterprise applications that are sitting on VMs and moving them into public Cloud is normally not going to save money. It's actually going to potentially cost more in public Cloud by doing that strategy. This is especially true if you're not closing a data center where these physical servers came from. Those have physical overhead, how heating, cooling, and it's not removing it from your TCO. What we're seeing is that building Cloud-native applications that can have a lower cost services will have a reduction in public cloud cost. Most companies, once they get to the Cloud, tend to need to refactor their application to reduce that cost. DevOps influence is a key to ensuring that your overall goal of controlling costs. It is key for your organization to develop some educational program for consumers of the Cloud on what the right way to build services actually is and to make sure that they are being cost-conscious when doing so. One example that I've seen implemented is that development environments are set to turn off automatically at night. Some organizations will work in particular regions where this will work, turning off environments that aren't required to be on 24/7 or even on the weekends. It'll save you a lot of money. Having environments that turn on at 6:00 a.m. and off at 06:00 p.m. will save you 50 percent on your bill right away without having to do anything, and even more, if you include the weekends as well. You only pay for your instance compute when it's powered on. If it's turned off, you're only paying for the disk space that's used and that's sitting there waiting for your server to get turned back on again, but the compute cost is nine percent of your overall bill in all the public Cloud costs. One of the ways to really build a foundation for this type of automation is to implement a global tracking or tagging requirement. Tags can be used to label certain compute instances in the Cloud and you can label them with an environment name, some variable like development or production, and you can build an automation script to look for certain tags on the instances and build a schedule to reach in and turn off all the instances labeled development. Tagging is also very useful in terms of doing cost reporting. I showed you earlier, in the module for AWS costs explorer tool, that there are some reports that are available to you in that tool that can be filtered based on tags as well. You can actually do reporting based on those tags. For example, if you wanted to know how much your development environments were costing you versus production, then you could add a tag filter in your reporting, where the tag is the environment variable, say, development versus production. The key here is putting enforcement on the tagging and making sure that people, when they deploy their infrastructure, that they're using those tags, and the tags are appropriately attached to the instances. When they're not used, there should be some alerting to either shut down the instance or delete it if it's not tagged correctly. That way you can enforce tagging throughout your environment. This DevOps education should also include things like how to build Cloud-native applications and how they can be built to not rely on persistent compute hardware. Applications can be written to scale up or down using compute services like Spot Instances. Let's take a look at how these can be used to control costs as well. In the next section of this module , on controlling costs, there's one of the greatest cost-savings tools out there, which is what they call Spot Instances. Both Amazon and Azure have called their instances spot. GCB calls them Preemptible Instances but what these are is a highly discounted compute instance that are sitting in the Cloud providers' data center. The Cloud providers are weekly installing hundreds and hundreds of servers just waiting for people to come in and start consuming them and build things on top of them. There are a lot of this unused hardware sitting there waiting for someone to come in and consume it. What the Cloud providers have done is say, well, I might as well try and make some money off of these servers that are sitting there unused and idle. They offer these servers at a highly discounted price and sometimes up to 90 percent off, but when a consumer comes in and says, hey, I want to purchase this, or I want to use this full-time in the Cloud provider, the Cloud provider will take it away from the person that's consuming it as a Spot Instance. When building a Cloud-native application, having a server taken away from your infrastructure is not a problem. But if you have an application that's only being run on one server, that'll be a major problem. The key here is to really have your engineering and developers understanding what the spot instances really are and how to consume them correctly. This can save you a lot of money without having to commit any money upfront in our eyes, or the savings plans. Spot instances will have a warning that's sent to an API that you can leverage, and you can query. When a server is going to be taken away from you in the pool, and this can be up to only two minutes at a time, but you can then build automation that would replace a spot instance with a reserve instance or even an on-demand instance if you really need to keep it. Until such time as there's another spot server that may be available for you to consume. This method requires that your application be able to handle the underlying infrastructure about being volatile. The server is taken away, and then you add it back in with a new spot instance. In summary, the mixture of spot instances, on-demand, and RI usage is a perfect collection of cost-savings methods that you can use for your organization. In the next section of this module on controlling costs, it's going to be discussing what alerting and preventative actions you can build into your strategy to help control those costs. These tools can be implemented for your organization that are simply notifications and awareness to the teams that are actually building in the Cloud. Or they could actually be restrictive controls that will prevent certain teams from doing things that are known to cause a Cloud builds disorder. Notifications and alerts can be a very useful tool, especially if teams are not savvy on what the Cloud costs actually are. For example, if someone starts an instance that is very large and left it running overnight or over a weekend. This can rap up a bill very fast, having motivation to shut things down or send email alerts when certain dollar amounts change drastically in an account can prevent this type of issue. I have personally seen someone leave a high dollar per hour machine running for three weeks at a time, 24/7, and getting a $30,000 bill at the end of the month. This is something you want to avoid. All the major Cloud providers have tools around budgeting and alerting. Normally these are set up in the billing section of each one of the Cloud providers and can be targeted towards individual email addresses or even sent as SMS messages. You can build reporting based on tags so as we mentioned in the previous slides, if you were to implement a tagging strategy for every engineer, they could just add their name to the infrastructure that they're building, and you can send a notification notices directly to those engineers on what their weekly bills are. It's a very powerful tool and knowledge is key in terms of making people aware of what they're spending in the Cloud. The budget reporting tools in the Cloud providers can also be used to set percent gain alerts for foreign accounts, if their accounts spends increase on a daily amount by 50 percent or 25 percent, whatever the value you want to send, you'll get an alert for it. Another great strategy for organizations is to implement restrictions on accounts, specifically around regional restrictions. All of the Cloud providers enable you to build infrastructure in dozens of regions around the world. But most organizations will only be building infrastructure into maybe five of those regions. The rest of regions aren't used by those organizations, is best practice to remove the ability to build infrastructure in regions that your organization doesn't support. A very common problem that occurs as a developer will log into their account, and they'll be in the wrong region when they do so. They didn't realize that when they are in a different region. They start to spin up instances in that region. The next time they log in, they may not realize that they go back to their normal region, thinking that someone deleted those instances, you just spin up the other day, and they start billing it again. But in reality, they built all of those other resources in an unused region. Original servers will sit there forever until someone realizes that it's turned on. Region restriction is a very good way to avoid this issue. If you are in the wrong region, they couldn't even build a server in the first place, they'll realize their error right away. Another method that's very useful is to limit the type of instances that your organization will use. For example, if you're purchasing reserved instances to certain types of instance families, then you can ensure that those reserve instances will be actually consumed. Letting your accounts just choose any type of instance can be detrimental to your overall cost savings strategy. It's a balancing act between letting your developers be agile, but also be cost-conscious. You can always limit your developers at the beginning and add more compute choices to your rules as those needs change. But if you're buying Reserve Instances, it's important to make sure they're being consumed first. These types of controls are important to consider when trying to optimize costs in the Cloud. I'll give you a demo of AWS budgets in alerting and to show you how simple it is to set one of these in the Cloud provider. This demo is to show you what AWS budgets can do for you in terms of sending alerts. This can be a useful tool for you or your consumers at the Cloud. You can be able to set these budgets from either the top level or at any linked account level. Right now I'm at an individual account. This may be something you educate your team's own accounts to say you're going to spend $1,000 a month. That's great. That's your budget. You may want to know when you're going to reach that budget, when you're close to it or if you're going to exceed it. What you can do is you can just type in the word budget in the console and then click on "AWS Budgets" and that will take you to the budget service. You can also do it from the Cost Explorer screen. You can just click on "Budgets" here and it'll take you to there. We're in the budget screen, so we're just going to go ahead and click on "Create a Budget" and we're going to do a cost budget. You can do usage, you can do savings plans. There is lots of different options here. But for this demo I'm just going to do a cost budget. I want to know when my daily costs are going to exceed, say, $15. In the UE here they have options for monthly, daily, quarterly. Monthly is pretty good. If you set $1,000 a month, what you want your max to be, you can set that to alert you when you're going to get close or when it forecasts you think is going to get close. For my example here, I'm just going to choose daily because I want to know when it's going to be done right away. You can see that they do not support any forecasting for daily alerts. In this case I don't really need any forecasting. I just want to know when my daily amount is going to be exceeded. You can see here that they have a fixed amount. You can set a start date. I can set when it's going to expire. It also gives you some kind of background. Over the last 30 days, my average bill has been $20 a day. I'm just going to set up an alert for $15 so that I get an alert right away in my email. I'm going to show you that. It does have some other options here that you can really dive into to figure out what costs you want to really do budgets on. But for this demo, I'm just going to keep it simple and accept the defaults. I'm going to say daily budget, that's just a name it's going to come across. It will come across in the email with that name to whatever you put in there. Then you can see that it actually created the budget, but we need to add a threshold. We need to know when exactly I'm going to hit that $15 mark and what to actually do. In this case, I want to say, "Hey, show me when my threshold of 100 percent of that $15 budget." You could say actual or forecasted right here. In this case, I'm just going to choose "Actual". What do you want to do? You can either SNS an email, you can do SNS alerts, you can even chatbot alerts, all kinds of things. I'll just drop in my email address into this. Add another one or I can just click on "Next". It gives you a review of what you're going to do and I'm going to say create a budget. This budget will show up. It will tell me right away where I'm at. Right now, here is the threshold, I said $15. It's already exceeded. Here is my amount used for the day. It should give me all those. You can create multiple budgets, you can send multiple emails to different people depending on what you want to do. Set a daily budget to say your development group or you could even get as fancy as looking at tagging strategies around budgets to say, create a budget for Joe and Mary. Give them their own budget and any resource that exceeds a certain dollar figure with Joe or Mary's name on it, they can get an alert. You can get as complex as you want with this. It should have sent me an email saying that this daily budget has been exceeded. Let me go ahead and pull up my email and see if it's there. I did get an email here. You can see in the screen that I get an email from Amazon and you could see the daily budget was the name that it actually gave it here down at the bottom. My $15 budget amount of my total spend for the day exceeds $15 and sends me a nice little email. You can go in there and go into your budgets and adjusted as you want, or at least you're aware of what's happening in there. That's really all. It was just an email notification to say you've exceeded your quota for the day or month or quarter or whatever you want to set up. This can really help you make sure your teams are aware of what they're going to spend. That's a key important thing for maintaining costs in the Cloud. All of the main Cloud providers offer basic tooling for you to use to manage your spends over time. AWS has a tool that's called Trusted Advisor. This tool groups more than just costs into it and it provides a lot of advice on security and other services like data retention, etc. The cost optimization portion of this will provide you with basic recommendations based on your usage over time. By default is set to three-day increments to determine if whatever its recommendations are includes things like RI purchases as well as things like this that may have been orphaned. They should be cleaning up but has a lot of useful information. Let me show you where you can find this tool in the AWS UI. It's a very useful tool overall for anything in your account. Again, in here as in the billing dashboard. But you can just type in Trusted Advisor in the menu and click on trusted advisor. That'll bring up the service for you. The dashboard will give you lots of advice regarding everything around Amazon. Not just cost savings. This module specifically around cost savings, but the trusted advisor will give you things about securities. Things are problems with your account and you should really go through them all to verify you don't have any breaches or any particular things in your account. They also talk about fault tolerance. If you're building things that aren't really resilient in the Cloud. You're not building Cloud-native things like that. There's, or your performance is low or high. Trusted advisor can really provide you some of those details. I'm going to concentrate on the cost optimization because this is a cost module that we're really talking about. Let's dig into that a bit. This is actually one of the linked accounts. The linked accounts can all see this stuff as well. They can see their own alerts and things like that for their cost accounts. You can see here that the cost optimization thing, it's making recommendations down below. It's saying that I've got some RDS databases that are idle, low utilization on some easy instances. If you change your instance size, you can save some money. Underutilized EBS volumes. When you build a bunch of instances out in the Amazon, a lot of times they get left behind and those can add up some money. Insane in the sense here that 23 of my 32 EBS volumes appear to be underutilized, probably not even used. I could save $172 a month by just getting rid of those. A lot of these things are alerts that are saying, you're all good, these are all intensive purposes. You're not really out of balance here, but the ones that are marked with little exclamation point, those are the ones to take account and look at. Unassociated elastic IPs are another one that's very common out there is that people will build servers and give them a public IP address or an elastic IP. Then they delete the server but don't forget to delete the elastic IPs. They're not very expensive. They're like a dollar a month each, but still it adds up over time. That's AWS Trusted Advisor. Let's go ahead and look at Azure Advisor and see what that one offers us. Azure has something similar, It's called Azure Advisor. Let's take a look at that. This is Microsoft Azure Advisor. You can get to this service just by typing in Advisor in the top menu here, you can see that I've been here before. This will take you to the service itself. You can make sure that you're selecting, all of your subscriptions by detail that really looks at the one you were in. But you want to select them all. If you want to see across your entire organization and then as with AWS, the advisor is really geared towards all things cloud in terms of giving you advice on what you should be doing. Talks about security or liabilities. You should really dive into each one of these, especially security, to make sure you don't have any issues in the Cloud that could potentially compromise your environments but for this exercise we're going to be just looking at the cost recommendations. If I click on cost here it should give me a detailed report of what it recommends that I go do to give me some potential savings and they rank them from high, medium, low impact. In this case it's saying the number one thing I can do to save money is to buy some reserve instances and I can save a certain amount of dollar figure per month by doing that. They'll give you some other things too like some native services they think you should move to but, again, those are hard to manage at a top-level management side of things. You really need to talk to the individual accounts or the subscriptions that have those things in their accounts and talk to them if they want to move to something else rather than what they've had spun up in their account. They do give you high, medium, and low. Again, they'll talk about resources that are underused, so like here I've got some empty data explore resources. By cleaning things out you can save money so really looking at some of those details are important. You can look at this holistically at a top-level or organization but each one of the individual accounts also have access to this tool as well and you should really train them on how to make sure that they go in here on at least on a monthly basis to make sure that they don't have any blatantly wasting of resources and that will really help you and your company in long-term at saving cost. Finally, Google has a tool called GCP recommender. Let's take a look at that. This is Google recommendations so this is a service provided by Google right in the dashboard. When you login to your account you can directly see the recommendations and availability for that so you just click on recommendations here and it will give you same thing with Amazon and as you're and they lump them all together, security services, permissions, excessive permissions, things like that but today we'll just be talking about the billings stuff. You can look at here, tell you right away that you're billing account for all of your accounts, you could save a certain amount by purchasing a commitment and you can click on "View All" to see more details about what they're going to recommend. In this case, they're going to recommend that I purchase some codes or committed use discounts and they can say if in the US-West-2, if I were to use the Google VMware engine and spend commitment of 2,974 I could save approximately $9,000 a month. They'll give you a list of their recommendations of all of these. If you know that you're not going to be doing certain things like, oh, I know this sequel database is just a test one, you can click on them and then say dismiss and then they'll get removed from your recommendations. It's pretty simple. You can learn more about it by clicking on "Learn more" here and you can actually get into the details of it. They do have history reports on your savings available in the console as well but it's a nice simple tool way for you to really look at, what does Google natively going to say my recommendations are? Like I said, you can dismiss the ones that you know you've already talked with those teams or whatnot. That's all we have for the native tooling. Let's recap what we've learned in this module. Centralized management of all of your Cloud providers and your organizational spend is really the only choice in order to control your costs. Essentially, managing things really will benefit your organization. Creating a finance role or team in your organization that can specialize on cost management and enforcement of best practices across your organization will pay for itself in the long run. Using the finance team to evangelize your consumers of the Cloud on cost, what Cloud cost is will also help lower your spends in public cloud. Building, alerting, and preventative restrictions on Cloud console, make sure that your organization is aware of the costs that they're incurring and knowledge is key to your success. Finally, there are some native tools that are available to you in each of the cloud providers like AWS Trusted Advisor, Google recommendations, and Azure Advisor. Thank you for watching this section of the course.
