AWS costs: RDS vs Aurora pricing - a small app, both ways

For a small app — one database, modest traffic, nothing fancy — Amazon RDS is very likely cheaper than Amazon Aurora, and the gap isn't small: Aurora's own pricing page confirms its burstable-instance CPU credits cost 20% more per vCPU-hour than RDS PostgreSQL's, before you've even compared instance prices or added Aurora's separate charge for storage I/O requests. That's the part almost nobody checks first.

Jake runs a phone repair and resale shop, and about eight months ago he built a small inventory and repair-ticket web app for his own three locations. It needed a database. He asked AWS to recommend one, got back "Amazon Aurora" as the shiny featured option on the RDS pricing page, and almost clicked deploy without asking anyone.

Ethan, who's helped Jake untangle every AWS bill surprise for the past two years, put it this way when Jake asked him to sanity-check the choice: "Aurora isn't a discount database that also happens to scale. It's a scale database that AWS lets you run small — and running it small means paying for headroom you're not using."

Why RDS usually costs less for a small app

Both services are managed relational databases you rent by the hour (or by the ACU-second, for Aurora Serverless). But three structural differences stack in RDS's favor when your workload is small:

1. Aurora's compute has a documented premium. Even before comparing sticker prices on instance classes, Aurora's own pricing page states that its T4g/T3 burstable-instance CPU credits are billed at $0.09 per vCPU-hour, while RDS for PostgreSQL's equivalent T4g/T3 CPU credits are billed at $0.075 per vCPU-hour — a 20% higher overage rate on Aurora for the exact same kind of instance, before you've provisioned anything else.
2. Aurora Standard charges per I/O request; RDS's General Purpose SSD (gp3) storage does not bill I/O separately. A chatty small app — lots of small reads and writes, which is most CRUD apps — racks up Aurora I/O charges that simply don't exist as a line item on RDS gp3 storage.
3. RDS lets you provision exactly the size you need and stop paying instance-hours when you stop the instance. Aurora's storage auto-scales, which is valuable at scale, but for a small, stable dataset it buys you nothing over provisioning 20 GB once on RDS and leaving it alone.

None of that means Aurora is a bad product — it means Aurora's value proposition (instant failover, storage that scales without you touching it, replica read-scaling with shared storage) is aimed at a problem a small app usually doesn't have yet.

How Amazon RDS actually bills a small app

RDS bills for five things, and understanding each one is what lets you compare it honestly against Aurora instead of eyeballing a single "instance price."

DB instance hours

You pick an instance class (the size and shape of the virtual machine your database runs on — more vCPU and RAM costs more per hour) and pay for every hour it's in an "available" state, from launch until you stop or delete it. Billing is per-second with a 10-minute minimum following any billable status change, such as creating, starting, or modifying the instance. A small app usually lands on a "burstable" instance class (the T-family), which is priced to handle typical light, spiky traffic cheaply and only charges extra "CPU credits" if your average CPU usage over a rolling 24 hours goes above the instance's baseline.

Storage, provisioned in advance

RDS General Purpose (SSD) storage lets you provision anywhere from 20 GiB up to 64 TiB, and you're billed for what you provisioned — not what you actually used — per GB-month. If you provision 50 GB and only fill 10, you still pay for 50. You can also choose Provisioned IOPS storage (scaling from 1,000 to 256,000 IOPS) if you need guaranteed, consistent I/O throughput, but a small app rarely needs it and it costs more.

Backup storage

Automated backup storage equal to 100% of your provisioned database size is free per Region. Beyond that free allowance — extra manual snapshots, longer retention, or backups kept after you delete an instance — you're billed per GB-month.

Data transfer

Data moving between RDS and an EC2 instance in the same Availability Zone is free. Cross-AZ replication for a Multi-AZ deployment is also free. Once you cross Availability Zones between EC2 and RDS in the same Region, standard EC2 regional data-transfer rates apply, and outbound internet transfer follows AWS's tiered rate schedule.

What you stop paying when you stop the instance

Stopping (not deleting) an RDS instance stops instance-hour billing, but you're still charged for provisioned storage — including Provisioned IOPS — and backup storage within your retention window. To stop every RDS-related charge entirely, you have to delete all instances and snapshots.

How Amazon Aurora actually bills a small app

Aurora's billing model looks similar on the surface — instance hours, storage, backups, data transfer — but two of those work fundamentally differently, and there's a category RDS doesn't have at all: per-request I/O charges.

Two cluster configurations, priced differently

Aurora clusters run in one of two configurations, and you choose which one at the cluster level: Aurora Standard, where you pay for instances, storage, and I/O per request; or Aurora I/O-Optimized, where instance and storage rates are higher but read and write I/O operations cost nothing. AWS's own guidance: if your I/O spend would exceed 25% of your total Aurora bill under Standard, I/O-Optimized can save up to 40% — which tells you plainly that I/O-Optimized is a workload-shape decision, not a default upgrade. AWS's own worked example puts a number on that trade-off directly: for a db.r6i.large instance in US East (N. Virginia), Aurora Standard runs $0.29 per hour, while the same instance under Aurora I/O-Optimized runs $0.377 per hour — a 30% higher compute rate in exchange for zero per-request I/O charges.

Provisioned instances vs. Serverless

You can run Aurora on fixed provisioned instances (billed per instance-hour, same partial-hour and 10-minute-minimum rules as RDS) or on Aurora Serverless v2, which measures capacity in Aurora Capacity Units (ACUs) — roughly 2 GiB of memory plus proportional CPU and networking per ACU — and bills per second, scaling from as low as 0.5 ACU in increments as fine as 0.5 ACU. In US East (N. Virginia), Aurora serverless is billed at $0.12 per ACU-hour under Aurora Standard and $0.156 per ACU-hour under Aurora I/O-Optimized, per AWS's own worked pricing example.

Storage that scales itself — and costs differently for it

You never provision Aurora storage; it grows automatically as your data grows, and you're billed per GB-month for what you actually use. In US East (N. Virginia), AWS's own example prices Aurora Standard storage at $0.10 per GB-month and Aurora I/O-Optimized storage at $0.225 per GB-month. That's not automatically cheaper than RDS's provisioned rate — it depends entirely on how close your provisioned RDS storage is to your actual usage, and on which Aurora configuration you're running.

Backups follow the same 100% free rule

Like RDS, you aren't charged for backup storage up to 100% of the size of your database cluster, and snapshots taken inside your retention window are free. Beyond that, backup storage is metered per GB-month.

Data transfer, same free cases

Data transferred between Aurora and an EC2 instance in the same Availability Zone is free, as is cross-AZ traffic for cluster replication. The AWS Free Tier's 100 GB of monthly outbound internet transfer applies across all AWS services and Regions, aggregated — it's not an Aurora-specific perk.

Compute: the CPU credit gap nobody checks

Almost every "small app database" recommendation defaults to a burstable T-class instance (T4g or T3), because these instances are priced cheap for baseline usage and only cost extra when your average CPU utilization over a rolling 24-hour period exceeds that instance's baseline. Here's the documented gap between the two services on exactly that overage charge:

Put a real number on that gap: say your small app runs a nightly import job that pushes CPU above baseline for a combined 100 vCPU-hours over the course of a month — a couple of hours a night, most nights. On RDS for PostgreSQL, that's 100 × $0.075 = $7.50 in CPU credit charges. On Aurora, the identical 100 vCPU-hours of overage costs 100 × $0.09 = $9.00. A $1.50 difference on its own won't break anyone's budget, but it scales linearly with how much your app actually bursts — a heavier batch job or a busier support desk running 500 vCPU-hours of overage a month turns that into a $37.50 vs. $45.00 gap, every month, for no functional difference in what your app does. It's the same rate gap either way: Aurora's CPU credit overage is always 20% higher than RDS for PostgreSQL's.

That rate only bites if your app's average CPU crosses the instance's baseline for a full rolling day — a genuinely bursty app (traffic spikes for a few minutes, then idles) won't trigger it much on either engine. But a small app that runs a background job, a nightly report, or a batch import that keeps CPU elevated for hours will hit this line item, and it's cheaper on RDS every time.

Storage: provisioned upfront vs. pay for what you use

This is the one place Aurora's model looks genuinely appealing for a small app, and it deserves an honest look rather than a dismissal.

On RDS, you provision a storage size upfront — say 20 GB — and you're billed for that 20 GB every month whether your data grows to fill it or sits at 3 GB. If you need more later, you resize the volume (which can involve a brief performance hit while it reconfigures), and your bill is prorated for the change within the month.

On Aurora, storage isn't provisioned at all. It scales automatically in the background, and you're billed per GB-month for what's actually stored. For a small app with a genuinely tiny, slow-growing dataset, this removes the "guess how big to provision" step entirely.

Where this stops being a clear Aurora win: most small apps provision RDS storage in the 20–50 GB range, which is already inexpensive in absolute dollar terms, so the "waste" from over-provisioning is a few dollars a month at most — not enough to offset Aurora's higher compute rate on its own. Storage becomes a meaningful factor only once your dataset is large enough, or growing unpredictably enough, that guessing wrong on RDS provisioning would mean resizing repeatedly or paying for tens of unused gigabytes for months.

I/O requests: the line item that only exists on Aurora Standard

This is the part of Aurora's bill that catches small-app owners off guard, because it's genuinely absent from RDS's General Purpose (SSD) storage pricing. On Aurora Standard, every read and write I/O operation against your storage is metered and billed separately, per million requests, on top of instance and storage charges. On RDS with General Purpose SSD storage, I/O throughput is bundled into the storage rate — you don't get a separate per-request bill.

AWS's own worked example shows the mechanics: a database reading 350 data pages per second and writing 100 data pages per second, sustained for 30 days, generates enough billed I/O requests to add real dollars to the monthly total under Aurora Standard — separate from, and in addition to, the compute and storage charges.

You avoid this specific charge entirely by switching the cluster to Aurora I/O-Optimized (which raises instance and storage rates but zeroes out per-request I/O charges), or by staying on RDS, where the concept doesn't apply to General Purpose SSD storage at all. For a small, low-traffic CRUD app — the kind that does a modest, steady trickle of reads and writes rather than millions of operations a day — this charge is usually small in absolute terms, but it's one more reason the "Aurora premium" for a small app is rarely just the instance-hour difference.

Backups, snapshots, and the free 100% allowance

Both engines treat backups identically as a policy: automated backup storage equal to 100% of your provisioned database size (RDS) or your database cluster size (Aurora) is free per Region, and snapshots taken within your configured retention window don't cost anything on top of that. This is one of the few places small-app owners can stop worrying entirely — a default backup setup on either engine, sized to a small dataset, essentially costs nothing extra.

Where it starts costing money on either engine: extra manual snapshots beyond your retention window, keeping snapshots after you delete the instance or cluster, or cross-Region snapshot copies (which incur data-transfer charges for the copy, then standard storage charges to keep it in the destination Region).

Free tier: what's actually free on each engine

The Free Tier terms differ by when you signed up for AWS, and it's worth checking which bucket you're in before you assume either database is free to prototype on.

RDS Free Tier

If you signed up for the AWS Free Tier before July 15, 2025, you get up to 12 months of free RDS usage on select single-AZ instances, up to 750 hours per month (aggregated across instance types if you run more than one), plus 20 GB of General Purpose SSD storage and 20 GB of automated backup storage per month — available on MySQL, MariaDB, PostgreSQL, or SQL Server Express Edition. If you signed up after that date, you instead choose a Free Plan or Paid Plan, either offering $100 in credits plus up to $100 more for activating foundational AWS services, valid for 12 months.

Aurora Free Tier

New AWS customers can start with Aurora PostgreSQL serverless at no cost under the Free Tier: the $100 (plus up to $100 additional) credit applies here too, and the Free Plan specifically grants access to Aurora PostgreSQL serverless instances up to 4 ACUs and 1 GiB of storage per cluster. Upgrading to the Paid plan raises that ceiling to 256 ACUs and storage auto-scaling up to 256 TiB. Notably, Aurora's free-tier path is Aurora PostgreSQL serverless specifically — not Aurora MySQL, and not provisioned Aurora instances.

Two small-app scenarios, priced by the components that matter

Exact instance-hour prices move by Region and by AWS's own list-price updates, so rather than print a single dollar figure that could be stale by the time you read this, here's how the components stack up against each other for two shapes of small app, with the parts AWS's own pricing pages give exact numbers for worked out in full.

Scenario 1: Jake's repair-ticket app — steady, low traffic, single instance

One small burstable instance, single Availability Zone, 20 GB of storage, modest read/write volume that rarely spikes CPU above baseline. On RDS: instance-hour cost at the burstable class's base rate, storage billed for the full 20 GB provisioned, no per-request I/O charge, backup free within the 100% allowance. On Aurora Standard: a higher instance-hour rate for the same instance class, storage billed only for actual data used (likely less than 20 GB, so a partial offset), plus a per-million-request I/O charge that RDS simply doesn't have — and if Jake's nightly inventory sync pushes CPU over baseline for around 100 vCPU-hours a month, that's the $7.50-versus-$9.00 CPU credit gap worked out above, on top of everything else. For this shape of app, RDS wins on total cost in effectively every case, because the storage savings from Aurora's pay-per-use model are too small at this scale to offset the compute, credit, and I/O premium stacked together.

Scenario 2: a side-project app with unpredictable, spiky traffic

Traffic that's near-zero most of the week and spikes hard during a specific window (a weekend sale, a newsletter send, a demo). Here, a fixed-size instance on either engine means paying for peak capacity around the clock. Aurora Serverless v2 changes the comparison, and AWS's own worked example shows exactly how the ACU math plays out: a workload that needs 5 ACUs and runs for 30 minutes, scaling instantly up from a 0.5 ACU floor and back down again in about three minutes, costs $0.33 in compute under Aurora Standard or $0.43 under Aurora I/O-Optimized for that single burst. Run a handful of bursts like that across a week instead of holding a fixed instance online 24/7, and the total can undercut even the cheapest fixed instance — the lower your average utilization between spikes, the more that per-second, scale-to-0.5-ACU billing wins. This is the one small-app pattern where Aurora's pricing model, not just its architecture, can genuinely come out ahead.

Reserved Instances, Savings Plans, and Aurora Serverless v2

Once you've settled on a fixed instance for either engine and you're confident it'll run long-term, committing to it can cut the compute portion of your bill meaningfully — but the discounts differ between the two services.

Reserved Instances (both engines)

RDS Reserved Instances (1-year or 3-year terms, with No Upfront, Partial Upfront, or All Upfront payment options) can save up to 69% over on-demand rates in steady state, per AWS's own RDS pricing page. Aurora's Reserved Instances, on the same three payment structures, are quoted separately: up to 45% off for a 1-year term and up to 66% off for a 3-year term compared to Aurora on-demand pricing. Both offer size flexibility — your discount applies across instance sizes within the same family (like T3 or R5) — but RIs never cover storage, I/O, or backup costs on either engine, only compute.

Database Savings Plans (both engines)

Rather than reserving a specific instance, a Database Savings Plan commits you to a dollar-per-hour spending level across eligible RDS and Aurora usage for a 1-year term, in exchange for a lower effective rate — useful if you expect your instance size to change but want the commitment discount anyway.

Aurora Serverless v2 — no long-term commitment needed to save

Serverless v2 doesn't have its own Reserved Instance mechanism in the same way, because there's no fixed instance to reserve — you're already only paying for the ACUs you consume, per second, with fine-grained scaling down to 0.5 ACU increments. Its savings case comes from matching capacity to demand automatically, not from a multi-year commitment.

When Aurora is worth it even for a small app

Ethan's rule of thumb for Jake: "Don't ask whether Aurora is more expensive — it usually is, at your scale. Ask whether the thing Aurora is good at is a thing you actually need." Three genuine cases where it is, even at small scale:

• You need multiple read replicas and want them sharing one storage volume instead of each replica carrying its own separately-provisioned RDS storage.
• Failover time is a business requirement, not a nice-to-have — Aurora's replicas are built to fail over faster than RDS's standby promotion in a Multi-AZ deployment.
• Your traffic is genuinely unpredictable — not just "small," but spiky in a way that makes provisioning a fixed instance a constant guessing game. This is the Aurora Serverless v2 case from the scenarios above.

If none of those describe your app today, the honest answer is that you're paying the Aurora premium for insurance against a scaling problem you don't have yet — which can be a reasonable choice if you expect to need it soon, but isn't a cost-optimization decision.

RDS Extended Support: the surprise bill on old engine versions

This applies to both RDS and Aurora, and it's the charge that blindsides small-app owners who set up their database years ago and never touched the engine version again. Amazon RDS Extended Support lets you keep running a MySQL or PostgreSQL major version after that version's community end-of-life, in exchange for a per-vCPU-hour fee — for provisioned instances on Aurora, RDS for MySQL, and RDS for PostgreSQL, and per-ACU-hour for Aurora Serverless v2. The fee is date-dependent and rises over time: AWS's own worked example shows a PostgreSQL 12 instance in US East (Ohio) charged $0.100 per vCPU-hour for the first two years past end-of-standard-support, then $0.200 per vCPU-hour starting in year three — double.

You start being charged the day after your engine's major-version end-of-standard-support date, on top of your normal instance, storage, and backup charges, and it applies to every instance running that version, including Multi-AZ standbys and read replicas. You stop it entirely by upgrading to a version still in standard support, or by deleting the instance.

The decision, in one table

Jake ended up on RDS for PostgreSQL, single instance, 20 GB gp3 storage, single Availability Zone for now. Ethan's closing argument won it: "You can migrate to Aurora later if you actually grow into needing it. You can't easily un-spend the premium you paid while you didn't."

If you do outgrow RDS and want to move to Aurora later

1. Confirm engine compatibility. Aurora MySQL and Aurora PostgreSQL are compatible with their respective RDS engines, but always check the current supported version list before committing to a migration path.
2. Take a snapshot of your RDS instance. This is your rollback point if anything goes wrong during migration.
3. Restore that snapshot into a new Aurora cluster rather than migrating live data directly — this keeps your original RDS instance untouched and running while you validate the new Aurora cluster.
4. Point your application at the new Aurora cluster's endpoint only after you've validated queries, indexes, and any engine-specific extensions behave identically.
5. Decide on Aurora Standard vs. I/O-Optimized based on your actual I/O volume once you have real usage data from the new cluster, not a guess made before migrating.

Frequently asked questions

Is Amazon Aurora always more expensive than Amazon RDS?

No, but for a small, steady-traffic app it usually is, mainly because of Aurora's higher CPU credit rate on burstable instances and its per-request I/O charge under the Standard configuration — two costs RDS's General Purpose SSD storage simply doesn't have. Aurora can beat RDS for spiky, unpredictable traffic via Serverless v2, or at larger scale with multiple read replicas.

What is the actual price difference between RDS and Aurora for a small app?

The exact dollar gap depends on your Region and instance class and should be checked in the AWS Pricing Calculator, but the documented structural gaps are: a 20% higher CPU credit rate on Aurora's T-class instances compared to RDS for PostgreSQL (for example, $9.00 versus $7.50 for 100 vCPU-hours of overage), plus a per-million-request I/O charge on Aurora Standard that RDS's General Purpose SSD storage doesn't bill separately.

Does Aurora charge for storage differently than RDS?

Yes. RDS bills for storage you provision upfront, whether you use all of it or not. Aurora bills per GB-month for storage you actually consume, and it scales automatically without you provisioning anything — in US East (N. Virginia), that's $0.10 per GB-month under Aurora Standard or $0.225 per GB-month under Aurora I/O-Optimized, per AWS's own pricing examples.

What are Aurora I/O charges and can I avoid them?

Under Aurora Standard, every read and write I/O operation against your storage is metered per million requests and billed separately from compute and storage. You avoid this specific charge by switching your cluster to the Aurora I/O-Optimized configuration, which raises instance and storage rates by roughly 30% (per AWS's own db.r6i.large example: $0.29/hr Standard versus $0.377/hr I/O-Optimized) but charges $0 for read and write I/O — or by staying on RDS's General Purpose SSD storage, which doesn't have a per-request I/O charge at all.

Is Aurora Serverless v2 cheaper than RDS for a small app?

It depends on how idle your app is most of the time. Serverless v2 scales down to as little as 0.5 ACU, billed per second — AWS's own worked example prices a 5-ACU burst lasting 30 minutes, with a 3-minute scale-down, at $0.33 total under Aurora Standard or $0.43 under I/O-Optimized. An app that's mostly idle with occasional traffic spikes like that can end up paying less than a fixed RDS instance sized to handle those spikes around the clock. For steady, always-on traffic, a fixed RDS instance is usually still cheaper.

Do RDS and Aurora both have a free tier?

Yes, but the terms differ by when your AWS account was created. Pre-July 15, 2025 accounts get 12 months of free RDS usage on select single-AZ instances with up to 750 hours per month, 20 GB of gp2 storage, and 20 GB of backup storage. Newer accounts get $100 in credits (plus up to $100 more) for 12 months across eligible services, and Aurora's specific free path is Aurora PostgreSQL serverless, up to 4 ACUs and 1 GiB of storage under the Free Plan.

What happens to my bill if I stop my database instance overnight?

On both RDS and Aurora, stopping (not deleting) an instance stops instance-hour billing, but you are still charged for provisioned storage and any backup storage within your retention window. To eliminate all charges, you have to delete the instances and any associated snapshots.

Are Reserved Instances worth it for a small app?

If you're confident the instance will run long-term at a stable size, yes — RDS RIs can save up to 69% over on-demand in steady state, and Aurora RIs offer up to 45% off for a 1-year term or up to 66% off for a 3-year term. Neither RI covers storage, I/O, or backup costs, and neither covers CPU credit overages, so they only discount the compute portion of your bill.

What is Aurora I/O-Optimized and should a small app use it?

It's a cluster-level configuration that trades higher instance and storage rates for zero per-request I/O charges — about 30% more on compute, per AWS's own example. AWS's own guidance says it pays off once I/O would otherwise exceed 25% of your total Aurora spend. Most small, low-traffic apps don't generate enough I/O volume to cross that threshold, so Aurora Standard — or RDS entirely — is usually the better fit.

Does Aurora cost more because of CPU credits?

Partly, yes. Aurora's T4g/T3 CPU credit overage rate is $0.09 per vCPU-hour, versus $0.075 per vCPU-hour on RDS for PostgreSQL — a 20% higher rate for the identical scenario of exceeding your instance's CPU baseline. On 100 vCPU-hours of overage in a month, that's $9.00 on Aurora versus $7.50 on RDS. This only matters if your app's average CPU crosses baseline over a rolling 24 hours; genuinely bursty, brief spikes usually don't trigger it on either engine.

Will I get hit with RDS Extended Support charges?

Only if you're running a MySQL or PostgreSQL major version past its community end-of-standard-support date, on either RDS or Aurora. The charge is per vCPU-hour (or per ACU-hour for Aurora Serverless v2), starts the day after end-of-standard-support, and roughly doubles after the first two years — AWS's own example shows $0.100 per vCPU-hour rising to $0.200 per vCPU-hour in year three for PostgreSQL 12. Upgrading to a version still in standard support stops it.

Can I switch from RDS to Aurora later without starting over?

Yes. The standard path is to take a snapshot of your RDS instance and restore it into a new Aurora cluster, then validate before switching your application's connection endpoint. This keeps your original RDS instance running as a fallback throughout the migration.

Does Multi-AZ double my costs on both RDS and Aurora?

On RDS, a Multi-AZ deployment with one standby roughly doubles your instance-hour cost, since you're running a second, identically-sized standby instance; cross-AZ replication traffic between primary and standby is free. Aurora's storage is already replicated across three Availability Zones as part of its architecture, and you're billed for one copy of the data — but adding Aurora read replicas for high availability still means paying instance-hours for each replica instance.

Which one is cheaper for a side project or MVP?

For steady, low traffic, RDS on the Free Tier or a small burstable instance is almost always the cheaper starting point, since it avoids Aurora's CPU credit premium and per-request I/O charges entirely. If your MVP's traffic pattern is genuinely spiky and mostly idle between bursts, it's worth pricing out Aurora Serverless v2 as well before deciding.

Do backups cost extra on RDS or Aurora?

Not by default, on either engine. Automated backup storage up to 100% of your database's provisioned size (RDS) or cluster size (Aurora) is free per Region, and snapshots inside your retention window don't cost anything additional. Extra manual snapshots beyond that allowance, or snapshots kept after deleting the instance, are billed per GB-month.

How do I get an exact price instead of an estimate?

Use the AWS Pricing Calculator for RDS or Aurora, enter your Region, instance class, storage size, and deployment type (Single-AZ, Multi-AZ, provisioned, or serverless), and it will return a current, region-specific estimate — which is more reliable than any fixed dollar figure printed in an article, since AWS updates list prices over time.

Also Read:

• What Is Amazon DynamoDB? NoSQL in Plain English
• What Is Amazon S3? Cloud Storage Explained in Plain English
• AWS costs: The NAT gateway bill - the $32/month nobody planned
• AWS costs: DynamoDB on-demand vs provisioned - the crossover math

• AWS costs: Data transfer pricing - the map of what is free and what is not

•  AWS costs: CloudWatch Logs ingestion - the log bill that outgrew the app

Revision note. Written September 2026, covering current Amazon RDS (MySQL, PostgreSQL) and Amazon Aurora (MySQL-Compatible, PostgreSQL-Compatible) On-Demand, Reserved Instance, and Aurora Serverless v2 pricing structures as published on AWS's own pricing pages. AWS updates list prices and free-tier terms periodically, so check the AWS Pricing Calculator for your Region before committing to an instance size. If you've been staring at two pricing pages trying to figure out which number actually applies to your small app, you're not missing something obvious — the two services genuinely bill differently, and now you know exactly where, is what i hope, happy learning!.