Answers: <blockquote>
  <p>But from what I've understood Fargate is more suitable for container that have a limited lifetime?</p>
  </blockquote>
  <p>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.</p>
  <p>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 &amp; 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.</p>
  
Answers: CC BY-SA 4.0
Answers: 2021-05-11T11:31:35.570Z
Answers: 2021-05-13T18:07:44.940Z
Answers: 2021-05-13T18:07:44.940Z
Answers: Sathyajith Bhat
Answers: <p>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.</p>
  
Answers: CC BY-SA 4.0
Answers: 2021-05-11T21:00:23.870Z
Answers: 2021-05-11T22:32:12.830Z
Answers: 2021-05-11T22:32:12.830Z
Answers: Preston Martin
Answers: <p>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 &quot;batchy&quot; 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 (<a href="https://aws.amazon.com/blogs/containers/theoretical-cost-optimization-by-amazon-ecs-launch-type-fargate-vs-ec2/" rel="noreferrer">blog one</a> and <a href="https://www.trek10.com/blog/fargate-pricing-vs-ec2" rel="noreferrer">blog two</a>).</p>
  
Answers: CC BY-SA 4.0
Answers: 2021-05-11T08:11:34.633Z
Answers: 2021-05-11T08:11:34.633Z
Answers: mreferre
Body: <p>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. <a href="https://aws.amazon.com/fargate/pricing/" rel="noreferrer">Prices</a></p>
  <p>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?</p>
  
Comments: CC BY-SA 4.0
Comments: 2021-05-12T08:04:14.720Z
Comments: 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.
Comments: jdog
Comments: CC BY-SA 4.0
Comments: 2021-05-12T08:27:20.920Z
Comments: 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?
Comments: Felix Eklöf
Comments: CC BY-SA 4.0
Comments: 2021-05-12T09:27:20.417Z
Comments: 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
Comments: jdog
Tags: <amazon-web-services><amazon-ecs><eks>
Title: Is AWS Fargate suitable for web applications?
UserDisplayName: Felix Eklöf
ThreadText: # Is AWS Fargate suitable for web applications?
  
  (Asked by: username_0 on 2021-05-10)
  
  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](https://aws.amazon.com/fargate/pricing/)
  
  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?
  
  **Tags:** amazon-web-services, amazon-ecs, eks
  
  > **Comments:**
  > **username_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.  
  > **username_0**: 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?  
  > **username_1**: 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  
  
  ---
  
  ## 3 answers
  
  ### Answer by username_4 on 2021-05-11. Score: 6 | Accepted answer
  
  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](https://aws.amazon.com/blogs/containers/theoretical-cost-optimization-by-amazon-ecs-launch-type-fargate-vs-ec2/) and [blog two](https://www.trek10.com/blog/fargate-pricing-vs-ec2)).
  
  
  ---
  
  ### Answer by username_2 on 2021-05-11. Score: 4
  
  > 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.
  
  
  ---
  
  ### Answer by username_3 on 2021-05-11. Score: 2
  
  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.
  
  
  ---
  
  