AWS Pricing Calculator: How to Estimate Costs for Your Project (With Real Examples)
"How much will AWS cost us?" is the first question every small business asks before moving to the cloud — and the hardest to answer honestly. AWS has over 200 services, each with its own pricing model, and the official pricing pages read like tax law.
The good news: you don't need to understand all of it. The AWS Pricing Calculator exists specifically for this, and with the right inputs, you can get a reliable monthly estimate in 20 minutes.
At Otocolobus, we've built AWS infrastructure for dozens of SMBs. In this article, we'll walk you through the calculator step by step using three real-world scenarios from our projects — with actual costs, not hypothetical ones.
The AWS Pricing Calculator: Where to Start
Head to calculator.aws. The interface is straightforward: you add services one by one, configure them to match your expected usage, and the calculator gives you a monthly estimate.
A few things to know before you start:
Pick your region first. For European businesses, eu-central-1 (Frankfurt) is the standard choice. Pricing varies by region — Frankfurt is slightly more expensive than US regions but keeps your data in the EU, which matters for GDPR compliance.
Estimate conservatively, then add 15-20%. The calculator gives you the cost of the services you configure. It doesn't account for data transfer between services, CloudWatch logging, or the dozen small charges that add up. We always pad our estimates by 15-20% to cover these.
Focus on the big items first. In most SMB projects, 80% of the bill comes from three or four services. Nail those estimates and the rest is rounding error.
Scenario 1: Company Website (Static or Mostly Static)
The simplest and cheapest setup on AWS — and the one most small businesses actually need. A company website, a landing page, a marketing site. No server running 24/7, no database. Just files served fast.
What you need:
- S3 — to host your HTML, CSS, JS, and images
- CloudFront — CDN for fast global delivery and HTTPS
- Route 53 — DNS
Step-by-step in the calculator:
1. S3. Add S3:
- 1 GB standard storage (most company sites are well under this)
- 100,000 GET requests/month, 10,000 PUT requests/month (deployment)
- S3 costs are negligible at this scale — a few cents
2. CloudFront. Add CloudFront:
- 50 GB data transfer out per month
- 500,000 HTTPS requests per month
- This covers a site with a few thousand daily visitors comfortably
3. Route 53. Add Route 53:
- 1 hosted zone (~$0.50/month)
- 500,000 DNS queries/month (~$0.20)
What the calculator shows: ~€5–8/month
What we actually see on client invoices: €8–15/month. There's not much room for surprises here — that's the beauty of static hosting. The small gap comes from CloudWatch alarms if you set them up, slightly higher request counts, and the occasional spike in traffic from a social media post or a newsletter.
This is orders of magnitude cheaper than running the same site on a VPS or a container. If your company site doesn't need a database or server-side logic, don't pay for one.
Scenario 2: B2B SaaS API (Sporadic Usage, Scale to Zero)
This architecture makes sense when your users are businesses, not consumers. Usage follows office hours — mornings in one timezone, afternoons in another, quiet overnight, dead on weekends. You don't want to pay for a server sitting idle 70% of the time.
What you need:
- Lambda — to run your API logic
- API Gateway — to expose your API to clients
- DynamoDB — database (on-demand mode, pays per request)
- S3 — file storage
- CloudFront — if serving any static content
Step-by-step in the calculator:
1. Lambda. Add Lambda and configure:
- 500,000 requests per month (a reasonable starting point for a B2B product with ~50 active tenants)
- Average duration: 200ms per invocation
- Memory: 256 MB
- Lambda's free tier covers 1 million requests/month, so you may pay nothing here initially
2. API Gateway. Add API Gateway (HTTP API — cheaper than REST API):
- 500,000 API calls per month
- Average message size: 3 KB
3. DynamoDB. Add DynamoDB in on-demand mode:
- 500,000 write request units/month
- 2,000,000 read request units/month (reads are typically much higher than writes)
- 5 GB storage
4. S3. Add S3 for file storage:
- 10 GB standard storage
- 50,000 GET requests/month
What the calculator shows: ~€8–20/month
What we actually see: €15–40/month. Serverless architectures tend to have less gap between estimate and reality because you're not paying for idle resources. The biggest surprise cost here is usually API Gateway — at high volume, it can exceed the Lambda cost itself.
Why not ECS here? For B2B SaaS with sporadic usage, paying for a container running 24/7 makes no sense. Lambda scales to zero: no tenants active, no cost. With ECS Fargate, you'd pay at least ~€20/month for a single task doing nothing on weekends and evenings. At this scale that doubles your bill for no benefit.
Scenario 3: B2C E-Commerce (Predictable Traffic, Always On)
Different pattern from B2B: consumers shop in the evenings, browse on lunch breaks, and spike on sale days. Traffic is more predictable and more sustained — you can see when your users are active. Always-on containers make more sense here than per-request billing, and Lambda handles the background work: order processing, email notifications, inventory updates.
What you need:
- ECS Fargate — for the web application (always on)
- RDS PostgreSQL — relational database for products, orders, users
- Lambda — for asynchronous processing (order events, notifications)
- S3 — product images, user uploads
- CloudFront — CDN for images and static assets
- Application Load Balancer — to route traffic to your containers
- SES — transactional emails (order confirmations, shipping updates)
Step-by-step in the calculator:
1. ECS Fargate. This time, always-on with room for traffic:
- 2 tasks running 24/7 (redundancy — if one dies, the other keeps serving)
- 1 vCPU, 2 GB memory per task
- This handles a few thousand daily active users comfortably
2. RDS PostgreSQL. Add RDS:
db.t4g.small(2 vCPU, 2 GB RAM)- 50 GB storage with gp3
- Single-AZ for now (Multi-AZ when revenue justifies it)
3. Lambda. For async processing:
- 200,000 invocations/month (order events, email triggers, inventory sync)
- Average duration: 300ms
- Memory: 256 MB
4. S3 + CloudFront. Product images and static assets:
- 20 GB S3 storage
- 100 GB CloudFront data transfer out/month
- 1,000,000 HTTPS requests/month
5. Application Load Balancer. Add ALB:
- 1 ALB running 24/7
- 10 LCU — a reasonable average for moderate e-commerce traffic
6. SES. Transactional emails:
- 10,000 emails/month (~$1)
What the calculator shows: ~€130–180/month
What we actually see: €200–280/month. At this tier, the hidden costs start adding up: NAT Gateway (€35/month), CloudWatch logging (€15–25/month), data transfer between availability zones, and Route 53. The gap between the calculator and reality is wider than in serverless setups because you have more always-on components generating background charges.
The Cost Traps Nobody Warns You About
The calculator handles the obvious services well. Here's what it consistently underestimates or misses entirely:
NAT Gateway — the silent budget killer. If your Fargate tasks or Lambda functions run in a private subnet (which they should for security), they need a NAT Gateway to reach the internet. In the Frankfurt region, a NAT Gateway costs ~€35/month just to exist ($0.052/hour), plus ~€0.048 per GB of data processed. For a small app doing moderate API calls to external services, this can easily add €40–70/month — often more than the compute cost itself.
How to reduce it: Use VPC endpoints for AWS services (S3, DynamoDB, ECR). These are cheaper and keep traffic off the NAT Gateway. For S3 and DynamoDB, gateway endpoints are free.
Data transfer between availability zones. If your ECS task is in eu-central-1a and your RDS instance is in eu-central-1b, every byte transferred between them costs €0.01/GB in each direction. It's tiny per request, but at scale it adds up.
CloudWatch Logs ingestion. Every log line your application writes costs money to ingest and store. Verbose logging in production can add €20-50/month without you noticing. Set log retention policies (14 or 30 days) and avoid logging request/response bodies in production.
Public IPv4 addresses. Since February 2024, AWS charges $0.005/hour for every public IPv4 address — whether it's attached to a running instance or sitting idle. That's ~$3.60/month per address. This applies across all services: EC2 instances, ALBs, NAT Gateways, RDS instances — each one with a public IP adds to the bill. Orphaned Elastic IPs are the obvious waste (we routinely find 3–5 per client account), but even your actively used addresses now cost money. It's one more reason to consider IPv6 where your stack supports it.
ECR storage. Every Docker image you push to ECR stays there forever unless you set lifecycle policies. After a year of deployments, you might have hundreds of old images costing a few euros a month — not catastrophic, but needless.
A Real Cost Analysis: PaaS vs AWS Lambda vs Self-Hosted
Not every cost story is about fixing mistakes. Sometimes it's about choosing the right platform before you overspend.
A B2B SaaS client came to us running a multi-tenant application on a popular PaaS — React frontend, Python backend as serverless functions, managed Postgres with one database per tenant. At their current scale (~10 tenants), the bill was manageable: roughly £90/month. But they were planning to grow, and wanted to understand what their infrastructure would cost at 100, 500, and 1,000 tenants before committing to a platform long-term.
We analyzed three paths: staying on the current PaaS, migrating to AWS Lambda, and moving to self-hosted containers on a traditional VPS provider.
What we found:
At 10 tenants, all three options cost roughly the same — £55–90/month. The differences only show up at scale:
| Scale | Current PaaS | AWS Lambda | VPS / Dedicated |
|---|---|---|---|
| 10 tenants | ~£90/mo | ~£55/mo | ~£90/mo |
| 100 tenants | ~£315/mo | ~£280/mo | ~£470/mo |
| 500 tenants | ~£2,600+/mo | ~£990/mo | ~£1,150/mo |
| 1,000 tenants | ~£4,600+/mo | ~£1,700/mo | ~£1,900/mo |
The PaaS bill hits a cliff at around 500 tenants — the point where their Enterprise tier kicks in. AWS Lambda stays cheapest at every measured scale above the free tier, thanks to per-invocation billing and scale-to-zero economics. The VPS path is competitive and avoids vendor lock-in, but its fixed server costs make it pricier than Lambda in the 100–500 tenant range.
The hidden cost driver: the database, not compute. At 1,000 tenants, the client's managed Postgres bill alone would exceed the compute platform cost on any option. For the VPS path, switching to self-hosted Postgres cuts the total dramatically. The biggest cost savings came from a database decision, not a compute decision.
Our recommendation: Stay on the current PaaS now (zero ops overhead, fastest iteration at this stage), but collect usage metrics so the migration decision is driven by real data, not guesswork. When the triggers hit, move to AWS Lambda.
The whole analysis took a few days. It saved the client from either migrating too early (wasting engineering time) or too late (hitting a multi-thousand-pound monthly cliff they didn't see coming). That's the kind of cost work that a calculator can't do on its own.
How to Use the Calculator Effectively
After walking dozens of clients through this process, here's our playbook:
Start with one scenario, not your entire infrastructure. Estimate your most critical workload first. Get that right, then add the rest.
Use the "share" feature. The calculator lets you export and share estimates via link. Send it to your team for review before making decisions. We send these to every client as part of our architecture proposals.
Revisit monthly for the first quarter. Your initial estimate will be wrong — that's fine. Compare it to your actual bill in Cost Explorer after the first month, identify the gaps, and adjust. By month three, your estimates should be within 10% of reality.
Don't optimize before you measure. We see companies buying Reserved Instances in their first month because "it saves money." It does — if you know what you're reserving. Run on-demand for 2-3 months, understand your actual usage patterns, then commit.
What Your Estimate Should Include
Before you finalize your estimate, make sure you've accounted for:
- Compute (Fargate, Lambda, or EC2)
- Database (RDS or DynamoDB)
- Storage (S3)
- CDN (CloudFront)
- Load balancer (ALB)
- NAT Gateway (add this — the calculator won't remind you)
- DNS (Route 53 — ~€0.50/hosted zone/month plus per-query charges)
- Monitoring (CloudWatch — at minimum, basic logging and alarms)
- 15-20% buffer for data transfer, miscellaneous charges, and surprises
Add these up and you'll have a number you can confidently bring to a budget meeting.
At Otocolobus, we help SMBs estimate, build, and optimize their AWS infrastructure. If you've run the calculator and want someone to sanity-check your numbers — or if you'd rather skip the guesswork entirely — get in touch. We'll walk through your specific case.