
AWS announces per-second billing for EC2 instances - jonny2112
https://techcrunch.com/2017/09/18/aws-announces-per-second-billing-for-ec2-instances/?ncid=rss
======
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...](https://cloud.google.com/compute/docs/sustained-use-discounts)

~~~
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.

~~~
doh
Not sure that will happen anytime soon. It's the same with Local SSD. The
virtualization of this environment is very challenging, maybe beyond a point
where it makes sense for them to do so.

~~~
williamstein
But GCE already has local SSD’s for preempt instances, and they even cost
less.

~~~
doh
Wasn't aware they added the support. Well, maybe they can figure out GPUs too.

~~~
jeffmcjunkin
I'd be surprised if it'd be that much additional work, if the local SSD
options are NVMe -- which is _also_ PCI-e like GPU's.

~~~
0x0
Wait what, would they expose the raw SSD pci device to your vm? What's
stopping you from scraping all the leftover data from the previous customer?

~~~
tylerjd
Probably something along the lines of secure erase. Most modern SSDs/NVMe
drives are encrypted by default in firmware. All the firmware needs to do is
throw away the old keys and generate new ones. It's better than zeroing the
drive as there is no wear to the write cycles and guarantees that the slack
space in the SSD is also cleared, which DD'ing to /dev/nvme0 wont be certain
of. The nvme-format tool can be used for this:
[http://manpages.ubuntu.com/manpages/zesty/man1/nvme-
format.1...](http://manpages.ubuntu.com/manpages/zesty/man1/nvme-
format.1.html)

~~~
wtallis
On newer SSDs, the sanitize command would be preferable for this use over the
format command. IIRC, the format command doesn't require quite as strong a
security guarantee as the sanitize command: the latter ensures that user data
is cleaned from both the flash and all buffers, CMBs, etc.

------
ranman
Link to AWS Blog Post: [https://aws.amazon.com/blogs/aws/new-per-second-
billing-for-...](https://aws.amazon.com/blogs/aws/new-per-second-billing-for-
ec2-instances-and-ebs-volumes/)

------
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/...](http://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/free-
tier-alarms.html)

~~~
extra88
Looking at the CloudWatch console, I see I can also add AutoScaling and EC2
actions that are triggered by an alarm. That still leaves open other risks
like a bandwidth bill for S3 hosted content.

------
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?

~~~
mfringel
I think "second vs. minute" might be into "distinction without a difference"
territory. Sure, per-second will definitionally help at the margins, but I'm
dubious about the amount of money it will actually save.

That all being said, it _can_ enable a bunch of interesting things (e.g. more
interesting stuff with AWS Lambda), and I look forward to see what per-second
billing becomes an enabling technology _for_.

~~~
grzm
Sure. I read 'nodesocket as arguing that AWS is promoting per-second as a
distinction between AWS and GCP ("somewhat as a gimmick" in their words).
That's not mentioned in the submission, nor the AWS blog post announcement.

The important and very real distinction is the change from per-hour to per-
second. If you're going to make it more granular (which from per-hour is a
good thing), why would AWS stop at per-minute if it's the same or only
marginally more difficult to make it per-second, particularly when they have
the added benefit of being more granular that GCP? In other words, I don't see
the reduction as _primarily_ a marketing move on AWS's part. I'm sure they
felt pressure to make it more granular. Stopping at parity doesn't necessarily
make sense, nor should they be called out for doing more purely for marketing
reasons.

------
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.

~~~
reilly3000
Apple is moving in the opposite direction with onboard-only face ID and ARKit.

------
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](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.

~~~
andruby
Hyper.sh runs docker containers, not VM's, and has per-second billing with a
minimum of 10s.

I really want to use them to parallelise CI test runs, but haven't gotten
round to setting this up yet.

~~~
alauda
Check [https://github.com/hyperhq/hykins](https://github.com/hyperhq/hykins)

------
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.

~~~
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?

~~~
jdc0589
it's totally dependant on your workload. for some users there will be
absolutely no difference, for others it could easily be thousands or tens of
thousands of dollars of savings over a year.

~~~
vacri
Thanks, I stand corrected. I've read through a few other use cases in the
comments here and I can see now that there's scope for savings, depending on
workload.

------
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...](https://azure.microsoft.com/en-us/services/container-instances/)

------
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.

~~~
riobard
You're describing exactly [https://hyper.sh](https://hyper.sh).

~~~
nogox
Or Azure ACI.

Per-second billing doesn't add much value to EC2.

~~~
WalterGR
EC2's granularity was hourly before. _That 's_ the value being added.

~~~
nogox
Per-minute billing makes more sense to EC2, given the reason above.

~~~
shawabawa3
Well, on average it's per-minute billing with a 30 second discount.

I agree it's basically marketing from AWS, but it's still strictly better than
per minute billing

------
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.

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

~~~
andrewstuart
You miss the point.

The lifetime of a web request, for example, can be measured in milliseconds.

It is now possible, technically anyway, for operating systems to boot, service
the request and disappear.

There needs to be pricing models that reflect computing models like this.

~~~
mmcconnell1618
There is likely a point of diminishing returns in this type of scenario. The
OS boot time, the web service setup time, the actual request and then the
shutdown time. Also consider that unless you have an external caching layer,
you may be processing some requests that could have been cached by an always-
on server. If your site has predictable traffic patterns then I suspect the
math would be in favor of always-on provisioned servers with scale up/down
based on traffic. If you have a very high traffic site the extra OS boot time
(even in milliseconds) is going to add up quickly. You'd have to be very sure
the spin up/down time is less than the idle time of the always-on server.

------
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.

------
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!

~~~
SadWebDeveloper
That is basically the serverless main "point of sell" you are just one step
away from automation (if you aren't already doing it) and it will be virtually
the same as serverless

~~~
aidos
You're right, this is effectively a serverless mode. But the serverless
instances that are currently available (at least on aws) aren't powerful
enough for some applications. For those of us stuck in the middle, needing big
machines with serverless behaviour, this is a massive win.

~~~
FridgeSeal
I'm in the same boat as you: data science workloads that run intermittently on
big hardware.

What are you running your big jobs on? Because I'm currently using Batch, but
given you've got to wait for the compute environment/VM to start up (if it's
not already running), and that's a pain because it takes _forever_ to startup.

I wish I could just run containers on large hardware the same way we can run
lambda's: press the button and it just runs, I don't really care about having
my own full compute environment, I just need enough memory and CPU to run it.

~~~
aidos
Ours are actually user generated and the running time of each task is variable
(few minutes to an hour). Users can to dump anywhere between 1 and 200 tasks
on at a time.

The way we have it set up is:

\- simple job queue with RQ (redis)

\- monitoring watches the queue and pumps a metric into Cloud Watch (there are
a few different types of job and it calculates a single aggregate value for
"queue pressure")

\- autoscale then sets the desired capacity for a fleet of r4.2xlarge machines
(somewhere between 1 and 20)

\- the autoscale config protects all those machines from scale-in so they have
to be shutdown externally

\- each of those machines has a cron on boot that tracks the start time

\- this enables a cron to run just before the end of each hour. If that
machine isn't doing anything at the time, it will shut itself down

\- the machines are set to terminate on shutdown so they die completely

\- additionally, we've hacked RQ so that workers that are closer to death will
move themselves to the back of the queue more frequently. This ensures that we
have a higher chance of not being busy / shutting them down at the end of the
hour.

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

