When customers migrate to Google Cloud Platform (GCP), their first step is often to adopt Compute Engine, which makes it easy to procure and set up virtual machines (VMs) in the cloud that provide large amounts of computing power. Launched in 2012, Compute Engine offers multiple machine types, many innovative features, and is available in 20 regions and 61 zones! 

Compute Engine’s predefined and custom machine types make it easy to choose VMs closest to your on-premises infrastructure, accelerating the workload migration process cost effectively. Cloud allows you the pricing advantage of ‘pay as you go’ and also provides significant savings as you use more compute with Sustained Use Discounts. 

As Technical Account Managers, we work with large enterprise customers to analyze their monthly spend and recommend optimization opportunities. In this blog, we will share the top recommendations that we’ve developed based on our collective experience working with GCP customers. 

Getting ready to save

Before you get started, be sure to familiarize yourself with the VM instance pricing page—required reading for anyone who needs to understand the Compute Engine billing model and resource-based pricing. In addition to those topics, you’ll also find information about the various Compute Engine machine types, committed use discounts and how to view your usage, among other things. 

Another important step to gain visibility into your Compute Engine cost is using Billing reports in the Google Cloud Console and customizing your views based on filtering and grouping by projects, labels and more. From there you can export Compute Engine usage details to BigQuery for more granular analysis. This allows you to query the datastore to understand your project’s vCPU usage trends and how many vCPUs can be reclaimed. If you have defined thresholds for the number of cores per project, usage trends can help you spot anomalies and take proactive actions. These actions could be rightsizing the VMs or reclaiming idle VMs.

Now, with these things under your belt, let’s go over the five ways you can optimize your Compute Engine resources that we believe will give you the most immediate benefit. 

1. Apply Compute Engine rightsizing recommendations

Compute Engine’s rightsizing recommendations feature provides machine type recommendations that are generated automatically based on system metrics gathered by Stackdriver Monitoring over the past eight days. Use these recommendations to resize your instance’s machine type to more efficiently use the instance’s resources. It also recommends custom machine types when appropropriate. Compute Engine makes viewing, resizing and other actions easier right from the Cloud Console as shown below. 

Recently, we expanded Compute Engine rightsizing capabilities from just individual instances to managed instance groups as well. Check out the documentation for more details.

For more precise recommendations, you can install the Stackdriver Monitoring agent which collects additional disk, CPU, network, and process metrics from your VM instances to better estimate your resource requirements. You can also leverage the Recommender API for managing recommendations at scale.

2. Purchase Commitments

Our customers have diverse workloads running on Google Cloud with differing availability requirements. Many customers follow a 70/30 rule when it comes to managing their VM fleet—they have constant year-round usage of ~70%, and a seasonal burst of ~30% during holidays or special events. 

If this sounds like you, you are probably provisioning resources for peak capacity. However, after migrating to Google Cloud, you can baseline your usage and take advantage of deeper discounts for Compute workloads. Committed Use Discounts are ideal if you have a predictable steady-state workload as you can purchase a one or three year commitment in exchange for a substantial discount on your VM usage.

We recently released a Committed Use Discount analysis report in the Cloud Console that helps you understand and analyze the effectiveness of the commitments you’ve purchased. In addition to this, large enterprise customers can work with their Technical Account Managers who can help manage their commitment purchases and work proactively with them to increase Committed Use Discount coverage and utilization to maximize their savings.

3. Automate cost optimizations

The best way to make sure that your team is always following cost-optimization best practices is to automate them, reducing manual intervention.

Automation is greatly simplified using a label—a key-value pair applied to various Google Cloud services. For example, you could label instances that only developers use during business hours with “env: development.” You could then use Cloud Scheduler to schedule a serverless Cloud Function to shut them down over the weekend or after business hours and then restart them when needed. Here is an architecture diagram and code samples that you can use to do this yourself. 

Using Cloud Functions to automate the cleanup of other Compute Engine resources can also save you a lot of time and money. For example, customers often forget about unattached (orphaned) persistent disk, or unused IP addresses. These accrue costs, even if they are not attached to a virtual machine instance. VMs with the “deletion rule” option set to “keep disk” retain persistent disks even after the VM is deleted. That’s great if you need to save the data on that disk for a later time, but those orphaned persistent disks can add up quickly and are often forgotten! There is a Google Cloud Solutions article that describes the architecture and sample code for using Cloud Functions, Cloud Scheduler, and Stackdriver to automatically look for these orphaned disks, take a snapshot of them, and remove them. This solution can be used as a blueprint for other cost automations such as cleaning up unused IP addresses, or stopping idle VMs. 

4. Use preemptible VMs

If you have workloads that are fault tolerant, like HPC, big data, media transcoding, CI/CD pipelines or stateless web applications, using preemptible VMs to batch-process them can provide massive cost savings. In fact, customer Descartes Labs reduced their analysis costs by more than 70% by using preemptible VMs to process satellite imagery and help businesses and governments predict global food supplies.

Preemptible VMs are short lived— they can only run a maximum of 24 hours, and they may be shut down before the 24 hour mark as well. A 30-second preemption notice is sent to the instance when a VM needs to be reclaimed, and you can use a shutdown script to clean up in that 30-second period. Be sure to fully review the full list of stipulations when considering preemptible VMs for your workload. All machine types are available as preemptible VMs, and you can launch one simply by adding “-preemptible” to the gcloud command line or selecting the option from the Cloud Console. 

Using preemptible VMs in your architecture is a great way to scale compute at a discounted rate, but you need to be sure that the workload can handle the potential interruptions if the VM needs to be reclaimed. One way to handle this is to ensure your application is checkpointing as it processes data, i.e., that it’s writing to storage outside the VM itself, like Google Cloud Storage or a database. As an example, we have sample code for using a shutdown script to write a checkpoint file into a Cloud Storage bucket. For web applications behind a load balancer, consider using the 30-second preemption notice to drain connections to that VM so the traffic can be shifted to another VM. Some customers also choose to automate the shutdown of preemptible VMs on a rolling basis before the 24-hour period is over, to avoid having multiple VMs shut down at the same time if they were launched together. 

5. Try autoscaling 

Another great way to save on costs is to run only as much capacity as you need, when you need it. As we mentioned earlier, typically around 70% of capacity is needed for steady-state usage, but when you need extra capacity, it’s critical to have it available. In an on-prem environment, you need to purchase that extra capacity ahead of time. In the cloud, you can leverage autoscaling to automatically flex to increased capacity only when you need it. 

Compute Engine managed instance groups are what give you this autoscaling capability in Google Cloud. You can scale up gracefully to handle an increase in traffic, and then automatically scale down again when the need for instances is lowered (downscaling). You can scale based on CPU utilization, HTTP load balancing capacity, or Stackdriver Monitoring metrics. This gives you the flexibility to scale based on what matters most to your application. 

High costs do not compute

As we’ve shown above, there are many ways to optimize your Compute Engine costs. Monitoring your environment and understanding your usage patterns is key to understanding the best options to start with, taking the time to model your baseline costs up front. Then, there are a wide variety of strategies to implement depending on your workload and current operating model. 

For more on cost management, check out our cost management video playlist. And for more tips and tricks on saving money on other GCP services, check out our blog posts on Cloud Storage, Networking and BigQuery cost optimization strategies. We have additional blog posts coming soon, so stay tuned!

We’re thrilled to share the news that leading global research and advisory firm Forrester Research has named Google Cloud a Leader in the recently published report The Forrester Wave^TM: Public Cloud Container Platforms, Q1 2022. Forrester evaluated the container and cloud-native offerings of a select group of top public cloud container platform vendors across 29 comprehensive criteria. 

We are proud that Forrester evaluated the strength and cohesion of our offerings, including Google Kubernetes Engine (GKE), Cloud Run, Anthos, Cloud Build, Cloud Deploy, Cloud Code and more, writing that, “Google Cloud is the best fit for firms that want extensive cutting-edge cloud-native capabilities for distributed workloads spanning public cloud, private cloud, and multicloud environments.” 

Google Cloud received the highest possible scores in the criteria of service and application catalogs, microservice development support, service mesh support, serverless and FaaS support, DevOps automation, container image support, control plane configuration, hybrid cloud support, container networking, product vision, supporting products and services, market approach, revenue, and breadth of offering. We also achieved the highest score in the Strategy category of all the vendors evaluated.

Google Cloud is all-in on containers and cloud native 

The cloud-native tools and technologies created by Google Cloud are already powering the most innovative, scalable and secure apps around the world, from the most exciting digital natives to the most important enterprise industry leaders. Why? Cloud native means building and running modern apps that intentionally take advantage of the global scale, pervasive automation, elastic infrastructure, and secure resiliency of the public cloud. 

For enterprises, cloud native in practice means using containers, Kubernetes, serverless, and DevOps automation to build amazing customer-facing apps quickly, to modernize existing business-critical apps safely, and to operate them all on cost-efficient, powerful, and secure cloud infrastructure globally.Over the past decade, Google Cloud’s technology innovation has fueled various domains of the cloud native ecosystem, such as Kubernetes and Go languages as the foundation, Istio for service mesh, Kubeflow for machine learning, Knative for serverless, and Tekton for CI/CD. Long-term investment and practices in cloud-native power its superior product vision and excellent supporting products and services.The Forrester Wave: Public Cloud Container Platforms, Q1 2022

Dedicated to simplicity, speed, and scale for your modern apps

Our mission is to create, integrate, scale, and secure the best open source and commercial cloud-native technologies – backed by a consistent cloud control plane – so you can spend more time dreaming of ways to delight your customers and less time building and operating platforms. We are committed to leading in cloud-native open source communities and making containers and Kubernetes accessible to everyone, from everywhere. 

Here are a few recent highlights across our container services and tools, aimed at helping you build and modernize your most important apps with cloud native:

The most scalable fully managed Kubernetes service, Google Kubernetes Engine (GKE), achieved an overall solution score of 92 out of 100 in Gartner’s Solution Scorecard. In 2021, we introduced GKE Autopilot, a fully managed, security-hardened Kubernetes service optimized for production workloads. This unique mode of operation allows you to focus on your workloads while Google manages your cluster infrastructure. There’s nothing else like it. Then, we made GKE apps even faster with GKE image streaming. With proven scalability to 15K nodes in a single cluster and innovations such as four-way autoscaling, node auto-upgrades, integrated logging and metrics, cost optimization insights, native backup and restore, and multi-instance GPUs to accelerate machine learning workloads, GKE remains the best choice in managed Kubernetes services.

With Cloud Run, we expanded the range of users who benefit from containers to those who don’t know much about them. Introduced in 2019, Cloud Run combines the serverless attributes of autoscaling and developer experience with the flexibility of containers. Developers can use any language, runtime or binary, and deploy code using buildpacks to automatically build container images from source without worrying about provisioning machines and clusters. Cloud Run goes beyond FaaS and beyond earlier generations of serverless computing. Cloud Run runs more legacy workloads, integrates with Cloud Build for secure and compliant builds, offers deeper cost controls and billing flexibility, and encourages portability. We added support for social feeds, collaborative editing, and multiplayer games that use bidirectional streaming. Minimum instances reduce cold-start delays so you can run more latency-sensitive applications. And recently, we launched support for network file systems, allowing developers to share and persist data between multiple containers and services.

Anthos is at the heart of the Google Distributed Cloud, a portfolio of software and hardware solutions announced in 2021 that extend Google’s container platform services to the data center and the edge. Anthos is how we extend GKE to wherever you need cloud-native apps. Manage clusters on-premises on bare metal and VMware-virtualized servers, on AWS and Azure, and at the edge – all with a Google Cloud-backed control plane for consistent, automated operations at scale. We added a hosted service for configuration management to keep all your clusters in sync, and trimmed our installation footprint and streamlined cluster management with a new multi-cloud API that enables you to use a single API for full lifecycle management of Anthos Kubernetes clusters in AWS or Azure.

Finally, since no public cloud container platform is complete without powerful DevOps tools, we expanded our CI/CD offerings to make your developers even more productive, wherever they build and deploy cloud native apps. Use Cloud Code and Cloud Shell as your go-to cloud-native IDEs. Cloud Build is a fully managed serverless DevOps automation platform for use cases spanning CI/CD, Infrastructure-as-Code, AI/MLOps, and more, across infrastructure GKE, Cloud Run, Cloud Functions and more. Google Cloud Deploy is a fully managed continuous delivery service that provides one-click release promotion and roll-backs, built-in metrics, and out-of-the-box security. Artifact Registry and Container Analysis provide managed artifact repositories, vulnerability scanning, and help secure the software supply chain.Google Cloud has a solid cloud-native innovation roadmap, targeting simplicity at scale for enterprise clients.The Forrester Wave: Public Cloud Container Platforms, Q1 2022

We are delighted and humbled to be recognized as a Leader in public cloud container platforms by Forrester. Grab your copy of The Forrester Wave^TM: Public Cloud Container Platforms, Q1 2022 today and let us know how we can help you build and modernize your most important apps how you want and where you want.

Enterprise application teams need to manage more than just containers in their software supply chain. That’s why we created Artifact Registry, a fully-managed service with support for both container images and non-container artifacts.

Artifact Registry improves and extends upon the existing capabilities of Container Registry, such as customer-managed encryption keys, VPC-SC support, Pub/Sub notifications, and more, providing a foundation for major upgrades in security, scalability and control. While Container Registry is still available and will continue to be supported as a Google Enterprise API, going forward new features will only be available in Artifact Registry, and Container Registry will only receive critical security fixes.

Below, we’ll highlight the key improvements Artifact Registry provides over Container Registry, as well as the steps to start using it today.

A unified control plane for container, OS and language repositories

Artifact Registry includes more than just container images: as a developer, you can store multiple artifact formats, including OS packages for Debian and RPM, as well as language packages for popular languages like Python, Java, and Node. In addition, you can manage them all from a single, unified interface. 

A more granular permission model with Cloud IAM

Artifact Registry comes with fine-grained access control via Cloud IAM. Unlike Container Registry, this allows you to control access on a per-repository basis, rather than all images stored in a project. This enables you to scope permissions as granularly as possible, for example to specific regions or environments as necessary.

Repositories in the region of your choice

Artifact Registry supports the creation of regional repositories, which allows you to put your artifacts and data directly in the location that they’ll be used, allowing for higher availability and speed. In Container Registry, you’re limited to “multi-regions”: for example, the closest multi-region for Australia is Asia. However, with Artifact Registry’s regional support, you can create a repository directly in the Sydney data center.

A pricing model that respects your region

While Artifact Registry’s pricing is still based on a combination of network egress and storage usage, support for regional repositories means that you can choose in what region to host your container repositories. Although per unit storage costs are higher for Artifact Registry, optimizing the locations of your repositories to be hosted in the same region where they are used can result in cost savings, because any network traffic within the same region is not considered egress and is thus free.

Part of a secure supply chain

Artifact Registry was designed from the ground up to integrate into our suite of secure supply chain products. This means that it can optionally use Container Analysis to scan your container images for vulnerabilities as they’re uploaded to Artifact Registry, and works directly with Binary Authorization to secure your deployments.

We’re here to help you migrate

If you already use Container Registry, you can take advantage of all the current and upcoming features of container image storage with Artifact Registry by migrating to it. To help, we’ve prepared the following guides:

• Transitioning from Container Registry provides an overview of how to use Artifact Registry instead of Container Registry in a backwards-compatible way
• Copying images from Container Registry guide you to move container images from an existing repository to an Artifact Registry repository

If you’re currently hosting your container images with a third party, you can begin using Artifact Registry directly, by following the instructions in our guide, Migrating containers from a third-party registry, which shows you how to avoid rate limits on image pulls or third-party outages which can disrupt your builds and deployments.

And if you’re just getting started storing container images, you can begin using Artifact Registry as your image repository right away. To learn how, check out Artifact Registry quickstart for Docker, a guide to using Artifact Registry as a single location for managing private packages and Docker container images.

Join our community 

Our Artifact Registry communities are also great resources to help answer your questions and for guidance on best practices: 

• Ask questions on Stack Overflow using the google-artifact-registry tag
• Visit the Google Cloud Slack community and ask a question in the #artifact-registry channel. If you haven’t already joined the Slack community, use this form to sign up.

In an industry as highly regulated as healthcare, building a single secure and compliant application that tracks patient care and appointments at a clinic requires a great deal of planning from development and security teams. So, imagine what it would be like to build a solution that includes almost everything related to a patient’s healthcare, including insurance and billing. That’s what Highmark Health (Highmark)—a U.S. health and wellness organization that provides millions of customers with health insurance plans, a physician and hospital network, and a diverse portfolio of businesses–decided to do. 

Highmark is developing a solution called Living Health to re-imagine healthcare delivery, and it is using Google Cloud and the Google Cloud Professional Services Organization (PSO) to build and maintain the innovation platform supporting this forward thinking experience. Considering all the personal information that different parties like insurers, specialists, billers and coders, clinics, and hospitals share, Highmark must build security and compliance into every part of the solution. 

In this blog, we look at how Highmark Health and Google are using a technique called “secure-by-design” to address the security, privacy, and compliance aspects of bringing Living Health to life.

Secure-by-design: Preventive care for development

In healthcare, preventing an illness or condition is the ideal outcome. Preventive care often involves early intervention—a course of ideas and actions to ward off illness, permanent injury, and so on. Interestingly, when developing a groundbreaking delivery model like Living Health, it’s a good idea to take the same approach to security, privacy, and compliance. 

That’s why Highmark’s security and technology teams worked with their Google Cloud PSO team to implement secure-by-design for every step of design, development, and operations. Security is built into the entire development process rather than waiting until after implementation to reactively secure the platform or remediate security gaps. 

It’s analogous to choosing the right brakes for a car before it rolls off the assembly line instead of having an inspector shut down production because the car failed its safety tests. The key aspect of secure-by-design is an underlying application architecture created from foundational building blocks that sit on top of a secure cloud infrastructure. Secure-by-design works to ensure that these building blocks are secure and compliant before moving on to development.

The entire approach requires security, development, and cloud teams to work together with other stakeholders. Most importantly, it requires a cloud partner, cloud services, and a cloud infrastructure that can support it. 

Finding the right cloud and services for secure-by-design 

Highmark chose Google Cloud because of its leadership in analytics, infrastructure services, and platform as a service. In addition, Google Cloud has made strategic investments in healthcare interoperability and innovation, which was another key reason Highmark decided to work with Google. As a result, Highmark felt that Google Cloud and the Google Cloud PSO were best suited for delivering on the vision of Living Health—its security and its outcomes. 

“Google takes security more seriously than the other providers we considered, which is very important to an organization like us. Cloud applications and infrastructure for healthcare must be secure and compliant,” explains Highmark Vice President and Chief Information Security Officer, Omar Khawaja. 

Forming a foundation for security and compliance

How does security-by-design with services work? It starts with the creation and securing of the foundational platform, allowing teams to harden and enforce specified security controls. It’s a collaborative process that starts with input from cross-functional teams—not just technology teams—using terms they understand, so that everyone has a stake in the design. 

A strong data governance and protection program classifies and segments workloads based on risk and sensitivity. Teams build multiple layers of defense into the foundational layers to mitigate against key industry risks. Google managed services such as VPC Service Controls help prevent unauthorized access. Automated controls such as those in Data Loss Prevention help teams quickly classify data and identify and respond to potential sources of data risk. Automation capabilities help ensure that security policies are enforced.

After the foundational work is done, it’s time to assess and apply security controls to the different building blocks, which are Google Cloud services such as Google Kubernetes Engine, Google Compute Engine, and Google Cloud Storage. The goal is to make sure that these and similar building blocks, or any combination of them, do not introduce additional risks and to ensure any identified risks are remediated or mitigated. 

Enabling use cases, step by step

After the foundational security is established, the security-by-design program enables the Google Cloud services that developers then use to build use cases that form Living Health. The service enablement approach allows Highmark to address complexity by providing the controls most relevant for each individual service. 

For each service, the teams begin by determining the risks and the controls that can reduce them. The next step is enforcing preventive and detective controls across various tools. After validation, technical teams can be granted an authorization to operate, also called an ATO. An ATO authorizes the service for development in a use case.

For use cases with greater data sensitivity, the Highmark teams validate the recommended security controls with an external trust assessor, who uses the HITRUST Common Security Framework, which maps to certifications and compliance such as HIPAA, NIST, GDPR, and more. A certification process follows that can take anywhere from a few weeks to a few months. In addition to certification, there is ongoing monitoring of the environment for events, behavior, control effectiveness, and control lapses or any deviation from the controls.

The approach simplifies compliance for developers by abstracting compliance requirements away. The process provides developers a set of security requirements written in the language of the cloud, rather than in the language of compliance, providing more prescriptive guidance as they build solutions. Through the secure-by-design program, the Highmark technology and security teams, Google, the business, and the third-party trust assessor all contribute to a secure foundation for any architectural design with enabled Google Cloud services as building blocks. 

Beating the learning curve 

Thanks to the Living Health project, the Highmark technology and security teams are trying new methods. They are exploring new tools for building secure applications in the cloud. They are paying close attention to processes and the use case steps and, when necessary, aligning different teams to execute. Because everyone is working together collaboratively toward a shared goal, teams are delivering more things on time and with predictability, which has reduced volatility and surprises. 

The secrets to success: Bringing everyone to the table early and with humility

Together, Highmark and Google Cloud PSO have created over 24 secure-by-design building blocks by bringing everyone to the table early and relying on thoughtful, honest communication. Input for the architecture design produced for Highmark came from privacy teams, legal teams, security teams, and the teams that are building the applications. And that degree of collaboration ultimately leads to a much better product because everyone has a shared sense of responsibility and ownership of what was built. 

Delivering a highly complex solution like Living Health takes significant, more purposeful communication and execution. It is also important to be honest and humble. The security, technology, and Google teams have learned to admit when something isn’t working and to ask for help or ideas for a solution. The teams are also able to accept that they don’t have all the answers, and that they need to figure out solutions by experimenting. Khawaja puts it simply, “That level of humility has been really important and enabled us to have the successes that we’ve had. And hopefully that’ll be something that we continue to retain in our DNA.”