AWS announces per-second billing for EC2 instances

[zedpm]

That's sure nice, but I'm waiting for AWS to switch to automatic sustained use discounts [0] like GCP offers.

[0]: https://cloud.google.com/compute/docs/sustained-use-discount...

[mbesto]

They would legitimately lose a lot of money if they did this now (and I would argue, wouldn't make up for it in market share). Most companies I work with who switch to AWS think it's a 1:1 conversion in terms of cost from a data center and pretty much just "leave AWS on" not realizing that they are not only paying for computing cost but the hidden cost of being able to scale up more instances quickly.

[jaxbot]

I'm waiting for GCP to support preemptible GPU instances. Would love to be able to spend ~50% less on GPU instances when running a batch job that can be stopped and reloaded.

[_wmd]

It wouldn't be a switch, it'd be a new feature. GCP also offers the equivalent of explicit instance reservations

[pmelendez]

That is cool if you maintain a fixed number of instances but it doesn't seem to be very cost efficient if you are implementing autoscale

[ranman]

Link to AWS Blog Post: https://aws.amazon.com/blogs/aws/new-per-second-billing-for-...

[deafcalculus]

I really wish AWS would allow users to cap billing. Something that freezes all AWS services if the monthly bill exceeds X would make me a lot more comfortable when experimenting with AWS.

[sarabande]

Agreed. Right now you can set billing alarms, but not actually freeze billing. http://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/...

[angrygoat]

This is the main reason I keep a $40/month Linode running, when I'd probably save if I used AWS -- most of the time my instance isn't doing a lot. I just don't want the anxiety of a billing surprise due to a mistake, or a DDOS coming my way.

[homero]

I lost $1200 to an s3 mistake when I was broke years ago, it really sucked.

[matteblack]

Have you looked into a tool like Gorilla Stack - https://www.gorillastack.com/?

(Note: I have no investment in the company)

[sitkack]

This is really dangerous due to the way clouds calculate billing, it isn't a mistake that clouds want to enable users to make.

[nodesocket]

Per second billing is somewhat of a gimmick just so Amazon can say they are more granular than Google Compute. The difference between seconds and a minute of billing is fractions of a cent. Rounding errors.

The exception is Google Compute has a 10 minute minimum, so if you are creating machines and destroying them quickly, per second billing will be noticeable.

[grzm]

I think the useful comparison people are making is the difference between the previous per-hour billing and new per-second billing. Sure, if they can get some mileage comparing per-second to per-minute, great. At the end of the day isn't the increased granularity better?

[aidos]

This is one of the better things to happen in ec2 in years for me. We have a bunch of scripts so a spot instance can track when it came online and shut itself down effectively. It took far too much fiddling around to work around aws autoscale and get efficient billing with the per hour model. In the end we came up with a model where we protect the instances for scale in and then at the end of each hour, we have a cron that tries to shut all the worker services down, and if it can't it spins them all up again to run for another hour. If it can, then it shuts the machine down (which we have set on terminate to stop). The whole thing feels like a big kludge and for our workload we still have a load of wasted resources. We end up balancing not bringing up machines too fast during a spike against the long tail of wasted resource afterwards. This change by ec2 is going to make it all much easier.

[gumby]

Back to the future: this was how computing worked back in the punch card days. Minicomputers and personal computers were supposed to liberate you from this tyranny: computing so cheap that you could have a whole computer to your self for a while!

[mikeash]

Somehow we've reached a point where a 2GHz, 2GB computer that fits in your pocket is only worth using as a terminal.

[sinatra]

The global scale makes even that cheap computing become fairly expensive. So, it's only natural that we'll take punch card type ideas (at local scale) from the past and apply them at our global scale.

[segmondy]

We still have whole computers to ourselves. Those that wish to throw their money away renting can knock themselves out.

[Spooky23]

We have these things. It's even cheaper in most cases. :)

[JosephLark]

Likely due to GCP competition. I believe GCP was always per-second? [Edit: Misremember that, they were always per-minute. Lots of good information below directly form the related parties.]

Azure looks to be per-hour [Edit: Wrong again, they are per-minute as well. Oddly enough, I did check their pricing page before, but missed the per-minute paragraph and only saw the hourly pricing] but I'm seeing something about container instances possibly being per-second.

[Scaevolus]

GCP VMs are per-minute, with a minimum of 10 minutes (vs AWS' new minimum of 1 minute). Second resolution is nice, but I doubt it makes much difference in pricing for most workloads. https://cloud.google.com/compute/pricing#billingmodel

Azure's containers don't use a full VM-- they're more like AWS Lambda or other serverless frameworks, so they do per-second billing with no minimums.

Disclaimer: I work at Google on Container Engine.

[jen20]

I was under the impression Azure was also per minute, and AWS was the last hold out of hourly billing among the big three until today.

[lostapathy]

This should enable some entirely new use cases, especially around CI and automation in general.

Per-second billing greatly reduces the overhead to bringing up an instance for a short task then killing it immediately - so I can do that. There's no need to build a buffer layer to add workers to a pool and leave them in the pool, so that you didn't end up paying for 30 hours of instance time to run 30, two-minute tasks within an hour.

[movedx]

For us it will mean we can spin down Bamboo elastic agents much quicker and save money.

[YokoZar]

I once considered writing an EC2 autoscaler that knew the exact timestamps of the instances so that it could avoid shutting down VMs that still had 59 minutes of "free" time left because they'd been up across another hour-long threshold. That sort of nonsense logic shouldn't be useful, but Amazon was giving a huge economic incentive for it.

This is certainly a long time coming.

[daigoba66]

If it helps, AWS' default auto scaling algorithm specifically takes into account instances which are nearest to their next billing hour and prioritizes those for termination accordingly to, in theory, save money.

[matwood]

> I once considered writing an EC2 autoscaler that knew the exact timestamps of the instances so that it could avoid shutting down VMs that still had 59 minutes of "free" time left because they'd been up across another hour-long threshold.

Years ago my boss at the time did this (this was when scaling had to mostly be done in code/by hand). I just recently updated all the code as I moved it to using spots. The low price of spots made it less important to shut ones down closer to the hour mark though.

[vacri]

Remember that AWS has been in the game for over a decade. Per-hour billing was amazing when it came in.

Also, is the economic incentive really that huge? Or is it just a nicety?

[macarthy12]

> that it could avoid shutting down VMs that still had 59 minutes

AWS batch currently does this. I presume that will change now.

[djhworld]

This is great news and a long time coming.

I really hope Amazon build something like Azure Container Instances [1], as per second billing would make this sort of thing feasible.

[1] https://azure.microsoft.com/en-us/services/container-instanc...

[rsynnott]

Ah, finally. They've ruined my idea for an optimal EMR job runner. Under the old system, if you have a linearly scalable Hadoop job, it's cheaper to, say, use 60 instances to do some work in an hour vs 50 instances to do the work in 70 minutes, assuming you're getting rid of the cluster once you're done. No more!

[nogox]

I think the per-second billing is off the point. How does it help, if the EC2 instance takes tens of seconds to launch, and tens of seconds to bootstrap?

To make the most of per-second billing, the compute unit should be deployed within seconds, e.g. immutable. prebaked container. You launch containers on demand, and pay by seconds.

[bschwindHN]

It has a one minute minimum anyway. And does it not help? Let's say a deployment strategy has a temporary increase in instances so it can transition to a new version of the application. If your deployment takes 5 minutes, you're only paying for 5 minutes worth of extra instances whereas the hourly billing would get you for an entire hour. Am I completely misunderstanding something?

[riobard]

You're describing exactly https://hyper.sh.

[andrewstuart]

Really welcome, although per millisecond would be better.

It's now possible to boot operating systems in milliseconds and have them carry out a task (for example respond to a web request) and disappear again. Trouble is the clouds (AWS, Google, Azure, Digital Ocean) do not have the ability to support such fast OS boot times. Per second billing is a step in the right direction but needs to go further to millisecond billing, and clouds need to support millisecond boot times.

[planteen]

Just curious here, what OS can do millisecond boot times? How many milliseconds are you talking? And the constant boot time of the OS is so much less than the OS responding to the web request that this is actually worth it?

[vidarh]

If you're concerned about cost, AWS is almost never the right place to host to begin with.

[jawns]

Sounds like you're describing AWS Lambda / serverless architecture. But maybe I'm not understanding your use case?

[ttobbaybbob]

Interesting that the techcrunch link has thrice as many upvotes as the amazon link

[grzm]

I suspect it's simply a function of which one happened to catch people's eye and where they started their discussion. Multiple submissions on the same topic (from the same or different sources) aren't that uncommon. Once one gets some momentum, it's likely to be reinforced: it'll appear higher on the front page, more people will notice it, more people will comment, more people will notice the comments on that article, which will make them notice that article, et cetera. I don't think you can read much more into it than that. I wouldn't be surprised if a mod comes along and merges the comments from one into the other, if they notice it.

What would be interesting is if they had exactly the same upvotes and comments.

[ranman]

Hackernews black magic :/

[SadWebDeveloper]

Serverless advocates/engies are probably the only people celebrating this, everyone else keeps waiting for self renew instance reservation... last time i forgot about them it was too late.

[scaryclam]

The market for this is much broader. We do a bunch of data science so spinning up a heavy machine and only getting billed for the 5 minutes usage is a massive saving for us. I'm quite excited by this news!

[nunez]

This is great and will save a lot of people a good amount of money.