Compute Engine

Google Cloud Compute Engine (GCE) is an Infrastructure-as-a-Service (IaaS) offering that lets you run Virtual Machines (VMs) on Google’s global infrastructure. It delivers high-performance, bare-metal-like compute power with full OS-level control and flexible pay-as-you-go pricing.

Core Value Proposition

Flexibility & Scale: Rapidly adjust resources up or down manually or automatically based on demand.
Cost Efficiency: Pay only for what you consume via hourly/per-second billing, with deep discounts for fault-tolerant workloads.
Customization & Access: Choose any Linux or Windows OS, configure custom machine specs, and SSH directly into instances.
Bare-Metal Performance: Minimal abstraction layers between your code and the underlying hardware maximize CPU and memory efficiency.
Security: All disk data is automatically encrypted at rest using Google-managed or customer-supplied keys (wrapped with public/private key pairs).

Machine Families & Architecture

Compute Engine categorizes instances into broad Machine Families optimized for specific workloads, within which you select specific Machine Types (vCPU and memory configurations).

Family	Best For	Key Characteristics
General-Purpose	Web servers, standard databases, dev/test environments	Balanced price-to-performance ratio across CPU and memory.
Compute-Optimized	High-performance computing (HPC), gaming servers, media transcoding	Highest single-core performance and large core counts.
Memory-Optimized	In-memory databases (e.g., SAP HANA), large-scale data analytics	Highest memory-to-core ratios for massive datasets.
Accelerator-Optimized	Deep learning, AI training/inference, heavy parallel processing	Integrated with specialized hardware like GPUs and Tensor Processing Units (TPUs).

Storage & Data Management

Storage in GCE is decoupled from compute instances, acting as high-availability block storage that can be created, attached, detached, and resized independently.

Disk Types & Performance

Standard (HDD): Cost-effective bulk storage suited for large, sequential read/write operations.
SSD: High-performance storage designed for fast random read/write operations.
Local SSD: Physically attached to the host server for maximum possible IOPS and lowest latency (ephemeral).

Key Rule on Disk Performance: Disk speed is directly tied to IOPS (Input/Output Operations per Second). Larger disks provide higher IOPS—meaning you may sometimes provision a larger disk purely to meet performance targets.

Managing Disks

Attachment States: A persistent disk exists in one of three states: Unattached (default at creation), Attached Read-Write (mounted to one VM), or Attached Read-Only (can be attached to multiple VMs simultaneously).
Constraints: Disks can be expanded at any time without downtime, but cannot be shrunk. A disk must reside in the same zone as the VM instance to be attached.
Setup: New disks are attached like external drives, then formatted (e.g., using mkfs.ext4) and mounted via the OS.

Snapshots vs. Custom Images

+-----------------------------------+

| Persistent Disk Data |

+-----------------------------------+

+-------------------------+-------------------------+

| |

v v

[ Snapshots ] [ Custom Images ]

- Differential Backups - Golden Templates

- Point-in-time recovery - Fleet deployment

- Stores only changed blocks - OS + baseline software

Snapshots (Backups): Capture point-in-time state using differential storage (only saving block-level changes since the last snapshot). Used for disaster recovery and point-in-time restore.
Images (Templates): Serve as standardized baseline templates (OS + pre-installed software) used to provision new identical disks across an organization.

Scalability & High Availability (Instance Groups)

Managed Instance Groups (MIGs) allow you to treat a collection of identical VMs as a single operational unit.

Autoscaling: Dynamically adjusts the number of VMs in response to real-time metric spikes (e.g., CPU usage exceeding a set threshold during peak business hours) and scales down during lulls to reduce costs.
Self-Healing: Automatically monitors VM health checks; if an instance becomes unresponsive, the group terminates and replaces it.
Rolling Updates: Enables seamless software rollouts by updating a specified fraction of the fleet at a time, ensuring zero downtime and easy rollback if bugs are detected.

Pricing Model

GCE billing is calculated based on three distinct resource vectors:

Compute Capacity: Total vCPU and RAM allocated per hour/second.

Preemptible / Spot VMs: Excess Google compute capacity offered at up to an 80% discount. These instances can be reclaimed by Google at any time, making them ideal for fault-tolerant, batch-processing workloads.

Storage: Total provisioned capacity (GB/TB) per month based on the storage tier (Standard, SSD, Local SSD, Snapshots).
Egress Network Traffic: Data exiting the Google Cloud network or moving across distinct regions/zones. Ingress (incoming) traffic is free.

Enable Compute Engine API

Create an Instance

By default an E2 instance would be created for $25.46 a month.

Review configurations.

Can customize machine name

Choose Region and/or zone for machine location

Regions and zones

Compute Engine resources are hosted in multiple locations worldwide.

These locations are composed of regions and zones. A region is a specific

geographical location where you can host your resources.

Resources that live in a zone, such as virtual machine instances or zonal persistent disks, are referred to as zonal resources. Other resources, like static external IP addresses, are regional. Regional resources can be used by any resource in that region, regardless

of zone, while zonal resources can only be used by other resources in the same zone.

We can adjust the instance to reduce monthly costs by customizing configuration for memory and CPU

Use Preset tab to select lower powered machines

Selecting small reduces monthly costs

By selecting Shared core it reduces monthly cost.

Google Compute Engine offers shared-core machine types, which are a cost-effective option for running small, non-resource-intensive applications. These machine types, primarily within the E2 family (e.g., e2-micro, e2-small, e2-medium), operate by timesharing a physical CPU core with other virtual machines.

Choose your CPU

Rightsizing is the process of optimizing the resources allocated to an application or workload in order to achieve the best balance between performance and cost. It involves adjusting the computing resources, such as CPU, memory, and storage, to match the needs of your workloads while minimizing expenses.

Machine Power - More memory, more CPU’s more power higher cost

Operating System setup. Default is Debian Linux