Why Your Cloud Bill Exceeds the Compute Estimate

Quick answer

A compute estimate usually covers only the servers running your application. Your cloud bill can also include disks, storage requests, data transfer, NAT gateways, load balancers, public IP addresses, databases and monitoring. Some charges continue when the application is idle—or its servers are stopped. Build the estimate from the entire architecture, then compare billed usage with your assumptions. (aws.amazon.com)

This guide is for teams budgeting a workload or investigating an unexpectedly large bill. AWS provides the concrete examples; it is not a provider recommendation.

Pricing scope: Official pricing pages and documentation were checked on October 4, 2026. The worked example uses US dollars and US East (N. Virginia), us-east-1, with published example rates as planning inputs. Some regional pricing tables load interactively, so refresh the inputs in the provider’s calculator before approving spending. The example is not a quote or a measured customer result.

1. Estimate the architecture, not just the servers

Start with a diagram and a billing worksheet. For every component, record:

• Resource count and deployment region.
• Running hours or provisioned capacity.
• Usage-based charges, such as requests or processed data.
• Redundancy, replicas and retained copies.
• Owner, environment and the source of the usage assumption.

A useful worksheet separates capacity-based charges from activity-based charges. A NAT gateway, for example, has both an hourly charge while provisioned and a charge for each gigabyte it processes. A quiet workload can therefore still incur networking costs. (aws.amazon.com)

For an existing workload, investigate the bill in this order:

1. Compare the same billing period and cost basis.
2. Identify the services contributing most to the difference.
3. Inspect their usage types and regions.
4. Match each charge to a resource or shared platform component.
5. Compare billed quantities—not just dollars—with the estimate.

Do not assume an unexplained charge is waste. Ask whether it reflects a missing component, higher demand, a longer-running environment or an architectural requirement. Record the explanation before changing anything.

2. Storage costs include capacity and operations

For block storage, estimate the capacity you provision, not only the space the application currently fills. Amazon EBS gp3 pricing separates storage capacity from additional provisioned performance above the included baseline. Snapshots are another pricing category. (aws.amazon.com)

For object storage, the bucket’s size is only part of the estimate. Amazon S3 lists storage, requests, retrievals, data transfer and additional management features as separate cost components. Some storage classes also have minimum billable object sizes or minimum storage durations. (aws.amazon.com)

Practical checks

• List application disks, database storage and object storage separately.
• Estimate PUT, GET and LIST operations from application behavior.
• Include retained versions, replicated copies and backup storage.
• Check retrieval charges before selecting an archival class.
• Review temporary storage created by imports, exports and migrations.

A common mistake is choosing a storage class using its capacity price alone. Before changing classes, model how often readers access the objects, how long objects remain stored and whether retrieval delays are acceptable.

Also distinguish average monthly storage from end-of-month storage. If the dataset grows during the month, make that growth assumption explicit rather than silently treating the final size as constant.

3. Networking can create several charges for one data path

Draw each important data path: user responses, third-party API calls, database replication, cross-region copies and access to cloud storage.

A NAT gateway can add processing charges to traffic that also incurs ordinary data-transfer charges. AWS’s pricing example also shows that placing an instance and its NAT gateway in different availability zones can introduce additional transfer charges. (aws.amazon.com)

Treat these as distinct questions:

• Where does the data go? Internet, another zone or another region?
• Which service sends it? Apply that service’s transfer rules.
• What processes it along the way? NAT gateways, load balancers or other network services?
• Which allowances apply? Are they already used elsewhere?

AWS currently provides 100 GB of monthly internet data transfer out, aggregated across AWS services and regions, excluding China and GovCloud. Do not give every application its own copy of that shared allowance. (aws.amazon.com)

Application Load Balancers add an hourly charge and Load Balancer Capacity Unit, or LCU, usage charges. LCUs reflect dimensions including connections, processed bytes and rule evaluations; AWS uses the highest applicable dimension rather than simply counting requests. Public IPv4 addresses are separately chargeable. (aws.amazon.com)

Practical check: For a large traffic flow, trace its actual route before proposing a change. S3 gateway endpoints have no hourly or data-processing charges, but that does not make every endpoint type free or eliminate every other charge. (aws.amazon.com)

4. Managed databases need their own estimate

Do not bury the database inside “compute.”

Amazon RDS for PostgreSQL identifies database instance usage, provisioned storage, backup storage and data transfer as cost components. Configuration choices can also introduce additional charges, including provisioned IOPS and applicable extended-support fees. (aws.amazon.com)

Record the following before selecting a database price:

• Engine, version and instance class.
• Single-zone or multi-zone deployment.
• Storage type, capacity and performance settings.
• Read replicas and their deployment locations.
• Backup retention and manual snapshots.
• Expected data-transfer paths.

These are configuration questions, not invitations to remove resilience. Compare alternatives against the workload’s availability and recovery requirements.

Stopping a database does not remove all its costs. AWS states that a stopped RDS PostgreSQL instance still incurs provisioned-storage and backup-storage charges, although database instance-hour charges stop. (aws.amazon.com)

If the configuration is undecided, label the database amount as an allowance rather than presenting it as a verified forecast. An unresolved database estimate should remain visible during budget approval.

5. Logging and idle resources belong in the budget

Logging deserves a usage model of its own. CloudWatch pricing distinguishes log ingestion, storage and analysis-related features; metrics and alarms can add further charges. (aws.amazon.com)

Estimate log ingestion from an explicit assumption, such as:

Requests per day × average logged bytes per request

Add background jobs and platform logs separately. Treat this as an initial model, then replace assumptions with observed usage when available. Do not invent a compression ratio to estimate stored logs.

Check log levels, duplicate collection and retention settings. Reduce unnecessary verbosity only after identifying the records needed for security, troubleshooting and operational review.

For idle environments, inspect the surrounding resources as well as the servers. Stopping an EBS-backed EC2 instance stops its instance-usage charges, but its persistent volumes remain chargeable. NAT gateway hourly charges and allocated public IPv4 charges can also continue independently of application demand. (docs.aws.amazon.com)

Before removing a resource, confirm its owner, dependencies, recovery role and retention requirements. “Unused today” is not enough evidence to delete it.

6. Worked example: expanding a $100 compute budget

Consider an illustrative web application planned around a $100 monthly application-compute allowance.

Assume:

• A 730-hour planning month—not the length of every calendar month.
• Two private application servers with 100 GiB of combined gp3 storage.
• Two zonal NAT gateways processing 200 GB in total.
• One internet-facing Application Load Balancer averaging one billable LCU.
• Four public IPv4 addresses: two for NAT and two assumed for the load balancer.
• 500 GB-month of S3 Standard storage, 100,000 PUT requests and one million GET requests.
• 1,000 GB of internet transfer out, with the shared 100 GB allowance entirely available.
• 100 GB of application-log ingestion and 20 GB-month of stored logs.
• A $75 database allowance, pending configuration and pricing.

The compute and database amounts are hypothetical budget inputs, not quoted instance prices. The remaining inputs use rates published in official AWS examples and documentation.

Component	Calculation	Monthly amount
Application compute	Hypothetical allowance	$100.00
Managed database	Unverified planning allowance	$75.00
EBS gp3 capacity	100 GiB × $0.08/GiB-month	$8.00
S3 Standard capacity	500 GB-month × $0.023	$11.50
S3 PUT requests	100,000 ÷ 1,000 × $0.005	$0.50
S3 GET requests	1,000,000 ÷ 1,000 × $0.0004	$0.40
NAT gateway hours	2 × 730 × $0.045	$65.70
NAT processing	200 GB × $0.045	$9.00
Public IPv4 addresses	4 × 730 × $0.005	$14.60
Load balancer hours	730 × $0.0225	$16.43
Load balancer capacity	730 LCU-hours × $0.008	$5.84
Internet transfer out	900 billable GB × $0.09	$81.00
Log ingestion	100 billable GB × $0.50	$50.00
Log storage	20 billable GB-month × $0.03	$0.60
Illustrative planning total	Rounded to cents	$438.57

Rate references: EBS capacity; S3 capacity and requests; NAT and IPv4; load balancing; internet transfer; and logging. (aws.amazon.com)

The example assumes applicable log allowances are already consumed elsewhere. NAT-processed traffic and internet-egress traffic are separate usage quantities; do not infer one from the other.

The result is a planning demonstration, not a complete invoice forecast. It includes $263.57 beyond the two hypothetical compute and database allowances. It excludes taxes, support, discounts, credits, snapshots, cross-zone transfer, DNS, security services and other unmodeled usage. The database allowance must be replaced before approval.

As a sensitivity check, another 100 billable GB of internet egress adds $9 at the example rate. If that traffic also traverses NAT, another $4.50 of processing applies. These are separate meters, not duplicate arithmetic.

7. Use tags, budgets and rightsizing to explain the difference

Use three controls for three different jobs.

Tags identify ownership. Choose a small consistent set, such as Application, Environment, OwnerTeam and CostCenter. AWS requires user-defined tags to be activated for cost allocation before they can organize billing reports. Applying a resource tag alone is not the complete setup. (docs.aws.amazon.com)

Keep an explicit unallocated category. Agree how shared platform charges will be divided rather than forcing every charge into an application tag.

Budgets provide warnings. Set alerts for actual spending and forecast spending, assign recipients and document the response. A budget alert is not an automatic spending cap: AWS documents delays between resource usage, billing and notification. Automated budget actions require separate configuration. (docs.aws.amazon.com)

Rightsizing supports capacity decisions. AWS rightsizing recommendations consider CPU, memory when enabled, network and storage-related utilization. Do not resize using average CPU alone. (docs.aws.amazon.com)

Before accepting a recommendation, check peak demand, memory pressure, latency, batch schedules and failover headroom. Test the change and retain a rollback option. Measure the resulting bill and service performance; a recommendation is not evidence of realized savings.

Finish each review with an updated worksheet: observed quantities, revised assumptions, unresolved items and a named owner. The goal is an explainable bill that meets operational requirements—not a lower number at any cost.

Read next: Turn RTO and RPO Into a Cloud Backup and Restore-Test Plan