Why Your Cloud Database Pays for Data It Never Moves

Your database query returns 50KB of results. You pay for that. Then you pay again when those results leave the data center, again when they cross availability zones, and potentially again when they hit your application tier. The data didn't go anywhere meaningful — it went from one AWS rack to another — but the meter ran the whole time.

This is how cloud database pricing actually works, and most teams don't figure it out until they're staring at a bill that's 40% higher than their estimates.

The Egress Model Is Working Exactly as Designed

I want to be clear about something: cloud providers aren't making a mistake with egress pricing. It's deliberate. The model is designed to make it cheap to get data in and expensive to get data out — or even to move it around internally. AWS, Azure, and GCP all operate on this principle, with minor variations in how they label the line items.

Here's what the actual cost structure looks like for a mid-sized PostgreSQL workload on AWS RDS in us-west-2 (Oregon):

• Instance costs: db.m6g.xlarge (4 vCPU, 16GB RAM) — roughly $0.48/hour, about $350/month
• Storage: $0.115/GB-month for gp2, plus $0.10/GB for I/O requests above baseline
• Multi-AZ: Double the instance cost for the standby replica — another $350/month
• Egress to internet: $0.09/GB after the first GB free per month
• Cross-AZ data transfer: $0.01/GB in each direction — so $0.02/GB round trip
• RDS Proxy: $0.015 per vCPU-hour if you're using it for connection pooling

That last one surprises people. RDS Proxy is a managed service that sits in front of your database to handle connection pooling — something that should be a basic feature — and AWS charges extra for it.

Now run the math on a SaaS application with 500GB of data, a read replica in a different AZ, and 2TB of monthly egress to end users. You're looking at $1,200+ per month just in transfer and replication costs, on top of the base instance fees. The compute isn't the expensive part. The data movement is.

What "Cross-AZ" Actually Means for Your Architecture

If you've architected for high availability on AWS — and you should be, if you're running production workloads — you've almost certainly introduced cross-AZ traffic without fully accounting for it.

A typical three-tier web app looks like this:

Load Balancer (us-west-2a)
    → App Server (us-west-2b)  ← cross-AZ
        → RDS Primary (us-west-2c)  ← cross-AZ
            → RDS Standby (us-west-2a)  ← cross-AZ replication

Every hop between availability zones costs money. The app server talking to the database: $0.02/GB round trip. The synchronous replication to the standby: another $0.02/GB. If you're also running a read replica for reporting queries, add another $0.02/GB for that replication stream.

For a database that handles 10TB of internal traffic per month — not unusual for a busy transactional system — that's $200/month in transfer fees that have nothing to do with serving users. It's the infrastructure talking to itself.

AWS will tell you that multi-AZ is the right approach for durability, and they're not wrong. But they won't prominently advertise that the durability model they recommend generates significant ongoing transfer revenue for them.

The Backup and Snapshot Problem

Here's one that catches teams off guard: automated backups and snapshots.

RDS automated backups are "free" up to 100% of your provisioned storage. Sounds fine. But manual snapshots are billed at $0.095/GB-month. And if you're doing any kind of cross-region backup — which is the right call for disaster recovery — you're paying $0.02/GB for the transfer plus the storage costs in the destination region.

A 500GB database with daily snapshots retained for 30 days, backed up to a second region, generates:

• ~15TB of snapshot storage across both regions: ~$1,425/month
• ~500GB of cross-region transfer per day: ~$900/month at $0.02/GB

That's $2,300/month in backup infrastructure alone. For a 500GB database.

The teams that get hit hardest by this are usually running compliance workloads — healthcare, finance, anything with a regulatory retention requirement — because they're keeping backups longer and they can't compromise on the cross-region redundancy. The compliance requirement creates the cost exposure.

A Real Example: What a Healthcare SaaS Company Actually Paid

A Boise-based healthcare SaaS company came to us after their AWS bill hit $38,000 in a single month. They had a relatively straightforward HIPAA workload: a PostgreSQL database storing patient records, a Rails application tier, and a React frontend served via CloudFront.

Their database costs broke down like this:

• RDS Multi-AZ (db.r6g.2xlarge): $1,100/month
• Storage (2TB gp3): $230/month
• Read replica for reporting: $550/month
• Cross-AZ transfer (estimated 8TB/month): $160/month
• Egress to CloudFront: $180/month (CloudFront to internet is cheaper, but the origin fetch isn't free)
• Snapshot storage and cross-region backup: $2,100/month
• RDS Proxy: $87/month
• Database subtotal: ~$4,400/month

Their total bill was $38K because the database was only part of the problem — they were also running a Kubernetes cluster, multiple Lambda functions, and a data pipeline that moved records between S3 and RDS constantly. Every step in that pipeline generated transfer costs.

After migrating to IDACORE, their monthly infrastructure bill came down to $24,000. The database workload specifically dropped to under $1,800/month — same PostgreSQL, same data volume, no egress fees between services, no cross-AZ transfer charges because the architecture lives in a single coherent facility rather than being artificially distributed across availability zones for a managed service's benefit.

The compliance posture actually improved, because Idaho data residency meant their patient data stayed in state — something their legal team had been trying to achieve on AWS without success.

How Flat-Rate Pricing Changes Your Architecture Decisions

When you're not paying per-GB for internal data movement, you make different decisions.

On AWS, there's a real financial incentive to minimize cross-service communication. Teams cache aggressively not just for performance reasons, but to avoid transfer costs. They batch API calls. They denormalize data to reduce query volume. Some of these are good practices regardless — but some of them are architectural compromises you're making because the billing model punishes data movement.

At IDACORE, your virtual server talking to your database doesn't generate a separate line item. Your application pulling from object storage doesn't cost more because you made 10,000 requests instead of 1,000. The pricing is for the resources you provision — compute, RAM, storage — not for the conversations those resources have with each other.

This sounds like a small thing until you're designing a microservices architecture where services need to communicate constantly, or a data pipeline where records flow through multiple processing stages, or a reporting system that pulls from production and writes to a data warehouse. In those scenarios, hyperscaler transfer pricing isn't a minor annoyance — it's a fundamental constraint on how you build.

For Idaho companies specifically, there's another dimension: latency. Our data center is 85 miles from Boise, and the sub-5ms round-trip to the Treasure Valley means your application tier and database tier can actually be in the same facility without the artificial AZ distribution that AWS requires for durability. You get the performance benefits of colocation without the transfer cost penalties.

Compare that to running on AWS us-west-2 in Oregon, where you're looking at 20-40ms to Boise metro before your application has done anything useful. For a database-heavy application that makes dozens of queries per page load, that latency compounds fast.

What to Actually Do About This

If you're currently on a hyperscaler and your database bill is higher than you expected, start with your Cost Explorer or equivalent. Filter for data transfer costs specifically — not just the database service line. You'll often find that 25-35% of your total database spend is transfer, not compute or storage.

Then model what your workload would look like with flat-rate pricing. The math isn't complicated:

1. Take your last 3 months of transfer costs (cross-AZ, egress, cross-region backup)
2. Add your snapshot storage costs beyond the free tier
3. That's your baseline savings floor — what you'd save before any compute optimization

For most mid-sized PostgreSQL or MySQL workloads we see, that number is $800-2,500/month. For larger analytics databases or high-throughput transactional systems, it's considerably more.

The other thing worth doing: audit your backup architecture. Cross-region backup on AWS is expensive and often configured by default when teams set up RDS. If you're retaining 30 days of daily snapshots across two regions, you may be spending more on backup storage than on the running database.

---

If you're running a database workload in the Treasure Valley and your egress and transfer costs are eating into what should be a straightforward infrastructure budget, we've done this migration enough times to know exactly where the costs are hiding. Tell us what your current setup looks like and we'll give you a real number — not a ballpark estimate, an actual line-item comparison based on your workload.