Amazon EC2 Pricing Changes Effective April 1, 2014
aws.amazon.com
aws.amazon.com
Bill Miller, the chief investment officer at Legg Mason Capital Management and a major Amazon shareholder, asked Bezos at the time about the profitability prospects for AWS. Bezos predicted they would be good over the long term but said that he didn’t want to repeat “Steve Jobs’s mistake” of pricing the iPhone in a way that was so fantastically profitable that the smartphone market became a magnet for competition.
Google isn't running a charity. Shutting down losing services is a smart business decision. If you see the cloud going the way of the typewriter, then you should also be looking elsewhere to run your computing resources.
As long as there are people who pay more for the Google cloud service than Google's own usage is worth, selling to others reduces the overall costs of computing for Google.
I can't help but feel that I got really fucked by poor timing that I couldn't control. It would hurt so much less if these price changes were more gradual and somewhat consistent (perhaps monthly).
:)
Anyway, what a massive drop in price and what a swift reaction from Amazon. Competition can really do wonders. I just hope we won't be seeing drops in the level of service.
Cheers to Google.
They already charge an immense premium over your own fleet of micro to large instances, but by the time you rack up enough dynos for it to make sense to spend the necessary weeks migrating your infrastructure there's a good chance that replicating the environment with your own in house version (30+ instances?) is non trivial enough to be scary.
Once you're over a handful of dynos, the sunk costs and uncertainty will keep you there until it becomes totally ludicrous.
Heroku launched with $0.05/hr pricing.
Amazon's new m1.small pricing is $0.044/hr, nearly a 50% price drop over four years.
Heroku still is $0.05/hr, the same price as when it launched. Heroku runs on EC2.
[1] http://www.sunsetlakesoftware.com/2010/09/15/how-run-drupal-...
Just never EBS. Ever.
TLDR: it's okay for backups, but in critical path it's a world of sadness. Failure modes are too painful.
The performance of EBS is pretty bad, and getting decent performance is expensive. Having said that, if your application runs in memory and disk usage is infrequent then it is probably fine to use EBS. EBS is also much more expensive than the instance storage, but it is also durable unlike instance storage.
On the whole, "never ever EBS" is too strong language making it incorrect. As usual, it depends.
Most databases have replication but you need to make sure that the characteristics of how the database handles a node failure are well understood. Worst case you use EBS, put your state on it, snapshot it regularly, and ship those snapshots to another region because when EBS fails it fails hard.
Also, logs make every machine stateful. Use something like logstash to centralize that state.
That or sidestep ELB in your region to a team of stateless load balancers that terminate SSL.
The pricing seems reasonable for the performance (I've not done benchmarks if I'm being honest), and you get to treat all your EC2 instances as expendable.
I meant rather that is there any other option for persistent data on AWS?
Also, on EC2, EBS-backed instances boot faster [2]. Of course, you can (and should) still treat EBS-backed instances as expendable.
[1] http://aws.amazon.com/rds/faqs/#hardware-scaling
[2] http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Component...
To be honest, I didn't know RDS was backed by EBS but it makes little real difference to me as long as the backup procedures are rock-solid and the performance is acceptable.
At Netflix we use Cassandra and store all data on local instance storage. We don't use EBS for databases.
It's one of those "huh, never ever thought of it from that angle" sort of ideas. The very idea of putting your absolutely valuable data on ephemeral storage and just duplicating it.
Thanks for that.
https://wiki.postgresql.org/wiki/Synchronous_replication
This way you should be able to tolerate failure of a single instance without losing data.
of course, if a comet hits the master db server, you might lose a tiny bit data (typically 0.1 seconds) if not using sync replication.
you can use sync replication for the important things that you absolutely can't lose, and async replication for everything else.
I wouldn't take it that far! There is conflicting information on which between Standard EBS and Instance store performs better but there have been benchmarks to support that EBS does perform more consistently than instance store (example: http://serverfault.com/questions/111594/which-is-faster-for-...). Also, you can now launch EBS optimized instances which use a network stack intended to separate EBS I/O giving better throughput. iops is expensive but is great to have when you need it.
Sure, if EBS goes down in your zone, you're hosed. But unless you're completely independent as a service, chances are you do depend on something which uses EBS so you might be hosed anyways.
Instance store is great free storage to use. Since it needs to be mounted explicitly, I'm guessing that most people don't end up using it. Thats a shame too; so use that free storage but EBS isn't evil either.
I prefer AWS for work stuff because firewall, security groups and networking are much easier to manage.
I have not yet tried GCE but I may move some of my dev stuff over once they roll out the private git repos.
https://source.developers.google.com/p/PROJECT/r/default
You might have to turn it on in your developer console, not sure.
At the moment, pushing to its "master" branch tries to deploy to app engine, so that might not be what you're looking for.
You can clone it (and, in the future, your connected repos and other Google-hosted repos) with 'gcloud init PROJECT', and things should work nicely.
AWS is.
I find it bizarre that Amazon put so much effort into pushing the idea theat their killer feature is price. Plenty of people outflank them on price. What's best about Amazon it their tooling. They have hands-down better tooling than their competition.
I use gandi for my personal stuff (because I'm less bothered by the French government spying on me than the US one) and it's much cheaper than Amazon. But in terms of being able to easily mass-manage a complex environment? Not even close. DO? Don't make me laugh.
This is the Southwest Airlines model. Tell everyone you're great on price often enough, even if it's not always true, and plenty of people will think you're good on price.
Given this tidbit, might you reserve an instance now, pay the lower fee, but still take advantage of the new hourly rates on April 1? Or are you locked in at whatever rate your reservation is for?
Bummer, though. We just reserved a multi-AZ m3.large RDS instance last week. I wish AWS would take up Google's system of graduated price reductions over steady run duration.
When we switched off EC2 it was financially advantageous to basically give away our heavy instances on the marketplace just to shed the liability.
In this example, it becomes a question of whether it's worth saving $130'ish a year for the liability that a 1-year m3.medium heavy util reservation represents. At the lower end, that's not a huge amount of liability, but it may be a case where I just don't bother reserving m3.mediums anymore because it's a wash.
For example:
Now: m3.xlarge $1266 $0.105 per Hour $1922 $0.086 per Hour
April 1st: m3.xlarge $886 $0.074 per Hour $1345 $0.06 per Hour
It sounds weird if Amazon is actually going to keep charging the higher rate to existing customers, as they've already paid the higher reservation fee as well.
It's pretty much Caveat emptor with them.
As far as I know this minimum is set by Amazon, but I don't see that pricing listed in the announcement here.
wonder if there would be price battle on bandwidth.
Dell C1100 1U (almost 4 years old) 2x 6core with HT, 24 active threads 144 GB RAM 10x 300 15k SAS
I think there are very few use cases where Amazon makes sense. Their VMs are very expensive, and under powered for what you pay.
For the most part, it's because the cost of hardware isn't the only factor, but the flexibility, ability to rapidly scale (and descale), and, most importantly, the fact that Amazon takes care of all the dirty network engineering/system administration work required to keep the plumbing working.
But, hey, that's the great thing about the free market - every company/individual gets to make the choices that are most advantageous for themselves. I wouldn't be surprised that in regions where network engineers/sysadmins make less than $125-$150K/year, and there isn't a need to turn up a dozen servers overnight, (and, turn them off the night after that) - that AWS/Azure/GCS isn't attractive. But, clearly, for others, it is.
- G2 popular use cases: Game streaming, 3D application streaming, and other server-side graphics workloads.
- CG1 popular use cases: Computational chemistry, rendering, financial modeling, and engineering design.
Economically cloud can make a lot of sense for several potential customers, including:
* those who have highly variable workloads (so they can spin up lots of servers to meet demand then spin them down afterwards)
* those who favor OpEx over CapEx (Like startups)
* and for those who are bypassing internal IT for TTM reasons (e.g. "shadow IT")
Another point to consider is that while AWS is increasingly dropping prices the same is in effect happening for people procuring their own hardware. The performance over price ratio (on multiple axis) is also improving for on premises deployments (c.f. Moore's Law).
But that's been Amazon's strategy for almost two decades. Their goal is to instead grow their business. Currently they are at $74 Billion / year in revenue, and still increasing. Once they stop their massive spending on growth, they will (presumably) be able to increase their profits.
And what happens when AWS is no longer a revenue source?
Shareholder (owner)'s decision: cut it.
Not a big deal if you are running a business but pretty significant ($588/year) if you are doing personal dev work.
So, pay extra for the support contract?