Spot VMs is a great way to reduce cost for interruptible, stateless and fault-tolerant workloads like batch processing or containers. Starting these types of VMs follows the same principles as regular VMs. The following snippet launches a C4A Spot VM:

Google Cloud Migration Center is a great way to understand the total cost of ownership (TCO) for a migration to Google Cloud by running automatic assessments or uploading information about an estate using the output of tools such as RVTools.

The power of groups

IT environments can be quite complex and may have grown over the years. Line of businesses may have different requirements in terms of the compute platform or locality of their workloads. In order to accurately model these requirements, Migration Center uses Groups to logically group discovered assets.

It could happen. Total mahem. An administrative pricipal for a project was accidentally leaked. An attacker has taken you projects hostage. You need to recover and fast. Restoring project access is the least of your worries your concern is to restore services. Luckily you have all workloads protected with snapshots! All deleted by the attacker! This is an exaggerated and hypothetical scenario but I have seen similar things happening. In this article I’m exploring an approach to protect against such a scenario.

Identity-Aware Proxy (IAP) is a powerful tool in the tool chain of Google Cloud administrators and users. It can be used to control access to cloud-based and on-premises applications and VMs running on Google Cloud.

IAP adds *common *authentication and authorization infrastructure based on Cloud IAM to connections without the need for a change to program or protocol logic. By removing the need to expose connection endpoints to the public internet, IAP works from all networks without the need for a VPN connection.

One of the most requested features from customers that deploy Cloud SQL for SQL Server (Cloud SQL) has been Active Directory integration which was released last year. Since then Google Cloud has added cross-project capability which allows you to connect your Cloud SQL instance into a project that is different than the one hosting Managed Microsoft AD (Managed AD).

Many enterprises that migrate their IT estate to cloud will face the question on how to continue to support operations across workloads that remain on-premises and workloads that are migrated to cloud.

While virtual machines (VMs) behave largely the same in cloud from a data plane (what is happening on the inside of the VM), control plane functions can differ significantly.

Sole-tenant nodes are an important service on Google Cloud Platform to run workloads that require workload isolation or need to comply to specific licensing requirements that demand dedicated infrastructure. A detailed description what a Sole-Tenant Node is and how it is different from general fleet VMs can be found in the Compute Engine documentation.

Sole-tenant nodes are being used by customers for workload isolation and also for licensing compliance (e.g. bringing Window Server licenses). Throughout the life cycle of a sole-tenant node there might be the necessity of moving virtual machines to another node group or even to another machine family (e.g. moving to N2 from N1). Refer to the documentation, to learn more about Node affinity and anti-affinity options.

This article has now been published on the official Google Cloud Blog.

If you happen to use a Mac based keyboard and Google Cloud Shell you might be facing some issues when typing special chars such as \, |. There is a simple fix, that’ll get you going.

Hit the cog on the left upper side in Cloud Shell: