Cloud Run vs AWS Fargate: Serverless Containers Compared

Google Cloud Run and AWS Fargate both run containers without servers to manage, so they look like direct equivalents. They are built on different ideas. Cloud Run is a request-driven platform with a URL, autoscaling and scale to zero included. Fargate is the compute layer under ECS and EKS, and the load balancer, networking and scaling rules around it are yours to set up.

This comparison covers scaling, networking, billing model and setup for an HTTP backend with a Postgres database. It also shows how Encore (infrastructure from code) deploys the same code to either one, which matters when the choice of cloud is not final.

Cloud Run vs Fargate at a glance

Each option is covered below, starting with Encore.

Running one codebase on Cloud Run or Fargate with Encore

Encore is infrastructure from code for TypeScript and Go, with a platform that provisions and deploys into your own AWS or GCP account. The same application deploys to Cloud Run on GCP or to Fargate behind an Application Load Balancer on AWS, with rolling deploys, private subnets and an IAM role for each service on both.

A service and its database are declared in code, with nothing cloud-specific in it:

// notes/notes.ts
import { api, APIError } from "encore.dev/api";
import { SQLDatabase } from "encore.dev/storage/sqldb";

// Cloud SQL on GCP, RDS on AWS, a local Postgres under encore run.
export const db = new SQLDatabase("notes", { migrations: "./migrations" });

export const get = api(
  { expose: true, method: "GET", path: "/notes/:id" },
  async ({ id }: { id: number }): Promise<{ id: number; body: string }> => {
    const row = await db.queryRow<{ id: number; body: string }>`
      SELECT id, body FROM notes WHERE id = ${id}`;
    if (!row) throw APIError.notFound("note not found");
    return row;
  },
);

The migration in notes/migrations creates the notes table the queries use:

-- notes/migrations/1_create_notes.up.sql
CREATE TABLE notes (
    id BIGSERIAL PRIMARY KEY,
    body TEXT NOT NULL
);

On GCP, that becomes a Cloud Run service connected to Cloud SQL in a dedicated project. On AWS, it becomes a Fargate service that receives traffic through an Application Load Balancer and connects to RDS. Which one an environment uses is a setting on the environment, so a team can start on one cloud and add an environment on the other without touching the application. encore run starts Postgres locally and serves the same API before either cloud is involved.

For teams where coding agents write much of the backend, that split keeps agents in application code: they never edit task definitions or Cloud Run YAML, and the deployment target stays a decision people make.

The deployment guide covers the push-to-deploy flow, and environments explains how one app can run on Cloud Run in one environment and on Fargate in another.

Cloud Run: request-driven containers

Cloud Run takes a container image, or source code it builds for you, and returns an HTTPS URL. Instances are added as requests arrive and removed when traffic stops, down to zero unless you set a minimum. Each instance handles many requests at once, up to a concurrency setting that defaults to 80.

In that model, a service that scales to zero has cold starts on the first request. By default, CPU is only allocated while requests are being handled, so background work after a response needs instance-based billing or a separate Cloud Run job. Reaching private resources like Cloud SQL over private IP or Memorystore needs Direct VPC egress configured.

AWS Fargate: tasks you define

Fargate runs ECS tasks or EKS pods without EC2 instances to manage. For an HTTP service on ECS, you write a task definition with CPU, memory, image and environment, create an ECS service with a desired count, place it in VPC subnets with security groups, and put an Application Load Balancer in front of it. Autoscaling is a separate target tracking policy on CPU, memory or ALB request count.

Tasks run continuously at the count you set. There is no scale to zero on incoming requests, and you pay for each running task's vCPU and memory per second, per Fargate pricing, plus the load balancer. In exchange, there are no request timeouts or CPU throttling between requests, so long-running workers, WebSocket servers and queue consumers fit naturally.

Good to know

Neither service includes a database. On Cloud Run, the connection to Cloud SQL is a flag or a connector; on Fargate, RDS sits in the same VPC and the security groups decide who can reach it. Either way, the database is usually the bigger part of the setup and of the bill.

How to choose

Pick Encore when you want to write the backend once and run it on Cloud Run or Fargate in your own account, with the database, networking and IAM created from the code and the option to change clouds per environment.

Pick Cloud Run for HTTP services with uneven traffic, where scale to zero and a built-in URL save the most setup. Pick Fargate when the rest of your stack is on AWS, when services need to run continuously, such as workers and WebSocket servers, or when you need the VPC-level control of ECS.

Related guides

• Cloud Run alternatives
• What is AWS Fargate?
• EKS vs ECS vs Fargate
• How to connect Cloud Run to Cloud SQL