• Skip to primary navigation
  • Skip to main content
Last Week in AWS Logo
Master your cloud costs
  • About
    • Community
    • Contact
  • Blog
  • Newsletter
  • Podcasts
    • Last Week in AWS Podcast
    • Screaming in the Cloud
    • Nominate a Guest
  • Merch
  • Resources
    • AWS Network Map
The AWS Train comes for us all
05.27.2020

How to Compete with AWS

By Corey Quinn
As a Cloud Economist, I spend most of my time helping companies fix their horrifying AWS bills. But it’s something of an open secret that I periodically moonlight as an industry analyst.…
FacebookXLinkedInReddit
Home Blog How to Compete with AWS
Prev
Next

As a Cloud Economist, I spend most of my time helping companies fix their horrifying AWS bills. But it’s something of an open secret that I periodically moonlight as an industry analyst.

An analysis client recently asked me about the threat of AWS moving into their market as a strategic concern, and couldn’t understand at first why I scoffed at the idea. It turns out that my perspective isn’t particularly widely shared, so it’s probably time I wrote something down about it.

Put simply, competing with AWS isn’t hard

Let me clarify first that I’m not talking about Amazon; I’m talking about AWS. How do you compete with Amazon? No clue. You can’t outrun them, outfight them, or outthink them. That’s your problem.

AWS doesn’t eat markets, whereas Amazon retail does, then goes back for more. AWS operates on much straighter rails than Amazon.com does because its leadership fundamentally thinks differently. Every Amazonian is going to be indignantly reaching for their keyboard to tell me I’m wrong right about now. But hear me out: This is what I see from the outside.

All of the “we picked Azure/GCP because we didn’t want to fund our competitor” stories that carry any weight whatsoever are never told by technology companies; they’re told primarily by retailers who invariably have a suspiciously high number of current employees boasting AWS skills on LinkedIn. Amazon as a whole will, left unchecked, eventually grow to compete in all markets. (As a side effect, this leads to some onerous demands in their non-compete agreements.)

AWS is radically different; the list of what they’ll do under the Web Services umbrella is relatively short, and is largely trouble only for companies who are trying to do a few particularly ill-advised things.

Dodge the train

Now, the internet is full of hand-wringing about competing with AWS. Some of the biggest offenders here are companies that whine and cry because they stopped innovating. AWS doesn’t ever stop; you’ve gotta keep ahead of its bow wave of innovation if you want to last.

Or you do something unexpected.

Amazon is very hard to predict; AWS is surprisingly predictable. Companies get sherlocked by AWS largely because they’re trying to build a better AWS, which is fundamentally a losing proposition unless you’re basically Microsoft Azure and nobody else.

“Ah!” you cry, “AWS doesn’t offer a managed Nagios service; I’m going to build one and sell it!”

You would be missing two big things here.

First, it doesn’t matter if you’re the folks who wrote Nagios; you’re not going to do a better job of running it than AWS does. Their operational excellence is the secret sauce that makes AWS work.

Second, you’ve mistaken open source for a business model. It most assuredly is not; it’s a tactic. There’s a lot of value to having a community, but understand that relicensing your code after the fact makes people hate you.

This leads folks to get on one of those same rails that AWS is clearly on, and they’re a year or more ahead of AWS! Things are great! They’re winning customers everywhere, and VCs are showering them with praise and money. Then AWS catches up, and suddenly they’re writing sulky blog posts. In this particular case, the vendor has nothing to fear; AWS has a lot of work to do before DocumentDB will be nearly as effective at losing data.

Don’t try to outrun the train; dodge it. It’s on rails. It can’t follow you.

The key is, therefore, to build companies that specialize in things that AWS either can’t do or completely sucks at.

What sort of things does AWS suck at? Aside from giving products sensible names, lots of things, which we’ll examine next.

1. Anything that’s high touch

AWS flounders with anything that’s super high touch. You need look no further than the current wave of companies trying to renegotiate their commitments with AWS. That group is SLAMMED right now because despite all of AWS’s efforts, you can’t scale people the way you can computers.

A services business is also incredibly nimble with respect to AWS. I chose billing when I started mine, but there’s a lot of opportunity out there.

I’d argue that AWS could put me out of business tomorrow with the right feature release—but they won’t. They can’t; their constraints won’t allow it.

Take security as another example. They could make IAM understandable to basically everyone, but they haven’t. There’s no indication that they’re going to, either.

If anything, they’re instead rolling out things like tag- and attribute-based controls, which make this area even MORE complex. Making that approachable to humans in a well-executed way is a very successful business waiting to happen.

2. Things they’ve screwed up already

AWS also doesn’t usually take a second bite at the same apple. This gives you room to go after things they’ve already done, but poorly.

CloudFormation is a great example of this. It’s not a great user experience, but because of its gravity they can’t fix it. The closest they got was introducing YAML support.

Of course, they have the technical ability to fix it. But AWS treats APIs as a promise. They can’t just pull a Google and deprecate seven years of CloudFormation.

That API-as-promise is part of what makes AWS awesome. But it also provides an axis along which you can compete. They might go ahead and try to put a layer on top of it that makes it more approachable—such as with the CDK—but the CDK’s primary function right now appears to be “breaking during demos.”

3. Talking to anyone who isn’t an infrastructure engineer

If you’re trying to build a product whose primary market is those lucky souls who’ve never heard of Linux, AWS will either not compete with you or else compete so ineffectively that it becomes laughable.

Even within engineering, AWS sucks at communicating with customers outside of roughly four personas: backend engineering, data engineers, executives, and infrastructure engineers. If your target market isn’t one of those four personas, AWS isn’t so much a competitor as it is a convenient excuse not to try.

If you’re an accountant, a front-end developer, a lawyer, a corporate IT manager, or basically anything that isn’t one of the four personas that AWS knows how to talk to, you have something special going on. Not only do you basically not understand what AWS is talking about when they release something aimed at your market, but their message is so off-putting that you walk away absolutely convinced that whatever the hell it is that they’ve built clearly isn’t for you.

If you’re building a desktop management application, you’ll do well regardless of what AWS does.

If you’re trying to build a better database, I’m predicting some pain in your future.

One of the things that has me so concerned about their rumored AWS for Everyone service is that it’s incredibly likely that they’re going to mess this up completely and set the entire no-code movement back a decade in the process just by their own way of speaking to their audience.

4. Serving a specific industry

AWS is terrible at industry-specific offerings. Azure’s announcement of Azure for Healthcare is an example of this; it’s a good idea. (Note: If AWS had tried this it would be a terrible idea. They struggle mightily when targeting industry verticals in a way that Microsoft has absolutely mastered.)

They tried recently with Oil and Gas at re:Invent, and I’m told it went so badly that freaking oil companies were falling all over themselves to say “I’m not with them.”

Whatever you do, don’t build a way to interact with AWS services

If you fall into the trap of building a PaaS, you’re effectively trying to build a better AWS. They will use their operational efficiency to kick you into the dirt.

This is what happened to RightScale, which started off as a sensible way for humans to interact with the EC2 service. Then the native EC2 console improved, and now there are more people who haven’t heard of RightScale than those who have.

Bottom line? Do what AWS is bad at

If you’re trying to build a better AWS, you’ll fail. If you’re attempting to run some software under the thesis “we built it so we’re better at running it,” watch out.

If you’re offering something that aligns with competencies AWS is bad at, you’re probably onto something.

And if you’re looking to make fun of AWS every week, you can always start a newsletter.

But be forewarned: They’re getting increasingly good at this by launching products that are most likely jokes to begin with.

Corey Quinn Headshot
by Corey Quinn

Corey is the Chief Cloud Economist at Duckbill, where he specializes in helping companies improve their AWS bills by making them smaller and less horrifying. He also hosts the "Screaming in the Cloud" and "AWS Morning Brief" podcasts; and curates "Last Week in AWS," a weekly newsletter summarizing the latest in AWS news, blogs, and tools, sprinkled with snark and thoughtful analysis in roughly equal measure.

More Posts from Corey

Back to the Blog

Infinidash: AWS’s New Observability Play Has Great Bones and a Terrible Bedside Manner

By Corey Quinn

Infinidash: AWS’s New Observability Play Has Great Bones and a Terrible Bedside Manner AWS has just released something fascinating in the form of CloudWatch Omni. I want to be upfront before I dive further: “CloudWatch Omni” is a wretched name that I will not be using, so for the rest of this article and the […]

Read Moreabout Infinidash: AWS’s New Observability Play Has Great Bones and a Terrible Bedside Manner

Reading Observability Tools? That’s a Robot’s Job

By Corey Quinn

Last Thursday Honeycomb was kind enough to hand me the closing keynote slot at O11yCon, a conference whose entire premise is that observability matters and the people in the room are the ones who would know. I used that slot to argue that the primary reader of your telemetry is no longer a human, and […]

Read Moreabout Reading Observability Tools? That’s a Robot’s Job

S3 Is Not a Filesystem (But Now There’s One In Front of It)

By Corey Quinn

I’ve been saying “S3 is not a filesystem” for over a decade. I’ve said it on stages, in newsletters, on podcasts, and directly to the faces of large company employees who were too polite to tell me to shut up before they went back to their FUSE monstrosities. It was one of those reliable truths […]

Read Moreabout S3 Is Not a Filesystem (But Now There’s One In Front of It)
Billie Holding Mail Email Subscribe Icon

Get the newsletter!

Stay up to date on the latest AWS news, opinions, and tools, all lovingly sprinkled with a bit of snark.

You’re faced with tough questions about cloud costs. You should have confident answers.
Get in touch.
  • Newsletter
  • Podcasts
  • Blog
  • Merch
  • About
  • Contact
  • Disclosures
Billie Footer
footprint-orange
© 2026 L9 Labs, Inc. All Rights Reserved.
Terms of Service Privacy Policy Cookie Policy