Cost management and performance optimisation. For a cloud developer, ignoring these is like driving a sports car with the handbrake on — you burn fuel fast and go nowhere. The PCD exam demands you prove you can build applications that run fast without costing a fortune, using Google Cloud's built-in tools to monitor, analyse, and adjust continuously.
Jump to a section
A simple way to picture Cost Management and Performance Optimization
Have you ever tried to feed a family of four on a fixed weekly budget, only to find you're out of money by Thursday because you bought pre-chopped vegetables and brand-name cereal?
That's exactly what happens when you don't manage cloud costs. Pre-chopped veg is like paying extra for a managed service when you could do the chopping yourself. Brand-name cereal is like leaving a virtual machine running all weekend when nobody's using it.
In this analogy, your weekly budget is your cloud spending limit. The supermarket is the cloud provider. You have two main choices: buy the expensive, ready-to-eat stuff (fully managed services) or buy raw ingredients and prep them yourself (self-managed infrastructure). The trick is balancing convenience against cost. You might spring for pre-chopped onions because you hate crying, but you'd never buy pre-made sandwiches because you can make them cheaper.
Performance optimisation is like arranging your shopping list so you don't have to walk back and forth across the store. You group items by aisle, grab the frozen stuff last, and use the self-checkout when the queue is long. In cloud terms, that means caching frequently accessed data (the frozen aisle slowdown), using content delivery networks (the express checkout), and right-sizing your resources (buying the medium bag of rice instead of the giant one that goes stale).
Get this balance wrong and you either starve on Thursday (budget overrun) or waste time cooking when you could be doing something else (poor performance). The exam wants you to know which knobs to turn and when.
Let's start with the fundamental shift the cloud brought. Before cloud computing, companies bought physical servers. They guessed how much capacity they'd need and bought it all upfront. If they guessed wrong, they either wasted money on idle servers or crashed under traffic spikes. The cloud changed that by letting you pay only for what you use. But that freedom introduces a new problem: it's easy to waste money if you don't watch what you're doing.
Cost management on Google Cloud means actively tracking and controlling your spending. The core tool is the Google Cloud Console's billing section. There you'll find the Cost Table, which breaks down spending by project, service, and labels (tags you attach to resources). You set budget alerts — for example, 'send me an email when this month's compute cost hits 500 Australian dollars'. You can even set up automated triggers to disable expensive resources if spending goes rogue.
The key concept here is the pay-as-you-go pricing model. Every service charges differently. Compute Engine (virtual machines) charges by the second after a minimum one-minute run. Cloud Storage charges per gigabyte per month. Cloud Functions charges per invocation and per millisecond of execution time. You need to understand which pricing model applies to each service you use.
Now, performance optimisation is the art of making your application respond quickly without over-provisioning resources. The main tool here is Cloud Monitoring, part of Google Cloud's operations suite. You set up uptime checks and dashboards that show metrics like CPU usage, memory pressure, and request latency. When you see a CPU consistently running at 20%, you can downsize that instance and save money. When you see latency spikes, you might need to increase capacity or add caching.
The relationship between cost and performance is a trade-off. You can always make an application faster by throwing more expensive hardware at it, but you're then paying for speed you may not need. Conversely, you can pinch pennies ruthlessly but then your users wait forever for pages to load. The sweet spot is called optimising for the right service level. The exam tests your ability to identify when to scale up, when to scale down, and which Google Cloud tool to use for each situation.
Let's break down the specific Google Cloud services you use for this:
Cloud Monitoring: collects metrics, logs, and traces from your resources. You set alerting policies that trigger when a metric crosses a threshold.
Cloud Logging: stores all your application and system logs. You can search through them to debug performance issues.
Cloud Trace: samples and analyses latency in your application. It shows you where time is spent — database queries, external API calls, or your own code.
Cloud Profiler: continuously samples CPU and heap usage of your production applications. It pinpoints the lines of code consuming the most resources.
Recommenders: machine learning-based suggestions that tell you which resources are underutilised or over-provisioned. Examples include the idle VM recommender and the persistent disk snapshot recommender.
Another critical concept is right-sizing. That means choosing the correct machine type for your workload. Google Cloud offers predefined machine types (small, medium, large) and custom machine types where you pick the exact number of vCPUs and memory. If your database server uses 4 vCPUs but only 2 GB of memory, you're wasting memory. Custom machine types let you match resources precisely.
Then there's sustained use discounts and committed use discounts. If you run a VM for more than 25% of a month, Google automatically applies a discount that grows the longer you run it (up to 30%). Committed use discounts require a 1-year or 3-year commitment in exchange for up to 70% off. These are critical for steady-state workloads.
Finally, you have managed services that shift operational overhead to Google. For example, Cloud Run (serverless containers) scales to zero when idle — you pay nothing when no requests arrive. App Engine (platform-as-a-service) does similar auto-scaling. These services are more expensive per unit of compute but can be cheaper overall because you don't pay for idle time. The exam loves comparing the total cost of ownership between managed and unmanaged services.
Assess current spending
Open the Google Cloud Console billing section and review the Cost Table. Filter by service, project, and labels to identify the biggest cost drivers. This step gives you a baseline to measure improvements against.
Identify idle and underutilised resources
Use the Idle VM Recommender and Rightsizing Recommender to find instances running with low CPU or memory usage. Also check for unattached persistent disks and static IPs not in use. These are the easiest resources to eliminate.
Right-size active resources
For each instance that shows low utilisation but cannot be stopped, change the machine type to one with fewer vCPUs or less memory. Use custom machine types to match the exact resource profile. This reduces compute charges immediately.
Set up autoscaling and budget alerts
Configure managed instance groups with autoscaling based on CPU utilisation or request count. Set the minimum instance count to a low number, ideally zero for non-production environments. Create a budget alert with a threshold that triggers a notification and optionally a Cloud Function to shut down resources.
Optimise storage and data transfer
Move infrequently accessed data to Nearline, Coldline, or Archive storage classes based on access patterns. Implement Cloud CDN to cache static content and reduce egress costs. Use Cloud Memorystore for caching frequently queried database results.
Leverage discounts and commitments
For steady-state workloads, purchase committed use discounts for 1 or 3 years. Review sustained use discounts already applied and calculate whether a commitment would save more. Ensure you understand the region and machine type restrictions before purchasing.
Meet Priya, a cloud developer at a mid-sized e-commerce company. She's responsible for the product catalogue application — the page that shows shoes, prices, and availability. Last month, the finance team emailed her CEO with a bill that was 40% higher than expected. Priya gets called into a meeting where the CEO says, 'We need to halve our cloud costs without slowing down the site.'
Priya starts by opening the Google Cloud Console and navigating to the billing reports. She filters by the last 30 days. The Cost Table shows that Compute Engine accounts for 70% of spending, with Cloud SQL (managed database) at 20% and Cloud Storage at 10%. She drills into Compute Engine and sees a list of all running virtual machines. Two instances catch her eye: a development server and a staging server labelled 'do-not-delete'. Both have been running 24/7 for three months. The development server isn't being used at all — the team finished that sprint weeks ago.
Step one: Priya stops the development server. She takes a snapshot of its disk first just in case someone needs it later. That saves about 400 Australian dollars per month.
Step two: she examines the staging server. It's a n1-standard-4 (4 vCPUs, 15 GB memory) running a load test every night. Using Cloud Monitoring, she sees the CPU never goes above 15% and memory sits at 30%. She right-sizes it to an n1-standard-2 (2 vCPUs, 7.5 GB memory). Savings: another 200 dollars per month.
Step three: Priya turns to Cloud SQL. The development database is also idle. She deletes it but keeps a backup exported to Cloud Storage. Savings: 150 dollars per month.
Step four: she looks at the production servers. They handle real user traffic so she can't just stop them. But Cloud Monitoring shows that from midnight to 6 AM, the CPU barely hits 5%. She sets up a managed instance group with autoscaling based on CPU utilisation. This way, the group scales down to one instance during quiet hours and scales up to five instances during peak shopping times. Savings: about 300 dollars per month.
Step five: Priya checks the Recommenders section. The Idle VM Recommender confirms the two servers she already shut down. The Committed Use Discount Recommender shows she could save 40% on the production servers by committing to a one-year contract. She runs the numbers — the workload is stable; she commits. Savings: another 600 dollars per month.
Step six: performance time. Users have been complaining that the product page loads slowly on mobile. Priya uses Cloud Trace to sample a few thousand requests. She finds that the main bottleneck is a database query that fetches all product images every time a page loads. She adds a caching layer using Cloud CDN (Content Delivery Network) for images and Cloud Memorystore (managed Redis) for product metadata. Latency drops from 4 seconds to 800 milliseconds. The CDN also reduces egress costs because images are served from edge locations close to users.
Priya presents her changes to the CEO: total monthly savings of 1,650 dollars (50% reduction), plus a faster site. The CEO is happy. The exam expects you to know the exact steps Priya took and the specific Google Cloud tools she used.
The PCD exam tests cost and performance optimisation through scenario-based multiple-choice questions. You won't be asked to calculate actual dollar values, but you'll need to identify the correct tool or approach for a given situation.
Here are the specific concepts they love to test:
Recommenders: You must know the five main types: Idle VM Recommender, Persistent Disk Snapshot Recommender, Committed Use Discount Recommender, Rightsizing Recommender, and the new Unattached IP Address Recommender. A typical question: 'Your team has several VM instances that have had low CPU utilisation for the past 14 days. What should you do?' The correct answer is to use the Rightsizing Recommender, not to immediately delete the instances.
Budget alerts and billing exports: You will see questions asking how to set up a budget that triggers an action when spending exceeds a threshold. The answer is to create a budget alert in the billing console and configure a Pub/Sub notification that triggers a Cloud Function to shut down resources.
Sustained vs committed use discounts: Know the difference cold. Sustained use is automatic for instances running over 25% of a month. Committed use is a manual 1- or 3-year agreement. A classic trap: they describe a temporary workload (three months) and ask which discount to apply. The correct answer is neither — sustained use applies but committed use requires a year.
Managed instance groups and autoscaling: You'll be given a scenario with variable traffic and asked to choose the most cost-effective scaling approach. The answer is usually a managed instance group with autoscaling based on CPU utilisation or request count, scaled down to zero if possible.
Serverless vs compute engine: They will ask you to compare costs for a batch processing job that runs once a day for 10 minutes. The cheaper option is almost always serverless (Cloud Run or Cloud Functions) because you pay only for the execution time, not for idle instance time.
Storage class selection: Questions about storing archival data (logs from two years ago) versus frequently accessed data. Correct choices are Nearline (30-day minimum), Coldline (90-day minimum), and Archive (365-day minimum). Know the minimum storage durations.
Cloud CDN and caching: They test whether you know that CDN reduces both latency and egress costs. A common trap involves forgetting that CDN charges for cache misses — so for data that rarely repeats, CDN may not be cost-effective.
Cloud Trace and Cloud Profiler: They ask which tool to use to find a slow database query. Answer: Cloud Trace. Which tool to find a memory leak in production code? Answer: Cloud Profiler.
Trap patterns to watch for:
The 'just delete it' trap: A question presents idle resources and asks for the 'most cost-effective action'. Some beginners pick 'immediately delete the instance'. The correct answer is usually 'create a snapshot first, then delete' or 'use the Idle VM Recommender to confirm'.
The 'always use the cheapest' trap: They give a scenario where cheap storage causes terrible latency. The correct answer is to right-size, not just choose the cheapest option.
The 'discount overcommit' trap: They ask about a workload that might be migrated to another cloud next year. The trap answer is 'buy a 3-year committed use discount'. The correct answer is to avoid committed use discounts for workloads with uncertain futures.
Key definitions to memorise:
Right-sizing: Matching resource allocation to actual usage patterns.
Autoscaling: Automatically adjusting the number of compute instances based on load.
Sustained use discount: Automatic discount for running instances over a certain percentage of a month.
Committed use discount: Discount in exchange for a 1- or 3-year payment commitment.
Idle resource: A resource running with no significant utilisation.
Coldline storage: A storage class for data accessed less than once a quarter, with a 90-day minimum storage duration.
Cloud cost management is about actively monitoring spending, not just checking the bill at month-end.
Right-sizing resources — matching machine type to actual usage — is the single most impactful cost-saving action you can take.
Autoscaling saves money only when you also reduce the minimum number of instances during low-traffic periods.
Sustained use discounts apply automatically; committed use discounts require a manual 1- or 3-year purchase.
Cloud Trace identifies latency bottlenecks in your application; Cloud Profiler identifies CPU and memory hotspots in your code.
Use the Idle VM Recommender before stopping any instance to confirm it's genuinely unused.
Serverless is cost-effective for bursty, short-lived workloads, but Compute Engine with committed use discounts can be cheaper for steady-state applications.
Storage class selection matters: Archive storage has a 365-day minimum and high retrieval costs; use it only for long-term archival data.
These come up on the exam all the time. Here's how to tell them apart.
Sustained Use Discount
Applies automatically when an instance runs over 25% of a month
No upfront commitment required
Discount scales up to 30% based on usage
Committed Use Discount
Requires a manual 1- or 3-year purchase
Discount can be up to 70%
Applies only to specific regions and machine types
Cloud Monitoring
Collects numerical metrics (CPU, memory, latency)
Sends alerts based on threshold conditions
Used for setting dashboards and uptime checks
Cloud Logging
Stores and indexes text log entries
Allows searching and filtering of log data
Used for debugging and auditing
Cloud Trace
Samples and analyses latency across requests
Shows how long each service call takes
Identifies slow database queries and external API calls
Cloud Profiler
Samples CPU and heap usage continuously
Shows which functions or methods consume the most CPU time or memory
Identifies memory leaks and CPU bottlenecks in code
Serverless (Cloud Run)
Scales to zero when idle; pay only for request processing
No infrastructure management; automatic scaling
Cost per request is higher but no idle charges
Compute Engine (VM)
Charges per second while running, even if idle
Full control over the operating system and environment
Lower per-hour cost for steady-state workloads with discounts
Standard Storage Class
No minimum storage duration
Lower retrieval fees
Ideal for frequently accessed data
Archive Storage Class
365-day minimum storage duration
Higher retrieval fees
Ideal for data accessed less than once a year
Mistake
If I stop a Compute Engine instance, I stop being charged for it entirely.
Correct
Stopping an instance stops compute charges (vCPU and memory), but you still pay for persistent disk storage, static IP addresses, and any snapshots attached to that instance.
This misconception is common because beginners forget that storage and IP addresses are billed separately and persist when the instance is stopped. The Google Cloud Console shows compute charges separately, so it looks like costs go to zero.
Mistake
Autoscaling always saves money because it adds instances only when needed.
Correct
Autoscaling can increase costs if not configured correctly, because adding instances incurs new charges. The goal is to reduce the minimum number of running instances during low traffic, not just scale up reactively.
People assume autoscaling is purely a cost-saving mechanism, but it's actually a performance and reliability feature. If the minimum instance count is set too high, you still pay for idle capacity.
Mistake
Cloud Monitoring and Cloud Logging are the same tool.
Correct
Cloud Monitoring collects metrics (CPU, memory, latency) and sends alerts; Cloud Logging stores and lets you search through log text (error messages, access logs). They are separate products within the operations suite.
Both appear under the 'Operations' category in the console and are often mentioned together, leading beginners to conflate them. The exam tests the distinction explicitly.
Mistake
A committed use discount automatically applies to any instance I run.
Correct
Committed use discounts must be purchased in advance and apply only to instances in a specific region and with specific machine types. You cannot apply the discount retroactively.
Because sustained use discounts are automatic, beginners assume committed use discounts work the same way. They don't — you must actively purchase them.
Mistake
The cheapest storage class (Archive) is fine for any data I don't access often.
Correct
Archive storage has a 365-day minimum storage duration and a higher retrieval fee. If you accidentally store data you later need or delete it early, you'll pay more than if you had used Coldline or Standard storage.
Beginners see the low per-GB price and ignore the retrieval costs and minimum commitments. The exam loves testing storage class minimum duration rules.
Mistake
Using serverless always costs less than Compute Engine.
Correct
Serverless costs less for sporadic, short-lived workloads, but can cost more for steady-state, high-traffic workloads because per-invocation fees and concurrency pricing add up. Compute Engine with committed use discounts can be cheaper for continuous high usage.
The marketing around 'pay only for what you use' makes serverless sound universally cheaper, but the pricing models differ. The exam presents scenarios where Compute Engine is the cost leader.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Cloud Monitoring collects numerical metrics like CPU usage and latency, and sends alerts when thresholds are breached. Cloud Logging stores text logs (error messages, access logs) for search and analysis. They serve different purposes but work together.
Yes. Sustained use discounts automatically apply when you run an instance for more than 25% of a billing month, up to a 30% discount. For larger savings, you can purchase committed use discounts with a 1- or 3-year commitment.
Base it on how often you access the data. Standard for frequently accessed data (multiple times per month), Nearline for data accessed less than once a month, Coldline for quarterly access, and Archive for data you expect to keep for a year or more and access rarely.
Immediately check the Cost Table in the billing section to identify which service and project caused the increase. Look for new instances, increased data transfer, or misconfigured autoscaling. Then review Cloud Monitoring alerts to see if there was a traffic surge or a deployment error.
No. Stopping a VM stops compute charges for vCPU and memory, but you continue to pay for attached persistent disks, static IP addresses, and snapshots. To stop all charges, you must delete the instance and release the IP address.
The Idle VM Recommender is a tool in the Google Cloud Console that analyses your instances and flags any that have had low CPU, memory, and network activity for a prolonged period. You review its recommendations and decide whether to stop or delete those instances.
You've finished Cost Management and Performance Optimization. Continue through the PCD study guide to build a complete picture of the exam.
Done with this chapter?