Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Recently, Amazon announced new instance types for RDS.

Currently, we are running db.m1.large, and it looks like the new db.m3.large is comparable but cheaper.

Before moving these over, I wanted to double check with you guys that there are no hidden "gotchas" I'm not seeing. Are there any reasons not to move our instances to the new, cheaper, faster instance type?

share|improve this question
Looking at this site,, it looks like the new m3.large instances only support 32GB? Or maybe that's only for EC2 non-EBS instances? Also, it doesn't look like m3.Large is EBS optimized? (Not sure if we are already taking advantage of that w/ the current instance or not...) – DOOManiac Mar 5 '14 at 15:56
What database product are you running? Oracle, MySQL, and SQLServer all have different pricing structures independent of the instance size. – Bozojoe Mar 6 '14 at 23:54
BTW I don't see any of the db instances listed in – Bozojoe Mar 7 '14 at 0:55
We're using MySQL – DOOManiac Mar 7 '14 at 16:13
up vote 7 down vote accepted

The only real cons I can see are:

  • lack of PIOPS optimisation for the db.m3.large (where you would have guaranteed bandwidth connecting you to EBS and PIOPS volumes)
  • smaller (albeit faster) instance/ephemeral storage for the m3.large (32GB SSD vs 2x 480GB HDD), and to be honest I'm not sure instance storage is relevant for RDS instances

And that's it. In return for these cons, you receive faster CPUs and lower prices.

I have already moved a standard m1.large instance running CentOS+MySQL slave (i.e. an EC2 instance, not an RDS instance) to an m3.large. The idle CPU floor dropped from around 6-7% to 1.5-2%, and peak loads are reduced from around 85-90% to 45-50%, simply by relaunching as an m3.large.

share|improve this answer
I'm currently not using PIOPS at all. (Should I be?) In this case, I'm guessing it doesn't matter if the instance type is not PIOPS-optimized, right? – DOOManiac Mar 7 '14 at 16:15
You only want PIOPS if you want a guaranteed level of IO performance, i.e. if you're running a heavily used database or hit a disk hard with reads and/or writes. More detail, as usual, on the AWS site:… And yeah, if you're not using a PIOPS volume, then PIOPS optimisation is moot for the instance :) – neuro Mar 8 '14 at 14:23
Oh, and I switched an m1.xlarge CentOS+MySQL instance to an m3.xlarge in the wee hours of this morning, and while Saturday load isn't quite an absolute indicator of performance change, CPU load on a reasonably trafficked DB server serving a busy website cluster is down by two thirds. The extra performance of the uprated Xeons is definitely worth the switch. – neuro Mar 8 '14 at 14:26
Point of order: In EC2, EBS-optimization applies to both Provisioned-IOPS and Standard EBS volumes. (RDS does not seem to make ebs-optimization available as an option when creating an DB Instance.) If this question was posed for EC2 instances, this would be an notable distinction to make, as applications with higher I/O would benefit from ebs-optimization even for EBS standard volumes. – Drew Jun 16 '14 at 17:33

according to the AWS RDS documentation db.m1.large is PIOPS-optimized, but db.m3.large is not

RDS Instance Classes

Standard - Second Generation db.m3.large

vCPU:2 ECU:6.5 Memory (GiB):7.5 PIOPS-Optimized:No Network Performance:Moderate

Standard - First Generation db.m1.large

vCPU:2 ECU:4 Memory (GiB)7.5 PIOPS-Optimized:Yes Network Performance:Moderate

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.