AWS
The biggest cloud. Every service you can imagine, complexity and cost to match. EC2, S3, Lambda, RDS.
VISIT AWSKey takeaway: Correct at the top of the scale curve and expensive everywhere else, and the expense is mostly staff time rather than invoice. Pick AWS when you need specific primitives like Aurora, DynamoDB global tables, or Step Functions, or an AWS-native compliance posture. Below that threshold, a PaaS that resells AWS complexity as something usable is the better default.
Quick facts
- CategoryHyperscaler
- PricingPaid
- LicenseProprietary
- Created2006
- GitHub starsclosed
- Edge-readyYes
- Free tierYes
- Egress billingExpensive
Bundled services: EC2 S3 Lambda RDS DynamoDB CloudFront EKS
What it is
AWS is the largest cloud provider with the broadest service catalogue, EC2, S3, Lambda, RDS, DynamoDB, EKS, and 200+ other services. Pay-as-you-go, complex pricing, real operational overhead. The default for enterprise workloads at serious scale where the cost of operating a hyperscaler is justified.
Best for
- Enterprise workloads with dedicated platform-engineering capacity
- Apps requiring specific AWS services (Aurora, DynamoDB Global, Step Functions)
- Regulated industries with AWS-native compliance posture
When not to pick it
Skip AWS for small to mid teams, the operational complexity and bill-management cost are real. PaaS layers (Render, Vercel) are usually the right answer.
My take
AWS is the right answer at the top of the scale curve. For most teams, the PaaS layers above it are the better default, they take AWS's complexity and resell it as something usable.
The catalogue is both the moat and the tax
AWS wins the argument when your requirement names a specific service. Aurora, DynamoDB global tables, Step Functions, Kinesis, EKS, and the compliance certifications behind them exist at a depth nobody else matches, and if a regulator or an existing architecture already assumes them, the discussion is over before it starts. What comes with that is a surface area no small team can hold in its head. Every service has its own IAM semantics, its own networking assumptions, and its own failure modes, and wiring three of them together is a project rather than an afternoon. Teams that succeed on AWS have someone whose actual job is AWS: infrastructure as code, tagging discipline, account structure, and a security posture that gets reviewed rather than assumed. Teams that struggle are usually the ones that expected it to behave like a PaaS.
Cost control is a role, not a checkbox
The AWS bill is a system in its own right. Compute is often the small part next to egress, cross-availability-zone traffic, NAT gateway charges, and the storage of things nobody remembers creating. Reserved capacity, savings plans, and spot instances all cut it substantially, but each is a decision requiring forecasting that small teams do not have the data or the time to do. This is the honest reason PaaS layers exist: Render, Vercel, and Fly all run on hyperscaler infrastructure and resell it with the complexity removed, and for most workloads that markup costs less than the staff time to avoid it. Cross the threshold where infrastructure spend rivals a platform engineer's salary and the maths inverts. Below it, going direct usually costs more once you count the people.
Frequently asked questions
Is AWS cheaper than Vercel?
On raw compute and bandwidth, yes, often by a wide margin. Once you add the engineering time to build and operate what Vercel gives you for free, usually not, until you reach real scale. The crossover point sits roughly where your hosting spend rivals the cost of the person who would manage the infrastructure.
AWS or GCP?
AWS for breadth, ecosystem, and any requirement naming a specific AWS service. GCP for data and machine learning work where BigQuery has no direct equivalent, and for Kubernetes where GKE is the cleanest managed offering. If procurement or existing architecture points one way, follow it. Multi-cloud by preference is a cost, not a hedge.
Do I need AWS for a small app?
Almost certainly not. A small application with a database, some background jobs, and normal traffic runs happily on Render, Railway, or a Hetzner box with Coolify on top, at lower cost and with far less to learn. Move to AWS when a specific service or compliance requirement makes it necessary, not in anticipation of scale.
Links
Similar tools you should also consider
If AWS is your pick, the next conversation is short
The 30-min call is where your hosting choice becomes a real architecture, a migration plan if you are switching, and a price range you can take to your stakeholders without surprise bills in month 4. Describe your stack, your traffic shape, your budget. I tell you whether AWS is genuinely your fit.