- And now talking about cost optimization.
So let's look at some cost optimization best practices.
First and foremost,
leverage billing and cost management tools.
This is a way to
not directly help you save costs or optimize costs,
but it gives you the visibility you need
to see how your costs are trending,
how your services are being used,
what are you paying for.
If you don't have that visibility,
it becomes very difficult to optimize the costs
in your environment.
So organize and structure your costs.
Analyze billing reports.
With Cloud Billing, you can export data
into BigQuery, for example, to analyze it.
You can use labels to attribute costs back
to departments or teams.
It's a great way to structure and organize your costs.
You can build custom dashboards
for a more granular cost view of your infrastructure.
You can use quotas, budgets, and alerts
to closely monitor costs and forecast costs over time
and to get notified when costs are reaching your budget.
For example, it's a useful way of having a tool
to help you react when costs are getting out of hand.
If you set up a notification for, for example,
when your costs reach 80% of the budget,
then you can go in and shut some things down
and maybe reduce some of the sizes of VMs
and any sort of strategies to reduce costs.
Now, to get into some actual tools and ways to reduce costs,
the most obvious is to don't pay
for resources you don't use.
And for that, a good thing to do is to identify idle VMs.
And a tip here is to use
the Recommender service on Google Cloud
and, specifically, the Idle Resource Recommender,
available as one recommender in the Recommender service,
which will help you identify which VMs have been idle
that you can potentially reduce the size of
or just shut down altogether.
You can schedule VMs to automatically start and stop.
There is a Google-recommended solution that uses
Cloud Scheduler, Cloud Pub/Sub,
and Cloud Functions to achieve this.
Although, recently there's a new instance scheduler feature
that you can use to more easily set those up
right from within the Google Cloud console.
So you don't need that solution anymore,
but it's a more recent development.
I don't know if the exams have caught up to it.
You can rightsize VMs,
and for that, you can leverage custom machine types.
It's a unique feature in GCP
where you can define a very granular number
of CPUs and memory that you wish for your machines.
That would give you just exactly what you need
and nothing more.
So you don't need to rely on the predefined machine types.
You can create one that really fits
your use case, your requirements.
You can apply machine type recommendations
from the Recommender service,
which may recommend you a smaller instance
than the ones you're using
if it identifies that it's been underutilized
so that it will basically recommend you reduce the size
and so that you can save costs.
You can also leverage preemptible VMs
or spot VMs, as they're now called.
And those are just much cheaper VMs,
and we will explain what those are later in the course.
To optimize storage costs,
you can leverage storage classes and lifecycle policies.
Here on the screen,
you see all the different classes
with their minimum duration
or the recommended minimum duration
for it to be cost effective
or to make sense financially.
So starting on the top, we have Standard Storage class.
That one has the most expensive storage cost
but also the least expensive retrieval cost
with no retrieval cost basically.
Then moving down to Nearline Storage,
the storage cost reduces a little bit,
but the retrieval cost now increases.
There's a cost to retrieve data.
However, if you retrieve that data
or access that data less often
than once a month or once every 30 days,
it becomes cheaper.
For Coldline Storage, the duration is 90 days.
So if you access data less than once a quarter
or once every 90 days,
then it will be cheaper to put it in Coldline Storage.
And for data that you access very rarely,
less than once a year,
then Archive Storage would probably be the best option,
with the cheapest storage cost.
But it has the highest retrieval cost.
So you need to make sure those are
data that are not expected to be accessed very often.
And also avoid unnecessary object duplication.
Here's another strategy.
Tune your data warehouse.
Enforce controls to limit query costs.
Queries can get very expensive in BigQuery
if you don't have controls around it,
if you don't have a good strategy around them.
Use partitioning and clustering.
Those are techniques to improve
the query performance in a database
and make them more cost effective
and specifically for BigQuery here.
And check for unnecessary streaming inserts.
You can use batch loading
if streaming inserts is not required
because batch loading is free,
whereas streaming inserts you need to pay for.
And use Flex Slots, which is a commitment
to an amount of BigQuery query capacity.
So it's a way to commit to a certain usage level,
and that gives you a cheaper cost.
When it comes to networking, identify the top talkers,
those applications or components that are sending
a lot of traffic over the network.
And optimize regional and intercontinental network egress.
Keep in mind you pay for network egress on Google Cloud,
which is to say if you have traffic leaving Google Cloud
then you pay for it.
So be careful with that.
Consider the standard network tier,
as opposed to the premium.
If you don't know what those tiers are,
we'll get into it later in the course.
Filter out logs you don't need in Cloud Logging,
and enable sampling if possible for VPC Flow Logs
and Cloud Load Balancing.
Cost for those logs can get very expensive
because it's a lot that can be generated,
especially if you enable VPC Flow Logs
or any of those kind of features
that really creates a lot of logs.
Then the storage cost for those can be very expensive.
So enable sampling if possible.
Reduce the amount of logs that get generated with filters.
Leverage committed use discounts.
This is for Compute Engine VMs.
You can commit to a level of usage
for a one-year or three-year term.
And in exchange for that, you get much lower cost
than the standard on-demand pricing.
But it is a commitment, so you need to be sure
that level of capacity will be needed.
So this is good for steady-state kind of workloads
that runs on Compute Engine VMs.
So as I mentioned here,
ideal for predictable resource needs
and available in one or three-years term.