How to Choose Google Cloud Server? Google Compute Engine (GCE) Common Examples and Cost Performance Evaluation
When choosing Google Cloud (GCP) servers, many people were confused by the pile of Tau T2D, N2, C3 and E2 at first glance. The naming logic of large factories has always been obscure, coupled with the complexity of billing items (calculation power, memory, network and disk are all calculated separately). If you are not careful, you will step on the pit, either the performance will be stuck or the bill will explode at the end of the month.
Don't blindly read the rhetoric of the official documents. This tutorial does not handle parameters, but directly uses vernacular and real business scenarios to help you get through the core instances of Google Compute Engine (GCE) and give the most grounded selection and money-saving strategies.
1. Core Concepts: Three "Stealth Bills" to Avoid GCE"
Before picking a machine, you must first understand the underlying logic of Google Cloud, otherwise the bill will exceed the budget if you choose the best configuration.
CPU architecture: GCE now has Intel, AMD and Ampere (ARM) three arrays. AMD and ARM are usually 20% ~ 30% more cost-effective than Intel under the same running score. If there are no specific X86 closed-source software dependencies, AMD or ARM is preferred.
Network bandwidth is charged separately: many Xiaobai think that if they buy a sea server, the public network traffic will be contracted. GCE's outbound traffic (Egress) is very expensive. Even if you buy a $5/month machine, if you run 100GB of traffic to mainland China or Europe, the traffic fee may be several times the machine fee.
Disk performance binding capacity: GCE's ordinary cloud disk (pd-standard) or balanced disk (pd-balanced), its IOPS (number of reads and writes per second) and throughput are increased with the proportion of the hard disk capacity you purchase. If you buy a 10GB disk to run the database, it will be stuck directly when the concurrency is high. This is not a CPU problem, but the speed limit of the hard disk.
2. the depth of the core examples of horizontal comments: which one should you choose?
Google Cloud divides instances into four broad categories: general (General-purpose), compute-optimized (Compute-optimized), memory-optimized (Memory-), and accelerated (Accelerator-optimized). For 90 percent of business and individual developers,
General-purpose
and
Compute-optimized
That’s enough.
1. E2 series: extreme money saving, black under the lamp "sharing type"
E2 is an entry evergreen for GCE. Its core logic is
Resource reuse (shared CPU)
.
Features: There is no fixed physical CPU binding, and the computing power is dynamically allocated at the bottom layer. It does not have the concept of "CPU points" like T3/T4 of AWS (speed limit when points are used up). E2 will only be used as a whole when encountering continuous high load.
Passive frequency reduction when resources are tight.
Applicable scenarios: personal blog, development and test environment, small API interface with low traffic, lightweight daily script.
Pit avoidance tip: Never use E2 to run the database of the production environment. Once the next-door neighbor is running data frantically, your machine may experience inexplicable delay jitter.
2. N2 / N2D series: stable production of the main force
N2(Intel) and N2D(AMD) are standard exclusive instances.
Features: Default kernel-to-memory ratio of 1:4 (e. g. 2-core 8G). The performance is extremely stable, the physical core is completely yours, and there is no neighbor interference.
Application scenarios: enterprise small and medium-sized website backend, medium-sized MySQL/PostgreSQL database, various standard microservices.
Cost-effective choice: no brain choose N2D. N2D uses AMD EPYC processor, the basic performance is not inferior to Intel, but the price is usually 10% ~ 15% cheaper.
3. Tau T2D Series: King of Cost Performance (Highly Recommended)
If you're looking for the most cost-effective x86 instance, this is it.
Features: It is an AMD-optimized array launched by Google specifically to combat AWS Graviton. It does not provide hyperthreading (Hyper-Threading), and every vCPU you buy is a real physical core (Physical Core).
Application scenarios: high-concurrency Web access layer, high-traffic API gateway, video transcoding, medium and large independent applications.
Cost-effective choice: T2D is even more cost-effective than N2D under the same computing power requirements. If your business requires stable high CPU output and does not require more than 60 cores, T2D is preferred.
4. C3 / C3D series: a new generation of performance monsters
C3 introduces Google's own IPU (infrastructure processor), which accelerates the network and storage overhead.
Features: High single-core performance, high network throughput, support for the latest DDR5 memory.
Application scenarios: game servers, high-frequency trading systems, middleware requiring ultra-low latency, and large distributed clusters.
Cost-effective evaluation: performance burst table, but the price is expensive. Unless your business has encountered a network IO or single accounting capacity bottleneck, there is no need to pay for this premium at this stage.
5. T2A series: ARM array touchstone
With Ampere Altra processor.
Features: single core price is extremely cheap, energy efficiency ratio is extremely high.
Applicable scenarios: Containerized applications and distributed nodes that have been adapted to the ARM architecture.
Hint: Make sure your Docker image or running environment supports arm64 architecture before purchasing, otherwise troubleshooting errors will crash you.
Horizontal comparison table of cost performance of 3. mainstream examples
To make you
With intuitive feelings, we take
West United States computer room (us-central1)
,
2 core 8G (or similar configuration)
On-demand (On-demand) as the benchmark for horizontal evaluation:
Example series
Configuration specifications
Chip Architecture
Estimated Monthly Price (Calculated only)
Performance Overview
Price/performance rating
Best Recommended Scenarios
E2
Share Intel/AMD
~$50
Low, risk of jitter
★★★★☆
Develop test/low-stream websites
N2
Exclusive Intel Ice Lake
~$71
Stability
★★★☆☆
Standard Enterprise Production Environment
N2D
Exclusive AMD EPYC
~$62
Stable and highly versatile
★★★★☆
Production Database/Microservices
Tau T2D
Exclusive AMD (True Physical Core)
~$57
Strong (single-core performance is excellent)
★★★★★
High Concurrency Web/Application Server
T2A (ARM)
Exclusive to Ampere Altra
~$38
Excellent (high multi-core efficiency)
★★★★★
Containerized/ARM native applications
C3
Exclusive Intel Sapphire
~$84
Very high (low latency)
★★★☆☆
Game clothes/high frequency computing requirements
Note: The above prices are official approximate and do not take into account various discounts (e. g. sustainable use discount SUD). The actual billing will vary depending on the location of the computer room (e. g. Hong Kong and Singapore are usually 20% ~ 40% more expensive than the United States).
4. copying: a selection guide for different business scenarios.
If you are too lazy to compare, take your seat directly:
Scenario A: personal blog, foreign trade station, small personal projects
Selection strategy: E2-micro or E2-small.
Reason: The traffic is not large, the CPU is idle for a long time, and it is most cost-effective to use a shared instance.
Save money configuration: disk selection 30GB-50GB pd-balanced (balance disk), taking into account the speed and price.
Scenario B: Enterprise website, standard SaaS backend, high-frequency API interface
Selection strategy: Tau T2D series (if t2d-standard-4).
Reason: T2D does not have hyper-threading, but gives a real physical core. It responds extremely fast in the face of sudden traffic and is cheaper than N2D.
Save money configuration: if the business can do stateless scaling, with more than 100GB of pd-balanced disk.
Scenario C: Self-build medium and large production databases (MySQL, PostgreSQL, and Redis)
Selection strategy: N2D custom configuration (Custom) or C3 series.
Rationale: Databases require extremely stable CPUs and high IOPS. N2D allows you to customize CP
U and memory ratio (such as the high memory ratio of 4 cores and 32G) do not need to be forced to buy extra CPU in order to need large memory.
Hard core suggestion: SSD permanent disk (pd-ssd) or Extreme disk must be selected as the system disk of the database, with a capacity of at least 100GB, otherwise the disk IOPS will become the fatal bottleneck of the whole system.
5. bone-level money-saving tips: How to get GCE bills to be cut by another 50%?
Buying the right model is only the first step. The real way for big factories to save money is in the billing mode.
1. Make good use of "Custom Machine Types"
This is a god-level feature of Google Cloud far beyond AWS and Azure. Another family can only choose a fixed package (for example, 8G memory must be equipped with 2-core CPU).
In GCE (N1, N2, N2D support), if you find the program
Eat memory but not CPU
, you can pull the fine-tuning bar yourself and come up with a wonderful configuration of "2 cores 16G.
Paying only for the resources you need can save you at least 20% of your ineffective resource overhead.
2. Commitment to use discounts (Commitment Based Discounts - CUD)
If your business is going to run for a long time (say at least a year), don't pay by the hour.
Go backstage and check the 1-year or 3-year commitment discount.
There is no need to stop the machine or change the machine. As long as you promise to maintain this calculation level within this year, Google will directly give you a 63% discount (1 year) or 45% discount (3 years) on the bill.
3. Preemptible instances (Spot VMs) run non-core business
If your business is a distributed architecture, or just run offline data analysis and video transcoding during the day.
Turn on the Spot VM switch.
Cost: Google may at any time when the system resources are tight, 30 seconds in advance notice and forced to recycle your machine.
Earnings: The price is directly 10% to 40% off. It's really sweet to use it to run stateless K8s nodes or temporary computing tasks.
6. Summary
In fact, it is not difficult to choose GCE. The core formula is three sentences:
Lightweight, testing, saving money to find E2;
Conventional production, high cost performance, no brain Tau T2D or N2D;
Don't forget that disk bandwidth is expensive, and custom configuration saves a lot of money.
Run the business first and use GCP's perfect Cloud Monitoring to monitor for three months. If you find that the long-term CPU utilization rate is less than 15%, you will be determined to downgrade online-this is the greatest charm of cloud computing.
