Cost Planning
1. Cost Planning
Cost planning is an important phase in your design that starts with capacity planning. I recommend that you treat capacity planning not as a one off task, but as a continuous, iterative cycle, as illustrated on this slide. Start with a forecast that estimates the capacity needed. Monitor and review this forecast. Then allocate by determining the resources required to meet the forecasted capacity. This allows you to estimate costs and balance them against risks and rewards. Once the design and cost is approved, deploy your design and monitor it to see how accurate your forecasts were. This feeds into the next forecast as the process repeats. A good starting point for anybody working on cost optimization is to become familiar with the VM instance pricing. It is often beneficial to start with a couple of small machines that can scale out through auto scaling as demand grows. To optimize the cost of your virtual machines, consider using committed use discounts, as these can be significant. Also, if your applications are fault tolerant and can withstand possible instance preemptions, then Spot instances can reduce your Compute Engine costs by up to 91%. Compute Engine provides sizing recommendations for your VM instances, as shown on the right. This is a really useful feature that can help you select the right size of VM for your workloads and optimize costs. For more details on Spot VMs see the Google Cloud documentation. A common mistake is to over-allocate disk space. This is not cost-efficient, but selecting a disk is not just about size. It is important to determine the performance characteristics your applications display: the I/O patterns, do you have large reads, small writes, vice versa, mainly only read data? This type of information will help you select the correct type of disk. As the table shows, SSD persistent disks are significantly more expensive than standard persistent disks. Understanding your I/O patterns can help provide significant savings. To optimize network costs, it is best practice to keep machines as close as possible to the data they need to access. This graphic shows the different types of egress: within the same zone, between zones in the same region, intercontinental egress, and internet egress. It is important to be aware of the egress charges. These are not all straightforward. Egress in the same zone is free. Egress to a different Google Cloud service within the same region using an external IP address or an internal IP address is free, except for some services such as Memorystore for Redis. Egress between zones in the same region is charged and all internet egress is charged. One way to optimize your network costs is to keep your machines close to your data. Another way to optimize cost is to leverage GKE usage metering, which can prevent over-provisioning your Kubernetes clusters. With GKE usage metering, an agent collects consumption metrics in addition to resource requests by polling PodMetrics objects from the metrics server. The resource request records and resource consumption records are exported to two separate tables in a BigQuery dataset that you specify. Comparing requested with consumed resources makes it easy to spot waste and take corrective measures. This graphic shows a typical configuration where BigQuery is used for request-based metrics collected from the usage metering agent and, together with data obtained from billing export, it is analyzed in a Looker Studio dashboard. Earlier in this course, we talked about all of the different storage services. It’s important to compare costs of the different options as well as their characteristics. In other words, your storage and database service choice can make a significant difference on your bill. Your architectural design can also help optimize your costs. For example, if you use Cloud CDN for static content or Memorystore as a cache, you can save instead of allocating more resources. Similarly, instead of using a datastore between two applications, consider message/queuing with Pub/Sub to decouple communication between services and reduce storage needs. The pricing calculator should be your go-to resource for estimating costs. Your estimates should be based on your forecasting and capacity planning. The tool is great for comparing costs between compute and storage services, and you will use it in the upcoming design activity. To monitor the cost of your existing service, leverage the Cloud Billing Reports page as shown here. This report shows the changes in cost compared to the previous month, and you can use the filters to search for particular projects, products, and regions, as shown on the right. The sizing recommendations for your Compute Engine instances will also be in this report. For advanced cost analysis I recommend exporting your billing data to BigQuery, as shown in this screenshot. You can then analyze the billing data to identify large expenses and optimize your Google Cloud spend. For example, let’s assume you label VM instances that are spread across different regions. Maybe these instances are sending most of their traffic to a different continent, which could incur higher costs. In that case, you might consider relocating some of those instances or using a caching service like Cloud CDN to cache content closer to your users, which reduces your networking spend. You can even visualize spend over time with Looker Studio, which turns your data into informative dashboards and reports that are easy to read, easy to share, and fully customizable. The service data is displayed in a daily and monthly view, providing at-a-glance summaries that can also be drilled down to provide greater insights. To help with project planning and controlling costs, you can set a budget. Setting a budget lets you track how your spend is growing towards that amount. Set a budget name and specify which project this budget applies to. Set the budget at a specific amount or match it to a previous month's spend. Set the budget alerts. These alerts send emails to Billing Admins after spend exceeds a percentage of the budget or a specified amount. In our case, it would send an email when spending reaches 50%, 90%, and 100% of the budget amount. You can even choose to send an alert when the spend is forecasted to exceed the percent of the budget amount by the end of the budget period. In addition to receiving an email, you can use Pub/Sub notifications to programmatically receive spend updates about this budget. You could even create a Cloud Run function that listens to a Pub/Sub topic to automate cost management.2. Let's practice!
Create Your Free Account
or
By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.