Amazon RDS vs Amazon EC2 for Magento
When hosting Magento on AWS, RDS is often assumed to be the default database.
At luroConnect we do not use RDS and have saved thousands of dollars a month for many of our customers. This write-up on RDS vs EC2 is focussed on Magento, and was born out of migrating a customer from RDS to EC2.
The story was interesting. As we onboarded the customer over a year ago, the agency insisted that we use RDS. We had calls trying to convince them we could handle the database on EC2. The Magento database was over 500GB, with a lot of products and around 1,000 orders a day.
A year later, we were asked to see how we could reduce the AWS costs, and the RDS costs stuck out very prominently. An RDS instance plus a read-only replica for a busy website can cost a lot! The agency was ready to try, provided we gave them a near-zero-downtime transition and a near-zero-downtime rollback to RDS.
The feedback when we moved to EC2? “We find uncached pages are served faster.”
The migration learnings will lead to more articles, but this one focusses on the argument of why we use EC2 instead of RDS for Magento. Needless to say, we have built the devops tools and processes that make this decision a no-brainer if you host on luroConnect.
“Since it is expensive and popular, it must be better”
… said my 10 year old. But everyone says this about AWS RDS, without batting an eyelid.
It is about marketing, isn’t it? A feature you can sell at a premium, a feature not easy for competitors to emulate, a feature you may never use!
RDS is one of them. Anyone with or without having worked with AWS tells me it is a no-brainer to use RDS for your MariaDB database, in our case for Magento websites. No questions, no arguments. I do get into arguments, and I am shown AWS documentation.
Of course RDS has features not easy to emulate. But AWS has been good in its documentation, so for those who care to read, it is possible to replicate them, at least where it matters.
What RDS gives you
RDS, from my perspective, has these features:
- Easy to change configuration values. The UI tells you clearly which parameters need a restart and which don’t. In any case, you expect the change is committed so a restart will retain it. The last bit is crucial, especially when a restart is not needed: you make a change in a parameter and forget to commit it. A restart, and you lose your change.
- Atomic writes, not needing “double write buffers”. What are double write buffers? “This buffer was implemented to recover from half-written pages. This can happen in case of a power failure while InnoDB is writing a page (16KB = 32 sectors) to disk. On reading that page, InnoDB would be able to discover the corruption from the mismatch of the page checksum. However, in order to recover, an intact copy of the page would be needed.” Double write buffers are for safety, but lead to a performance issue: “Both the checksum calculation and the double writing consume time and thus reduce the performance of page flushing. The effect becomes visible only with fast storage and heavy write load.” For Magento this means websites with a large catalog and higher-IOPS disks. AWS RDS gives atomic writes. But AWS also documents how this can be implemented on EC2, in its guide to torn write prevention.
- Easy to create a read-only replica, reliably. If you have worked with MySQL / MariaDB, you know the issues with creating a read-only replica (slave). Lots of documentation, but when it actually comes to making a slave, there is always a doubt whether it will work. The key reason is getting a consistent snapshot or backup. Even using AWS snapshots, we have not found a way to do this reliably and without downtime: either create a write lock, take (or start) a snapshot and release the lock, or stop MySQL, take (or start) a snapshot and restart MySQL. Taking an RDS slave, on the other hand, seems to work without downtime. Alternatively, a backup strategy also requires some locking, provided in the MySQL command line. When using a backup as the strategy we have always found it better to take backups when indexing or setup upgrade is not running.
- Quicker at making the slave. AWS RDS is also quicker in making the slave, even though we may use a snapshot strategy. AWS snapshots can take time based on the size of the (occupied) disk. For large disks it can take long.
- Easy to add a proxy. Again, it is just an option to select and a proxy starts. There is no need to configure CPU/RAM for the proxy. However, there is no guide to tell you a proxy will give a performance improvement.
The flip side: cost
But let us look at the flip side, costs. This was part of an analysis we did for an existing customer in June 2025. If you use RDS the only savings option is a Reserved Instance. EC2 gives a “lighter” commitment with a Savings Plan. (RDS estimate is for single AZ, no proxy. All disks are 12,000 IOPS, 500 Mbps. All in the Ohio region. All figures are US$ per month.)
An illustrative pricing comparison
| Server | Instance type | On demand | 1 yr reserved |
|---|---|---|---|
| RDS master | db.r8g.12xlarge (48 core, 384GB memory, 1500GB disk) | 4,780 | 3,420 |
| RDS slave | db.r8g.4xlarge (16 core, 128GB memory, 1500GB disk) | 1,720 | 1,250 |
| RDS total per month | 6,500 | 4,670 | |
| EC2 master | r8g.12xlarge (48 core, 384GB memory, 1500GB disk) | 2,250 | 1,545 |
| EC2 slave | r8g.4xlarge (16 core, 128GB memory, 1500GB disk) | 850 | 635 |
| EC2 total per month | 3,100 | 2,180 |
A 50% month-on-month cost difference cannot be ignored!
What does it cost you? A few seconds of downtime during slave creation, and an external proxy (we use ProxySQL on EC2) has to be set up and configured. Managing configuration values with discipline can be accomplished by a shell script, with knowledge of which values update dynamically and which do not. Values are always written to the my.cnf file, ensuring a restart will keep the new values.
Note: I have had many devops engineers swear RDS is faster. That has not been my experience, for the same configurations. Open to discussion on this topic. RDS Aurora is a different product, and a blog for later!