When it comes to running MySQL or PostgreSQL on top of AWS, you’ve got three realistic options to choose from. Let’s figure out what works best for you.
I should preface this with a warning: If you’re running an existing large installation of databases on AWS, you can probably stop reading now.
There aren’t too many stories where migrating a large working database environment to a new service makes sense—and if you’re in the weird exception case, you already know what you’re doing and why.
1. Run your own databases on EC2 instances
This is the approach many folks take if they have either of these two primary concerns.
First, they want to retain fine-grained control over database settings, maintenance windows, and obscure edge cases of varying validity.
The second concern that drives this behavior is that this is pretty much how you ran things in an on-prem environment. The idea of handing over operational control of The Thing That Kills Your Company If It Breaks to a third party is a slight bridge too far for you to cross, and you want to retain your current flexibility.
Note that this also arises if you’re trying to avoid scaring your existing DBA staff into wondering what their three- to five-year career prospects look like (a concern that I understand, but don’t share; this field isn’t going away anytime soon!).
I’m not saying that this is a “wrong” approach. But it does increase the management overhead around things that aren’t adding business value to virtually any company’s endeavors.
2. Run RDS
This is the default “safe” option for most shops: a managed database with limited control that AWS runs for you. They handle replicas, backups (if you enable them!) and maintenance.
The economic story here is frankly mixed. You can fine-tune specific volumes and instances less finely than you can on top of EC2. But, on balance, there’s a lot less to worry about.
One notable caveat: maintenance windows.
AWS schedules maintenance over a standing weekly window. Be sure that this window is during a time when you can afford database downtime, or else make plans to migrate off of databases with pending maintenances automatically. There are scheduling options with AWS that make this more straightforward, but be warned that it’s not going to be a dance through the park.
3. Run Amazon Aurora
Aurora looks like RDS with built-in multi-AZ durability for the volumes backing your database instance. In the event of a catastrophic failure of an entire AZ (something we have yet to see but would very much like to just out of morbid curiosity), your data will be intact—though your actual database nodes may not be. This uses a bit of “under the hood” style secret sauce.
From an economic standpoint, this choice is very much rolling the dice.
On average, you’ll save a ballpark of 20% off of traditional MySQL RDS. But since you pay per million I/O operations (a metric you won’t get to see until you migrate), you’re gambling that this won’t lead to a less-than-delightful bill surprise. One additional consideration: Aurora scales well–in some cases, too well. Extremely high performance, multi-master capabilities across regions, and custom endpoint options are incredibly handy, but they’re also almost impossible to replicate on other platforms. It’s a form of architectural lock-in that’s incredibly challenging to get away from once you’re dependent upon it.
I wish I could say that there was a clear winner here for every use case, but I simply can’t.
In the absence of site-specific data, I’d start with Aurora due to cost and performance reasons and then fall back to traditional RDS. I’d run EC2 instances only as a last resort, but that’s reflecting my lack of comfort with hands-on database management.
Your mileage may vary—but your databases really shouldn’t.
