[acdha]

You have to weigh these risks against the likelihood of them actually happening. If AWS made a first-ever price increase, yes, you'd then have to consider whether you could beat that pricing by doing it in-house but you have to balance that against the very low odds of it actually happening and the up-front costs of hiring a ton of staff (e.g. just having 24x7 support requires something like 5 people when you factor in leave, vacations, etc.), buying or renting a lot of hardware, developing and getting operational confidence in a complicated software stack, etc.

That's a LOT of money to spend up front on a gamble that something which has never happened before occurs with so little notice that you wouldn't be able migrate away first. It's hard to see anyone but the major players having enough economy of scale to see positive returns on that investment, much less having enough budget room to where that makes sense rather than spending the same amount of money on something which users actually see.

That gets to the other reason why this is so unlikely: raising prices in a predatory manner would be a loud message to every AWS customer to find alternatives. Since AWS generates something like 7-8 billion dollars a year that's an enormous amount of money to risk — far greater than any short-term return they'd see.

[falcolas]

> If AWS made a first-ever price increase

Actually, AWS does this all the time: for new or growing large scale users they offer a discount on the list price. Once the user is firmly embedded in AWS, they stop offering the discount. This can lead to an effective doubling of the cost of using AWS.

[acdha]

That's not the same thing because you know in advance exactly which terms you're getting and you can make your decision accordingly.

[falcolas]

You don't know when, or even if. It's entirely subjective on how secure Amazon feels in keeping your business.

I know of one business where it took 4 years for Amazon to start dropping that hammer. A real killer for any maturing startup.

Yes, you could simply budget for the full price and set aside that money, but any smart executive will tell you that money is better invested in the company. Would you be willing to fire 10-20 employees with 1-4 years of tenure because Amazon decided you were tied enough to them to drop your discount?

[BatFastard]

As an AWS user since 2007, I have seen my bill for existing services drop every month. Now they keep on adding great new services, but they are not jacking up the price on anything. Hm.. I want to plan my game, costs for the servers will be going down each year, can I live with that?

[abiox]

i'm not convinced that we're talking about a "smart executive" in this particular scenario.

[mikeash]

I don't understand what you mean by balancing it against the up-front costs of hiring a ton of staff. The whole point here is that if you're not locked in to AWS (because you don't use their free-with-massive-strings-attached game engine) then you can migrate to some other cloud service if AWS no longer suits you.

[acdha]

What I was getting at is the need to actually look at those costs rather than just assuming that it's always better to maximize flexibility. Running your own services has a high up front cost because you have to pay people to build, test, and secure everything before you see any return. You can come up with estimates for the various outcomes and how likely each would be but that's a lot more nuanced than this thread had been, particularly with speculation like “What if they suddenly increase the price by an order of magnitude?”.

The detail which I think techies are particularly prone to forget is that businesses deal with “lock-in” (i.e. contracts) all the time; it has downsides but managing those is routine. In particular, many businesses love to defer up-front costs into a structure where they only need to pay for actual usage.

[jo909]

I agree that the large price increase scenario is pretty unlikely, and not what this is about.

This is about bundling decisions together that do not need to be bundled. Changing the game engine after the fact is about the hardest thing you can do, virtually impossible after a certain stage. The decision for the engine is necessarily a very very early one.

But you can easily and very likely need to improve your backend many many times, even far into the games development or after release. Limiting your options for that so early is very risky.

And your are right, that risk could be offset by some large enough benefit you only get with that engine. I just fail to see where that would be. I can still use all of AWS if I choose an independent game engine.