AWS ECS Fargate vs Google Cloud Run 2025

I like AWS and work with its resources daily. Containerized applications are very popular these days. In AWS, you can use Lambda to run containers, ECS Fargate or even Kubernetes. I often use Fargate because it’s AWS-managed, easy to use, easy to configure, and good for long-running heavy applications with high traffic.

However, I often experienced scaling issues with Fargate during high-traffic peaks, which led to customer error responses. I wrote an article on how to save your Fargate application from traffic spikes.

But I would like to consider another option.

This article will compare AWS ECS Fargate with Google Cloud Run.

Preparation

To compare Fargate with CloudRun, I decided to run Performance Tests and observe metrics for both services.

I prepared a simple Fibonacci express.js app and uploaded the Docker container to the Docker hub. Both GCP and AWS support images.

I will not describe how to create a Fargate scalable app or Google CloudRun service. It’s simple, and many docs are already on the internet.

However, I would like to note that CloudRun already has a built-in Load Balancer. For AWS Fargate, you must spend more time creating ALB, target group, and Cluster before creating a web service.

I will use CPU-based scaling for both solutions since the Fibonacci sequence requires a lot of computation power.

Google Cloud Run

The benefit of Cloud Run is that you don’t need a separate load balancer service. It already has a built-in LB, which scales requests according to load. However, if you need more specific LB functionality, like requests route, blocking, etc., you must use Google Load Balancing.

To set up web service using Cloud Run:

  • Go to CloudRun
  • Create service
  • Chose your docker image (can be from Docker Hub or Google Artefact Registry)
  • Configure CPU/RAM, everything else can be default.
  • That is, you are good to

Each test will have 4 phases but with different rampTo and arrival rate values:

phases:
    - duration: 120
      arrivalRate: 1
      rampTo: 1
      name: Warm up phase
    - duration: 120
      arrivalRate: 1
      rampTo: 2
      name: Ramp up load
    - duration: 120
      arrivalRate: 2
      rampTo: 5
      name: Moderate load
    - duration: 120
      arrivalRate: 5
      rampTo: 10
      name: Peak load

Performance Test Summary

Test 1 Configuration: Fibonacci 30, up to 10 users during peak.

Test 2 Configuration: Fibonacci 30, up to 12 users during peak.

Output Results:

Test 3 Configuration: Fibonacci 40, up to 12 users during peak.

Output Results:

After running tests, Cloud Run handled them very well. Here is a monitoring graph from Google Monitoring, which can tell more.

High CPU utilization throughout the test case can suggest that resources are utilised very well during scaling.
Container instance scaling was quick and smooth.

Also, I noticed a thing: after the high peak, they scaled down quickly as well, but still, there are some containers (around 10) left that are idle. So if the peak happens again, they will scale in a shorter time.

This graph shows the time it takes to spawn up the container. Its impressive compared to a Fargate

Generally, I can say that Google Cloud Run scales very well. Let’s see how Fargate will do it for the same test cases.

AWS ECS Fargate

To set up Fargate web service, you have to do the following:

  • Create ECS Cluster
  • Create an Application Load Balancer
  • Create a Target Group for ALB
  • Create Task Definition (here we will define 1CPU and 2GB RAM)
  • Create Fargate web service in ECS Cluster
  • Configure the service to use ALB and the target group created above, and set up autoscaling.
  • I’ve set up step scaling based on CPU consumption. More CPU used — more tasks will be added

Let’s run the same tests as we did for Cloud Run

Get Oleksandr Hanhaliuk’s stories in your inbox

Test 1 Configuration: Fibonacci 30, up to 10 users during peak.

Output Results:

Test 2 Configuration: Fibonacci 30, up to 12 users during peak.

Output Results:

Test 3 Configuration: Fibonacci 40, up to 12 users during peak.

Output Results:

The result after the test is worse than that of Cloud Run. The average response time seems the same, but there are a lot of failed requests. During the tests, I observed unhealthy targets, which led to this due to slow scaling. The main reason is that Fargate scaling is based on Cloud Watch Alarm. The alarm has a minimum period of 1 minute. Plus, according to my observation, container spinup time is around 40 seconds. According to AWS, if you use the EC2 launch type, image pull behaviour has a caching mechanism. But it seems this doesn’t work for the Fargate launch type. I’ve seen issues opened as well as discussions regarding this. But it seems like AWS has still not solved it.

Here are some CloudWatch metrics during the tests.

CPU Utilization dropped when task scaling was finished.
Scaling stopped after reaching 10 tasks. PS: later on, it scaled more, but the test was already finished

Pricing

AWS Fargate bills users based on resource consumption, while Google Cloud Run bills on a pay-as-you-go model. For AWS you should also consider ALB traffic. Cloud Run is more expensive for applications with forecasted or stable traffic and can be up to 2x times more expensive. However, if your application has unpredictable traffic, which is low most of the time, Cloud Run will be cheaper and more feasible.

I have a low-traffic app with an average of 2 req/s and 1–2 tasks (1 CPU/4 GB) running constantly. Last month, I paid around $40$ for it.

A similar Fargate app would cost around 60$.

Conclusion

I cannot say which is better because they can both be good for specific tasks.

Let’s draw a line here with the pros and cons for both.

AWS ECS Fargate

Pros:

  • integrations with AWS resources
  • are more flexible in configuration. You can choose Spot instance types as well as EC2
  • pay for resources — which makes it cheaper for stable traffic or long-running jobs

Cons:

  • scaling is slow, which is not good for high-traffic spikes
  • deployment is also slow. This can be crucial during incidents, bug fixes and development in general
  • more complex setup

Google Cloud Run

Pros

  • very quick deployment for the new revisions.
  • quicker scaling
  • easy initial setup
  • simple Google console and dashboard

Cons

  • limited in configuration
  • pricing model pay-per-request — can cost more for long-running jobs and stable traffic without sudden spikes. This is more similar to AWS Lambda or GCP Functions; however, it’s not because CloudRun doesn’t have limits lambda’s has

That’s it. I think we can shed some light on the differences between AWS Fargate and Cloud Run. Cloud Run surprised me with quick deployment and scaling, but its pricing model is less preferable than in AWS.

Similar Posts