I did a quick browse of developer jobs on LinkedIn the other day, and out of the roles and companies that mentioned cloud providers, the overwhelming majority of them were referring to AWS specifically. Sure, GCP and Azure have both made pretty decent gains in the market these last few years, but AWS still very much holds a tight grip on the industry that it itself more or less pioneered. Now don't get me wrong, I think AWS is an excellent cloud provider and for those of you out there who know what you're really doing with it, it's a great choice. But my gripe isn't with that.

It's not uncommon to hear justifications of picking AWS go among the lines of "we're all familiar with it, so let's just use it", "it's easier to hire people with AWS experience", or a plethora of any other "just cause" logic. In my opinion, far too many companies and engineering teams out there are using AWS "just cause", and:

• aren't able to use AWS to it's full potential.
• don't need the full potential of AWS.
• are slowed down by the heavyness and complexity of AWS
• are paying far too much for cloud hosting

Full disclaimer: I use AWS, my company uses AWS, and I very much do think it's the right choice for many teams, but I also recognize that we almost fell into these traps ourselves very early on, which is what inspired me to write this.

Anyways, here's why I think you may not need AWS:

Your infrastructural needs are simple

If your infrastructure looks like any combination of the following:

• A handful of VMs/EC2 instances administered manually
• A managed database like RDS
• A statically generated frontend hosted on CloudFront/S3
• Applications/services running inside containers either using ECS or Kubernetes
• A small number of serverless functions (lambdas)
• Some file storage service

Then there's pretty much nothing that you couldn't do on any other cloud provider (particularly a more lightweight one like DigitalOcean). I once overheard someone trying to setup an entire AWS organization from scratch just to deploy a static website. That person would've been far better off going with something like Netlify, Vercel, Firebase or any plethora of static site hosting options out there (all of whom are much much cheaper than setting up a full AWS stack).

You can switch into AWS at any time, but not away from it

There are a number of fantastic AWS services like SQS, SNS, DynamoDB, etc that many successful companies' tech blogs often mention and swear by. Yet, the cautionist in me sees a few issues with latching on to using these services prematurely:

• If your core platform is tightly coupled with these services, you can't realistically ever move off them without a ridiculous amount of effort. AWS knows this, and whilst I'm not saying this would happen - most small-to medium sized companies would be completely helpless should Amazon decid to triple the prices of these services overnight.
• They don't really do anything an open source alternative (like RabbitMQ, Mongo, Redis, etc etc) couldn't do. AWS also probably supports running a managed version of these open source alternatives as well (Amazon MQ, Elastic), so you might as well use them.
• You never know when/if these services would be sunset or deprecated in the future. The decision lies solely on Amazon, which at the end of the day is a business driven by profits.
• To interact with these services, you'd need to use Amazon's privately maintained SDKs and APIs, which are often poorly documented and subpar.
• Often, you can't run these services locally for local development, or the local emulators are not particularly reliable.

My personal approach is to always try to avoid vendor lock in as much as possible, especially early on on the lifetime of an engineering team. Combined with the fact that there exists plenty of "lite" clouds like DigitalOcean, Linode, etc that offers to the standard cloud features like VMs, containers, databases and such, I think it's never a bad choice to start with them first then move to AWS (or GCP/Azure if you fancy) later when your tech and team matures.

AWS is really hard to use

AWS is fundamentally a hugely complicated beast of a product. There's like a bajillion services, and an intricate web of details regarding how they work (or don't work) with each other. Such complexity is always going to suffer from the fact that no UI in the world could capture all the use cases intuitively, and the AWS console itself is not going to be winning awards for UI design anytime soon.

There's also often multiple ways to accomplish something. Want to expose your Lambdas as RESTful HTTP APIs? You'll need to use one of two flavours of APIGateway: HTTP APIGateway, or REST APIGateway. But first, you'll need to do some reading on which one to use. And though in many cases it's not particularly challenging nor too effortful to find and read the documentation to figure this out, the time taken does add up, and wrong decisions can be catastrophic.

Furthermore, its becoming considered best practice to use infrastructure-as-code tools like CloudFormation or Terraform in order to create reproducible and versiond environments. These tools themselves, whilst not being particularly too difficult on the surface, can easily become a full-time job to maintain and develop.

If you're team with more than 2-3 people, then it's also likely that there's varying skill levels when it comes to AWS. Maybe someone knows how to perfectly navigate and utilize the console or terraform, but others may struggle or spend more time trying to figure out how to do something (hint: if there's multiple people in your team who have IAM permissions to do anything and everything, then you are probably doing it wrong!). In my opinion, the only way to really maximize productivity with AWS is to have a dedicated infrastructure/DevOps engineer. Even if you're a dev that's knowledgable and skilled with AWS, it's useful to have someone on the team be fully dedicated and own the the responsibility of managing infrastructure.

AWS at its core has become a product intentionally designed for usage by full-time AWS experts. And there's nothing wrong with that (well, personally I think it's a bit sneaky of them to intentionally be trying so hard to push the perceived value of AWS certs and courses in order to also promote AWS itself, but I disgress...), you just need to be aware of the fact in order to really get out the most value.

It's real easy to overpay

AWS pricing is hard to manage. Sure, there are tools like setting pricing usage caps and such, but the default options in most AWS infrastructure setup often somehow have hidden pricing caveats in them in the first place. It's astonishingly easy (read: I've done this many times) to set up something with options that look sensible, then come back a few days later and see that it's burned through hundreds of dollars/pounds. This is significantly less likely to happen if you are 1.) using lighter cloud services or 2.) have a dedicated AWS engineer on your team to oversee these things.

Some of the services are actually garbage

Whilst being an A in FAANG, it's important to remember that Amazon itself is still a huge organization that carries a large amount of bureacracy and mishaps. With that comes the fact that many of its services (and in particular, the internal teams that build those services) are badly mismanaged, poorly organized, or don't communicate well with other teams. Many of its products seem like they start out as a "hey, wouldn't it be cool if we offered this" thought from some middle manager that never gains traction and becomes all-but-abandoned. If you're a dev reading this, then you've probably got one or more friends working at AWS who can (even if they work on a good product that they like) attest to this.

I once picked an AWS product over building a custom solution, as its promises seemed amazing and the pricing (both at small and large scale) was incredible. Turns out, it was a horrendous product, and we spent weeks more time than we should have trying to figure out its quirks and hunt for its documentation (it was Cognito, by the way).

If you want some AWS-related (insightful entertainment), there's no better place than the AWS subreddit. As with most things, it's always the most loyal fans that are the most critical.

You've made it to the end of this post

If you've made it to here, thanks for sticking with my rant. Just to end on a positive note and reiterate my disclaimer: I'm not saying that you should never use AWS, I'm saying that you should understand the cons of it and see the alternatives first before diving it in, particularly if you are a young and/or small team.