Amazon AWS is Bad for Your Website: Here’s Why

Amazon AWS is too Complicated

Imagine this scenario:

You’ve set up your site with AWS. Properly configured all the moving parts, created the connections between them, optimized your buckets, protocols, SSL certificates and CDN. It’s been running fine for months. Then one morning you wake up blurry-eyed, only to find your site is down, and suddenly WHAM! No visitors, no revenue. It’s out, and you’re not sure why.

In a panic, you try and debug the problem, only to realize you’ve completely forgotten everything you knew. You haven’t the foggiest about how everything works together. All your knowledge has slipped away in the course of a few months. Your site is unavailable, and you don’t even know where to start.

Terrible right? That’s a realistic scenario if you choose Amazon AWS to host your website.

Amazon AWS: Power vs Complexity

I was recently chatting with a friend, and cloud architect about the “best” cloud solution for my site. His first question was “What are your resources? How much time/effort can you spare?”. Similarly, I asked a question on Reddit about CDNs and dynamic caching, and one of the responders asked me the same thing, namely:

“How much work are you willing to put in”

My answer was simple. None. I want to press a button and make it work. That’s it. Because I have a business to run. Unfortunately, cloud solutions don’t work like that.

If you’re like me, you’ve probably thought about migrating your site to Amazon AWS or another cloud infrastructure provider like Cloud Compute or Azure. And I can see the attraction. Here are some of the perceived advantages:

  1. It might actually be cheaper than ordinary hosting
  2. Flexibility in server locations
  3. Scales easily based on traffic
  4. Can add CDNs, Load Balancers, SSL, and other features
  5. Easy to take snapshots or backups

But for the most part, none of these are worth the fragility and opportunity costs on your business. This is particularly true if you’re a single business owner and don’t have teams of tech personnel to take care of your site.

Businesses Need Simplicity

Businesses want stability. Simplicity. This is because they focus on a steady revenue stream above all else. And that means no disruptions. If something is already working, they’re loathe to change it. And for good reason. All too often, a system migration messes things up, leading to downtime, headache, and no clear idea of what actually improved.

Basically, choose something that requires you to do as little as possible

If you’re a business owner, you know what I’m talking about. You would rather use a solution that’s less than “ideal”, but reliable. You do NOT want a “perfect” set up, but one that’s less susceptible to disruptions. But developers have other ideas.

Developers Like Complexity

Developers on the other hand, have different ideas. Tech people enjoy complexity. They get excited by new solutions and new architectures. The latest thing. IT consultants storm into your office and excitedly tell you to implement “best practices”. New API, and new workflows. They tell you that your existing methods are shit.

What developers don’t understand is that their revenue stream is not on the line. Most of the time, they don’t personally face the consequences of disruption. They still get paid. In other words, they have less skin in the game.

Amazon AWS Introduces Complexity and Fragility

For all its benefits, Amazon AWS makes website hosting more complicated than it should be for a regular business owner. This isn’t a riff on Amazon. They probably make it as easy as they know how. But as much as cloud architectures have simplified over the years, it falls far short “press a button”.

All the moving parts associated with Amazon AWS make my website fragile. It increases the number of things that can go wrong. And the entire management of the infrastructure rests on my shoulders. Which means that if something goes wrong, I need to debug and fix it.

As a business owner, I loathe complexity in my technology. That’s because each additional step exposes a new vector for problems. The more I need to carefully configure and tune my set up, the more likely it is that it’ll blow up.

Technical Know-How Dissipates Over Time

How often have you returned to some code that you wrote a while back, and had no clue about what’s going on? It’s your code! Your comments! But you’ve forgotten everything about the application, which function calls do what, and how you’ve solutioned the problem.

This is a common problem with technology if you’re not continuously applying your knowledge. Memory fades, and eventually you forget how stuff works – even when you yourself have designed it! Now imagine how much worse it’s going to be if it’s someone else’s architecture.

When you decide to give up your simple web hosting for an Amazon AWS solution, you’re trading power for increased complexity. And with that increased complexity, comes the need to constantly monitor it and stay in touch. Otherwise your knowledge will fade, and when something goes wrong, you’ll find yourself powerless to fix it.

You HAVE to Plan for Failure

While implementing any technology, you have to plan for when it fails. Because it will fail. And usually at the worst possible moment. This is why large enterprises have fail-over systems that automatically pick up the slack. Because no matter how great your solution is, sooner or later, it will sputter and go out.

This is why customer service in hosting comes at a premium. You might not realize the value of paying for great support while things are humming along smoothly. But when you really need it, you’ll thank the gods for your investment. Because compared to the revenue of your business, the cost of being prepared is usually insignificant.

When it comes to Amazon AWS or any other cloud solution, the plan is basically “fix it yourself”. There’s no-one to call, no-one to hold accountable. And since every AWS architecture is different, you won’t have anyone who can apply a standardized fix. Whoever deals with the problem will need to be intimately familiar with your site and all its moving parts.

Spend Time Making Money – Not on Technology

I understand the attraction of making a site work on a new technology. The feeling of satisfaction seeing your website load on an experimental configuration. Watching it respond properly to external pressures. It’s a tremendous sense of success.

But that feeling is not the goal of your business. Your goal is to make money. And while you may think that your solution will lead to better performance and better sales, it might not. Ask yourself whether you’re doing this merely because you can, or whether you’re serving an actual business need.

Because as a business owner, you have a limited amount of time. And you need to decide the most profitable way to spend that time. Do you reach out to clients, improve your marketing, work on your site design to increase your conversions? Or do you spend dozens of hours trying to find the “best” configuration to squeeze out a few additional milliseconds of performance on our site?

You have to find the fine technology line, after which you’re just doing it for the fun, and the false feeling of accomplishment. Not to improve your business itself.

Alternatives to Amazon AWS

So if cloud architectures like AWS and Compute aren’t a great idea, what do you use? The answer is managed hosting. Not a VPS, or a dedicated server, but good, solid managed hosting. My “go-to” solution is the SiteGround GoGeek plan. It has all the power of a VPS, but in a managed environment. And if your site goes down, you have awesome customer support to help you out.

If you need more power than GoGeek, I would go with something like Liquid Web’s Cloud Sites.  Basically, choose something that requires you to do as little as possible. Something with customer support that you can call to fix when stuff goes down. Because sooner or later, your site will fail and when that happens, you don’t want to be scrambling to fix it with shaking hands.

This entire article might seem like I’m taking a step back. After all, isn’t AWS the future? The answer is that it might be. But for regular people to use, it needs to be a lot simpler. It has to be a “set it and forget it” kind of solution. Otherwise you’re asking business owners to divert precious time and resources into maintaining a fragile cloud architecture that can break down for any number of reasons.

And business owners have better things to do with their time. Like making money.

About Bhagwad Park

I've been writing about web hosting and WordPress tutorials since 2008. I also create tutorials on Linux server administration, and have a ton of experience with web hosting products. Contact me via e-mail!


  1. Are you aware that AWS Lightsail makes a prepackaged WordPress site for ~$3 a month?


  2. Honest Opinion says

    this is an irresponsible post that oversimplifies the complex questions a business owner needs to ask about this topic and for what??? so you can earn a few bucks on affiliate marketing you really suck!!


  3. I searched “AWS terrible” because I’m feeling like there is no way that it’s actually as good as it is made out to be from my experience so far. It is Beyond terrible so far.

    I used to use Liquid Web and it was great. I used Siteground GoGeek plan for the past year and it was Great. I would never, ever, use godaddy, bluehost, or similar. They are terrible. Rackspace is good but costly, IBM is also, and Digital Ocean has good support/help. AWS I haven’t yet tried.

    I have been learning/trying AWS Lightsail the past week, and every single thing in this post is accurate from my personal experiences.

    First of all, support is so terrible it shouldn’t even exist. I’ve been waiting on a call for 20 minutes just now, then tried a new ticket/call and have been waiting on that also for 25 minutes so far and counting… My conversation last night took an hour and got nowhere.

    This is only 1 single example of 1 single thing to learn/do…
    How to change the Lightsail instance IP address to the domain name:
    1. Login into SSH
    2. cd apps/wordpress/htdocs/
    3. dir
    4. vim wp-config.php
    5. use down arrow to find define(‘WP_SITEURL’, ‘http://’ . $_SERVER[‘HTTP_HOST’] . ‘/’);
    define(‘WP_HOME’, ‘http://’ . $_SERVER[‘HTTP_HOST’] . ‘/’);
    6. press i
    7. change to define( ‘WP_HOME’, ‘’ );
    define( ‘WP_SITEURL’, ‘’ );
    8. press ESC
    9. type :wq
    10. hit Enter
    11. Close terminal window
    12. Reboot your instance

    12 steps for one small thing. And that’s common. So, it is a lot of diving in headfirst into a steep learning curve involving a ton of time and effort for I’m not sure what exactly with no support and terrible docs/video. I am starting to think it’s really not worth it.


Speak Your Mind