Super interesting. If I did the math right, a 3year heavy reserved t2.micro instance comes out to $4.48/mo, which is cost competitive with Digital Ocean. The proof will come in the benchmarks, but this may become my preferred hosting solution.
It's $77 for 1 year reserved if I'm reading it correctly. That's $6.44 per month for an instance with double the RAM of the DO $5 instance. The specs look like the size that DO is charging $10 for currently. For a 3 year reserved instance it's $4.48 a month for double the size of the DO $5 instance. There's also a free tier, so the first year is free to try it out.
DO was competitive with EC2 on price but not on features (and certainly not on security), now with the price advantage gone...
How many customers use more than 1GB of outbound traffic per month for a $5 server? Data transfer in is free on EC2 and the first 1GB outbound is free too according to the pricing page.
Isn't the first GB of your account traffic free with AWS vs DO giving you 1 TB per droplet?
While 1 EC2 instance may not use more then 1 GB (which is a very low quota unless your CDNing everything), if you have a couple of instances your almost certainly going over that.
ok, so about $6.90 per month for 1 year then including storage. Thats still less than a 1GB RAM DO server which goes for $10 per month, and much less if you go for 3 years. Factoring in 1 year of free tier makes it even less.
It doesn't include storage
Id doesn't include SSD storage
It doesn't include provisioned IOPS for SSD Storage (well, ridiculously low)
It doesn't include bandwidth
IT doesn't include support.
The issue is that this offering is complex to understand as opposed to DO which is incredibly simple to understand. It is actually pretty funny how hard it is to understand this offering from AWS, it takes many paragraphs of reading to figure it out.
There's nothing to understand with DO because they don't tell you what their definition of a "CPU" is. For all I know it could be oversubscribed in a worse way than EC2.
Most people don't care the exact speed of the CPU for a server, as long as it's stable and doesn't lockup with little load, especially when purchasing a Micro instance. If CPU utilization is high then it's time to upgrade to another CPU or start another instance if possible.
It would be better to do real speed tests of each service to determine average "CPU" speed. I'm sure both services are constantly optimizing for both shared hardware usage and speed, so the stats would have to be updated regularly.
AWS is a simple model: pay for what you use. Most cheap hosts (i.e. please kill me DreamHost) give you no SLA and your rolling the uptime dice. Three years on DH and I wanted to kill myself. Three years on AWS and life is just splendid!
To understand your billing, you need to understand what you're consuming, which you always should. These credits add a little wrinkle, but also make the service cheaper and more deterministic. If you have credits, you'll get the CPU you bought with them.
I would replace 'super interesting' with 'Super complex'. It's an example of how you can make the price of a $10-40/mo server complex to the extent that you need to read the blog post numerous times before you understand the construct.
And even then, one still needs to factor in the 'other' costs like I/O or IOPs, disk (persistent/EBS), IPs, internet and inter-region data transfer… before you understand the real cost.
And then you need to compare to other instance types (which soon will cover the full alphabet -- c, cg, cr, g, h, i, m, r, t… ) and then other providers.
You still have several unresolved issue -
1. Are your assumption on usage (cpu, I/O, internet etc) correct? Will they change?
2. How do I compare performance across providers for a given VM specification.
3. Can I get support when I need it?
And I am sure there are others
It certainly means there is room for other players who just make it simple, whether they are infrastructure folk (like DO/Linode etc) or platform plays that make the pricing understandable by the audience they are trying to target (like Heroku/Ninefold)
The interesting thing about Amazon (vs the VPS market, where DigitalOcean, Linode, and I live) is that when amazon lowers prices, they lower prices for existing customers who don't make changes to their accounts. When a VPS provider like Linode lowers their prices, they usually charge existing customers the same amount, and simply give them more resources.
Just an observation. I'm not criticizing either way of doing things; obviously, lowering prices straight out is better for the customer, and keeping revenue stable while just upgrading hardware is better for the provider. Last time I lowered prices, I lowered prices directly, and just took the revenue hit. I'm planning my next upgrade now, and instead of lowering prices, I plan on giving everyone more ram/disk/ssd, while holding prices steady.
It is something I've thought about... the problem is that I'm going to have to go down by more than half, and it's way easier to lease enough hardware to more than double everyone's allocations than it is to double my customer base to make up for the lost revenue.
>Perhaps I have selective memory, but I've never seen Linode lower prices, they just keep upping the specs on the lowest tier.
Yes, exactly. I'm saying that is the standard way to do it in the VPS market, in part because until D.O. most of us were self-funding, and it's way easier to pay for double the compute resources than to deal with a 50% cut in revenue.
In the "cloud" market where amazon is, the standard way to do it is to directly lower prices.
AWS is a little bit a hybrid of both. If you're paying hour-to-hour, all cuts are immediate. But there is such a huge discount for reserved instances, that many large clients are using a large proportion of them. With a 3-year "heavy utilization" reserved instance, Amazon has gotten a significant % of the total price for running that instance up front, locked in for 3 years. Since the biggest part of the revenue (the reservation fee) is locked in, cutting the hourly rate only gives back a smallish part of the revenue to those kinds of clients.
Really? when they lower the price of the per-hour billing they don't lower the locked-in fees?
Huh. In the VPS market, from what I've seen, the rule is "treat your existing customers as well as your new customers"
while, say, the co-location market is like the real-estate market. "Subsidize your new customers, and if they are still alive when the lease is up, take profits in the form of much higher renewal rent."
I guess what you describe with pre-pays is sort of inbetween. There's a difference in most minds, I think, between raising a price and just not lowering it when you perhaps could be expected to. Most people new to the real-estate market feel pretty bent out of shape when they find out that they have to pay significantly more in rent to renew their existing contract than they will pay if they move.
Thanks. That's good feedback. We are working hard on the upgrades, but I have been way too slow :(
I do observe that there seems to be a price floor phenomena; for any customer, any price below $x is largely equivalent; they will go for the best thing they can get for $x, so providing a better product helps, but lowering the price below $x doesn't change the equation for that customer. Of course, $x is different for each person, so lowering your price does get you customers who had a lower value for $x.
I've already lost most of the customers that had a value for $x that was greater than what they were paying me at this point; I'm not losing customers nearly as quickly as I predicted. Right now, if I screw something up, of course, I lose the effected customers; I mean, it's really dramatic. You always lose some customers when you screw something up, but I lose way more now than when my prices were lower than the credible competition. But other than that, things have largely stabilized.
I should note that I'm a hobbyist/enthusiast type of customer; if you're losing business on price grounds, I can definitely see where a price cut would help.
(Also, it doesn't help that the wiki is crufty and out of date, and boot menu, last time I rebooted, was still on CentOS 5.)
> I should note that I'm a hobbyist/enthusiast type of customer; if you're losing business on price grounds, I can definitely see where a price cut would help.
I think similar principles govern business spending, only $x for them is usually higher. I have a couple of business co-lo customers who have been customers for like half a decade; some of them are still using the hardware they came in on. They could save a lot of money by upgrading hardware (and thus reducing their footprint) or even moving to "the cloud" at this point, because while co-locating modern hardware is cheaper than "The Cloud" - co-locating ancient hardware is not.
The idea is that it works for them, so they aren't going to fuck with it. I'd bet money, though, that if I fucked something up and caused them a serious outage, they'd be gone pretty quick.
>(Also, it doesn't help that the wiki is crufty and out of date, and boot menu, last time I rebooted, was still on CentOS 5.)
I just want to acknowledge those problems. We only have vague plans for the wiki, but we're actively working on upgrading the rescue image and the hypervisor (which, I imagine, is the part of the boot menu you are complaining about.) - these changes will probably not be implemented until our switchover to the new ganeti-based system, but... that should be soonish.
Be careful here. Despite announcing 42 price reductions over the 7 years of AWS existence, the M1 tier was only reduced for the first time in 3 years after Google/Azure dropped their pricing. They push through a huge number of price drops, but sometimes (actually often) their headline drop is one very small, unique charge, leaving everything else unaffected.
They will, but only for people who didn't lock in a reserved instance. Amazon doesn't typically upgrade instance types, but rather introduces new ones. So if you lock in a t2.micro instance for a 3-year reserved period, you are stuck with exactly those specs for 3 years. If they introduce a t3.* instance class next year, you don't get a free upgrade to the new specs.
That increases the flexibility, but afaict doesn't help with the upgradeability angle. When Amazon passes along the technological dividend by creating new instances with a better price/performance profile, it's usually as new family types. So your reserved t2.* instance can swap with other t2.* instances, but won't be able to take advantage of any t3.* instance that's introduced in the future.
It's not a huge deal, just something to take into account when projecting out costs: the 3-year reserved instances are locking in today's prices until 2017, in return for a discount over today's non-reserved prices. Whether this produces long term gains requires some assumptions about how the market will change over the next 3 years.
And that's worth quite a lot, given Amazon's bandwidth is expensive. The 2tb in the Linode $10 account will run you about $200 with Amazon. Doubtful anyone is burning 2tb on a $10 account, and I'm sure Linode has that in mind, but even if you're using 200gb of bandwidth that would still cost you over $20.
Pricing plans for Amazon also include the best security and interconnects bar none, fastest access to the wide array of AWS and AWS hosted services and an ecosystem of tools and apps.
And of course Amazon has transparent disclosure for outages and security issues unlike say Linode.
