Author - Suma G

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 $ for many of our customers, each month. We wrote up a RDS vs EC2 focussed on Magento - born out of migrating a customer from RDS to EC2.

The story we had 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 db on EC2. The Magento database was over 500GB, with a lot of products and 1000ish orders a day.

However, a year later, we were asked to see how we could reduce the AWS costs. And the RDS costs stuck out very prominently. A RDS + a read only replica of a busy website can cost a lot! However, the agency was ready to try - provided we gave them a ~0 downtime transition and an option of ~0 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 devops tools and processes which makes this decision a no brainer if you host on luroConnect

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.

Ofcourse 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, at least where it matters.

RDS from my perspective, has these features:

• Easy to change configuration values. The UI tells you clearly what parameters need a restart and what don’t. In any case, you expect the change is committed so a restart will retain that. The last bit is crucial – especially when a restart is not needed. You make a change in a parameter and forget to commit. A restart and you lose your changes.

• 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 leads to 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 is websites with a large catalog and higher IOPs disks. AWS RDS gives atomic writes. But, AWS also documents how this can be implemented in EC2. Please click here to access the AWS documentation.

• Easy to create a readonly replica, reliably. If you have worked with mysql / mariadb, you know issues with creating a readonly replica (slave). Lots of documentation, but when it actually comes to making a slave, there is always a doubt if it will work. The key reason is getting a consistent snapshot or a backup. Even using AWS snapshot, we have not found a way to do this reliably and without downtime – either by creating a write lock, take (or start) a snapshot and release the lock or stop mysql, take (or start) a snapshot and restart mysql. Taking a RDS slave on the other hand seems to work without a downtime. Alternatively, a backup strategy also requires some locking – provided in the mysql command line. When using a backup as a strategy we have always found it better to take backups when indexing or setup upgrade is not running.

• AWS RDS is also quicker in making the slave – even though we may use a snapshot strategy. AWS snapshots can takes time based on the size of the (occupied) disk. For large disks it can take long.

Easy to add proxy Again it is just an option to select and a proxy starts. There is no need to configure CPU/RAM of the proxy. However, there is no guide to tell you a proxy will give a performance improvement.

But let us look at the flip side – costs. This was part of 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 savings plan. (RDS estimate is for single AZ, no proxy. All disks are 12000 iops, 500Mbps. All in Ohio region.)

A 50% month-on-month cost difference cannot be ignored!

A few seconds downtime during slave creation, an external proxy (we use proxysql on EC2) has to be set and configured. Managing configuration values with discipline can possibly accomplished by a shell script – with knowledge of what values are dynamically updating and which are not. Values are always written to the my.cnf file, ensuring a restart will keep new values.

NOTE: We have had many devops swear RDS is faster. That has not been my experience – for same configurations, etc. Open to discussion on this topic. RDS Aurora is a different product and a new blog for later!