This chapter covers Google Compute Engine machine types and families, a core topic for the ACE exam. You will learn how to choose the right machine type for any workload based on vCPU, memory, and specialized hardware. Approximately 10-15% of ACE exam questions touch on machine families, custom machine types, sole-tenant nodes, and committed use discounts. Mastery of this topic is essential for optimizing cost and performance in Google Cloud.
Jump to a section
Imagine you run a workshop with many workbenches. Each workbench is a Compute Engine instance. The workbench's surface area is its vCPUs—how many tasks you can work on simultaneously. The drawers under the bench are memory (RAM)—you can store frequently used tools there for quick access. A workbench with a small surface (few vCPUs) and few drawers (low RAM) is like an e2-small. For heavy woodworking (CPU-intensive tasks), you might need a workbench with a large surface and a single deep drawer (high vCPU, moderate RAM)—that's an N2 machine. For tasks requiring many tools at hand (high memory), you'd want a workbench with many deep drawers but a modest surface—that's an M3 memory-optimized machine. The workshop itself is a Google Cloud region. You can move workbenches between workshops (migrate instances) but not easily. Some workbenches are built on a solid steel frame (sole-tenant nodes) for isolation. The cost of each workbench depends on its size and how long you use it. You can also choose to rent a workbench by the hour (on-demand) or commit to a year (committed use discounts) to save money. If you need a workbench temporarily for a rush job, you can use a preemptible workbench (preemptible VM) that costs much less but may be taken away when the workshop needs the space.
What are Compute Engine Machine Types and Families?
Compute Engine offers predefined machine types grouped into families optimized for different workloads. Each machine type defines a specific combination of virtual CPUs (vCPUs), memory (GB), and sometimes additional capabilities like GPUs or local SSDs. The families are:
General-purpose: E2, N2, N2D, N1, T2D, T2A — balanced vCPU-to-memory ratios for most applications.
Compute-optimized: C2, C2D, C3 — high vCPU-to-memory ratio for CPU-intensive workloads.
Memory-optimized: M1, M2, M3 — high memory-to-vCPU ratio for memory-intensive workloads.
Accelerator-optimized: A2, G2 — for GPU-intensive workloads like ML and rendering.
How Machine Types Work Internally
A machine type is defined by the number of vCPUs and the amount of memory. Each vCPU is a hyperthread of a physical core on Google's custom hardware. The vCPU-to-memory ratio is fixed for predefined types but can be adjusted in custom machine types within limits.
vCPU: Each vCPU corresponds to one hardware hyperthread. For example, an n1-standard-4 has 4 vCPUs, meaning 4 hyperthreads on 2 physical cores (if the host CPU supports 2 threads per core).
Memory: Memory is allocated from the host machine's RAM. The memory is dedicated to the VM and not overcommitted. For predefined types, the memory per vCPU is fixed (e.g., N1 standard types have 3.75 GB per vCPU).
Networking: The number of vCPUs also determines the maximum egress bandwidth. For example, an instance with 8 vCPUs can achieve up to 16 Gbps egress, while one with 16 vCPUs can achieve up to 32 Gbps.
Key Components, Values, Defaults, and Timers
#### General-Purpose Families
E2: Economy, low cost. E2 has shared-core options (e2-micro, e2-small, e2-medium) that use a fraction of a vCPU. E2 standard types (e2-standard-2 to e2-standard-32) have 4 GB per vCPU. E2 high-memory (e2-highmem-2 to e2-highmem-16) have 8 GB per vCPU. E2 high-CPU (e2-highcpu-2 to e2-highcpu-16) have 1 GB per vCPU. E2 uses Intel or AMD CPUs.
N2: Intel Cascade Lake or later, with up to 128 vCPUs. N2 standard types have 4 GB per vCPU (e.g., n2-standard-8 has 32 GB). N2 high-memory have 8 GB per vCPU, N2 high-CPU have 1 GB per vCPU.
N2D: AMD EPYC Rome, similar ratios to N2 but often lower cost.
N1: Older generation, up to 96 vCPUs. Standard types have 3.75 GB per vCPU (n1-standard-8 has 30 GB). High-memory have 6.5 GB per vCPU, high-CPU have 0.9 GB per vCPU.
T2D: AMD EPYC, up to 60 vCPUs, standard types have 4 GB per vCPU.
T2A: ARM-based (Ampere Altra), up to 48 vCPUs, standard types have 4 GB per vCPU.
#### Compute-Optimized Families
C2: Intel Cascade Lake, up to 60 vCPUs, 4 GB per vCPU (e.g., c2-standard-8 has 32 GB).
C2D: AMD EPYC, up to 112 vCPUs, 4 GB per vCPU (c2d-standard-32 has 128 GB).
C3: Intel Sapphire Rapids, up to 176 vCPUs, 4 GB per vCPU (c3-standard-88 has 352 GB).
#### Memory-Optimized Families
M1: Up to 96 vCPUs, memory ranges from 1.4 GB per vCPU (m1-megamem-96 has 1.4 TB) to 3.5 GB per vCPU (m1-ultramem-40 has 160 GB).
M2: Up to 416 vCPUs, memory up to 12 TB (m2-ultramem-416).
M3: Up to 128 vCPUs, memory up to 4 TB (m3-megamem-128).
#### Accelerator-Optimized Families
A2: For NVIDIA A100 GPUs. A2 standard types have 12 vCPUs per GPU (e.g., a2-highgpu-1g has 12 vCPUs, 85 GB memory, 1 A100). A2 megagpu types have 96 vCPUs and 8 A100 GPUs.
G2: For NVIDIA L4 GPUs. G2 standard types have 4 vCPUs per GPU (e.g., g2-standard-4 has 4 vCPUs, 16 GB, 1 L4).
Custom Machine Types
You can create custom machine types with any number of vCPUs (from 1 to the family maximum) and memory (from 0.9 GB to 6.5 GB per vCPU, depending on family). For example, on N2 you can create a custom type with 6 vCPUs and 26 GB memory. The cost is based on the vCPU and memory count. Custom types are not available for E2 shared-core or T2A.
Sole-Tenant Nodes
Sole-tenant nodes allow you to have dedicated physical servers for your VMs. You specify a node type (e.g., n2-node-80-640) which has a fixed number of vCPUs and memory. You can then create VMs on that node using any machine type that fits within the node's resources. This provides hardware isolation for compliance or licensing requirements.
Committed Use Discounts (CUDs)
You can commit to using a certain amount of vCPUs and memory (in a region) for 1 or 3 years and receive up to 57% discount (for 3-year commit). CUDs apply to machine types within the same family (e.g., N2). You can also purchase CUDs for sole-tenant nodes or GPUs.
How Machine Types Interact with Related Technologies
Reservations: You can reserve instances of a specific machine type in a zone to guarantee availability.
Autoscaling: When configuring managed instance groups, you can specify a machine type. Autoscaling will create instances of that type.
Live Migration: Most machine types support live migration during host maintenance events. However, instances with GPUs or preemptible VMs do not.
Shielded VM: Available for all machine types, but requires specific features.
Configuration and Verification Commands
To list all machine types in a zone:
gcloud compute machine-types list --zone=us-central1-aTo describe a specific machine type:
gcloud compute machine-types describe n2-standard-4 --zone=us-central1-aTo create an instance with a custom machine type:
gcloud compute instances create my-instance --custom-cpu=6 --custom-memory=26GB --zone=us-central1-aTo create a sole-tenant node:
gcloud compute sole-tenancy node-groups create my-node-group --node-template=my-template --zone=us-central1-aTo view committed use discounts:
gcloud compute commitments listIdentify workload requirements
Determine the CPU and memory needs of your application. For a web server, a general-purpose machine like n1-standard-2 (2 vCPU, 7.5 GB) may suffice. For a batch processing job, compute-optimized like c2-standard-8 (8 vCPU, 32 GB) is better. For an in-memory database, memory-optimized like m1-megamem-96 (96 vCPU, 1.4 TB) is needed. Also consider if you need GPUs, local SSDs, or sole-tenant isolation.
Select machine family and type
Based on requirements, choose the family: general-purpose (E2, N2, etc.), compute-optimized (C2, C3), memory-optimized (M1-M3), or accelerator-optimized (A2, G2). Then pick a predefined type that matches your vCPU and memory needs. For example, if you need 4 vCPUs and 16 GB, you could use n2-standard-4 (4 vCPU, 16 GB). If the predefined ratios don't fit, consider a custom machine type.
Consider cost optimization
Estimate the cost. For short-term or flexible workloads, use on-demand pricing. For steady-state workloads, purchase committed use discounts (1 or 3 years) for up to 57% savings. For fault-tolerant batch jobs, use preemptible VMs (up to 80% discount). Also consider using E2 for cost-sensitive workloads with moderate performance needs.
Create instance with chosen machine type
Use gcloud or console to create the instance. Specify the machine type via --machine-type flag (e.g., --machine-type=n2-standard-4) or use --custom-cpu and --custom-memory for custom types. For sole-tenant, specify --node-group. For GPUs, specify --accelerator. The instance will be provisioned on a host that supports the machine type.
Monitor and adjust performance
After deployment, monitor CPU and memory utilization using Cloud Monitoring or gcloud commands. If utilization is consistently low, downsize to a smaller machine type. If high, upgrade. Use the gcloud compute instances set-machine-type command to change the machine type (requires stopping the instance). For example: gcloud compute instances set-machine-type my-instance --machine-type=n2-standard-8 --zone=us-central1-a.
Scenario 1: E-commerce Web Application
A large e-commerce company runs a web application on Compute Engine. They use an autoscaling managed instance group with n2-standard-4 instances. During Black Friday, traffic spikes. The autoscaling algorithm adds more instances, but the existing instances have high CPU. They consider switching to compute-optimized c2-standard-4 for better CPU performance per vCPU. However, they also have memory-intensive caching. They decide to use custom machine types with 4 vCPUs and 32 GB memory (n2-custom-4-32768) to balance cost and performance. They also purchase 1-year committed use discounts for the baseline capacity. Misconfiguration: If they use E2 instances, they may experience CPU throttling under sustained load because E2 uses shared-core for smaller types. They must ensure they use E2 standard types with dedicated vCPUs.
Scenario 2: Machine Learning Training
A research lab trains deep learning models using TensorFlow. They need high GPU performance. They choose A2 instances with NVIDIA A100 GPUs. They use a2-highgpu-4g (4 A100 GPUs, 48 vCPUs, 340 GB memory) for training. They also attach local SSDs for fast data loading. They use preemptible VMs for hyperparameter tuning to reduce costs. Common pitfall: They forget that A2 instances require a specific machine image and drivers. They also need to ensure the region has A2 availability. If they attempt to live migrate an A2 instance, it will fail because GPUs do not support live migration.
Scenario 3: SAP HANA on Google Cloud
A multinational corporation runs SAP HANA on Compute Engine. SAP HANA is memory-intensive. They choose memory-optimized M1 instances with up to 1.4 TB of memory. They use m1-ultramem-96 (96 vCPU, 1.4 TB) for production. They also use sole-tenant nodes to meet licensing requirements for SAP. They configure the node group with node type m1-node-96-1408 (96 vCPU, 1408 GB). They commit to 3-year CUDs for the node group. Issue: If they try to use a custom machine type on the sole-tenant node, they must ensure it fits within the node's resources. They also need to configure the instance to use the correct SAP-certified image.
The ACE exam tests your ability to select the appropriate machine type for a given workload scenario. Key objective codes: 1.2 (Compute Engine machine types and families). The exam will present scenarios like 'a batch processing job that is CPU-intensive' or 'a large in-memory database' and ask you to choose the best machine family.
Common wrong answers: 1. Choosing N1 high-CPU for a memory-intensive workload. Candidates confuse high-CPU (low memory) with high-memory. Remember: high-CPU has ~1 GB per vCPU, high-memory has ~6.5 GB per vCPU (N1). 2. Selecting E2 for a latency-sensitive application. E2 uses shared-core for small types and may have variable performance. The exam expects you to choose N2 or C2 for consistent performance. 3. Assuming all machine types support live migration. GPUs and preemptible VMs do not. Also, some machine types (e.g., M1 with > 6.5 GB per vCPU) may not support live migration. 4. Forgetting that custom machine types are not available for E2 shared-core (micro, small, medium) or T2A.
Specific numbers and terms to memorize: - E2 standard: 4 GB per vCPU - N1 standard: 3.75 GB per vCPU - N2 standard: 4 GB per vCPU - N1 high-CPU: 0.9 GB per vCPU - N1 high-memory: 6.5 GB per vCPU - C2 standard: 4 GB per vCPU - M1 megamem: 14 GB per vCPU (approx) - M1 ultramem: 3.5 GB per vCPU (approx) - Maximum vCPUs: N2: 128, C3: 176, M2: 416 - CUD discount: up to 57% for 3-year commit - Preemptible VM discount: up to 80%
Edge cases: - Can you change machine type of a running instance? No, you must stop it first. - Can you attach GPUs to any machine type? No, only to specific families (N1, N2, A2, G2). - Can you use committed use discounts for custom machine types? Yes, but you commit to a baseline of vCPUs and memory, not a specific machine type.
Elimination strategy: On a question asking for the most cost-effective machine type for a batch job that can be interrupted, look for 'preemptible' in the options. If the job is CPU-intensive and cannot be interrupted, choose compute-optimized family (C2, C3) with on-demand or CUD.
Machine types are grouped into families: general-purpose (E2, N2, N2D, N1, T2D, T2A), compute-optimized (C2, C2D, C3), memory-optimized (M1, M2, M3), and accelerator-optimized (A2, G2).
Predefined machine types have fixed vCPU and memory ratios; use custom machine types for flexible ratios (except E2 shared-core and T2A).
Committed use discounts (CUDs) offer up to 57% savings for 1 or 3 year commitments on vCPUs and memory per region and family.
Preemptible VMs cost up to 80% less but may be terminated at any time; ideal for fault-tolerant batch jobs.
Sole-tenant nodes provide dedicated physical servers for compliance or licensing; you specify node type and create VMs on the node.
To change machine type, stop the instance first; live migration is not supported for GPUs or preemptible VMs.
Maximum vCPUs vary by family: N2 (128), C3 (176), M2 (416), A2 (96).
These come up on the exam all the time. Here's how to tell them apart.
E2 (Economy)
Lower cost per vCPU
Shared-core options for small workloads
4 GB per vCPU for standard types
Intel or AMD CPUs
Variable performance under sustained load
N2 (General-purpose)
Higher performance, consistent
Up to 128 vCPUs
4 GB per vCPU for standard types
Intel Cascade Lake or later
Better for production workloads
C2 (Compute-optimized)
High vCPU-to-memory ratio (4 GB/vCPU)
Up to 60 vCPUs
Ideal for CPU-intensive tasks
Intel Cascade Lake
Supports live migration
M1 (Memory-optimized)
High memory-to-vCPU ratio (up to 14 GB/vCPU)
Up to 96 vCPUs
Ideal for in-memory databases
Intel Skylake or later
Some types do not support live migration
Mistake
E2 machine types are always cheaper than N2.
Correct
E2 may be cheaper but can have lower and variable performance due to shared-core for small types. For sustained CPU-heavy workloads, N2 may be more cost-effective per unit of work.
Mistake
You can change the machine type of a running instance.
Correct
You must stop the instance before changing its machine type. The gcloud command gcloud compute instances set-machine-type requires the instance to be stopped.
Mistake
All machine types support live migration.
Correct
Instances with GPUs, preemptible VMs, and instances using certain machine types (e.g., M1 with >6.5 GB per vCPU) do not support live migration. Check documentation.
Mistake
Custom machine types can have any number of vCPUs up to 96.
Correct
The maximum vCPUs for custom types depends on the family. For N2, max is 128; for C2, max is 60; for M1, max is 96. Also, vCPU count must be a multiple of 2 for most families except E2 and T2D.
Mistake
Committed use discounts apply to all instances in a project.
Correct
CUDs apply to resources in a specific region and for a specific family (e.g., N2). They cover vCPUs and memory used by instances of that family, not all instances.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
E2 is the economy family designed for cost savings, with shared-core options (e.g., e2-micro) that use a fraction of a vCPU. N2 is a general-purpose family offering higher and more consistent performance with dedicated vCPUs. E2 uses both Intel and AMD CPUs, while N2 uses Intel Cascade Lake or later. For production workloads requiring consistent performance, choose N2; for cost-sensitive, non-latency-critical workloads, choose E2.
No, GPUs can only be attached to specific machine types: N1, N2, A2, and G2 families. You must also choose a compatible number of vCPUs and memory. For example, attaching an NVIDIA A100 GPU requires an A2 instance. Additionally, GPU instances do not support live migration.
Use the gcloud compute instances create command with --custom-cpu and --custom-memory flags. For example: gcloud compute instances create my-instance --custom-cpu=6 --custom-memory=26GB --zone=us-central1-a. The vCPU count must be a multiple of 2 (except for some families) and memory must be between 0.9 GB and 6.5 GB per vCPU (depending on family).
A sole-tenant node is a physical Compute Engine server dedicated to hosting only your project's VMs. Use it when you need hardware isolation for compliance, licensing, or security reasons. You create a node group with a specific node type (e.g., n2-node-80-640) and then create VMs on that node. You pay for the entire node regardless of how many VMs you run.
No, you must stop the instance first. Use gcloud compute instances stop to stop it, then gcloud compute instances set-machine-type to change the type, then start it. Note that stopping an instance may cause the external IP to change unless it is reserved.
CUDs are discounts in exchange for committing to a minimum usage of vCPUs and memory in a region for 1 or 3 years. You purchase a commitment (e.g., 8 vCPUs and 32 GB of N2 resources in us-central1) and receive up to 57% discount. The commitment covers any instances of that family in the region. You can also purchase CUDs for GPUs and sole-tenant nodes.
Most general-purpose and compute-optimized machine types support live migration. However, instances with GPUs, preemptible VMs, and some memory-optimized types (e.g., M1 with >6.5 GB per vCPU) do not. Check the documentation for specific machine type live migration support.
You've just covered Compute Engine Machine Types and Families — now see how well it sticks with free ACE practice questions. Full explanations included, no account needed.
Done with this chapter?