# GCP container/compute tech selection: how to choose among Cloud Run / GKE Autopilot / App Engine / Cloud Run functions

> A tech-selection guide to decide 'where to run your code' on GCP. It compares Cloud Run, Cloud Run functions (formerly Cloud Functions), App Engine, GKE/GKE Autopilot, and Compute Engine from the official recommendations and a real-operations view. With scale-to-zero, Kubernetes-specific features, the billing model, and migratability as axes, it explains with a decision flowchart and a cross-cloud mapping to AWS/Azure, from both the buyer's and developer's perspectives.

- Published: 2026-06-28
- Author: 友田 陽大
- Tags: GCP, Cloud Run, GKE, App Engine, サーバーレス, コンテナ, 技術選定, アーキテクチャ設計
- URL: https://tomodahinata.com/en/blog/google-cloud-run-vs-gke-app-engine-cloud-run-functions-compute-selection-guide
- Category: Google Cloud Run in production
- Pillar guide: https://tomodahinata.com/en/blog/google-cloud-run-production-guide

## Key points

- For new GCP development, 'when in doubt, Cloud Run' is the 2026 default answer. The official docs also recommend Cloud Run over App Engine for new use, and Cloud Functions (2nd gen) was integrated into Cloud Run functions.
- Choosing Cloud Run = running stateless containers without K8s ops, with scale-to-zero and metered billing. Most REST/GraphQL APIs, web apps, webhooks, and microservices fit.
- GKE/GKE Autopilot is needed when 'Kubernetes-specific features (DaemonSet, CRD, Operator, service mesh, network policy, node access)' are required. Cloud Run doesn't expose these.
- Cloud Run functions (formerly Cloud Functions) is FaaS responding to a single trigger. Since it runs on the Cloud Run platform, use it as the entrance when you want the function model, and move continuously to a Service when it grows complex.
- App Engine is for existing assets. New use is Cloud Run. Compute Engine (VM) is the last resort when you can't containerize, or need OS-level control or a resident GPU.

---

"On GCP, where's the right place to run this app?" — Cloud Run, GKE, App Engine, Cloud Functions (now Cloud Run functions), Compute Engine. Too many options, and you stall on the first move. And **getting the first choice wrong makes the cost of switching later heavy.** This is a decision directly tied to money and time, for both the buyer and the builder.

When I [built an internal AI platform for a major domestic broadcaster on GCP](/case-studies/broadcaster-ai-content-platform), I chose a design that **holds neither a dedicated VM nor a Kubernetes cluster, leaning thoroughly into managed with Cloud Run (services + jobs).** Being able to run five AI services, an auth hub, and heavy OCR/speech-synthesis/malware-scanning in production without patching nodes or managing a cluster came from this selection paying off.

This article, **faithful to the [Google Cloud official documentation](https://docs.cloud.google.com/run/docs/overview/what-is-cloud-run)**, organizes each option by "when and why to choose it" and lands on a **decision flowchart.** For production operations after choosing, see the [Cloud Run production-operations guide](/blog/google-cloud-run-production-guide).

---

## The conclusion first: the 2026 default answer is "when in doubt, Cloud Run"

Before the long comparison, here's the conclusion.

> **For new container/web workloads, consider Cloud Run first.** Go up to GKE or Compute Engine only when you need Kubernetes-specific features, or have a clear reason you can't containerize.

This isn't my opinion; it aligns with the official direction. The App Engine migration guide writes this.

> Cloud Run is a fully managed, modern application hosting platform that provides access to advanced capabilities, such as GPUs, at lower prices. ... For new Google Cloud users, we recommend using Cloud Run as the preferred alternative over App Engine. (— [Compare App Engine and Cloud Run](https://docs.cloud.google.com/appengine/migration-center/run/compare-gae-with-run))

And **Cloud Functions, once the representative of "serverless functions," was integrated under Cloud Run** (below). GCP's serverless is now **reorganized around Cloud Run.**

---

## The big picture of options: a gradient of abstraction

GCP compute lines up on a gradient of "**how much you leave to Google and where you start holding yourself.**"

| Option | Abstraction | What you manage | Scale-to-zero |
|--------|-------|-------------------|----------------|
| **Cloud Run functions** (formerly Cloud Functions) | Highest | Just the function's code | ○ |
| **Cloud Run** | High | The container image | ○ |
| **App Engine** | High (legacy) | The app + `app.yaml` | ○ (standard) |
| **GKE Autopilot** | Mid | Pods and manifests (nodes are left to it) | △ (per Pod; hard to truly reach zero) |
| **GKE Standard** | Low | Nodes + K8s workloads | × |
| **Compute Engine** | Lowest | VM, OS, runtime, all of it | × |

**The higher you go, the lower the operational load and cost (especially idle); the lower you go, the higher the freedom of control.** The principle is "**choose the highest-abstraction option that meets the requirements.**" Choosing a lower layer without reason means continuing to pay the biggest cost — labor.

---

## Cloud Run: when in doubt, here

**Run stateless containers, without Kubernetes ops, with auto-scaling that shrinks to zero according to traffic.** This is Cloud Run's core.

**When to choose Cloud Run:**

- REST/GraphQL APIs, web apps, webhook handlers, BFFs
- Microservice groups (independent deploy/scale per service)
- Event-driven processing (Eventarc / Pub/Sub triggered)
- Batch/long-running jobs (Cloud Run Jobs), resident workers (Worker Pools)
- Any language/framework (anything runs if it can be containerized)

**Cloud Run's strengths:**

- **Scale-to-zero**: no billing when there's no traffic. Overwhelmingly strong against sporadic/spiky load.
- **Zero operational load**: no nodes, no cluster. Don't think about patches or upgrades.
- **Language-agnostic**: container = deploy unit. Go/Node/Python/Java/.NET/Ruby/Rust, anything.
- **gRPC, WebSocket, HTTP/2 streaming supported.**

**What's "hard to do" on Cloud Run:**

- Kubernetes-specific features (DaemonSet, CRD, Operator, service mesh, network policy).
- Node-level access, privileged containers.
- A design that strictly requires "always 1 request = 1 instance" (concurrency 1 is possible but scaling performance drops).

If none of these apply — i.e., **most web/API workloads** — Cloud Run is the right answer.

---

## Cloud Run functions (formerly Cloud Functions): the FaaS entrance

**In 2024, Cloud Functions (2nd gen) was renamed "Cloud Run functions" and integrated under Cloud Run.** Cloud Functions (1st gen) became "Cloud Run functions (1st gen)." The substance keeps the "event-driven function model" while gaining access to **Cloud Run's performance, scaling, and security adjustment knobs (including GPUs).**

**When to choose Cloud Run functions:**

- A **small function** responding to a single trigger (HTTP / Pub/Sub / Cloud Storage / Firestore event, etc.).
- Glue code, automation, light webhooks where you "want to write just the function without thinking about containers."

**Choosing between it and Cloud Run (Service):**

| | **Cloud Run functions** | **Cloud Run (Service)** |
|---|------------------------|--------------------------|
| Unit | Function (handler) | Container |
| Trigger | Mainly a single trigger | Arbitrary HTTP routing, multiple endpoints |
| Suited scale | Small, single-purpose | Mid-to-large, multi-feature, frameworks |
| Migratability | To a Service when complex | — |

The point is that **both are on the same Cloud Run platform.** A migration of "start small with functions, and move continuously to a Service when the logic grows" works naturally. Use it as **the entrance when you want FaaS's convenience**, and promote it to a container Service when it bloats — this is healthy evolution.

---

## App Engine: don't choose it for new use (but know it)

App Engine is GCP's oldest PaaS. It had the convenience of writing `app.yaml` and deploying source, but **Cloud Run inherited that role and surpasses it in features too.**

Extracting the gist from the official comparison —

| Item | App Engine standard | Cloud Run |
|------|--------------------|-----------|
| Deploy unit | Source + `app.yaml` | Container (or source → buildpacks) |
| Concurrency | 10 req/instance | **80 (max 1000)** |
| Request timeout | 10 minutes with auto-scaling | **default 5 minutes, max 60 minutes** |
| Language | Limited (Python/Java/Go/PHP, etc.) | **Language-agnostic (container)** |
| WebSocket/gRPC streaming | × | **○** |
| GPU | × | **○** |

**New use is Cloud Run.** The official recommendation is to consider migrating existing App Engine apps to Cloud Run at modernization time too. There's hardly any reason left to actively choose App Engine.

---

## GKE / GKE Autopilot: when Kubernetes "is needed"

This is the point most easily gotten wrong in selection. **"Running many containers ≠ Kubernetes."** Microservices run fine on Cloud Run too. You choose GKE only when **the control plane and ecosystem of Kubernetes itself are needed.**

**When to choose GKE (especially Autopilot):**

- You need **Kubernetes-specific primitives**: DaemonSet, CRD, Operator, network policy, service mesh (Istio, etc.), privileged node access.
- You already have **Kubernetes-native assets / team skills**.
- You want to operate many (a guide of 10+) services **uniformly on a single K8s platform**.
- Stateful workloads (StatefulSet), complex batch (Kueue, etc.).

**The difference between GKE Standard and Autopilot:**

| | **GKE Standard** | **GKE Autopilot** |
|---|------------------|-------------------|
| Node management | Design/operate node pools yourself | **Google manages nodes** (focus on Pod-level operation) |
| Billing | Per node (VM) | **Per Pod (requested resources)** |
| Suited for | Want fine node control | Want K8s but lighter ops |

**The decisive difference between Cloud Run and GKE Autopilot:**

- **Cloud Run shrinks to zero and bills for what you use.** GKE (even Autopilot) tends to incur **minimal resident cost** and gets pricey with sporadic traffic.
- **Cloud Run doesn't expose the K8s API.** A world with no `kubectl`, no manifests. Conversely, if you need them, GKE.

> When I **chose Cloud Run over GKE** for the broadcaster platform, this was exactly the judgment. The five AI services required independent deploy/scale, but no service mesh or CRD was needed. Rather than bearing the constant operational load of node management, **leaning into managed with Cloud Run to minimize steady-state cost and ops effort** was overwhelmingly rational for a one-person-to-small-team setup.

---

## Compute Engine (VM): the last resort

The last resort when **you can't containerize** (special OS dependencies, legacy installer-type software), need **OS-level control**, or want to **permanently occupy a GPU** is a VM (Compute Engine). The freedom is maximum, but you hold **all of OS, patches, scaling, and availability yourself.** If you can't articulate "a clear reason it only runs on a VM," you shouldn't choose it.

---

## Decision flowchart

The right way is to go top to bottom and **stop at the first YES.**

```text
1. コンテナ化できない / OSレベルの制御・GPU常駐が要る？
   └─ YES → Compute Engine（VM）

2. Kubernetes固有の機能が要る？
   （DaemonSet / CRD / Operator / サービスメッシュ / ネットワークポリシー / ノードアクセス）
   └─ YES → GKE（運用を軽くしたいなら GKE Autopilot）

3. 単一トリガーに応答する小さな関数で十分？
   └─ YES → Cloud Run functions（複雑化したら Cloud Run Service へ）

4. 上のどれでもない（＝大半のWeb/API/マイクロサービス/バッチ）
   └─ → Cloud Run（Services / Jobs / Worker Pools）★既定解

（App Engine は新規では選ばない。既存資産は Cloud Run への移行を検討）
```

Most projects land on **#4 (Cloud Run).** Stopping at 1–3 is only "when there's a clear reason." **If you can't articulate the reason, Cloud Run.** This is the principle for not hesitating.

---

## Cross-cloud mapping: if you know AWS / Azure

If you already have AWS or Azure experience, understanding by correspondence is fast. I've run a payments platform and lumber-distribution DX on AWS Fargate and a broadcaster platform on GCP Cloud Run, but **the crux of serverless containers is continuous across clouds.**

| Concept | GCP | AWS | Azure |
|------|-----|-----|-------|
| Serverless containers | **Cloud Run** | App Runner / ECS on Fargate | Container Apps |
| Managed K8s | GKE / GKE Autopilot | EKS / EKS Auto Mode | AKS |
| FaaS (functions) | Cloud Run functions | Lambda | Functions |
| Legacy PaaS | App Engine | Elastic Beanstalk | App Service |
| VM | Compute Engine | EC2 | Virtual Machines |

Production operations of each cloud are summarized in individual articles — [AWS ECS on Fargate production operations](/blog/aws-ecs-fargate-production-guide), [Azure Container Apps production operations](/blog/azure-container-apps-production-guide), [Fargate vs Lambda vs App Runner selection](/blog/aws-ecs-fargate-vs-lambda-vs-app-runner-compute-selection-guide), [Azure Container Apps vs AWS Fargate comparison](/blog/azure-container-apps-vs-aws-ecs-fargate-serverless-container-comparison-guide). **The decision "choose serverless containers" itself is nearly the same across the three clouds.**

---

## Summary: selection is "maximizing abstraction"

GCP compute selection, taken to its core, converges on one principle — **choose the highest-abstraction option that meets the requirements, and descend to a lower layer only when there's a reason.**

- Most web/API/microservices/batch → **Cloud Run** (the 2026 default answer)
- Small functions → **Cloud Run functions** (can move continuously to a Service)
- When Kubernetes-specific features are needed → **GKE / GKE Autopilot**
- No reason to choose App Engine for new use. VM is the last resort.

Once the selection is decided, proceed to the engineering of production operations. For the container contract, concurrency, deployment, and security, the [Cloud Run production-operations guide](/blog/google-cloud-run-production-guide); for how to nail cost, the [concurrency, autoscale, and billing guide](/blog/google-cloud-run-autoscaling-concurrency-billing-cost-optimization-guide).

If you need accompaniment from the tech-selection stage, I take it on **one-person × generative AI, end-to-end from requirements definition to production operations.** Based on my track record of building container platforms on GCP, let's decide together a configuration that fits your load characteristics, setup, and budget.