14 ms·

Fargate looks really expensive compared to just running an EC2 instance. A 1 vCPU container with 2GB of RAM will run you $55/month. An m3.medium with 1 vCPU and

Fargate looks really expensive compared to just running an EC2 instance. A 1 vCPU container with 2GB of RAM will run you $55/month. An m3.medium with 1 vCPU and 3.75GB of RAM is $49. The prices seen to get uncomfortably worse from there, though I haven't priced them out the whole way, but a 4 vCPU container with 8GB of RAM is price-competitive ($222 for the container, $227 monthly for the machine) with a freaking i3.xlarge, with 4 vCPUs and 30.5GB, and the i3.xlarge also has 10Gbit networking. Topping Fargate out at 4 vCPUs and 30GB of RAM puts it right between an r4.2xlarge and an i3.2xlarge, both with 8 vCPUs and 61GB of RAM (the i3 is more expensive because it's also got 1.9TB of local SSD). Enough people are still trying to make fetch happen, where fetch is container orchestration, that I expect that fetch will indeed eventually happen, but this is a large vig for getting around not-a-lot-of-management-work (because the competition isn't Kubernetes, which is the bin packing problem returned to eat your wallet, it's EC2 instances, and there is a little management work but not much and it scales). If you have decided that you want to undertake the bin packing problem, AWS's ECS or the new Elastic Kubernetes Service makes some sense; you're paying EC2 prices, plus a small management fee (I think). I don't understand Fargate at all.

srdev 9y ago
Can you elaborate on what the bin packing problem is?
- andrewstuart2 9y ago
  It's multi-machine scheduling, basically. Given N resources and M consumers, how can I fit all M consumers most efficiently, while using the minimum N? The bin metaphor is that you imagine one or several bins on the floor, and a bunch of things to place in bins. Binpacking is just playing tetris to make sure all your things are packed into as few bins as possible, because bins cost money. https://en.wikipedia.org/wiki/Bin_packing_problem https://en.wikipedia.org/wiki/Bin_packing_problem
- barrkel 9y ago
  https://en.wikipedia.org/wiki/Bin_packing_problem https://en.wikipedia.org/wiki/Bin_packing_problem If you have a bunch of jobs and you need to run them efficiently on a bunch of compute, you need to be careful not to oversubscribe the hardware, especially wrt memory. There's an isomorphism between running differently sized jobs concurrently on a compute resources, and the bin packing problem. It's a scheduling problem.
- deleted 9y ago
  [deleted]
- eropple 9y ago
  Kubernetes requires machines big enough to run all your containers. Those machines are the bins. Your containers are the packages. Fitting your containers in such that there is no criticality overlap (in AWS, that all instances of service X are spread across machines in different AZs) and that there is room for immediate scaling/emergency fault recovery (headroom on the machines running your containers) gets expensive. You're buying big and running little, and that comes with costs. Meanwhile, in AWS, you already have pre-sized blobs of RAM and compute. They're called EC2 instances. And then AWS pays the cost of the extra inventory, not you. (To forestall the usual, "overhead" of a Linux OS is like fifty megs these days, it's not something I'd worry about--most of the folks I know who have gone down the container-fleet road have bins that are consistently around 20% empty, and that does add up.) You may be the one percent of companies for whom immediate rollout, rather than 200-second rollout, is important, and for those companies a solution like Kubernetes or Mesos can make a lot of sense. Most aren't, and I think that they would be better served, in most cases, with a CloudFormation template, an autoscaling group with a cloud-init script to launch one container (if not chef-zero or whatever, that's my go-to but I'm also a devops guy by trade), and a Route 53 record. You're basically paying overhead for the privilege of `kubectl` that, personally, I don't think is really that useful in a cloud environment. (I think it makes a lot of sense on-prem, where you've already bought the hardware and the alternatives are something like vSphere or the ongoing tire fire that is OpenStack.)
  - andrewstuart2 9y ago
    I know you're answering the question of bin-packing, but after two years of experience with it, I can say that for me, bin-packing is one of the smallest benefits (though it sells very well with management), though perhaps a baseline requirement these days. The real benefits, in my experience, stem from the declarative nature of cluster management, and the automation of doing the sensible thing to enact changes to that declarative desired state.
    - eropple 9y ago
      Sure. CloudFormation exists for that, though, and both its difficulty and its complexity are way overstated while also letting you manage AWS resources on top of that. And it doesn't cost anything to use.
- manigandham 9y ago
  Running load efficiently on a given resource. Most VMs running a single app are under-utilized so it's more efficient to pack apps into containers and run them across a smaller pool of servers so that they all get the necessary resources without waste. Kubernetes does really well with this, although ease of deployment using config files and the abstraction from underlying vms/servers is probably more useful for most companies.
  - eropple 9y ago
    Kubernetes emphatically does not do better at resource utilization than not using Kubernetes. You should figure on between ten and twenty percent of wastage per k8s node, plus the costs of your management servers, in a safely provisioned environment. You can argue about the configuration-based deployment being worth it--I disagree, because, frankly, Chef Zero is just not that complicated--but it's more expensive in every use case I have seem in the wild (barring ones where instances were unwisely provisioned in the first place).
    - manigandham 9y ago
      Based on what evidence? We can put hundreds of customer apps into a few servers and have them deployed and updated easily. We could try to manage this ourselves but it's much less efficient while costing much more effort. GKE also costs nothing for a master and there is no overhead. K8S/docker also makes it easy to avoid all the systemd/init issues and just use a standard interface with declarative configs and fast deployments that are automatically and dynamically managed while nodes come and go. We have preemptible instances with fast local storage and cheap pricing that maintain 100s of apps. K8S also easily manages any clustered software, regardless of native capabilities, along with easy networking. Why would I use chef for that - if it can even do all that in the first place?
      - bonesss 9y ago
        > GKE also costs nothing for a master and there is no overhead. Just a historical perspective: GCE used to charge a flat fee for K8s masters after 6 nodes. After the announcement of the Azure K8s service, with no master-fee, GCE has dropped the fee as well :)
rockostrich 9y ago
Fargate seems like it's an in-between of Lambda and ECS. Lambda because it's pay-per-second on-demand functions being run (or in the case of Fargate, containers) and ECS because Fargate is ECS without having to worry about having the EC2 instances configured. I'm not sure where this falls in, but maybe developers were complaining about Lambda and wanted to just run containers instead of individual functions?
- NathanKP 9y ago
  Lambda has some limitations such as cold starts, 5 min max execution time, etc because it is designed for a much more granular operational model. Fargate is designed to run long running containers that could stay up for days or weeks, and always stay warm to respond to requests, so there is no cold start.
- mullen 9y ago
  It's Lambda with out the 5 minute limit.
  - lindydonna 9y ago
    Plus the ability to do custom containers. For some workloads, may be valuable.
- eropple 9y ago
  I assume as much; my contention is that that's not gonna really be worth it even to the people who think they want it. Not at this price.
  - deleted 9y ago
    [deleted]
- dastbe 9y ago
  The way I think about it is temporal and spatial control, and giving up control over them so that some common entity can optimize and drive down your costs. With Fargate, you're giving up spatial control so you can just pay for the task resources you asked for. With Lambda, you're additionally giving up temporal control so you can just pay for resources when you're lambda is actually servicing a request. When I think about the offerings this way, I can start to decide when I want to use them because now I can ask myself "Do I need strict temporal/spatial control over my application?" and "Do I think I can optimize temporal/spatial costs better than Lambda/Fargate?".
deleted 9y ago
[deleted]
axelfontaine 9y ago
Yes, the pricing seems off by 3 orders of magnitude! 2734 USD for a month of t2.micro -like capacity! Unbelievable! https://aws.amazon.com/fargate/pricing/ https://aws.amazon.com/fargate/pricing/
- zedpm 9y ago
  Check your math. 1vCPU at $0.0506 per hour + 1 GB RAM at $0.0127 per hour gives $.0633 per hour. At 750 hours per month, that's $47.48 per month. A T2.micro is $8.70 per month, but not even close to a whole vCPU, so it's not a direct comparison. Edit: I think they have a mistake on the pricing page: the per-second rate looks more like a per-minute rate. Doing the calculation with the per-second and again with the per-hour stated prices gives a 60x difference in monthly cost. Edit2: Yep, they've now fixed the per-second price; it was originally 60x the correct price.
Androider 9y ago
A T2 will give even better real-world performance than an M3, at 2x vCPU and 4GB of RAM at ~$34/mo. Unless you're compute bound the bursting performance of T2s is perfect for web services. Add an instance reservation, with no upfront cost, and you're looking at ~$20/mo for a t2.medium. Using Fargate will reduce your instance management overhead, but not worth it at over 2x the price, at least for me. I'd rather have two T2's than one M4 for most web services, or 8 T2's over 4 M4's etc. for both better performance, reliability and price. T2's are the best bang for your buck by far, as long as your service scales horizontally.
- eropple 9y ago
  You're completely correct. I was just going price-to-price.
- ryeguy 9y ago
  No way t2's are a good choice for your average webservice. You don't get the full CPU with t2's. With a t2.medium if you're using over 20% of the cpu (40% of 1 vcpu or 20% of both), you're burning CPU credits. So unless you have a webapp that uses 8gb of memory yet stays somewhere under 20% cpu utilization (maybe with some peaks), you'll eventually get throttled. t2's are for really bursty workloads, which only makes sense for a webservice if you aren't handling much traffic in general and you have maybe 2 instances total.
  - eropple 9y ago
    Most web apps are IO bound, not CPU bound, and a throttled T2 has IO to spare versus its CPU usage.
    - Johnny555 9y ago
      t2's are great until something happens and you really need the full CPU, then you get throttled and suddenly your service goes down because it can't keep up with the load. If you use t2's for anything important, keep an eye on the CPU credit balance.
ntrepid8 9y ago
Looking through the pricing page I'm not sure what sort of workload this would make sense for. Just looking at the examples from the pricing page I think I'm getting sticker shock. - https://aws.amazon.com/fargate/pricing/ https://aws.amazon.com/fargate/pricing/ Example 1 > For example, your service uses 1 ECS Task, running for 10 minutes (600 seconds) every day for a month (30 days) where each ECS Task uses 1 vCPU and 2GB memory. > Total vCPU charges = 1 x 1 x 0.00084333 x 600 x 30 = $15.18 > Total memory charges = 1 x 2 x 0.00021167 x 600 x 30 = $7.62 > Monthly Fargate compute charges = $15.18 + $7.62 = $22.80 So the total cost for 5 hours of running time is $22.80? Am I even reading this correctly? If so, what would this be cost effective for?
- luhn 9y ago
  I think they mislabeled the pricing. If you look at the per-hour pricing ($0.0506/CPU-hour and $0.0127/GB-hour), that translates to $0.00084333 and $0.00021167 per minute, which is a pretty reasonable price. This also makes sense in light of their recent announcement of per-minute EC2 billing.
  - ntrepid8 9y ago
    Ah yes, that makes much more sense. Hopefully they will update the pricing page with the correct values soon :)
  - dd_says 9y ago
    That is correct
  - ntrepid8 9y ago
    Hopefully this is the correct math for their example 1: (1 * 2 * 0.00021167 * (600/60) * 30) + (1 * 1 * 0.00084333 * (600/60) * 30) = 0.380001 Because that's much better than the original: (1 * 2 * 0.00021167 * (600) * 30) + (1 * 1 * 0.00084333 * (600) * 30) = 22.80006
  - NathanKP 9y ago
    You are correct, we mislabelled the pricing on launch, it is corrected now. The correct values are: $0.0506 per CPU per hour $0.0127 per GB of memory per hour
mark242 9y ago
Yes. If you're using Elastic Beanstalk, or Cloudformation with autoscaling, Fargate seems to be an incredible waste of money. Maybe if you have an extremely small workload that doesn't need a lot of resources running, I could see it, but at that point you'd be better off with Lambda instead?
vhold 9y ago
Maybe it's precisely only billing for cpu and memory consumed, so if your workload has a small footprint and is mostly waiting around a lot for other services to respond it would be really cheap?
- colemorrison 9y ago
  nah, I asked, it's for the amount reserved, not the amount used. https://twitter.com/nathankpeck/status/935930795864211461 https://twitter.com/nathankpeck/status/935930795864211461
NathanKP 9y ago
AWS employee here. Just want to say that we actually had a typo in the per second pricing on launch. The actual pricing is: $0.0506 per CPU per hour $0.0127 per GB of memory per hour Fargate is definitely more expensive than running and operating an EC2 instance yourself, but for many companies the amount that is saved by needing to spend less engineer time on devops will make it worth it right now, and as we iterate I expect this balance to continue to tip. AWS has dropped prices more than 60 times since we started out.
- deleted 9y ago
  [deleted]
- eropple 9y ago
  I used the per-hour pricing in my numbers because I assumed the per-second was wrong, yeah.
- derefr 9y ago
  I know AWS services put outsized fees on things that don't really have marginal costs (e.g. S3 read operations), because the fees are used to disincentivize non-idiomatic use-cases (e.g. treating S3 as a database by scanning objects-as-keys.) Under this economic-incentive-system lens, I'm curious whether new AWS services might also be intentionally started out with high premiums, as a sort of economically-self-limited soft launch. Only the customers with the biggest need will be willing to pay to use the service at first, and their need means they're also willing to put up with you while you work out the initial kinks. As you gain more confidence in the service's stability at scale and matching to varied customer demands, you'd then lower the price-point of the service to match your actual evaluation of a market-viable price, to "open the floodgates" to the less-in-need clients.
  - nerpderp83 9y ago
    Well if something needs more burn in time, the last thing you want to do is get thousands or millions of customers. The reliability of a Timex or Toyota has to be high.
  - 9y ago
einrealist 9y ago
Can someone do the math and comare it to Cloud Foundry / OpenShift solutions? That AWS offering seems to be a step into this part of the market.
talove 9y ago
Just wanted to share a perspecticve: I think it's a misnomer to call it expensive or compare using a more abstracted service like Fargate vs something more granular like EC2. If I need a service that lets me prototype, build a product, be first to market, etc. splitting hairs over compute costs seems moot. Not to say it isn't interesting to see the difference in pricing or how AWS quantified how to set pricing of the service. FWIW, if you watched the Keynote stream, the theme of it was literally "Everything is Everything" and a bunch of catch-phrases basically meaning they've got a tool for every developer in any situation. One other note: From my experience I'd also argue it's often times easier to migrate from fully-managed to more-self managed services than the other way around. By nature of owning more operations, you make more decisions about how it operates. Those turn into the pain-points of any migration project.
- djsumdog 9y ago
  But does this lock you in to Amazon? Trying to run a DCOS/marathon or K8s cluster is not trivial. Last time I looked, every service out there basically spun up a Docker machine with some auto-magic cert generation. Surely there are other services out there which will just run containers, allowing you to deploy from a k8s or marathon template? What are the other options?
  - baudehlo 9y ago
    Sadly even giants like Rackspace are moving to being managers of AWS services. It’s hard to beat amazon’s pricing at scale, even if this is a touch over priced.
    - AlexCoventry 9y ago
      Got a cite for rackspace reselling aws resources?
      - YawningAngel 9y ago
        https://www.rackspace.com/en-gb/managed-aws https://www.rackspace.com/en-gb/managed-aws
deleted 9y ago
[deleted]
- deleted 9y ago
  [deleted]
- deleted 9y ago
  [deleted]

srdev 9y ago

Can you elaborate on what the bin packing problem is?

andrewstuart2 9y ago
It's multi-machine scheduling, basically. Given N resources and M consumers, how can I fit all M consumers most efficiently, while using the minimum N? The bin metaphor is that you imagine one or several bins on the floor, and a bunch of things to place in bins. Binpacking is just playing tetris to make sure all your things are packed into as few bins as possible, because bins cost money. https://en.wikipedia.org/wiki/Bin_packing_problem https://en.wikipedia.org/wiki/Bin_packing_problem
barrkel 9y ago
https://en.wikipedia.org/wiki/Bin_packing_problem https://en.wikipedia.org/wiki/Bin_packing_problem If you have a bunch of jobs and you need to run them efficiently on a bunch of compute, you need to be careful not to oversubscribe the hardware, especially wrt memory. There's an isomorphism between running differently sized jobs concurrently on a compute resources, and the bin packing problem. It's a scheduling problem.
deleted 9y ago
[deleted]
eropple 9y ago
Kubernetes requires machines big enough to run all your containers. Those machines are the bins. Your containers are the packages. Fitting your containers in such that there is no criticality overlap (in AWS, that all instances of service X are spread across machines in different AZs) and that there is room for immediate scaling/emergency fault recovery (headroom on the machines running your containers) gets expensive. You're buying big and running little, and that comes with costs. Meanwhile, in AWS, you already have pre-sized blobs of RAM and compute. They're called EC2 instances. And then AWS pays the cost of the extra inventory, not you. (To forestall the usual, "overhead" of a Linux OS is like fifty megs these days, it's not something I'd worry about--most of the folks I know who have gone down the container-fleet road have bins that are consistently around 20% empty, and that does add up.) You may be the one percent of companies for whom immediate rollout, rather than 200-second rollout, is important, and for those companies a solution like Kubernetes or Mesos can make a lot of sense. Most aren't, and I think that they would be better served, in most cases, with a CloudFormation template, an autoscaling group with a cloud-init script to launch one container (if not chef-zero or whatever, that's my go-to but I'm also a devops guy by trade), and a Route 53 record. You're basically paying overhead for the privilege of `kubectl` that, personally, I don't think is really that useful in a cloud environment. (I think it makes a lot of sense on-prem, where you've already bought the hardware and the alternatives are something like vSphere or the ongoing tire fire that is OpenStack.)
- andrewstuart2 9y ago
  I know you're answering the question of bin-packing, but after two years of experience with it, I can say that for me, bin-packing is one of the smallest benefits (though it sells very well with management), though perhaps a baseline requirement these days. The real benefits, in my experience, stem from the declarative nature of cluster management, and the automation of doing the sensible thing to enact changes to that declarative desired state.
  - eropple 9y ago
    Sure. CloudFormation exists for that, though, and both its difficulty and its complexity are way overstated while also letting you manage AWS resources on top of that. And it doesn't cost anything to use.
manigandham 9y ago
Running load efficiently on a given resource. Most VMs running a single app are under-utilized so it's more efficient to pack apps into containers and run them across a smaller pool of servers so that they all get the necessary resources without waste. Kubernetes does really well with this, although ease of deployment using config files and the abstraction from underlying vms/servers is probably more useful for most companies.
- eropple 9y ago
  Kubernetes emphatically does not do better at resource utilization than not using Kubernetes. You should figure on between ten and twenty percent of wastage per k8s node, plus the costs of your management servers, in a safely provisioned environment. You can argue about the configuration-based deployment being worth it--I disagree, because, frankly, Chef Zero is just not that complicated--but it's more expensive in every use case I have seem in the wild (barring ones where instances were unwisely provisioned in the first place).
  - manigandham 9y ago
    Based on what evidence? We can put hundreds of customer apps into a few servers and have them deployed and updated easily. We could try to manage this ourselves but it's much less efficient while costing much more effort. GKE also costs nothing for a master and there is no overhead. K8S/docker also makes it easy to avoid all the systemd/init issues and just use a standard interface with declarative configs and fast deployments that are automatically and dynamically managed while nodes come and go. We have preemptible instances with fast local storage and cheap pricing that maintain 100s of apps. K8S also easily manages any clustered software, regardless of native capabilities, along with easy networking. Why would I use chef for that - if it can even do all that in the first place?
    - bonesss 9y ago
      > GKE also costs nothing for a master and there is no overhead. Just a historical perspective: GCE used to charge a flat fee for K8s masters after 6 nodes. After the announcement of the Azure K8s service, with no master-fee, GCE has dropped the fee as well :)

rockostrich 9y ago

Fargate seems like it's an in-between of Lambda and ECS. Lambda because it's pay-per-second on-demand functions being run (or in the case of Fargate, containers) and ECS because Fargate is ECS without having to worry about having the EC2 instances configured. I'm not sure where this falls in, but maybe developers were complaining about Lambda and wanted to just run containers instead of individual functions?

NathanKP 9y ago
Lambda has some limitations such as cold starts, 5 min max execution time, etc because it is designed for a much more granular operational model. Fargate is designed to run long running containers that could stay up for days or weeks, and always stay warm to respond to requests, so there is no cold start.
mullen 9y ago
It's Lambda with out the 5 minute limit.
- lindydonna 9y ago
  Plus the ability to do custom containers. For some workloads, may be valuable.
eropple 9y ago
I assume as much; my contention is that that's not gonna really be worth it even to the people who think they want it. Not at this price.
- deleted 9y ago
  [deleted]
dastbe 9y ago
The way I think about it is temporal and spatial control, and giving up control over them so that some common entity can optimize and drive down your costs. With Fargate, you're giving up spatial control so you can just pay for the task resources you asked for. With Lambda, you're additionally giving up temporal control so you can just pay for resources when you're lambda is actually servicing a request. When I think about the offerings this way, I can start to decide when I want to use them because now I can ask myself "Do I need strict temporal/spatial control over my application?" and "Do I think I can optimize temporal/spatial costs better than Lambda/Fargate?".

deleted 9y ago

[deleted]

axelfontaine 9y ago

Yes, the pricing seems off by 3 orders of magnitude! 2734 USD for a month of t2.micro -like capacity! Unbelievable! https://aws.amazon.com/fargate/pricing/ https://aws.amazon.com/fargate/pricing/

zedpm 9y ago
Check your math. 1vCPU at $0.0506 per hour + 1 GB RAM at $0.0127 per hour gives $.0633 per hour. At 750 hours per month, that's $47.48 per month. A T2.micro is $8.70 per month, but not even close to a whole vCPU, so it's not a direct comparison. Edit: I think they have a mistake on the pricing page: the per-second rate looks more like a per-minute rate. Doing the calculation with the per-second and again with the per-hour stated prices gives a 60x difference in monthly cost. Edit2: Yep, they've now fixed the per-second price; it was originally 60x the correct price.

Androider 9y ago

A T2 will give even better real-world performance than an M3, at 2x vCPU and 4GB of RAM at ~$34/mo. Unless you're compute bound the bursting performance of T2s is perfect for web services. Add an instance reservation, with no upfront cost, and you're looking at ~$20/mo for a t2.medium. Using Fargate will reduce your instance management overhead, but not worth it at over 2x the price, at least for me. I'd rather have two T2's than one M4 for most web services, or 8 T2's over 4 M4's etc. for both better performance, reliability and price. T2's are the best bang for your buck by far, as long as your service scales horizontally.

eropple 9y ago
You're completely correct. I was just going price-to-price.
ryeguy 9y ago
No way t2's are a good choice for your average webservice. You don't get the full CPU with t2's. With a t2.medium if you're using over 20% of the cpu (40% of 1 vcpu or 20% of both), you're burning CPU credits. So unless you have a webapp that uses 8gb of memory yet stays somewhere under 20% cpu utilization (maybe with some peaks), you'll eventually get throttled. t2's are for really bursty workloads, which only makes sense for a webservice if you aren't handling much traffic in general and you have maybe 2 instances total.
- eropple 9y ago
  Most web apps are IO bound, not CPU bound, and a throttled T2 has IO to spare versus its CPU usage.
  - Johnny555 9y ago
    t2's are great until something happens and you really need the full CPU, then you get throttled and suddenly your service goes down because it can't keep up with the load. If you use t2's for anything important, keep an eye on the CPU credit balance.

ntrepid8 9y ago

Looking through the pricing page I'm not sure what sort of workload this would make sense for. Just looking at the examples from the pricing page I think I'm getting sticker shock. - https://aws.amazon.com/fargate/pricing/ https://aws.amazon.com/fargate/pricing/ Example 1 > For example, your service uses 1 ECS Task, running for 10 minutes (600 seconds) every day for a month (30 days) where each ECS Task uses 1 vCPU and 2GB memory. > Total vCPU charges = 1 x 1 x 0.00084333 x 600 x 30 = $15.18 > Total memory charges = 1 x 2 x 0.00021167 x 600 x 30 = $7.62 > Monthly Fargate compute charges = $15.18 + $7.62 = $22.80 So the total cost for 5 hours of running time is $22.80? Am I even reading this correctly? If so, what would this be cost effective for?

luhn 9y ago
I think they mislabeled the pricing. If you look at the per-hour pricing ($0.0506/CPU-hour and $0.0127/GB-hour), that translates to $0.00084333 and $0.00021167 per minute, which is a pretty reasonable price. This also makes sense in light of their recent announcement of per-minute EC2 billing.
- ntrepid8 9y ago
  Ah yes, that makes much more sense. Hopefully they will update the pricing page with the correct values soon :)
- dd_says 9y ago
  That is correct
- ntrepid8 9y ago
  Hopefully this is the correct math for their example 1: (1 * 2 * 0.00021167 * (600/60) * 30) + (1 * 1 * 0.00084333 * (600/60) * 30) = 0.380001 Because that's much better than the original: (1 * 2 * 0.00021167 * (600) * 30) + (1 * 1 * 0.00084333 * (600) * 30) = 22.80006
- NathanKP 9y ago
  You are correct, we mislabelled the pricing on launch, it is corrected now. The correct values are: $0.0506 per CPU per hour $0.0127 per GB of memory per hour

mark242 9y ago

Yes. If you're using Elastic Beanstalk, or Cloudformation with autoscaling, Fargate seems to be an incredible waste of money. Maybe if you have an extremely small workload that doesn't need a lot of resources running, I could see it, but at that point you'd be better off with Lambda instead?

vhold 9y ago

Maybe it's precisely only billing for cpu and memory consumed, so if your workload has a small footprint and is mostly waiting around a lot for other services to respond it would be really cheap?

colemorrison 9y ago
nah, I asked, it's for the amount reserved, not the amount used. https://twitter.com/nathankpeck/status/935930795864211461 https://twitter.com/nathankpeck/status/935930795864211461

NathanKP 9y ago

AWS employee here. Just want to say that we actually had a typo in the per second pricing on launch. The actual pricing is: $0.0506 per CPU per hour $0.0127 per GB of memory per hour Fargate is definitely more expensive than running and operating an EC2 instance yourself, but for many companies the amount that is saved by needing to spend less engineer time on devops will make it worth it right now, and as we iterate I expect this balance to continue to tip. AWS has dropped prices more than 60 times since we started out.

deleted 9y ago
[deleted]
eropple 9y ago
I used the per-hour pricing in my numbers because I assumed the per-second was wrong, yeah.
derefr 9y ago
I know AWS services put outsized fees on things that don't really have marginal costs (e.g. S3 read operations), because the fees are used to disincentivize non-idiomatic use-cases (e.g. treating S3 as a database by scanning objects-as-keys.) Under this economic-incentive-system lens, I'm curious whether new AWS services might also be intentionally started out with high premiums, as a sort of economically-self-limited soft launch. Only the customers with the biggest need will be willing to pay to use the service at first, and their need means they're also willing to put up with you while you work out the initial kinks. As you gain more confidence in the service's stability at scale and matching to varied customer demands, you'd then lower the price-point of the service to match your actual evaluation of a market-viable price, to "open the floodgates" to the less-in-need clients.
- nerpderp83 9y ago
  Well if something needs more burn in time, the last thing you want to do is get thousands or millions of customers. The reliability of a Timex or Toyota has to be high.
- 9y ago

einrealist 9y ago

Can someone do the math and comare it to Cloud Foundry / OpenShift solutions? That AWS offering seems to be a step into this part of the market.

talove 9y ago

Just wanted to share a perspecticve: I think it's a misnomer to call it expensive or compare using a more abstracted service like Fargate vs something more granular like EC2. If I need a service that lets me prototype, build a product, be first to market, etc. splitting hairs over compute costs seems moot. Not to say it isn't interesting to see the difference in pricing or how AWS quantified how to set pricing of the service. FWIW, if you watched the Keynote stream, the theme of it was literally "Everything is Everything" and a bunch of catch-phrases basically meaning they've got a tool for every developer in any situation. One other note: From my experience I'd also argue it's often times easier to migrate from fully-managed to more-self managed services than the other way around. By nature of owning more operations, you make more decisions about how it operates. Those turn into the pain-points of any migration project.

djsumdog 9y ago
But does this lock you in to Amazon? Trying to run a DCOS/marathon or K8s cluster is not trivial. Last time I looked, every service out there basically spun up a Docker machine with some auto-magic cert generation. Surely there are other services out there which will just run containers, allowing you to deploy from a k8s or marathon template? What are the other options?
- baudehlo 9y ago
  Sadly even giants like Rackspace are moving to being managers of AWS services. It’s hard to beat amazon’s pricing at scale, even if this is a touch over priced.
  - AlexCoventry 9y ago
    Got a cite for rackspace reselling aws resources?
    - YawningAngel 9y ago
      https://www.rackspace.com/en-gb/managed-aws https://www.rackspace.com/en-gb/managed-aws

deleted 9y ago

[deleted]

deleted 9y ago
[deleted]
deleted 9y ago
[deleted]