Cost optimization strategies in GCP - Time & Space Complexity
We want to understand how the cost-saving actions in cloud setups grow as we add more resources or services.
How does the effort or number of steps to optimize costs change when the cloud environment grows?
Analyze the time complexity of the following cost optimization steps.
// Pseudocode for cost optimization in GCP
for each project in organization:
list all active resources
for each resource:
check usage metrics
if underused:
recommend rightsizing or shutdown
else if idle:
recommend shutdown
else:
continue
log recommendation
notify owner
// This repeats for all projects and resources
This sequence checks all resources in all projects to find cost-saving opportunities.
Identify the API calls, resource checks, and notifications that repeat.
- Primary operation: Listing and checking each resource's usage metrics.
- How many times: Once for every resource in every project.
- Secondary operations: Logging recommendations and notifying owners for each resource.
As the number of projects and resources grows, the number of checks and notifications grows too.
| Input Size (n) | Approx. Api Calls/Operations |
|---|---|
| 10 projects with 10 resources each | ~100 resource checks and notifications |
| 100 projects with 100 resources each | ~10,000 resource checks and notifications |
| 1000 projects with 1000 resources each | ~1,000,000 resource checks and notifications |
Pattern observation: The total operations grow quickly as both projects and resources increase, multiplying together.
Time Complexity: O(n * m)
This means the effort grows proportionally to the number of projects times the number of resources per project.
[X] Wrong: "Checking one resource means the total effort grows only a little as we add more resources."
[OK] Correct: Each resource requires its own check and notification, so the total effort adds up quickly as resources increase.
Understanding how cost optimization scales helps you design efficient cloud management tools and shows you think about real-world cloud challenges.
"What if we batch notifications instead of sending one per resource? How would the time complexity change?"
Practice
Solution
Step 1: Understand cost drivers in GCP
Machine types with more CPU and memory cost more money.Step 2: Choose cost-saving options
Using smaller or cheaper machine types reduces the hourly cost.Final Answer:
Use smaller or cheaper machine types -> Option CQuick Check:
Smaller machines cost less [OK]
- Thinking more machines always save money
- Believing running all resources nonstop is cheaper
- Choosing the most powerful machines by default
Solution
Step 1: Review gcloud syntax for preemptible VMs
The flag to create a preemptible VM is--preemptible.Step 2: Identify the correct command
gcloud compute instances create my-vm --preemptible uses--preemptiblecorrectly to enable preemptible VM.Final Answer:
gcloud compute instances create my-vm --preemptible -> Option AQuick Check:
Use --preemptible flag to create preemptible VM [OK]
- Using --no-preemptible which disables preemptible
- Confusing machine-type with preemptible flag
- Using incorrect flag names
instances = [
{"name": "vm1", "machine_type": "n1-standard-1"},
{"name": "vm2", "machine_type": "n1-highmem-4"},
{"name": "vm3", "machine_type": "n1-standard-1"}
]
cheap_vms = [vm["name"] for vm in instances if vm["machine_type"] == "n1-standard-1"]
print(cheap_vms)
What is the output?Solution
Step 1: Understand the list comprehension filter
The code selects VMs where machine_type equals 'n1-standard-1'.Step 2: Identify matching VMs
vm1 and vm3 have 'n1-standard-1', vm2 does not.Final Answer:
['vm1', 'vm3'] -> Option BQuick Check:
Filter by machine_type 'n1-standard-1' gives vm1 and vm3 [OK]
- Including vm2 which has a different machine type
- Returning empty list by mistake
- Confusing keys in dictionary
gcloud compute instances create cheap-vm --machine-type=n1-standard-1 --enable-preemptible=falseWhat is the error and how to fix it?
Solution
Step 1: Analyze the preemptible flag usage
The flag--enable-preemptible=falsedisables preemptible VMs.Step 2: Correct the flag to enable preemptible
Use--preemptiblewithout false to create preemptible VM.Final Answer:
The flag disables preemptible; use --preemptible instead -> Option DQuick Check:
Use --preemptible to enable preemptible VMs [OK]
- Using --enable-preemptible=false disables preemptible
- Changing machine type instead of flag
- Ignoring flag syntax errors
Solution
Step 1: Identify automation options for VM management
Cloud Scheduler can run tasks on a schedule, and Cloud Functions can execute commands like stopping VMs.Step 2: Match automation to cost optimization goal
Automating stop/start reduces costs by not running VMs when unused.Final Answer:
Use Cloud Scheduler to trigger Cloud Functions that stop/start VMs on schedule -> Option AQuick Check:
Automate VM stop/start with Cloud Scheduler and Functions [OK]
- Relying on manual stopping which is error-prone
- Using preemptible VMs without scheduling
- Increasing VM size which raises costs
Ready to prove it?
Pass the test and this pattern moves unknown
