But how do you use it?
When building on AWS you come to realise that you can't assume anything when you hear that someone is "building on AWS".
I have read or heard some variation on "we run on AWS" countless times, and more often than not I am left with no real insight into what that actually means. Within a company or in a given context it may become obvious, but in the wider, context-free world it is far from obvious.
Once upon a time - maybe from 2006 to 2009 - there was really only one thing meant by "building on AWS" and that is running software on EC2 instances.
But that small handful of services available in 2006 is now... well, lots.
By some measures it passed 168 services in 2020 (and there is little excuse not to take the time to hear about 168 AWS Services in 2 minutes in wonderful song!). And today, late 2025, there are around 240 services.
And that's before we consider that we can count in different ways and we can consider major features within services, and so on, so some people may argue that there are even more!
So what?
Consider that "we build on AWS" conveys about as much information as "we program in JavaScript". It's nice to know, but there is danger in reading too much into it, danger in presuming, danger in projecting your experience onto the statement.
For example, programming in Javascript may mean:
- Frontend code running in the browser
- Backend code running in Node.js or Deno
- Building Chrome extensions
- Using a framework
- Using vanilla JS
- Using Typescript
- CoffeeScript?
- Using ES5, ES6, transpiling
- etc.
And building on AWS could mean, quite genuinely:
- Storing some images in S3
- Using virtual machines with EC2
- Serverless compute with Lambda
- Managed Kubernetes with various flavours of EKS
- Many different ways to use AI
- Day-to-day work using Amazon WorkSpaces desktop as a service
- Rendering 3D graphics using a Deadline Cloud
- Controling satellites orbiting the Earth with AWS Ground Station
- Using Amazon Lumberyard to combat a verifiable real-life zombie apocalypse
Which is to say, if it includes outer space and zombies then "building on AWS" can mean pretty much anything.
What should we do instead?
With so many different services, take the time to explain exactly which are the key ones you are using, and any features of those services that are key for you.
With over a dozen AWS certifications available that scratch the surface of some of these AWS services, it is fair to assume that even people familiar with AWS may not know the services you are using. So take the time to tell your audience what that service does. Find a link to the AWS docs and add it to your content.
Are you advertising a job "building on AWS"? Well, is it building modern cloud-native, serverless, applications, or are you at the forefront of AI, or are you talking to satellites, or are you moving a few servers from a datacentre to the cloud? Are you building something that just happens to run on AWS or are you really leaning into the high-level services that are available.
It's a shame we don't have some catchy acronyms to summarise this information: I'd love something as neat as the widely understood LAMP or MEAN stacks, but it's not something I've seen. Maybe that's something to think about.