What a web app costs per month on Azure, AWS, Google, Oracle
A typical web app on a cloud has the same five parts everywhere: app servers, a load balancer, a managed PostgreSQL database, file storage and data going out to users. Every cloud sells all five, under different names and with different billing rules. This guide explains how each part is charged, so you can see which ones grow with your traffic and which are fixed.
The five parts
| Part | Azure | AWS | Google Cloud | Oracle Cloud |
|---|---|---|---|---|
| App servers | Virtual Machines (Dsv5) | EC2 (M6i) | Compute Engine (N2) | Compute (E5 Flex) |
| Load balancer | Application Gateway v2 | Application Load Balancer | Cloud Load Balancing | Flexible Load Balancer |
| Database | Database for PostgreSQL | RDS for PostgreSQL | Cloud SQL for PostgreSQL | Database with PostgreSQL |
| Files | Blob Storage | S3 | Cloud Storage | Object Storage |
| Data out | Bandwidth | Data transfer out | Network egress | Outbound data transfer |
We compare these because they do the same job: a general-purpose Linux VM, a layer-7 HTTP load balancer, a managed PostgreSQL server, hot-tier object storage and internet egress. We do not compare, for example, a burstable VM against a fixed-performance one.
What is fixed and what grows
Fixed by the hour. App servers and the database server cost the same whether they are busy or idle. Doubling traffic does not change their price until you add servers or move to a bigger size.
Fixed plus usage. A load balancer has an hourly base charge plus a charge sized by traffic. The traffic part is measured differently on each cloud, so the same traffic is billed in different units.
Grows with volume. File storage grows with the gigabytes you keep. Data out grows with every response you send, and it is usually the part that surprises people first.
Free in one direction. Data coming into the cloud from the internet is free. Only data going out is billed.
What changes the bill most
- The number and size of app servers. Hours are the same on every cloud (730 a month if they run all the time), so the difference is the hourly rate and the size options.
- High availability for the database. A standby copy in a second zone is billed as a second copy of the compute, and on most clouds the storage too. Oracle shares storage between its two nodes, so it counts once. Turning it on roughly doubles the database line.
- Data out. Price per gigabyte falls in tiers as volume grows, and each cloud has different tiers and a different free allowance. Volume at the edges, such as a few hundred gigabytes or tens of terabytes, is where clouds differ most.
- Where your users are. Google prices data out by destination, so a site with users in India and one with users in the US are billed differently.
What the estimates leave out
The estimator uses on-demand list prices, runs servers 24 hours a day, and spreads traffic evenly over the month. It does not include database backups, monitoring, DNS, a CDN, support plans or taxes. Discounts for committing to one or three years, spot or preemptible VMs and free tiers are also left out, because they depend on your contract. Treat the result as a way to compare clouds on the same terms, not as a quote.
How to size yours
Start from four numbers: requests per second at an ordinary busy time, gigabytes sent to users each month, how many app servers you run, and database size and storage. The estimator’s example buttons give a small, medium and large starting point.
Then change one input at a time. Switch high availability on and off, double the data out, or halve the servers, and watch which line moves. That tells you what to design around before you build.
For the price of any single part, see the compare pages for the load balancer, database, virtual machine, storage and data transfer. Each shows every price line with its unit and the vendor’s own price page.