Why Is My SaaS AWS Bill So High? How to Reduce Backend and Infrastructure Costs

Your SaaS is growing. Users are signing up, traffic is increasing, and the product is working. Then the AWS bill arrives.

It is higher than you expected. It is growing faster than revenue. And when you look at the billing dashboard, the numbers are real but the reasons are not obvious.

This situation is extremely common. A SaaS can have relatively modest traffic while still generating a disproportionately large AWS bill not because AWS is expensive by nature, but because of architecture decisions that were made quickly, resources that were sized for the wrong assumptions, queries that hit the database more often than they need to, and services that run continuously when they do not need to.

The goal of this guide is not to help you make your infrastructure as cheap as possible. Cutting corners on infrastructure causes reliability problems, security gaps, and customer experience failures that are far more expensive than the money saved. The goal is to help you get more useful capacity from every dollar to identify the waste, fix the inefficiency, and build infrastructure that scales with revenue rather than ahead of it.

Why SaaS AWS Bills Grow So Quickly

During early development and MVP stages, AWS costs are typically low. A single server, a small database, minimal traffic the bill is predictable and manageable. The cost growth accelerates as soon as real users arrive, and it often grows faster than the traffic itself because of how infrastructure is provisioned under pressure.

The major cost drivers in a typical SaaS AWS deployment:

• Compute EC2 instances, ECS tasks, EKS nodes, and Lambda invocations. Often the largest line item, and frequently over-provisioned.
• Databases RDS and Aurora instance costs, storage, I/O operations, read replicas, and automated backup storage. Database costs scale with size, usage, and the efficiency of the queries running against them.
• Storage S3 buckets accumulate quickly. User uploads, application assets, logs, backups, and database snapshots all persist unless explicitly managed.
• Data transfer one of the most misunderstood AWS costs. Data moving out of AWS to the internet, across regions, or even across availability zones all incurs charges that compound with traffic volume.
• Load balancers Application Load Balancers have both hourly and LCU-based charges that can become significant at higher traffic volumes.
• Serverless functions Lambda costs are often low in isolation but can become significant when functions are invoked at high frequency or run for extended durations.
• Containers ECS and EKS add orchestration overhead, and the underlying compute running the containers applies the same over-provisioning risks as EC2.
• Monitoring and logs CloudWatch charges for custom metrics, log ingestion, log storage, and dashboards. Verbose application logging at scale generates surprising bills.
• Backups and snapshots automated RDS snapshots and EBS snapshots accumulate. Old snapshots that are never deleted continue to incur storage costs indefinitely.
• Third-party services NAT Gateways, Secrets Manager API calls, SQS messages, SNS notifications, and other ancillary services each add small costs that aggregate meaningfully.

The pattern is consistent: infrastructure was provisioned during a period of growth pressure, sized for anticipated peak rather than actual average, and never reviewed once the immediate problem was resolved. Small inefficiencies at every layer compound into a bill that seems disconnected from the actual scale of the product.

Step 1: Find Out What Is Actually Costing You Money

Before making any changes, understand where the money is actually going. Optimising without measurement is guessing, and guessing in infrastructure is expensive.

AWS Cost Explorer

AWS Cost Explorer is the starting point for any cost investigation. It breaks down spending by service, by region, by account, and over time. Enable it if you have not already, and look at the last 90 days to understand the trend rather than just the current month.

Cost allocation tags

If your resources are tagged by environment (production, staging, development) or by team or feature, cost allocation tags let you see exactly which environment or component is driving spending. Implementing consistent tagging is one of the highest-leverage infrastructure improvements a team can make, because it makes every future cost question significantly easier to answer.

AWS Billing dashboard

The billing dashboard shows month-to-date costs, forecasted spend, and service-level breakdowns. Set up billing alerts for thresholds that represent meaningful overspend a notification at 80% of your expected monthly spend gives time to investigate before the bill closes.

AWS Compute Optimizer and Trusted Advisor

AWS Compute Optimizer analyses CloudWatch utilisation metrics and recommends right-sized instance types for EC2, ECS, Lambda, and EBS. Trusted Advisor identifies idle resources, under-utilised instances, and common cost optimisation opportunities. Both are free to use and provide actionable, specific recommendations.

A simple cost investigation checklist:

• Which service accounts for the largest share of the monthly bill?
• Which service has grown the fastest in the last 90 days?
• Is staging or development infrastructure contributing significantly to costs?
• Are there services with unexpected usage spikes?
• Are there resources in regions that do not serve production traffic?
• Are there services running that have no obvious owner or purpose?
• What does daily cost look like is it consistent or are there specific days or events driving spikes?

Step 2: Stop Paying for Oversized Compute

Over-provisioned compute is the most common source of unnecessary AWS spending. It happens for understandable reasons when the product was slow, someone made the server bigger. When traffic grew, the instance was upgraded before anyone measured whether the current one was actually at capacity. The result is expensive servers running at 10-20% CPU utilisation.

Right-sizing EC2 and ECS

Pull CPU and memory utilisation data from CloudWatch for the last 30 days. Look at average utilisation, not peak. If average CPU utilisation is consistently below 30%, the instance is over-sized for current load. AWS Compute Optimizer will suggest specific alternative instance types based on this data.

The goal is to size for the P90 or P95 of your actual utilisation, not for the theoretical maximum. For production services, leave a buffer but that buffer should be measured, not assumed.

Development and staging environments

Development and staging servers almost never need to be as large as production. A staging environment that mirrors production instance sizes for a product with a few hundred users is paying for capacity that serves no purpose. Use smaller instances for non-production environments and schedule them to stop outside working hours a development server that runs from 8am to 8pm on weekdays instead of 24/7 saves 65% of its running cost immediately.

Duplicate and forgotten environments

Every fast-growing team accumulates environments that were created for a specific purpose and never shut down. Load test environments, demo environments, old feature branches, prototype servers they all run continuously and none of them serve production customers. A quarterly audit of running instances and their purpose pays for the time it takes.

Step 3: Use Auto Scaling Properly

Fixed infrastructure a set of servers running at the same size 24 hours a day, 7 days a week is appropriate when traffic is constant and predictable. Most SaaS products do not have constant traffic. They have peaks during business hours, quieter nights and weekends, and occasionally dramatic spikes around launches or campaigns.

Sizing infrastructure for peak demand means paying peak cost continuously. Auto Scaling Groups, ECS Service Auto Scaling, and serverless functions all offer the ability to match compute capacity to actual demand. The key is configuring them correctly.

Common auto scaling mistakes

• Minimum capacity too high if the minimum instance count is set to the same value as peak capacity, auto scaling provides no cost benefit outside peak periods
• Scaling on the wrong metric scaling on CPU alone without considering request latency and connection count can lead to both over-provisioning and under-provisioning
• Scaling too aggressively scaling out at low CPU thresholds and scaling in slowly leaves excess capacity running long after demand has dropped
• No scale-in policy many teams configure scale-out but forget scale-in, resulting in infrastructure that only ever grows

For most SaaS products, a properly tuned auto scaling policy with a low minimum capacity and sensible scale-out and scale-in thresholds reduces compute costs during off-peak periods significantly without affecting performance during peak usage.

Step 4: Optimize Your Database Before Adding More Servers

Database costs are consistently underestimated. An RDS or Aurora instance can be one of the largest monthly line items and its cost is driven by both instance size and the efficiency of the workload running against it. Many teams respond to a slow or overloaded database by upgrading to a larger instance. Sometimes that is the right answer. Often it is not.

Inefficient queries are expensive in multiple ways

A query that runs without an appropriate index performs a full table scan. On a table with millions of rows, this consumes CPU, memory, and I/O all of which are reflected in both response latency and AWS costs. Adding an index to a frequently executed query can reduce database CPU utilisation by a meaningful margin, which in turn may allow a smaller instance class.

N+1 queries and excessive requests

An N+1 query pattern where loading a list of items triggers a separate database query for each item turns a single API request into dozens or hundreds of database hits. At modest traffic, this is annoying. At scale, it multiplies database load far beyond what the traffic volume would suggest. Application-level query analysis (using RDS Performance Insights or tools like PgBadger for PostgreSQL) surfaces these patterns clearly.

Connection management

Databases have a finite connection limit. Applications that open connections without proper pooling exhaust the limit and create instability. RDS Proxy provides connection pooling as a managed service and is worth evaluating for applications with variable connection patterns. For applications using serverless functions, connection pooling is especially important because each Lambda invocation can open a new database connection.

Read replicas

Read replicas distribute read traffic across multiple database instances. They are appropriate when read queries are genuinely overwhelming the primary. They are not appropriate as the first response to database performance problems that step is query optimisation and caching. A read replica for a database with poorly optimised queries doubles the infrastructure cost without fixing the underlying problem.

Storage and backup costs

RDS automated backup retention defaults to 7 days. For many SaaS products, a shorter retention period is sufficient and reduces storage costs. Evaluate the actual recovery requirements and set retention accordingly. Ensure old manual snapshots are deleted regularly they persist indefinitely until explicitly removed.

Step 5: Add Caching Before Scaling Compute

The most predictable cost reduction in most SaaS architectures is a well-implemented caching layer. Caching stores the result of expensive operations database queries, API calls, computed values so they do not need to be recalculated on every request.

What should be cached

• Frequently read data that changes infrequently configuration, reference data, user permissions
• Expensive query results aggregations, reports, computed metrics
• API responses for public or semi-public endpoints
• Session data where applicable
• Third-party API responses that are called repeatedly with the same parameters

Redis and ElastiCache

ElastiCache for Redis is the standard approach for application-level caching on AWS. A small Redis instance handles an enormous volume of cache reads with negligible latency. The cost of a cache.t3.small instance is a fraction of the database or compute cost it offsets.

CDN caching

CloudFront can cache API responses, not just static assets. For SaaS products with public-facing endpoints that return data that does not change per user pricing pages, public listings, product catalogs CDN caching can eliminate a significant share of backend requests entirely.

HTTP caching

Proper use of Cache-Control headers, ETags, and Last-Modified responses allows browsers and CDNs to cache responses at the protocol level without application changes. For assets and API responses where this is appropriate, it is one of the cheapest performance and cost improvements available.

Step 6: Reduce Unnecessary API and Backend Work

Every unnecessary operation the backend performs has a cost: compute time, database load, and latency. Many high AWS bills are partly explained by backend code that does more work than necessary on every request.

• Repeated API calls fetching the same data multiple times within a single request cycle, or making the same external API call for every user when the result is shared
• Polling clients that poll an API endpoint every few seconds instead of using WebSockets or server-sent events generate unnecessary backend load
• Over-fetching database queries that return entire rows when only a few columns are needed, or API responses that include fields the client never uses
• Synchronous operations that should be async sending emails, generating PDFs, processing images, or running reports inside the request cycle when the client does not need the result immediately
• Duplicate work multiple services fetching the same data independently instead of sharing a computed result through a cache or event

The connection between backend engineering decisions and AWS costs is direct. Every redundant database call is a database I/O charge. Every synchronous operation that holds a compute resource for seconds is capacity that cannot serve another request. Every large response payload is data transfer cost. Improving backend efficiency reduces infrastructure cost as a side effect.

Step 7: Move Expensive Background Work to Queues

Background processing work that does not need to happen synchronously within an API request is more efficiently handled by queues and worker processes than by blocking the request cycle.

What should go into a queue

• Email delivery triggering an email within an API request means every email failure or delay affects the response time the customer experiences
• Report generation generating a PDF or complex data export is compute-intensive. Doing it asynchronously and notifying the user when it is ready is both faster and cheaper.
• Image and video processing resizing, transcoding, and watermarking are CPU-intensive operations that should never block the request cycle
• AI generation LLM calls, embedding generation, and AI processing have variable latency. Queuing them and streaming or polling the result decouples the AI latency from the API response time.
• Data imports and bulk operations large file imports, batch updates, and bulk notifications should always be queued
• Notification delivery sending webhooks, push notifications, or SMS from a queue allows retries and failure handling without affecting the user-facing API

SQS is the standard AWS queue service and costs are minimal for typical SaaS volumes. Moving expensive work into queues allows the application servers to handle more user-facing requests on the same compute capacity which means the same cost serves more customers.

Step 8: Control AWS Data Transfer Costs

Data transfer is one of the most misunderstood AWS cost categories. AWS charges for data leaving its network to the internet, between regions, and in some cases between availability zones. These charges are volume-based and accumulate in proportion to traffic growth.

Common sources of avoidable data transfer cost

• Large API responses returning more data than the client needs on every request. Pagination, field selection, and response compression all reduce transfer volume.
• Cross-region traffic services deployed in different AWS regions communicating with each other incur inter-region transfer charges. Regional architecture decisions made early can create significant cost differences at scale.
• Cross-AZ traffic NAT Gateway data processing charges apply to traffic flowing through NAT Gateways. Services that make many inter-service calls through a NAT Gateway accumulate charges that are easy to miss.
• File downloads served from EC2 application servers serving large files directly to users incur both compute and data transfer costs. CloudFront or S3 direct downloads are significantly cheaper.
• Verbose API integrations integrations that pull large datasets from external services or push large payloads can create unexpected data transfer costs at scale.

Enable gzip or Brotli compression on API responses as a baseline. Implement pagination for any endpoint that returns lists. Review the architecture for cross-region service dependencies and consolidate where possible. Route file downloads through CloudFront rather than directly from application servers.

Step 9: Put Static Files Behind a CDN

Application servers should not serve images, JavaScript, CSS, fonts, PDFs, or videos. These tasks consume compute capacity and generate data transfer costs at the full AWS egress rate. A CDN serves these assets from edge locations close to the user, at a fraction of the cost.

S3 and CloudFront

The standard AWS pattern is S3 for storage and CloudFront as the CDN layer. User-uploaded files, application assets, and static site content are stored in S3 and served through CloudFront. The combination is significantly cheaper than serving the same content from EC2, and global performance is substantially better.

CloudFront also reduces origin requests content served from the edge cache never reaches the origin server, which means your application servers handle fewer requests for the same user-facing traffic volume. This reduces both compute load and data transfer costs from the origin simultaneously.

Step 10: Clean Up Logs and Monitoring Costs

CloudWatch is a powerful observability tool and a quiet cost contributor. Log ingestion, log storage, custom metrics, and dashboard usage all incur charges. For applications that log at debug level in production, or that have never configured log retention policies, CloudWatch costs can be surprisingly large.

Common logging mistakes

• Debug logging in production verbose application logs that were left at debug level after a troubleshooting session. Each log line is ingested and stored, and the volume at scale is substantial.
• No retention policy CloudWatch log groups default to indefinite retention. Logs from two years ago are still being stored and charged unless a retention policy has been applied.
• Duplicate logs application logs forwarded to CloudWatch and also to a third-party tool double the ingestion cost without adding observability value.
• High-frequency custom metrics custom metrics published on every API request at high traffic volumes generate significant metric charges.
• Development and staging logs mixed with production all environments logging at the same verbosity to the same log groups increases both volume and cost.

Set retention policies on all CloudWatch log groups immediately 30 days is appropriate for most production logs. Set production logging to INFO level rather than DEBUG. Review custom metrics and remove those that are not actively used in dashboards or alarms. For teams using third-party observability tools like Datadog or Grafana, evaluate whether CloudWatch logging is redundant. What Is Software Monitoring? A Practical Guide for SaaS Founders covers how to instrument a SaaS product effectively without generating unnecessary cost.

Step 11: Shut Down Resources You Don't Need

Every AWS account accumulates resources over time that serve no current purpose. They were created for a specific reason a load test, a proof of concept, a temporary migration, a demo and never removed. Each one generates a cost that provides no value.

A monthly infrastructure cleanup checklist:

• EC2 instances with no recent network traffic or CPU activity
• Stopped EC2 instances they still incur EBS storage charges
• Unused EBS volumes detached volumes that are no longer attached to any instance
• Old EBS snapshots snapshots taken for migrations or testing that are no longer needed
• Unused Elastic IP addresses Elastic IPs incur charges when not attached to a running instance
• Unused load balancers ALBs without any targets registered still incur hourly charges
• RDS snapshots beyond the retention period manual snapshots persist until deleted
• S3 buckets with lifecycle policies not configured logs and user uploads accumulate indefinitely without lifecycle rules
• Old CloudWatch log groups with no retention policy often from services that no longer exist
• Unused NAT Gateways NAT Gateways incur both hourly and data processing charges

The temporary infrastructure that became permanent problem is universal. A resource provisioned for a two-week project runs for two years because no one feels certain it is safe to delete. Consistent tagging with owner, environment, and creation date makes this investigation much faster.

Step 12: Use the Right Architecture for Your Traffic

Infrastructure architecture should match actual workload not anticipated future workload, not the architecture described in a conference talk about a company with a hundred times more traffic.

Early-stage SaaS

A simple architecture: one or two application servers behind a load balancer, a single RDS instance, S3 for file storage, and CloudFront for assets. This is sufficient for most SaaS products in their first year. The goal is reliability and predictability, not sophistication.

Growing SaaS

As traffic grows and specific bottlenecks emerge: add a Redis cache to reduce database load, move background work into SQS queues with dedicated workers, optimise database queries and add read replicas if genuinely needed, and configure auto scaling. Each addition should be driven by a measured problem, not by anticipation.

Larger SaaS

At significant scale, distributed services, more sophisticated auto scaling, database sharding or migration to Aurora Serverless, and global infrastructure become relevant. These are expensive architectural decisions that should only be made when the current architecture has been genuinely exhausted.

Building enterprise-level infrastructure before you have enterprise-level traffic is one of the most expensive patterns in early SaaS development. The complexity costs operational overhead, engineering time, debugging difficulty arrive immediately. The benefits arrive only if the scale materialises.

Step 13: Don't Overuse Microservices

Microservices can increase infrastructure costs in ways that are easy to underestimate when the decision is made. Each service needs its own compute, its own load balancer or service discovery, its own deployment pipeline, and its own monitoring. Network calls between services incur latency and data transfer costs that internal function calls do not.

A SaaS product with five microservices instead of a well-structured modular monolith may require:

• Five separate ECS services with five sets of minimum instances
• More load balancers or an API gateway layer
• More CloudWatch log groups and metrics
• Cross-service network traffic with associated transfer costs
• More complex deployment infrastructure
• More engineering time to manage service interactions and deployments

A modular monolith a single deployable unit with clear internal boundaries is cheaper to run, simpler to monitor, and easier to debug. It can be decomposed into services later when the business has reached a scale that genuinely justifies the complexity. The argument for microservices at early stages is almost always about engineering preference rather than operational necessity. Which Programming Language Is Best for Complex and High-Scale Software Projects? covers the architecture trade-offs in more depth.

Step 14: Optimize AWS Without Destroying Performance

There is an important distinction between cost optimisation and cost cutting. Cost optimisation improves the efficiency of the infrastructure while maintaining or improving its capability. Cost cutting reduces the infrastructure's capability in exchange for a lower bill. The former is good engineering. The latter is a risk to the business.

Do not remove these to reduce costs

• Automated database backups the cost of losing production data is not a billing problem. Keep backups. Review retention policies, but do not disable them.
• Monitoring and alerting operating without visibility into production is more expensive than the monitoring cost. Optimise what you monitor; do not eliminate it. Why Your SaaS Needs Sentry Before Your First 100 Customers explains why monitoring is not optional.
• Security services GuardDuty, WAF, and IAM controls have costs. Removing them to reduce the bill exposes the infrastructure to risks that have much larger financial consequences.
• Production redundancy removing multi-AZ deployment from a production database to save money introduces single points of failure. An availability incident at the wrong moment costs more than months of multi-AZ fees.
• Database capacity too aggressively under-sizing a production database creates performance problems that affect all customers. Right-size thoughtfully with monitoring, not speculatively.

The infrastructure that protects reliability, security, and customer data has a cost that is worth paying. The goal is to eliminate waste idle resources, inefficient queries, over-provisioned servers, duplicate logging not to compromise the foundation.

Example: Reducing a $3,000 Monthly AWS Bill

Here is a realistic example of what an AWS cost review often finds for a growing SaaS at around $3,000 per month. This is illustrative actual findings and savings depend entirely on the specific architecture and usage patterns.

Starting infrastructure breakdown

Changes made

• Right-sized production instances to match actual utilisation moved from over-provisioned to correctly sized instances with auto scaling configured
• Added database indexes on the five most expensive queries identified by RDS Performance Insights CPU utilisation on the database dropped significantly, enabling a smaller instance class
• Reduced RDS backup retention from 30 to 14 days; deleted old manual snapshots
• Fixed application caching identified the data that was being fetched repeatedly and cached it properly, raising cache hit rate to over 70%
• Set 30-day retention on all CloudWatch log groups; switched production logging from DEBUG to INFO level
• Enabled gzip compression on API responses; implemented pagination on the three largest list endpoints
• Reduced development environment to smaller instances and scheduled shutdown outside working hours
• Added S3 lifecycle rules to move old logs to Glacier and delete after 90 days

Result

The changes above produced a meaningfully lower bill without removing any production redundancy, disabling monitoring, or compromising reliability. The database optimisation had the largest single impact improving query efficiency allowed a smaller instance class and reduced the per-request cost of every database operation across the product.

Actual savings vary significantly by architecture, traffic pattern, and usage profile. The point of this example is not a specific number but the pattern: most SaaS AWS bills contain several distinct categories of inefficiency that are addressable without compromise.

How Much Should a SaaS Spend on Infrastructure?

There is no universal benchmark. Infrastructure costs as a percentage of revenue vary enormously depending on the product type, traffic profile, AI usage, data volume, and geographic distribution. These are broad reference points, not targets:

• Early-stage SaaS (pre-revenue to first $10k MRR) $50 to $500 per month is typical for a simple, well-designed infrastructure
• Growing SaaS ($10k to $100k MRR) $500 to $5,000 per month is common, depending heavily on the workload and whether caching and auto scaling are properly configured
• Larger SaaS ($100k+ MRR) $5,000 and above, with AI-heavy products or data-intensive platforms often significantly higher

A more useful question than total AWS spend is cost per customer or cost per active user. If infrastructure cost is growing faster than customer count or revenue, the unit economics are deteriorating which is the signal that optimisation work has a meaningful business impact. How Much Does It Cost to Maintain a SaaS Product in 2026? covers the full picture of ongoing SaaS operating costs.

AWS Cost Optimization Checklist

Every week

• Review cost changes in AWS Cost Explorer
• Check for unexpected usage spikes by service
• Confirm billing alerts are configured and have not triggered

Every month

• Review EC2, ECS, and RDS utilisation against instance sizes
• Check auto scaling policies are working as configured
• Remove unused EC2 instances, EBS volumes, snapshots, and Elastic IPs
• Review CloudWatch log groups for retention policies
• Review S3 buckets for lifecycle policies
• Review data transfer costs and identify unexpected sources
• Check development and staging environment hours

Every quarter

• Review overall architecture against current traffic and workload
• Review auto scaling configuration and minimum/maximum capacity settings
• Evaluate Reserved Instances or Savings Plans for stable, predictable compute workloads
• Review database query performance and identify optimisation opportunities
• Compare infrastructure cost growth against revenue and customer growth
• Audit all running services against their purpose remove anything without a clear owner

When Should You Re-Architect Your SaaS?

Optimisation is not always the answer. There are situations where the architecture itself not just the configuration is the source of the cost and performance problems.

Warning signs that re-architecture is the right investment:

• AWS bill is growing significantly faster than revenue or customer count, and optimisation efforts have not changed the trajectory
• The database is consistently overloaded despite query optimisation, caching, and correct instance sizing
• Scaling events are frequent, expensive, and difficult to predict
• Network costs are material and trace to architectural decisions that cannot be easily changed
• The infrastructure is genuinely difficult to operate incidents take too long to diagnose, deployments are risky, and the team spends significant time managing the platform rather than building product
• Specific performance bottlenecks have been confirmed by measurement to require architectural changes rather than optimisation

Re-architecture is expensive and should only be undertaken when the current approach has been genuinely exhausted. Most AWS cost problems are solved by the optimisation steps above rather than by rebuilding. The Biggest Mistakes First-Time SaaS Founders Make includes the pattern of re-architecting prematurely as one of the most common and costly errors.

AWS Cost Optimization vs Cutting Corners

The first column reduces cost while maintaining or improving capability. The second column reduces cost by accepting risk. The consequences of cutting corners materialise eventually a security incident, a performance failure during a product launch, data loss that cannot be recovered. The costs of those events are not measured in AWS bills.

The Real Goal: Lower Cost Per Customer

The total AWS bill is a less useful number than the cost to serve one customer. A $10,000 monthly infrastructure bill for a SaaS generating $200,000 in MRR represents 5% of revenue typically healthy. A $1,000 bill for a SaaS generating $3,000 in MRR represents 33% a business model problem.

The unit economics that matter for infrastructure:

• AWS cost per active user are infrastructure costs growing proportionally with the user base, or faster?
• AWS cost per transaction for transaction-heavy products like payments or e-commerce platforms
• AWS cost per API request for products where API volume is the dominant cost driver
• AWS cost per AI generation for AI SaaS products, inference and embedding costs can dominate. How Much Does It Cost to Run an AI Agent? and the AI Agent Development Cost Breakdown cover this in detail.

If cost per customer is declining as the business grows, the infrastructure is scaling efficiently. If it is flat or rising, there is a specific inefficiency driving the divergence and finding it is an engineering task with a business payoff.

Conclusion

Your AWS bill is rarely high because AWS is expensive. It is high because of how the infrastructure has been designed, provisioned, and maintained over time. The most common culprits are compute that was provisioned for anticipated traffic and never reviewed, database queries that hit harder than they need to, logs that accumulate without retention policies, development environments that run 24 hours a day, and resources that no one is quite sure are still needed.

Fixing these problems is an engineering task, not a billing task. It requires measurement understanding exactly which services cost what and why before changing anything. It requires discipline keeping infrastructure sized for actual usage rather than theoretical peaks. And it requires ongoing attention a quarterly review of infrastructure against actual workload is one of the highest-return engineering activities available to a SaaS team.

The goal is not the smallest possible AWS bill. It is infrastructure that is efficient, predictable, secure, and aligned with the revenue it supports.