MARK MIRCHANDANI: Getting a budget alert
when your Google Cloud Platform costs exceed your budget
is a great way to stay on top of your cloud costs,
but cost controls are more about [? than ?]
just avoiding billing surprises.
It's also important to provide the flexibility
you need to scale and have a way to restrict unnecessary costs.
On this episode of "Beyond Your Bill,"
we'll talk about how programmatic budget
notifications can be added to your budgets
and give some examples for setting up advanced cost
controls.
[MUSIC PLAYING]
In our previous video, we went through setting up
budgets and alerts in the GCP console
which trigger email notifications.
Since budget alerts are sent to billing account administrators
and billing account users, you can easily
control who gets those notifications.
However, that means you may need to wait for those people
to talk to the right teams and investigative
if changes need to be made.
If you want to put more proactive controls in place,
programmatic budget notifications
can allow you to run code based on your budgets.
After choosing a threshold when setting up a budget,
you can connect a Cloud Pub/Sub to the budget
where you'll choose a project and a Pub/Sub topic
to receive notifications.
Once the budget is published in the Pub/Sub,
you can have any number of subscribers
that will handle the notifications such as Cloud
Functions for our example.
If you're not familiar with Pub/Sub,
think of it as a simple message handler
which passes on any events such as budget
updates to any services that are subscribed to it.
Cloud Functions is a lightweight way and serverless
way to run code, and it's an ideal solution for quickly
handling budget alerts.
Any budgets you create with a Pub/Sub topic
will publish the current status of a budget
multiple times per day rather than waiting for a threshold
to be crossed.
With each budget you set up, you can
have both email notifications and programmatic notifications.
When setting up advanced cost controls like this one,
you'll want to make sure that your finance
teams and your IT teams work together
since this process involves both sides.
Once you've got everything connected with Pub/Sub,
the Cloud Function will receive notifications
with some important information such as the billing account
ID, the display name of the budget,
the most recent threshold exceeded,
and the amount of your costs for the scope of the budget.
Now that you're writing code with this information,
you can pretty much do anything the Google Cloud Platform
API will let you do.
One very common example is to post an update
to Slack or other platforms, connecting
any tools your team uses to stay on top of your costs.
Again, this keeps people up to date,
but we can also automate direct cost controls
to respond to these notifications.
One of the more drastic actions you can take
is to disable billing for a project entirely.
For example, you may have a development or test environment
and a dev team that constantly spins up
resources in that environment.
If someone on the team spins up an expensive resource
like a large compute instance and then
forgets to turn it off, it can rack up costs pretty quickly.
One way to avoid this may be to set
a budget and a programmatic budget notification that
removes the billing account from the project
after the specific cost is reached.
It's important to note that when you disable
billing on a project, all the billable resources
for that project are shut down and then deleted.
This is probably not something you
want to do in a production environment,
but it can be a quick way to make sure
that you set a very hard limit for your costs
on that specified project.
Sometimes a more nuanced approach
is better, such as limiting the number of resources
that can be spun up with quota, or simply stopping
all the compute instances without deleting them.
That way you're not paying for them and the appropriate team
can investigate why the usage was higher than planned.
There's some sample code in the links below for sending alerts
to Slack, disabling billing for a project,
and for stopping all compute instances when you
hit a specified budget amount.
These are great starting points, and they're
easy to extend with just a little bit of code
to fit your business needs.
When testing your code, you can manually send Pub/Sub messages
so that you don't actually have to wait for the budget amount
to be triggered.
Another driver of unnecessary or accidental costs
can be from resources that aren't being used optimally.
Over-provisioned resources are larger
than they need to be to serve their current workloads.
And since this is the cloud, it can be easier to scale them
down as needed.
Idle or part-time resources can also
be an easy target for saving costs
since they can be stopped or scaled down
when they're not at peak usage.
This can also be automated on a scheduled basis
such as regularly looking for resources that aren't
being used and removing them.
Two great examples of this are linked below.
Both walk through taking advanced actions
such as removing unused IP addresses and attached disks,
moving storage buckets to less expensive storage classes
based on their usage, and setting up
a schedule to start and stop Compute Engine instances.
Using programmatic budget notifications
is another step towards being able to setup cost
controls that match with your business needs.
Each business is different, so the specifics depend
on the amount you're looking to automate and extend your cost
controls, but the links below give you a great starting point
and provide some sample code.
Check them out and get a better handle
on controlling your cloud costs.
[MUSIC PLAYING]