1

I'm making a web-app, I've tried both ECS and EKS at AWS. It's been very comfortable to use Fargate instances instead of EC2. But I'm not sure I understand how to use them since when I count at it, it's so much more expensive. Prices

In the prices it says ~$0.05/h/vCPU which would mean 37.5$/m/vCPU. Which is very expensive compared to EC2. But from what I've understood Fargate is more suitable for container that have a limited lifetime? Does this mean that they are not useable at all(or atleast price worthy) for a webapp that's running 24/7? My web app can really shutdown an start up by requests, it would be to slow. Is there something I'm missing?

3
  • 1
    Isn't the key benefit of Fargate that you do not get charged on a per hour basis at all. Rather, the vast majority of web applications do have a lot of time spots when 0 vCPU is needed. This is of course reliant of all traffic to be properly cached and all background processes having been extracted. So its not a correct comparison to just multiply the hourly charge by 24/31 to get a monthly charge.
    – jdog
    May 12 at 8:04
  • I haven't really understood the way the calculate the cost. I thought that you were charged in Fargate by how much resources you had "provisioned" for that instance. But is it actually how much vCpu the instance is using, regardless how how much it's provisioned? May 12 at 8:27
  • I've just reread the pricing page. You are only charged for usage, however the minimum charge is 1 min, then per second. Unfortunately, this would mean a web application that has at least 1 request per minute would indeed be charged 24/7. So it still seems suitable for something like a CMS, where you know that you pay only for admin time and form submissions, likely much less than 1 per minute. But not for what I would consider a web application
    – jdog
    May 12 at 9:27
3

Fargate is absolutely suitable for web apps. We have many customers that use it that way (and many others that use it in a more "batchy" way). Fargate is a managed compute engine and AWS takes a more responsibilities in terms of scaling, patching, security, and so forth so comparing raw Fargate costs to raw EC2 costs isn't how I would compare them. Having that said, raw EC2 capacity (like for like) is usually just 20% cheaper than raw Fargate capacity. If you factor in the cost of operations (less with Fargate) and the fact that you hardly drive EC2 clusters at full utilization, the comparison tends to skew towards Fargate most of the times. These are a couple of blogs that talk about this (blog one and blog two).

3

But from what I've understood Fargate is more suitable for container that have a limited lifetime?

That's not strictly correct, Fargate capabilities include tasks which are suitable for short-term limited lifetime tasks as well as services which are designed to run all the time.

For sure, Fargate is more expensive as compared to EC2 - but you don't need to maintain the instance, patch the OS, have your container runtime and manage them, handle scaling of the underlying nodes - Fargate does this all for you. All you need to provide is a Docker image, how much vCPUs & Memory you need and to how many containers it should scale to, and AWS will take care of the rest. You can optionally provide a CloudWatch log group and have the container logs streamed to CloudWatch logs, or also stream them to custom log ingesters as well.

1

Nope, Fargate can be used for long running containerized workloads. Web apps, proxies, or any other containers. Maybe you are thinking of Fargate Spot? Fargate Spot is definitely not suitable for long running containers, and should only be used for running workloads that can be safely interrupted or stopped unexpectedly. This is because AWS is able to retake those instances from you at any point in time they choose.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.