Collectively, the three major players in cloud services offerings harvested 65% of the total global spend on cloud computing. In Q1 of 2022, that sees AWS with 33%, Microsoft's Azure with 22%, and Google with 10% coverage in the market.
So, how does the youngest and smallest of the giants hold up against its rivals? Let’s briefly consider the benchmarks that GCP has performed. A 2021 benchmark report reveals that the Google Cloud Platform (GCP) delivered the most throughput in terms of:
storage I/O read throughput
storage I/O write throughput
maximum throughput per minute
GCP’s top-performing machine had 165% and 237% more throughput than AWS and Azure, respectively. This trend held even with GCP’s bottom-performing network throughput machine performing 62% and 105% better than AWS’ and Azure’s top-performing network throughput machines. However, it may well be a case of “you get what you pay for”, as the same report puts AWS as the cheaper option, while GCP offered the best performance per dollar.
Performance aside, this article will focus on the issue that often burns hardest: GCP’s pricing model and cloud cost management.
Within GCP’s architecture is the concept of a project. Each project that you create has a billing account attached to it. Any charges incurred by the services that you initiate are billed to the attached billing account. One billing account can, therefore, be applied to multiple projects.
This approach is perhaps less oblique than AWS' and Azure's, which offer free tier services for up to 12 months to new customers. Although the GCP, along with the other two cloud computing giants, combine their new customer treats with an "always free" usage threshold for certain services. GCP offers over 20 products that are free up to designated monthly thresholds.
Much as we love something for nothing, that $300 can be burned up quickly, so too those monthly thresholds, so what can you expect to pay for?
GCP Pricing Models
Much like the competition, GCP offers:
Pay-as-you-go: GCP's pay-as-you-go pricing structure charges you only for the services you use. You will not pay anything up-front, nor will you be charged for terminating instances or services.
Committed use: To save money, you can pre-pay for resources. For example, committed use discounts on GCP's Compute Engine (their virtual machines) can save up to 57%.
There are also great savings to be made if you require the computing power, but not any guaranteed consistency of service. GCP offers Spot VMs, i.e., preemptible computing power, at a 60–91% discount. Of course, you lose your instance if the GCP needs to reclaim those resources for other tasks. This means such an approach is only suitable for workloads that are fault-tolerant.
GCP Services and Pricing
It is not the intention of this article to give you an overview of every service offered by the GCP or the GCP marketplace; rather, we will discuss the more popular service offerings and how the GCP charges for those.
GCP’s Compute Engine is part of its IaaS (Infrastructure as a Service), equivalent to AWS’ EC2 service. GCP takes its pay-for-what-you-use very seriously, with all vCPUs, GPUs, and GB of memory charged in per-second increments, with a 60-second minimum.
You can opt for either of the models discussed above: pay-as-you-go or committed use. The GCP even rewards the pay-as-you-go user with sustained use discounts. Even if you don’t commit and apply the committed use model, there are discounts of up to 30% for running specific Compute Engine resources for a significant portion of a billing cycle.
Google Kubernetes Engine(GKE)
Google Kubernetes (GKE) is the managed Kubernetes solution within GCP. Kubernetes provides automated container orchestration and efficient machine management and also improves reliability and decreases the time and resources attributed to DevOps. Google is deeply connected with Kubernetes, having donated Kubernetes as the founding project of the Cloud Native Computing Foundation (CNCF). Google continues to support the CNCF.
Kubernetes Engine autoscaling handles increased user demand for your services, keeping them available when it matters most. GKE is a managed service, and you can easily install and configure High Available Kubernetes Cluster with that service. It is a robust and stable service, and upgrades are incredibly simple on GKE. This is significant to DevOps Team because such upgrades are notorious among Operational Teams maintaining on-premise systems.
Cloud Storage is the GCP’s version of AWS S3. Buckets are charged per GB, and prices vary according to both the region they are in and the storage type, which may consist of standard, nearline, coldline, or archival storage.
Each storage type has a minimum charge, i.e., the expectation is that the data is stored for a minimum time, and that period raises a charge:
Standard: no minimum
Nearline: 30 days
Coldline: 90 days
Archival: 365 days
So, while you can delete, replace, or move an object before it has been stored for the minimum duration, you are charged as if the object was stored for that duration.
Of course, when applications rely on such data to function, then the data must be accessed. Such data will most typically be held in the “standard” or “nearline” tiers. The cost of accessing stored data varies by operation, with delete operations being free and other operations belonging to A- or B-grade pricing levels.
Such access is controlled via an API. Generally, with the exception of 404 responses, GCP doesn’t charge for operations that return 307, 4xx, or 5xx errors. When data does move, charges are raised for egress. Note, in the GCP, egress is data sent from Cloud Storage via HTTP. So, network egress applies when you move or copy data from one Cloud Storage bucket to another or when a GCP service accesses data in your Cloud Storage bucket. Ingress represents data sent to Cloud Storage in HTTP requests, but ingress is not charged for.
In some scenarios, egress is also free, for example, moving data within the same region. In other scenarios, egress is charged for, for example, moving data between continents (different regions).
Note that the cloud bucket storage described is not the same service as a Google persistent disk. A persistent disk is a component that may be added to a virtual machine, i.e., a Compute Engine instance, as discussed above. A persistent disk can be a cheaper solution: if a virtual machine needs local data access or needs to share local data with other virtual machines. Also, a virtual disk provides lower latency for read/write operations.
Virtual Private Cloud
If you connect Compute Engine instances, then you have built yourself a VPC, a virtual private cloud. Similar to Cloud Storage, ingress itself is free. However, if the ingress triggers an operation, for example, load balancing, then that operation may be charged.
When creating a VPC, you are connecting virtual machines, so ingress from one VM (virtual machine) equates to egress from another. The egress may be charged and charged per GB delivered. If you use the internal IP address of the devices, you are connecting within the same network, and no charges will be raised. Cross GCP zones or regions, and charges will ensue, even if you are on the same subnet.
There are some egress scenarios that are free of charge, such as when a VM calls upon a Google service such as the oracle Google Maps, or the Google streaming platform, YouTube.
Other services that raise charges include:
Reserving an external IP (which is more expensive if you reserve it but don’t use it)
Forwarding rules to the GCP API
Load balancing (HTTP and TCP/UDP)
These network services come in two tiers:
Premium tier delivers traffic on Google's premium backbone
Standard tier uses regular ISP networks
Not only are some services priced differently, those “always free” threshold limits do not apply to Standard Tier. There are some shared pricing strategies between the two tiers, for example, the price of IP addresses, instances, and forwarding rules.
The cloud service model is all about abstracting away the work required to setup the architecture that supports your tech. That means there is no need to establish your own backbone of Compute Engine instances or storage buckets in every region that you serve visitors content: instead, tap into GCP’s Content Delivery Network (CDN).
If you are serving up cacheable content, you pay for the cache lookup and cache egress in terms of bandwidth provided for HTTP/S requests. The egress charges will vary based on both the destination and usage. Usage is charged monthly per project per destination. The destination is determined by the client's IP address.
If the content is non-cacheable, then the charges are determined by the use case as it applies to (Cloud Storage or Compute Engine, as discussed above).
Most teams leveraging the CDN need to consider what the charges will be for:
Cache egress (cached responses served from Cloud CDN's caches)
Cache fill (you pay for the space you take up when filling the cache)
Cloud Load Balancing data processing
Cloud Storage operation charges (egress charges)
External backend operation charges (i.e., if an operation occurs in GVP Compute Engine instances, this may be charged)
If your content requirements are large (over 1 PB per month), you can discuss commitment-based reductions on rates with the GCP sales team.
GCP Database Services
GCP offers some seriously useful database services. There are 6 different database options that fit into 4 categories:
Relational Databases (Cloud SQL and Cloud Spanner)
Non-relational Databases (Cloud Datastore, Cloud Firestore, and Cloud Bigtable)
Object Storage (Cloud Storage)
Relational databases are restrictive in terms of design. All fields should be identified with the relationships between them established from the outset. Non-relational databases allow for the data types and fields to morph over time, without requiring a redesign of the database.
The Object storage option, for data such as images or other "blobs", is handled by Cloud Storage, covered above.
The "Warehouse" storage option is, in fact, a relational database, with data accessed using SQL. The reason it sits in its own category is that it is specifically set up to manage huge loads such as those created with data streaming, analytics, and reporting.
Cloud SQL is a managed relational storage provided by GCP that is used to store relational data. Cloud SQL will let you have a relational database in the cloud that is capable of handling gigabytes of data. There are other options that you should consider if you will be handling terabytes and petabytes of data.
Alongside the cost of the SQL instance itself, the following raise charges:
CPU (monthly or hourly pricing)
Memory (monthly or hourly pricing)
Storage (monthly hourly pricing)
Networking (monthly pricing)
Egress traffic (certain egress is not charged for)
Cloud Spanner is a relational database that provides transactional consistency at scale.
Alongside the cost of the amount of compute capacity in your instance, the following raise charges:
Amount of storage that your databases use
Amount of storage that your backups use (per GB)
Egress traffic (certain egress is not charged for)
Dataflow batch workers (when running exports or imports, the scenarios are a little complex, so do take time to understand the pricing)
Note that you are charged by instance, not by replica. Again, it is worth considering committed use to benefit from the discounts.
For a small application, Cloud Datastore could function as a free option, thanks to the daily allocation of free read, writes, and deletes; egress; operations; and the 1 GB of storage. Once those thresholds are crossed, then charges will be raised, with the exception of “small” operations, which maintain the free tier:
Read, write, delete (per 100,000 entities)
Stored data (per GB)
Such charges are very sensitive to the region in which they occur.
Firestore can act like a front end to Datastore or use its own database. Again you benefit from a free allocation, and ingress is free after that, expect daily charges for:
Number of documents you read, write, and delete.
Amount of storage that your database uses, including overhead for metadata and indexes (per gibibytes (GiB) where 1 GiB = 230 bytes)
Network bandwidth that you use (per GiB)
Validation of Firestore Security Rules (based on reads that are necessary to evaluate the rules).
Bigtable supports clusters that may be spread across regions/zones and duplicate nodes. Expect to be charged for:
The type of Bigtable instance and the total number of nodes in your instance's clusters
Amount of storage that your tables use (charged in GB/per month)
Amount of network bandwidth that you use (ingress and intra-region egress are free, cross-region egress is charged)
BigQuery can automatically allocate computing resources on an as-needed basis. Alternatively, you can reserve compute capacity, i.e., virtual CPUs. The pricing structure of BigQuery reflects the design you apply. Adopting the reservation approach means that you will be billed a flat rate per month or per annum for that designated service.
Analysis costs (charges raised by running queries)
“Slots” (the reserved compute capacity charged by region and available across projects: 100 slot minimum)
Analysis costs (charges raised by running queries)
Storage costs (charges for data)
Try it Yourself
The GCP provides a pricing calculator, so you can test the waters to predict what your cloud architecture may cost you.
Cloud Cost Management
With a firm understanding of what services you will pay for, you are well placed to ensure that you maintain control over your cloud costs. There are many tools and services that will also assist you to do so.
Billing and expense management tools like the GCP’s Quotas, Budgets, and Alerts let you stay on top of your current cloud costs to ensure you don't go over budget. To learn more about these, see the next article in this series.
A final word on cost control, remember overspending will occur if you are not aware that you pay for SaaS and PaaS according to what provision as well as what you consume. Keep a service running, and you’ll continue to incur costs. This is also true when you provision a specific resource above what you require, which is why right-sizing is a vital part of your cloud cost management strategy.