AWS
Worth the operational weight, once a system earns it
We run AWS in six client systems: TankAware, Cruise Search, ZhoopZhoop, WorkMateAI, SmartREI and Go4Gr8. We also ship other builds on Vercel and Supabase on purpose. This is what deciding between them has taught us.
The short answer
AWS earns its place when a system needs long-running compute, strict data placement, or infrastructure a client already runs. A small team shipping a first product moves faster on Vercel or Supabase.
AWS gives you control over almost every layer: the network, the instance type, where data physically sits, how long a job is allowed to run. That control has a cost. Someone has to configure it, patch it and be on call when it breaks. A small team does not want that job unless the system genuinely needs it.
AWS fits IoT ingestion, background jobs with no time ceiling, and regulated data with a strict retention rule. Vercel or Supabase fit a product that just needs to exist and change fast. Their deployment pipeline and database arrive already built.
What decides this
4 things that decide this
- 01AWS wins on control: instance sizing, network rules, and data placement are all yours to set, at the cost of someone having to set them.
- 02Vercel and Supabase win on speed to a working product, because the deployment pipeline and the managed database arrive already assembled.
- 03EC2 has no execution-time ceiling, which is the real reason to reach for it over a serverless platform that caps a function at minutes.
- 04S3 and RDS are the two services that show up in almost every client build we run on AWS, more than any compute choice.
A large set of separately billed infrastructure services
AWS is not one product. It is a catalogue of independent services, each with its own console and pricing, that you wire together yourself. EC2 rents you a virtual machine. RDS runs a managed database on it. S3 stores files. There is no bundled path from zero to a running product the way there is on a platform built around one framework.
That is also the point. Nothing about AWS assumes your workload looks like anyone else's. Think of a six-hour batch job, or a device streaming telemetry, or a document store under a legal retention rule. None of those fit a platform built around short web requests.
Where it holds up and where it does not
Strengths
- EC2 has no built-in execution-time limit, so a long-running job or a persistent connection just runs, where a serverless platform would kill it.
- S3 is the closest thing the industry has to a default for document and file storage, and every client build that stores files reaches for it.
- RDS gives you a real, tunable Postgres or MySQL instance, with control over instance size, backups and encryption settings rather than a fixed managed tier.
- Region and network configuration are yours to set precisely, which matters when a client's compliance rule names where data may sit.
Trade-offs
- Nothing runs itself. Patching, scaling rules, and backup schedules are the team's job unless you pay for a managed layer on top, and that cost is real time, not a subscription line.
- The IAM permission model is powerful and easy to get wrong. A role scoped too wide is the single most common AWS misconfiguration we have had to fix on a client system we did not build.
- Provisioning an EC2 instance and an RDS database from scratch takes hours of setup that Vercel or Supabase hand you for free on day one.
- Cost is hard to predict before a system is live, because compute, storage, transfer and managed-service fees are billed and scaled separately.
- IAM role createdScoped wide to save time
- No reviewNothing checks the permission boundary
- Instance left unpatchedNobody owns the schedule
- Backup untestedExists, but never restored once
- Failure at the worst timeDiscovered during an incident, not before
Every AWS failure we have inherited on a client system followed this pattern: control that nobody kept maintaining. The platform did what it was configured to do.
What we use it for, and what each system taught us
TankAware runs IoT sensor ingestion, alert models and an inspection engine for petroleum sites on AWS. Data sits encrypted in RDS and moves over TLS. Sensor data arrives continuously and unevenly, a bad fit for a platform billed per invocation. A rented instance that stays warm handles it without surprise costs.
Cruise Search runs its AI matching module on EC2. The search and follow-up logic needed a server that stays up, not a function that spins down between requests. WorkMateAI stores provider contracts and signed agreements in S3, where a retention rule applies per bucket instead of being argued about in application code. ZhoopZhoop keeps call transcripts and recordings on AWS, with media in S3, so that data survives independently of any one service restarting.
- 01Reach for EC2 when a job runs longer than a serverless platform's execution ceiling, not by default.
- 02Put files with a retention or compliance rule in S3 from day one. Retrofitting that rule later means an audit of every place a file was ever written.
- 03Scope every IAM role to the one action it needs. A role written for convenience during setup is the one that gets exploited later.
Systems running on this stack
What teams ask before committing
01Do startups need AWS?
Most do not, at the start. A new product usually moves faster on Vercel or Supabase, where deployment and the database arrive already assembled. AWS earns its place once a workload needs long-running compute, strict data placement, or infrastructure a client already runs. Adopting it before that point adds operational work with no system yet asking for it.
02AWS or Vercel for a new product?
Vercel, if the product is a standard web application and the team is small. It hands you the deployment pipeline and previews per pull request, which is time you would otherwise spend configuring EC2 and a load balancer. Move to AWS, or add it alongside, once a specific workload, like a long batch job, outgrows what a serverless platform allows.
03Is AWS overkill for a small team?
It can be, if nobody on the team owns patching, scaling and backup review. A managed platform absorbs those tasks and AWS does not. It stops being overkill once a system needs something Vercel or Supabase cannot offer, like an uncapped job duration or data pinned to one region.
04What is the most common AWS mistake you see?
An IAM role scoped wider than the job needs, usually created under time pressure and never revisited. It is the most common misconfiguration you find when you take over a system built by someone else. The fix is boring: scope every role to the one action it performs, and review the list periodically.
05Can we run part of a system on AWS and part elsewhere?
Yes, and several of our own builds do exactly that. A product can serve its web application from Vercel while a background job or a device pipeline runs on AWS. The two are not exclusive, and splitting a system by workload shape is usually a better call than forcing every part onto one platform.
Related
- AWS Bedrock vs Azure OpenAI →The same cloud, compared on AI hosting rather than infrastructure.
- Vercel, reviewed from production →Shipping speed beats control of the runtime.
- Supabase, reviewed from production →A managed Postgres alternative to assembling AWS yourself.
- Software built for one business →The service that makes this call for a client.
