It seems like this fits two needs, for smaller companies and/or people just getting started with EC2.

1. Laziness. Which I don't necessarily mean in a pejorative sense. Maybe someone just doesn't have time, yet, to learn/configure/maintain spinning up an instance for limited times.

2. Single instance. To spin up an instance, you need another computer. If you want that "manager" computer to be an instance at EC2, too, now you need two instances. With this approach, you can set up just one instance and get much of the same economic benefit.

EDIT: Also...

3. Predictable cost. If your manual spun-up instance turns out to need to run for 4 hours instead of 2, you get a bigger bill. With the t2 instances, you'll get a slower compute (if you run out of "credits") but not a bigger bill.

Again, this probably appeals most to small/new customers?

> Single instance. To spin up an instance, you need another computer.

I think you can do this with cloudformation, having it respond to the size of a work queue, however:

> Maybe someone just doesn't have time, yet, to learn/configure/maintain spinning up an instance for limited times.

This is why I can't answer the question above for certain, I got about that far in documentation and went off to find a simpler solution (for me, tutum: https://www.tutum.co/ )

As far as #2 goes, you don't need another instance. You can do it with time-based autoscaling groups. This does present problems of its own, but ones that are not hard to solve.

Yeah exactly. I do think however a method where they automatically repurchase credits when it runs low such that it just ends up costing something like double a normal instance when it does run low.

Well a c3.xlarge is $0.21 per hour (their "compute optimized current generation cpu" line).

24 * $0.21 = $5.04 per hour

You could burn those for two hours, almost, to match the lowest $9.50 per month cost of what they're talking about in the blog.

The c3 approach would give you 96 vCPUs during that time. The t2 micro for $9.36 or whatever per month, gives you one vCPU. I'd have to strongly favor spinning up 24 to 48 instances of the c3 large and clocking the job in one to three hours if possible.

Burstable jobs? This is where Spot Requests shine. Current spot price for c3.xlarge is $0.032/hr

24 * $0.032 = $0.78 per hour

I run all my CI infrastructure from spots for dirty cheap. Sure, it could all be yanked out from under me, but it's been running non-stop for over a year now. Plus, it keeps you from making "special snowflake" instances that you shouldn't. A minute and Puppet/Chef have got you a splendid new instance. ;)

If you are running a service that needs to be up all the time this is ideal. For other scenarios, what you describe is probably appropriate.

With burstable instances, you accumulate 6 CPU credits every hour so you can run at 100% load for an hour, once per 10 hours for t2.medium (once every 13.3 hours for t2.medium; once every 15 hours for t2.micro)

It would be nice to have a credit window greater than 24 hours though.

EDIT: ColinCera pointed out the math is incorrect. Updated and removed erroneous conclusion.

That's not correct. The way you accumulate credits lets you run for a full hour at 100% CPU, once every 10 hours. So if you have a lightly loaded server most of the day, you can burst to 100% CPU for 2+ hours per day.

A t2.medium starts with enough credits for about 15 minutes of 2 core CPU saturation and accumulates 12 minutes/hour thereafter. In non-burst mode it is about 5X slower. For this type of workload you'd likely be better off with a c3 or m3. t2 is a better fit for long term usage with periodic spikes (20% or less of total operational time).

It keeps your IP stable, I imagine there are some scenarios where this is a plus.

So does an Elastic IP.