AWS prices are already high, the danger is not so much that they will raise prices but that if your business conditions change. Perhaps there’s a new competitor and you can’t afford to splurge on cloud costs anymore, or your business needs to cut costs and focus on profitability because of economic conditions - you are stuck with this albatross.

High compared to what? GCP? Azure? A raspberry pi in a closet with a cable modem?

You generally pay for what you need and for what you can afford. If you don't need AWS or you can't afford AWS, it wouldn't make sense to use AWS. That goes for in-house software development, infrastructure management and pretty much anything else too...

I run a startup and work in another.

In my startup we use mostly linode and handle a lot of volume. I have a few VPSs and some dedicated hardware for specific tasks. Monthly bill roughly 200-250USD all included.

The other startup used the AWS free credits. Got extra credits and lived it up. Adopted Kubernetes and all the big AWS stuff. Brought in a few devops professionals. All super smart people.

Monthly spend 7kUSD on traffic/usage that's actually much smaller than the one I have with my startup. Availability is roughly the same (if anything, my startup has better uptime).

So yes, this is an Apples to Oranges comparison. I get that. They can better scale in theory etc. But if they pay 7k right now, I can't imagine how expensive it will be when they scale.

They started just using EC2 but slowly got roped into AWS services so now they have no vendor neutrality and no viable/easy way to reduce these costs.

So none of your requirements match up with AWS services. Of course it's not going to be a great match in that case, right?

If you need 'some random compute and a bit of networking' then no, do not use AWS.

Vendor neutrality isn't worth match to a business unless you are the EFF or intend to move vendors all day long.

You don't need AWS or any other cloud for volume (traffic volume, that is), heck I'd say stay away from the clouds for volume since that is where the bulk of your money disappears anyway.

But AWS spend a lot of time selling you lambda over any of these other solutions.

If you have less traffic then you should spend less.

This sounds like they don't have anyone who actually knows what they are doing, or did any form of cost/benefit analysis which will always mean you spend more than you should.

They likely overcomplicating things for no good reason. If you can handle their load on a $250 VPS what the heck the are doing with AWS?

What type of usage volume are we talking about here?

> Sure, you can play FUD games about AWS suddenly raising prices, but I doubt you'd have any historical evidence to back that up. So you'd better be able to say why being cloud-agnostic is critical to your business.

I'm not sure if you're being serious here. It's not about rising prices but making your business completely dependent on another entity and losing any options you might otherwise have.

As for past data, history is rife with stories of companies who made the mistake of trusting a big player their technology will be around forever. So many have invested in technologies like Flash because they were 100% sure they will be there forever.

If I was in charge of AWS, I would avoid sudden price increases, but instead focused on many new features and small charges. These look insignificant, "This is just 20 buck per TB, less than our spending on toilet paper." And then these slowly accumulate and the TCO is getting higher and higher, and again some new* smart features lure you - again, at a small cost. In the end, it turns out you can't leave even if you want.

*Or just your old open source library/framework repainted in AWS colors.

It depends on the situation, but by keeping a simpler architecture there's not necessarily any overhead. AWS has huge complexity which is a tradeoff against the complexity of simpler solutions, regardless of the $billing cost.

That sounds exceptionally vague. Simplicity rarely is bound to some vendor and more likely to be based on requirements and implementation engineering. It mostly gets as complex as it needs to be.

Simple things are simple: need IPv4 networking? Get an IPv4 allocation and route it to a (virtual) port of your choice. That is no different between on-prem, managed-dc, unmanaged-dc, managed server provider and cloud provider. There might be some semantics that are different, where a physical port cannot be unplugged via an API (at best you can down/up a switch port but that's not the same) and routing may or may not be implicit, may need a firewall or routing rule and may need translation. But all of that applies always anyway and gets named differently on who you are paying for it.

If you create something very complex, but it didn't have to be, perhaps it's simply a bad implementation and not a property of the technology that was applied. There are plenty of engineers that think they can roll their own crypto libraries, write their own filesystems and their own RDBMs... but what business case for the 99% out there really requires that? Nearly everything in a business is a generic problem any business has; it's always about products and/or services, and it's always bound to some legal and financial system the business operates in. Everything beyond that is just marketing and trust building.

The only unique thing in most cases is the data you have and the degree of integration of processes within the business. And neither of those are an actual technology problem or complexity driver.

AWS is extremely expensive for what it offers. It doesn't have to raise prices to be a bad idea, it just has a very large mindshare in the space.

I would say otherwise. Some basic things that come to mind - db snapshots that works - S3 - Cloud Trail - know who and when access a server and what commands they enter in their SSH session. - Session Manager - being able to control permissions in a single place. - S3 + Athena + QuickSight - easy reporting at scale - the list goes on and on

As soon as you have decent amount of data which you care about AWS became dirt cheap compared to on-perm when user right. Look at the list above and imagine how much effort you would have to put on an ongoing basis to support this.