AWS announces per-second billing for EC2 instances(techcrunch.com) |
AWS announces per-second billing for EC2 instances(techcrunch.com) |
[0]: https://cloud.google.com/compute/docs/sustained-use-discount...
Running 2x 4cpu instances for 1 month is the same as 4x 2cpu instances for 1 month, and will come out the same even if you switch in the middle.
(Note: I have no investment in the company)
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 like more info.
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.
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.
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.
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.
[0] - https://azure.microsoft.com/en-us/services/virtual-machines/
"Keep your budget in check with low-cost, per-minute billing. You only pay for the compute time you use."
I really want to use them to parallelise CI test runs, but haven't gotten round to setting this up yet.
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.
This is certainly a long time coming.
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.
Also, is the economic incentive really that huge? Or is it just a nicety?
AWS batch currently does this. I presume that will change now.
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...
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.
Per-second billing doesn't add much value to EC2.
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.
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.
The applications are "whatever you want imagine" but yes one application is building FAAS Function As A Service in which the operating system carries out a single function.
Put anther way, Docker is complex, overweight, and requires re-implementation of much computing infrastructure. You can meet many of the same goals as Docker in much more simple way not by building containers but by building tiny operating systems.
What would be interesting is if they had exactly the same upvotes and comments.
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.
But if I'm reading things correctly, it still took over two orders of magnitude longer to boot than it did to reply. So what sort of use case does millisecond boot help with? Very sporadic requests?
This was already possible even with a 2 second boot time. The problem is that it's a stupid use case because (unless the OS boots up in <10ms) the latency of waiting for the bootup is intolerable in any use case where a 2 second boot time was intolerable.
1) a complete and utter nightmare to debug.
2) A huge waste of computing resources. Even with a unikernel you're wasting time initialising resources and getting in to a ready state to be able to process a request. Why bother when you can be ready and respond effectively instantly?
Starting in milli-seconds is not the hard problem. Starting + warming caches in that time is -- that will get you a bunch of awards when you solve it.
I agree it's basically marketing from AWS, but it's still strictly better than per minute billing
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.
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.
Lightsail is dumbed down to the point of basically being worthless. There's really no reason to use Lightsail over Digital Ocean.
Not to mention all the big names missing from that list. For some reason Dimension Data makes the list (and it's woeful, from experience), but there's no Digital Ocean, OVH, Hetzner, etc...
One thing I noticed though is the pricing seems a bit biased; for example for AWS it recommends an m1.small with 1GB Ram and 20GB of Storage at $35 a month ... However if you used a t2.micro that would give you the same specs for $10.79
Thanks for pointing it out!
> "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.
If one were to look at storage, specifically, the move to 4k block sizes would seem like a particular boon in terms of increasing the volume of data covered by any given IOP.
Good morning! `aws ec2 start-instances --instance-ids i-12345678900`
Good night! `aws ec2 stop-instances --instance-ids i-12345678900`
http://docs.aws.amazon.com/autoscaling/latest/userguide/sche...
But since a Lambda is a program, you can make the criteria as complex as you like.
Tag it with "shutdown=non-biz-hours", and "timezones=UTC-7,UTC+0,UTC+5:30" and your shutdown script can figure out when it's outside of business hours in all of those timezones and shut it down.
To implement it use autoscaling group of size of 1. Then change desired to 0 or 1 based on need.
Standard vs. Convertible: Convertible allows you to switch between instance families (like c3, m3, m4, i2, r3 etc...) but it requires you to make a 3yr commitment, commit to a specific AZ and doesn't offer the same level of savings you'd get with a 3yr standard, I think it's closer to the savings you'd get with a 1yr Standard RI. Standard RI's come in 1yr or 3yr commitments. You can choose between the default option of the "Regional Benefit" which allows you to apply the RI to any instance that meets the RI criteria in a given region or you can choose the "Capacity Reservation" option which requires you to commit to a specific AZ to guarantee your reservation. That's right, your 'reserved' instance isn't necessarily reserved in the case of an outage unless you commit to a AZ.
One benefit that you get with Standard RI's is that they can be applied to any size instance in the family for which you've purcahsed them. Amazon allows you to convert between nano, micro, small, large, 2xlarge etc. within an Instance Family (t2, c3, m3, r4 etc.) with Standard RI's and they apply these conversions automatically on your bill.
Then you also have to choose how you pay, no-upfront and all monthly (smallest capex), partial upfront/partial monthly or all-upfront (largest capex).
It's frustrating because it's so complex that it makes me hesitate. I never feel like I'm getting the best deal and it just feels like AWS is taking advantage of the market by making pricing impossible to decipher.
Does anyone have any good methods for determining how many RI's to purchase, how often etc?