⚙️ FastAPI on GCP Cloud Run vs Compute Engine — Pricing and Performance Compared

🚀 Architecture Overview — Why It Differs

FastAPI on GCP Cloud Run is a serverless container platform that automatically scales to zero. Compute Engine runs a persistent VM that must be managed manually.

📑 Table of Contents

• 🚀 Architecture Overview — Why It Differs
• 📦 Container Image & Build Process — How to Package FastAPI
• 💸 Pricing Mechanics — How Costs Are Calculated
• 📊 Billing Granularity
• 📈 Example Cost Comparison
• ⚡ Performance Characteristics — What Impacts Latency
• 🧩 Concurrency Model
• 🚀 Cold Starts vs Warm Instances
• 🔧 Deployment Steps — From Code to Production
• 🛠️ Cloud Run Deployment
• 🖥️ Compute Engine VM Creation
• 🟩 Final Thoughts
• ❓ Frequently Asked Questions
• Can I run multiple FastAPI instances on a single Cloud Run service?
• How do I enable HTTPS on a Compute Engine VM?
• What happens to data stored on a Compute Engine VM if the instance is stopped?
• 📚 References & Further Reading

📦 Container Image & Build Process — How to Package FastAPI

Both platforms use a Docker image that contains FastAPI, its dependencies, and a lightweight server.

# Dockerfile
FROM python:3.12-slim # Install system dependencies
RUN apt-get update && apt-get install -y -no-install-recommends \ build-essential && \ rm -rf /var/lib/apt/lists/* # Create a non‑root user
RUN useradd -m fastapi
WORKDIR /app
COPY requirements.txt .
RUN pip install -no-cache-dir -r requirements.txt # Copy application code
COPY app/ ./app/ # Switch to non‑root user
USER fastapi # Use Uvicorn as the ASGI server
CMD ["uvicorn", "app.main:app", "--host", "0.0.0.0", "--port", "8080"]

What this does:

• FROM python:3.12-slim: provides a minimal runtime with the latest Python 3.12.
• apt-get install build-essential: required for compiling native dependencies such as cryptography.
• USER fastapi: runs the container as a non‑root user, improving security.
• uvicorn command: starts the ASGI server on the port expected by Cloud Run (8080).

Build the image and push it to Artifact Registry:

$ docker build -t us-central1-docker.pkg.dev/my-project/fastapi-repo/fastapi:latest .
Sending build context to Docker daemon 12.34MB
Step 1/10: FROM python:3.12-slim --> 5d1c0c7e6b5a
...
Successfully built 5d1c0c7e6b5a
Successfully tagged us-central1-docker.pkg.dev/my-project/fastapi-repo/fastapi:latest

Push the image:

$ docker push us-central1-docker.pkg.dev/my-project/fastapi-repo/fastapi:latest
The push refers to repository [us-central1-docker.pkg.dev/my-project/fastapi-repo/fastapi]
...
latest: digest: sha256:9b2c... size: 1234

💸 Pricing Mechanics — How Costs Are Calculated

FastAPI GCP Cloud Run and Compute Engine pricing depends on request concurrency, CPU allocation, and sustained‑use discounts.

📊 Billing Granularity

Cloud Run bills per 100 ms of CPU and memory usage while a request is active. Compute Engine bills per second for the VM regardless of traffic, with additional charges for sustained‑use and committed‑use contracts.

📈 Example Cost Comparison

According to the official Cloud Run pricing page, the per‑request model can be cheaper for workloads that see intermittent traffic because you only pay for the exact CPU‑seconds consumed.

What this does:

• CPU pricing granularity: Cloud Run’s 100 ms billing reduces waste for short‑lived requests.
• Sustained‑use discounts: Compute Engine automatically applies discounts after 25 % of the month’s usage, which can offset the higher base price for steady traffic.

Key point: For spiky traffic patterns, FastAPI GCP Cloud Run pricing typically favors Cloud Run; for constant high‑throughput, Compute Engine’s predictable per‑second billing may be more economical.

⚡ Performance Characteristics — What Impacts Latency

FastAPI’s async nature reduces request‑handling overhead, but the underlying platform determines the observable latency. (More onPythonTPoint tutorials)

🧩 Concurrency Model

Cloud Run allows a single container instance to handle multiple requests concurrently, up to the CPU limit you set. Compute Engine lets you configure the number of worker processes or Uvicorn workers manually.

🚀 Cold Starts vs Warm Instances

A Cloud Run service receives its first request after a period of inactivity by starting a new container, pulling the image from the registry, and initializing the Python runtime. This typically adds 300‑800 ms. Compute Engine instances stay warm, eliminating cold‑start latency but consuming resources continuously.

Benchmark results (average over 100 runs):

These numbers illustrate that the additional overhead of container start‑up on Cloud Run is offset by its ability to scale down to zero, which saves cost when traffic is low.

Key point: If sub‑100 ms latency is mandatory and traffic is constant, Compute Engine provides a tighter performance envelope; otherwise, Cloud Run’s scaling behavior often outweighs the modest latency penalty.

🔧 Deployment Steps — From Code to Production

Deploying FastAPI to Cloud Run and Compute Engine follows distinct command sequences, each exposing the platform’s operational model.

🛠️ Cloud Run Deployment

Use the gcloud CLI to create a fully managed service:

$ gcloud run deploy fastapi-service \ -image us-central1-docker.pkg.dev/my-project/fastapi-repo/fastapi:latest \ -platform managed \ -region us-central1 \ -allow-unauthenticated \ -cpu 1 \ -memory 512Mi
Deploying container image...
✅ Service [fastapi-service] revision [fastapi-service-00001] deployed successfully.
Service URL: https://fastapi-service-abcdefg-uc.a.run.app

The command provisions a new revision, pulls the image, and exposes an HTTPS endpoint. The --cpu 1 flag allocates a single vCPU per request, directly influencing the per‑request billing granularity discussed earlier.

🖥️ Compute Engine VM Creation

Spin up a VM, install Docker, and run the container manually:

$ gcloud compute instances create fastapi-vm \ -machine-type e2-medium \ -image-project debian-cloud \ -image-family debian-11 \ -tags http-server \ -metadata startup-script='#!/bin/bash apt-get update && apt-get install -y docker.io docker run -d -p 80:8080 us-central1-docker.pkg.dev/my-project/fastapi-repo/fastapi:latest'
Created [https://www.googleapis.com/compute/v1/projects/my-project/zones/us-central1-a/instances/fastapi-vm].
Waiting for operation to finish...done.

After the VM boots, the startup script installs Docker and launches the FastAPI container, binding port 80 on the host to port 8080 inside the container.

Verify the service is reachable:

$ curl -s http://$(gcloud compute instances list -filter="name=fastapi-vm" -format="value(networkInterfaces[0].accessConfigs[0].natIP"))
{"detail":"Welcome to FastAPI!"}

Both deployments expose the same API contract; the difference lies in how resources are allocated and billed.

What this does:

• gcloud run deploy: creates a serverless revision, handles TLS termination, and scales based on request volume.
• gcloud compute instances create: provisions a persistent VM, runs a startup script, and leaves the container running indefinitely.

🟩 Final Thoughts

Choosing between Cloud Run and Compute Engine for a FastAPI service hinges on traffic pattern, latency tolerance, and cost predictability. Cloud Run excels when you need automatic scaling, per‑request billing, and minimal operational overhead. Compute Engine shines for workloads that require constant CPU availability, custom OS tweaks, or strict latency guarantees.

The pricing model—FastAPI GCP Cloud Run Compute Engine pricing—reflects these trade‑offs. Understanding the billing granularity and performance implications enables a selection that aligns with both budget constraints and service‑level objectives.

❓ Frequently Asked Questions

Can I run multiple FastAPI instances on a single Cloud Run service?

Yes. Cloud Run can host multiple processes within a single container instance, but each request still consumes the same CPU and memory allocation defined at deployment time.

How do I enable HTTPS on a Compute Engine VM?

Install a reverse proxy such as NGINX, obtain a certificate from Let’s Encrypt, and configure NGINX to terminate TLS on port 443, forwarding traffic to the FastAPI container.

What happens to data stored on a Compute Engine VM if the instance is stopped?

Persistent disks retain their data across stops and starts, but any data written to the VM’s local SSD is lost when the instance is terminated.

💡 Want to practise this hands-on? DigitalOcean gives new accounts $200 free credit for 60 days — enough to spin up a full Linux/Docker/Kubernetes environment at no cost.

📚 Recommended reading: Best DevOps & cloud books on Amazon — from Linux fundamentals to Kubernetes in production, curated for working engineers.

📚 References & Further Reading

• Official Cloud Run documentation — pricing, limits, and deployment guide: cloud.google.com
• FastAPI deployment best practices — containerization and async handling: fastapi.tiangolo.com
• Compute Engine VM types and sustained‑use discounts: cloud.google.com