Why Google CloudRun is not an alternative for Amazon ECS!

Introduction

ECS is a popular container orchestration service provided by AWS. You can run any application on EC as long as you can containerise it. HTTP based applications or applications that consume messages from a queue - any use case - it just works, with no drama.

When evaluating a similar solution in GCP you’ll often hear about CloudRun. While CloudRun does allow you to run containerised applications it is tuned to run Http based workloads only. While nothing stops you from running non-http workloads on CloudRun but be prepared for unexpected surprises.

This blog will highlight the fundamental differences between Google Cloud Run and Amazon ECS, explaining why Cloud Run is not a viable replacement for ECS in many enterprise and production scenarios.

Key Differences Between Google Cloud Run and Amazon ECS

Comparison Table

Underlying Container Orchestration Model

• Google Cloud Run is a serverless container platform that abstracts away infrastructure concerns. You have no control over the infrastructure where your code runs. Also
• Amazon ECS, on the other hand, is a container orchestration service that runs on either AWS Fargate (serverless compute) or EC2 instances (managed clusters). ECS provides full control over compute, networking and scaling strategies.

Workload Suitability

• Cloud Run is best suited for event-driven, stateless applications that receive HTTP(S). Cloud Run enforces a strict request-response model, meaning containers must be designed for short-lived execution.
• ECS supports long-running, stateful applications that require persistent storage, custom networking, and integration with AWS services like VPC, IAM roles, and Load Balancers. ECS can run background services, workers, cron jobs, and real-time applications, offering greater flexibility for different workload types.

Networking

• Cloud Run is primarily designed for public-facing applications. While it can be configured to run within a VPC , the native experience does not support fine-grained network controls. At the end of the day the application runs on a managed infrastructure provided by Google. You have no control over that infrastructure.
  • Example: If your Cloud Run app needs to access a private Cloud SQL database, you can use the Serverless VPC Access Connector to connect to the VPC. However, the app itself remains publicly accessible unless you explicitly restrict access using IAM or other mechanisms. Also, you can’t limit Internet connectivity or impose firewall restrictions on the application as it is running on an infrastructure that you have no control on.
• ECS integrates seamlessly with AWS VPC, enabling you to run private workloads, internal services, and secure enterprise applications.

Scaling Behavior

• Google Cloud Run auto-scales down to zero instances when there is no traffic. While this behaviour is ok for http based applications where there’s no traffic - this might not work for applications that perform long running jobs or consume messages from a queue and processes them.
• ECS, can scale dynamically based on customisable rules.

If you are running HTTP workloads and you need to scale up/down just on the basis of number of http requests or CPU/memory utilisation then CloudRun will work out for you - but if you want to use any custom autoscaling behaviour like autoscaling based on number of messages pending in a queue CloudRun isn’t for you.

Persistent Storage & Stateful Applications

• Cloud Run does not support persistent storage or volumes natively. CloudRun has an in-memory filesystem, so writing to it uses the instance's memory. Note that you cannot specify a size limit for this filesystem, so you can potentially use up all the memory allocated to your instance by writing to the in-memory filesystem, which will crash the instance. You can use CloudStorage bucket as a volume using FUSE but remember if your application deals with large files you can expect issues with Fuse driver also.
• ECS allows mounting persistent storage volumes (EBS, EFS, or FSx), making it suitable for running any application that requires a large persistent store.

If you expect to have a lot of files getting stored temporarily which your application is not cleaning up - CloudRun will make your life really difficult.

When to Use Google Cloud Run vs. Amazon ECS

Conclusion

Google Cloud Run is a powerful serverless solution but is not a direct alternative to Amazon ECS. While Cloud Run is excellent for HTTP-based, event-driven workloads, it lacks the persistence, flexibility, and has autoscaling limitations.

You can consider Cloud Run as a replacement for ECS only if:

• You want a fully managed, serverless platform with automatic scaling.
• Your networking requirements are simple, and you don’t need deep VPC integration.
• You are building http based application that has a simple request response model and is not expected to have long running tasks.
• Your application does not store a lot of data on the filesystem.

So if you are migrating from AWS to GCP and someone recommends you to use CloudRun as a replacement for ECS - please think twice. If you want complete flexibility - it’s much better to move to GKE instead of CloudRun.

Migrating from AWS to GCP? Work with KubeNine and avoid common issues that enterprises face during migration. We enable our clients to get their migration done quickly and reliably.