6

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?

Improve this question
4
  • Looking at this site, ec2instances.info/?filter=.large, 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
    Commented Mar 5, 2014 at 15:56
  • What database product are you running? Oracle, MySQL, and SQLServer all have different pricing structures independent of the instance size.
    – Bozojoe
    Commented Mar 6, 2014 at 23:54
  • BTW I don't see any of the db instances listed in ec2instances.info
    – Bozojoe
    Commented Mar 7, 2014 at 0:55
  • We're using MySQL
    – DOOManiac
    Commented Mar 7, 2014 at 16:13

2 Answers 2

Reset to default
7
+50

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.

Improve this answer
4
  • 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
    Commented Mar 7, 2014 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: aws.amazon.com/about-aws/whats-new/2012/07/31/… And yeah, if you're not using a PIOPS volume, then PIOPS optimisation is moot for the instance :)
    – neuro
    Commented Mar 8, 2014 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
    Commented Mar 8, 2014 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
    Commented Jun 16, 2014 at 17:33
4

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

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .