Skip to content

PLANETSCALE 2024-02-15

Read original ↗

PlanetScale — Amazon Aurora Pricing: The many surprising costs of running an Aurora database

Summary

PlanetScale's Brian Morrison II walks through the eight cost axes of an Amazon Aurora cluster — instance type ( burstable vs memory-optimized, reserved instances), cross-AZ replicas for production, Aurora's dedicated- storage-appliance billing model (standard vs I/O-optimized), data transfer (cross-AZ, cross-region, and the Global database per-million- write + replication surcharges), RDS Proxy as a paid connection-pooling layer, blue/green deployment cost-doubling, backups (automated free-tier minus current-DB-size + manual snapshots), and monitoring (CloudWatch defaults + Enhanced Monitoring + Performance Insights). The second half contrasts each axis with PlanetScale, which bundles the cross-AZ-replica + connection-pooling + read-replica-based-change-application + automated-backup + monitoring stack into the per-instance price. The post's enduring architectural substance is the inventory of cost axes that follow from Aurora's distributed-storage architecture — and the canonical wiki introduction of several Aurora + RDS-Proxy + blue/green primitives that this wiki previously lacked.

Key takeaways

  • Aurora's pricing surface is a direct readout of its architecture. Aurora decouples compute from a distributed storage appliance that auto-scales blocks and replicates across three AZs. That architecture produces two storage SKUs (standard = pay-for-bytes + pay-per-IOPS; I/O-optimized = uplifted instance rate, no per-IOPS charge) plus a **per-AZ

  • per-region data-transfer surface. Morrison's rule of thumb: "Cost savings generally start to appear when your I/O charges exceed 25% of your total Aurora bill" — the canonical break-even for the standard-vs-I/O-optimized choice. (Source: sources/2024-02-15-planetscale-amazon-aurora-pricing-surprising-costs)

  • Instance types split into burstable vs memory-optimized, and only memory-optimized is production-recommended. Morrison: "Burstable instance types offer some cost advantages because Amazon runs them with fewer allocated resources during typical load while allowing them to 'burst' when higher demand hits for a limited amount of time. This is in contrast to memory-optimized instance types that consistently run at what they are advertised. Because the performance of burstable instances is relatively inconsistent when compared to memory-optimized, Amazon does not recommend them for production workloads." Price scale is dramatic: db.x2g.large 2 vCPU / 32 GiB = $0.377/hr, db.x2g.4xlarge 16 vCPU / 256 GiB = $3.016/hr, db.x2g.16xlarge 64 vCPU / 1024 GiB = $12.064/hr — linear scaling along memory- optimized sizes.

  • Cross-AZ replicas are effectively mandatory — and multiply the compute bill. "It is a best practice for all production databases to have at least one replica of the same instance type attached to the Aurora cluster but in a different AZ. Replicas are required for quicker failover in case the writer node goes offline. Replicas can also be used to help reduce downtime while rolling out required Aurora instance modifications that require restarts." For high-criticality workloads Morrison recommends one primary + two replicas across three AZs; "this effectively multiplies the costs of your selected instance type by the number of replicas you opt to have." Canonical wiki concepts/cross-az-replica-cost datum — the availability-cost floor on Aurora.

  • Aurora storage billing model is structurally distinct from EBS-backed RDS. "In Amazon Aurora, storage works a bit differently when compared to RDS or even configuring your own database cluster on AWS using EC2. Those configurations store your data on underlying EBS volumes and provide a number of choices. On the other hand, Aurora uses dedicated storage appliances that auto-provision 'blocks' of data to store your data. This enables Amazon to auto-scale your storage without you having to worry about running out of space." Result: no EBS-style per-volume IOPS / throughput / volume-type choice; instead a single binary choice at cluster-creation — Standard Storage (pay-for-GB + pay-per-IO) or I/O-Optimized Storage (higher instance price, zero per-IO charge). This is the canonical wiki disclosure of Aurora's storage-as-service billing model distinct from EBS's provisioned-volume model.

  • Data transfer has a wide cost surface. "Amazon charges for data transfer in many scenarios, whether that's between availability zones within a region, between regions themselves, or even exiting the public internet." Free zones: intra-region replication + Aurora ↔ EC2 in the same AZ. Everything else incurs per-GB charges — cross-AZ (within region), cross-region, egress-to-internet. Canonical wiki concepts/data-transfer-cost-surface introduction — same principle applies to every AWS service, but Aurora surfaces it as a database-specific cost axis because replicas live in other AZs by design.

  • Aurora Global Database is the cross-region read-replica cluster primitive — and carries per-million-write + data-transfer costs on top of compute + storage. "Global database allows you to have a separate read-only Aurora cluster that your data will be replicated to. Each region is independently scalable, so understanding the compute requirements for that region and selecting an appropriate instance type can help optimize costs … Amazon charges additional fees per 1 million write operations performed, as well as standard data transfer costs to replicate data between regions." Canonical wiki instance of patterns/global-read-replica-cluster — the three-layer cost model (compute + storage + replication fees) is the pattern's defining characteristic.

  • RDS Proxy is a paid connection- pooling layer that also speeds up failover. "AWS offers RDS Proxy as a lightweight proxy layer between your database clients and writer/reader compute nodes. RDS Proxy will perform connection pooling as well to better manage the resources consumed by the compute nodes. In the case of a node outage, RDS Proxy can also more quickly detect the outage and redirect traffic to another node without dropping client connections. This is an additional service on top of Aurora and thus incurs an additional charge on your AWS bill." Canonical wiki disclosure of RDS Proxy's dual role (pool + fast-failover) as a paid add-on — the same functional surface PlanetScale bundles into Vitess's vtgate (systems/vitess) or PgBouncer-inside-proprietary- proxy (systems/pgbouncer) for free.

  • Blue/green deployment doubles compute cost during the window + requires manual cleanup. "Many changes to your database will require your instances to be rebooted, which will incur some downtime while the operation is performed… Amazon recommends using blue/green deployments to make various database configuration changes, such as performing version updates or making schema changes. The process of redirecting traffic is known as a switchover, and while all connections will still be dropped during the switchover, the downtime is reduced." Cost shape: "your compute costs (selected instance type and replica count) will double while both environments are online. In addition to this, Amazon does not remove the old environment after a switchover and requires that you manually remove it before your bill goes back to normal." Canonical wiki patterns/blue-green-db-deployment — distinct from blue/green service-mesh migration (that's edge-traffic-shifting for stateless services); this is database-engine-version / schema-change / parameter-change cutover that still drops connections at switchover but reduces downtime vs in-place.

  • Backups have a two-track billing model. Automated backups: "you are charged for the amount of storage you use (in GB) minus the latest size of your database. This allows you to have one full backup at no charge, but you will be charged for any subsequent incremental backups." Manual snapshots: "these snapshots are not part of the automated system and are retained even if your database is deleted. Charges for manual snapshots are based on the size of the snapshot." Canonical wiki concepts/backup-storage-billing — distinct from object-store snapshot pricing because the "free current-DB size" carve-out is Aurora-specific.

  • Monitoring stack has three tiers — default CloudWatch metrics (free) + Enhanced Monitoring (CloudWatch Logs billing) + Performance Insights (retention-based billing). "Amazon Aurora will send a wide array of metrics to CloudWatch every minute for both the cluster and each individual instance at no extra cost… To get this information in real time, you can use Enhanced Monitoring as a service add-on. Enhanced Monitoring uses CloudWatch Logs, which are charged based on how much data is sent into CloudWatch each month… Performance Insights allows you to gather data from the actual database engine, giving you information that the MySQL process sees such as database load and query performance. Performance Insights bills based on how long you wish to retain the data, up to two years. The first seven days are included at no additional cost." Canonical three-tier disclosure of Aurora's monitoring cost model.

  • PlanetScale's counter-positioning collapses the cost surface. Morrison's PlanetScale-side framing for each Aurora cost axis: (a) instance types: no burstable / memory-optimized split; cluster price is per-instance- type and already includes 3-AZ replication; (b) storage: no standard / I/O-optimized split; Metal includes unlimited IOPS by default; (c) data transfer: zero customer-facing data transfer cost (exception: PlanetScale Managed in-customer-VPC = AWS-native transfer costs apply); (d) cross-region replicas: free read-only regions, same instance-type-spec as primary; (e) connection pooling: vtgate (MySQL/Vitess) or PgBouncer (Postgres) bundled at no additional charge, supporting "a nearly unlimited number of connections"; (f) operational cutover: rolling upgrades on Kubernetes pods via vtgate traffic redirection "completely automated and does not require any downtime" — no blue/green cost-doubling for version upgrades; database branches + deploy requests for schema changes without cluster duplication; (g) backups: 12-hour automated schedule included with paid plans, additional schedules + manual snapshots billed separately; (h) monitoring: Insights included with all databases, 7-day retention on Base plan + customizable retention on Enterprise. Canonical wiki patterns/simplified-pricing-surface instance — trade Aurora's per-axis controllability for collapsed billing.

Systems / concepts / patterns extracted

  • Systems

    • systems/amazon-aurora — extended with the pricing-architecture framing: storage model, replica model, data-transfer surface.
    • systems/aws-rds — contrast: EBS-backed per-volume choices vs Aurora's dedicated-storage-appliance model.
    • systems/aws-rds-proxy — new system page. Connection pooling + fast-failover proxy as a paid add-on on top of Aurora / RDS.
    • systems/aurora-global-database — new system page. Cross-region read-replica cluster primitive.
    • systems/aws-cloudwatch — monitoring substrate for Aurora's default metrics + Enhanced Monitoring surface.
    • systems/vitess + vtgate — functional equivalent of RDS Proxy, bundled into PlanetScale MySQL.
    • systems/pgbouncer — pooling for PlanetScale Postgres, bundled inside the proprietary proxy.
    • systems/planetscale-metal — PlanetScale's no-per- IOPS-charge counterpart to Aurora's I/O-Optimized SKU.

  • Concepts

  • Patterns

    • patterns/blue-green-db-deployment — new canonical wiki pattern. Stand up an identical DB environment, apply changes off-traffic, switchover drops connections but reduces downtime vs in-place change; doubles compute cost during the window and requires manual cleanup of the old environment.
    • patterns/global-read-replica-cluster — new canonical wiki pattern. Read-only replica cluster in a second region for locality; three-layer cost model (compute + storage + per-write + transfer).
    • patterns/vtgate-as-rds-proxy-equivalent — new canonical wiki pattern. When the sharding proxy already does connection pooling + fast failover, bundling RDS-Proxy-equivalent function eliminates the per-connection cost axis.
    • patterns/simplified-pricing-surface — new canonical wiki pattern. Trade per-axis controllability for collapsed-billing predictability; canonical instance is PlanetScale-vs-Aurora across eight axes.

Operational numbers

  • Instance prices (memory-optimized db.x2g family, Aurora MySQL, quoted verbatim):
    • db.x2g.large — 2 vCPUs, 32 GiB, $0.377/hr.
    • db.x2g.4xlarge — 16 vCPUs, 256 GiB, $3.016/hr.
    • db.x2g.16xlarge — 64 vCPUs, 1024 GiB, $12.064/hr.
  • I/O-Optimized storage break-even: "Cost savings generally start to appear when your I/O charges exceed 25% of your total Aurora bill."
  • Production replica count: 1 primary + ≥1 replica (same instance type, different AZ) recommended; 1 primary
  • 2 replicas across 3 AZs for high-criticality.
  • Reserved-instance term lengths: 1 year or 3 years.
  • CloudWatch default metric publish cadence: every minute (no extra cost).
  • Performance Insights free retention: first 7 days; additional retention up to 2 years billed.
  • PlanetScale defaults: 3-AZ replication bundled, unlimited IOPS on Metal, zero data-transfer cost except PlanetScale Managed, 12-hour automated backups free on paid plans, 7-day Insights retention on Base + custom on Enterprise.

Caveats

  • Scope: Aurora (provisioned), not Aurora Serverless. "The information provided in this article is specific to Aurora and not Aurora Serverless. Aurora Serverless is a different configuration that has its own pricing model." Autoscaled-serverless + Aurora DSQL + Aurora Limitless all have different pricing shapes not covered.
  • Pricing snapshot dated February 2024. Per-hour rates and specific SKU availability may have moved; structural axes (storage SKUs, replica multiplier, Global Database fee shape, RDS-Proxy-as-add-on, blue/green cost-doubling, backup-storage carve-out, monitoring tiers) are more stable than the numbers.
  • Vendor-posture post. PlanetScale has commercial interest in framing Aurora's pricing surface as complicated and PlanetScale's as simple. The architectural primitives named are accurate but the framing is advocacy. Treat the cost-axis inventory as load-bearing wiki content; treat the PlanetScale- collapses-them side as marketing.
  • No concrete dollar savings numbers. Morrison doesn't disclose a worked-example bill (e.g. "$X on Aurora maps to $Y on PlanetScale for workload Z"). The cost-architectural argument is structural, not numeric.
  • I/O-Optimized break-even number not empirically derived. The "25% of total bill" rule is a rule of thumb, no calculation shown — customers must verify against their own workload mix.
  • Connection-pool sizing not quantified. "A nearly unlimited number of connections" on PlanetScale is a marketing claim; no specific connection-count upper bound or backing-pool-size disclosure. The RDS Proxy side also lacks connection-count disclosure in the post.
  • Global Database replication-latency figures not disclosed. Only the cost shape of Global Database is covered; replication lag (historically ~1 sec for Aurora Global) is out of scope.
  • Backup RTO/RPO not discussed. Post covers backup billing only — no recovery-objectives, no point-in-time-recovery window, no stop-db-cluster / manual-pause interaction.
  • Performance Insights retention-cost formula not disclosed. "Bills based on how long you wish to retain the data" — no price-per-GB-month or price-per-day-of-retention numbers.
  • Blue/green mechanism details not disclosed. The post names the cost + switchover downtime shape but not the underlying AWS mechanism (RDS Blue/Green Deployments service launched GA 2022, uses logical replication to stage the green env and RENAME TABLE for cutover on MySQL; not described here).
  • Tier-3 source. PlanetScale first-party vendor- comparison post. Architectural substance concentrated in the Aurora half (storage architecture, replica topology, blue/green, Global Database, RDS Proxy); PlanetScale half is product-pitch with architectural-trade-off framing. Per companies/planetscale.md skip-rule "'Introducing…' / pricing announcements — skip unless there is a substantive architecture section alongside the announcement", this post clears on the basis that the Aurora pricing-architecture inventory is itself substantive: it canonicalises primitives (burstable-vs-memory-optimized, I/O-Optimized-vs-Standard storage, cross-AZ replica multiplier, Global Database's per-write fee, RDS-Proxy-as-add-on, blue/green cost-doubling, backup billing, Performance Insights retention tiers) that the wiki otherwise lacks a canonical source for — regardless of PlanetScale's framing.

Source

Last updated · 319 distilled / 1,201 read