I promised to do a pricing post on the Amazon RDS Aurora MySQL pricing, so here we go. All pricing is noted in USD (we’ll explain why)
We compared pricing of equivalent EC2+EBS server instances, and verified our calculation model with Amazon’s own calculator and examples. We use the pricing for Australia (Sydney data centre). Following are the relevant Amazon pricing pages from which we took the pricing numbers, formulae, and calculation examples:
- Amazon EC pricing (on demand)
- Amazon EBS pricing
- Amazon RDS Aurora pricing (on demand)
- Amazon AWS calculator tool
Base Pricing Details
| Specs | EC2 | RDS Aurora MySQL | |||||||
| instance type | vCPU | ECU | GB RAM | Storage | Linux/hr | instance type | Price/hr | ||
| r4.large | 2 | 7 | 15.25 | EBS Only | $0.160 | db.r4.large | $0.350 | ||
| r4.xlarge | 4 | 13.5 | 30.5 | EBS Only | $0.319 | db.r4.xlarge | $0.700 | ||
| r4.2xlarge | 8 | 27 | 61 | EBS Only | $0.638 | db.r4.2xlarge | $1.400 | ||
| r4.4xlarge | 16 | 53 | 122 | EBS Only | $1.277 | db.r4.4xlarge | $2.800 | ||
| r4.8xlarge | 32 | 99 | 244 | EBS Only | $2.554 | db.r4.8xlarge | $5.600 | ||
| r4.16xlarge | 64 | 195 | 488 | EBS Only | $5.107 | db.r4.16xlarge | $11.200 |
That’s not all we need, because both EBS and Aurora have some additional costs we need to factor in.
EBS pricing components (EBS Provisioned IOPS SSD (io1) volume)
“Volume storage for EBS Provisioned IOPS SSD (io1) volumes is charged by the amount you provision in GB per month until you release the storage. With Provisioned IOPS SSD (io1) volumes, you are also charged by the amount you provision in IOPS (input/output operations per second) per month. Provisioned storage and provisioned IOPS for io1 volumes will be billed in per-second increments, with a 60 second minimum.”
- Storage Rate $0.138 /GB/month of provisioned storage
“For example, let’s say that you provision a 2000 GB volume for 12 hours (43,200 seconds) in a 30 day month. In a region that charges $0.125 per GB-month, you would be charged $4.167 for the volume ($0.125 per GB-month * 2000 GB * 43,200 seconds / (86,400 seconds/day * 30 day-month)).” - I/O Rate $0.072 /provisioned IOPS-month
“Additionally, you provision 1000 IOPS for your volume. In a region that charges $0.065 per provisioned IOPS-month, you would be charged $1.083 for the IOPS that you provisioned ($0.065 per provisioned IOPS-month * 1000 IOPS provisioned * 43,200 seconds /(86,400 seconds /day * 30 day-month)).”
Other Aurora pricing components
- Storage Rate $0.110 /GB/month
(No price calculation examples given for Aurora storage and I/O) - I/O Rate $0.220 /1 million requests
(Presuming IOPS equivalence / Aurora ratio noted from arch talk)
So this provides us with a common base, instance types that are equivalent between Aurora and EC2. All other Aurora instances types are different, so it’s not possible to do a direct comparison in those cases. Presumably we can make the assumption that the pricing ratio will similar for equivalent specs.
On Demand vs Reserved Instances
We realise we’re calculating on the basis of On Demand pricing. But we’re comparing pricing within AWS space, so presumably the savings for Reserved Instances are in a similar ballpark.
Other factors
- We have 720 hours in a 30 day month, which is 2592000 seconds.
- 70% read/write ratio – 70% reads (used to calculate the effective Aurora IOPS)
- 10% read cache miss -10% cache miss rate on reads
- Aurora I/O ratio: 3 (Aurora requiring 2 IOPS for a commit vs 6 in MySQL – even though this is a pile of extreme hogwash in terms of that pessimistic MySQL baseline)
We also spotted this note regarding cross-AZ Aurora traffic:
“Amazon RDS DB Instances inside VPC: For data transferred between an Amazon EC2 instance and Amazon RDS DB Instance in different Availability Zones of the same Region, Amazon EC2 Regional Data Transfer charges apply on both sides of transfer.”
So this would apply to application DB queries issued across an AZ boundary, which would commonly happen during failover scenarios. In fact, we know that this happens during regular operations with some EC2 setups, because the loadbalancing already goes cross-AZ. So that costs extra also. Now you know! (note: we did not factor this in to our calculations.)
Calculation Divergence
Our model comes up with identical outcomes for the examples Amazon provided, however it comes up 10-15% lower than Amazon’s calculator for specific Aurora configurations. We presume that the difference may lie in the calculated Aurora I/O rate, as that’s the only real “unknown” in the model. Amazon’s calculator does not show what formulae it uses for the sub-components, nor sub-totals, and we didn’t bother to tweak until we got at the same result.
It’s curious though, as the the architecture talk makes specific claims about Aurora’s I/O efficiency (which presume optimal Aurora situation and a dismal MySQL reference setup, something which I already raised in our initial Aurora post). So apparently the Amazon calculator assumes worse I/O performance than the technical architecture talk!
Anyhow, let’s just say our costing is conservative, as the actual cost is higher on the Aurora end.
Scenarios
Here we compare with say a MySQL/MariaDB Galera setup across 3 AZs running on EC2+EBS. While this should be similar in overall availability and read-capacity, note that
- you can write to all nodes in a Galera cluster, whereas Aurora currently has a single writer/master;
- Galera doesn’t require failover changes as all its nodes are technically writers anyhow, whereas Aurora failover causes a cluster outage of at least 30 seconds.
| Servers | R/Zones | Instance | GB DB | I/O rate | EC2 | EBS | Aurora | ||||||||
| Read IOPS | Instances | Storage | I/O | EC2 Total | Instances | Storage | I/O | Aurora Total | |||||||
| 3 | 3 | r4.xlarge | 250 | 2,000 | 740 | $689 | $104 | $160 | $952 | $1,512 | $83 | $141 | $1,735 | ||
| 6 | 3 | r4.xlarge | 250 | 2,000 | 740 | $1,378 | $207 | $320 | $1,905 | $3,024 | $83 | $141 | $3,247 | ||
When using the Amazon calculator, Aurora comes out at about double the EC2. But don’t take our word for it, do try this for yourself.
Currency Consequences
While pricing figures are distinct per country that Amazon operates in, the charges are always in USD. So this means that the indicated pricing is, in the end, in USD, and thus subject to currency fluctuations (if your default currency is not USD). What does this mean?
So USD 1,000 can cost as little as AUD 906 or as much as AUD 1,653, at different times over the last 10 years. That’s quite a range!
Conclusion
As shown above, our calculation with Aurora MySQL shows it costing about twice as much. This is based on a reference MySQL/MariaDB+Galera with roughly the same scaling and resilience profile (e.g. the ability to survive DC outages). In functional terms, particularly with Aurora’s 30+second outage profile during failover, Galera comes out on top at half the cost.
So when is Aurora cheaper, as claimed by Amazon?
Amazon makes claims in the realm of “1/10th the cost”. Well, that may well be the case when comparing with the TCO of Oracle or MS SQL Server, and it’s fairly typical when comparing a proprietary system with an Open Source based one (mind again that Aurora is not actually Open Source as Amazon does not make their source code available, but it’s based on MySQL).
The only other way we see is to seriously compromise on the availability (resilience). In our second sample calculation, we use 2 instances per AZ. This is not primarily for performance, but so that application servers in an AZ don’t have to do cross-DC queries when one instance fails. In the case of Aurora, spinning up a new instance on the same dataset requires 15 minutes. So, do you want to take that hit? If so, you can save money there. If not, it’s still costly.
But hang on, if you’re willing to make the compromise on availability, you could reduce the Galera setup also, to only one instance per AZ. Yep!
So, no matter how you tweak it, Aurora is about twice the cost, with (in our opinion) a less interesting failover profile.
The Price of RDS Convenience
What you get with RDS/Aurora is the promise of convenience, and that’s what you pay for. But, mind that our comparison worked all within AWS space anyway, the EC2 instances we used for MySQL/MariaDB+Galera already use the same basic infrastructure, dashboard and management API as well. So you pay double just to go to RDS/Aurora, relative to building on EC2.
To us, that cost seems high. If you spend some, or even all that money on engineering that convenience around your particular setup, and even outsource that task and its maintenance, you get a nicer setup at the same or a lower cost. And last but not least, that cost will be more predictable – most likely the extra work will be charged in your own currency, too.
Cost Predictability and Budget
You can do a reasonable ball-park calculation of AWS EC2 instances that are always active, but EBS already has some I/O charges which make the actual cost rather more variable, and Aurora adds a few more variables on top of that. I’m still amazed that companies go for this, even though they traditionally prefer a known fixed cost (even if higher) over a variable cost. Choosing the variable cost breaks with some fundamental business rules, for the sake of some convenience.
The advantage of known fixed costs is that you can budget properly, as well as project future costs based on growth and other business factors. Purposefully ditching that realm, while exposing yourself to currency fluctuations at the same time, seems most curious. How do companies work this into their budgets? Because others do so? Well, following the neighbours is not always a good idea. In this case, it might be costly as well as financially risky.