Live data from Hacker News

AWS announces per-second billing for EC2 instances

techcrunch.com

131–140 of 149 posts

Re: AWS announces per-second billing for EC2 instances

#131
post #41

Earlier quoted context omitted.

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.

It's really really difficult to be able to turn on and off instances as needed, like turn a test instance on in the morning when developers come in and turn it off in the evening when they leave.

So basically you want to [pause] all the instances.

Re: AWS announces per-second billing for EC2 instances

#132

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.

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.

Have you looked at https://amazonlightsail.com/ as a way to make get a billing system similar to Linode?

Re: AWS announces per-second billing for EC2 instances

#133
post #109

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.

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?

Re: AWS announces per-second billing for EC2 instances

#134
post #117

Earlier quoted context omitted.

EC2's granularity was hourly before. That's the value being added.

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

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

Re: AWS announces per-second billing for EC2 instances

#135
post #42

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.

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

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

Re: AWS announces per-second billing for EC2 instances

#136
post #122

Earlier quoted context omitted.

Have you looked into a tool like Gorilla Stack - https://www.gorillastack.com/ ? (Note: I have no investment in the company)

Thanks Matteblack (whoever you may be) - my name's Oliver and I got alerted to this mention of GorillaStack. Without wishing to be too promotional, you can set a trigger to shut off EC2 when a cost threshold is reached. You can currently automate shut off of RDS but not yet from a cost threshold (that will be available shortly). TLDR: we can do a lot of what you ask but not all of it. Feel free to reach out if you'd…

Oliver, Curious to know how did you get this alert of mention?

Re: AWS announces per-second billing for EC2 instances

#137
post #132

Earlier quoted context omitted.

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.

Have you looked at https://amazonlightsail.com/ as a way to make get a billing system similar to Linode?

As someone who has used both and DigitalOcean, Lightsail performance is absolutely terrible compared to the above. It feels like you have perpetually run out of CPU credits.

Re: AWS announces per-second billing for EC2 instances

#138
post #136
post #122

Earlier quoted context omitted.

Thanks Matteblack (whoever you may be) - my name's Oliver and I got alerted to this mention of GorillaStack. Without wishing to be too promotional, you can set a trigger to shut off EC2 when a cost threshold is reached. You can currently automate shut off of RDS but not yet from a cost threshold (that will be available shortly). TLDR: we can do a lot of what you ask but not all of it. Feel free to reach out if you'd…

Oliver, Curious to know how did you get this alert of mention?

Probably from some online brand monitoring service. I've used https://brand24.com/ and it was quite powerful.

Re: AWS announces per-second billing for EC2 instances

#139
post #70
post #56

Earlier quoted context omitted.

Which is why reserved instances exist.

The reserved instance pricing model is really poorly implemented. You have to commit to an instance class and a region, and if you need to change you can, but there is some secondary market. When compared to a sustained use model, it is a disaster. Managing all that in a large org is a real pain in the ass.

Reserved instances are really a cultural hack. It's easy to get open budgets but capex is a different, harder process. Reserving strays into Capex.

Re: AWS announces per-second billing for EC2 instances

#140
post #73

Earlier quoted context omitted.

Not quite the same, you don't own the whole core on the t2 and will get cpu throttled.

> you don't own the whole core Moving the goalposts here. 'Not owning the whole core' is the default in the cloud.

For the other instances you get a specific number of units of processing capacity that you can use 100% of continuously if you like. For the micro instances, you get a base level and build up credits towards bursts, and can not maintain 100% utilization continuously. It's very much different and not the default. To quote Amazon:

> "A CPU Credit provides the performance of a full CPU core for one minute. Traditional Amazon EC2 instance types provide fixed performance, while T2 instances provide a baseline level of CPU performance with the ability to burst above that baseline level. The baseline performance and ability to burst are governed by CPU credits."

A t2.micro allows only 10% of the vCPU baseline performance. Anything above that needs to be "earned" at a rate of 6 credits per hour. The t2.micro can accumulate a maximum of 144 CPU credits (+ the 30 initial credits, that do not renew), each good for 1 minute of 100% use.

So in other words, you can on average only use 100% of the CPU for 6 minutes per hour.

Post reply on HN