5 ms·
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
by 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 agoI used the per-hour pricing in my numbers because I assumed the per-second was wrong, yeah.
- derefr 9y agoI 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 agoWell 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.
- sync 9y agoTangentially related: you can definitely use S3 as a database now, and they seem to encourage it: https://aws.amazon.com/blogs/aws/s3-glacier-select/ https://aws.amazon.com/blogs/aws/s3-glacier-select/
- mrep 9y agoWithout lock support, I wouldn't consider it a database.
- justonepost 9y agoKind of a read mostly database, actually useful for data lake type things.
- IanCal 9y agoYeah I'm really looking forward to this as I often have to get some part of one of many jsonl files that matches some condition. S3 select will likely let me delete a lot of custom code.
- deleted 9y ago[deleted]
- justonepost 9y agoYes, this is standard pricing model for all new tech.
- tbrock 9y agoI’m your target for this service as a large consumer of ECS that hates dealing with the underlying resources. Despite fargate being very compelling it’s priced too damn high (even without the mistake). I’d be willing to pay a premium but this is just not cost effective.
- heisnotanalien 9y agoYou hate starting an AMI and having a simple script to connect to an ECS cluster?
- tbrock 9y agoNo, that’s the easy part. I strongly dislike that auto scaling groups do not communicate with ECS (service scaling) and that updating your nodes to run a new ECS optimized ami is tedious and error prone. Want to scale up/down when you have high or low load? Cool, configure it at the ECS service level AND at the auto scaling group level. Will the auto scaling group take instances away before they’ve been drained of connections or randomly? Who knows the systems don’t talk to one another to coordinate: Fail What about just removing a node from the cluster when it fails? Decrease service count min temporarily -> Drain connections elb -> remove from target group -> kill instance. This is a 5-10 minutes process to do correctly that should be 1 click. Same problem, stuff doesn’t talk. Want to update to a new ECS optimied AMI to get updates and patches but ensure a minimum of core services keep running while you scale down after you’ve scaled up? Good luck!
- rem7 9y agoAlso, last time I checked IAM roles sucked on ECS. Not every container in the cluster should have the same role. I wonder if fargate fixes this.
- ilaksh 9y agoThe issue for me is we don't have funding, so just pay coming out of savings until we make money. The cheapest seems to be more than $40, but based on the description its only allocated $5 to $10 worth of computing. I am using Linode or Digital Ocean pricing for that, but even with Amazon's inflated EC2 pricing it's probably like $25 max. So I can't justify paying $40 per month when I can get the same horsepower for $10 or $20. I can set up an open source system for monitoring and containers restart automatically. For people that have $200,000 burning a hole in their pocket, it may be a different story.
- foolfoolz 9y agoif you are trying to pay bottom dollar for hosting aws is not the solution
- nvivo 9y agoYou're completely right. You can get an amazing server in a very good hosting provider at a fraction of AWS. Really. You can get for $200/month a good server in a good hosting that costs literally $5000/month or more on AWS. Azure and Google are not different. What you don't get is all their regions, easy scalability with EBS, managed services, etc. But all of that has a very high price, and depending on who you are and what you're trying to do, these cloud providers are probably the worst option.
- jopsen 9y agoCurious if this also holds for spot nodes... For build and test tasks... sure scalability would be needed. What would you suggest, scaleway seems to have poor APIs for automation, and atom CPUs so not useful..
- anthony_barker 9y agoMain thing was security... DO now offers F/W now though.
- chamini2 9y agoFocus on making a product that makes money and afterwards build with containers and these complex-to-maintain technologies. Start simple and take care of your scalability problems when you have them, not before.