In Part 1, we introduced a client moving from a monolithic system towards a microservices-based architecture on AWS, and how one decision stood out: the desire to run their database inside a container.

In Part 2, we looked at what it actually takes to run a database on AWS Fargate, from storage options to the realities of backup and recovery. And while we established that it’s entirely possible to run a database this way, we also saw where the model starts to show strain, especially for production-grade, performance-sensitive workloads.

In this final piece, we look at two additional alternatives – EC2 and RDS. Both options take a fundamentally different approach to the problem. More importantly, they shift where complexity lives.

Option 2: Self-Managed Database on EC2

In this configuration, the database is installed directly on an EC2 instance running Linux. The database runs as a native operating system service, just like it would in a traditional data centre, and persistent storage is provided by EBS volumes attached to the instance.

At first glance, this might feel like a step backward - especially in a world moving towards containers and serverless. But when it comes to databases, this model still holds up remarkably well for several reasons.
Unlike containers, EC2 instances are stateful by design:

• The instance persists
• The storage persists
• The relationship between compute and storage is stable This aligns naturally with how databases operate. But let’s see how this option stacks up against Fargate across our three core dimensions.

a) Persistent Storage
With EC2, storage becomes more manageable and predictable. Unlike Fargate's one-volume limit, EC2 allows multiple EBS volumes to be attached to a single instance. This allows for flexible architectures, e.g.,

• Separate volumes for data, logs, and backups
• Different volume types (gp3, io2) with independent IOPS and throughput settings for each workload.

In addition, resizing, attaching, detaching, and snapshotting are standard operations, all managed at the instance level without the need to orchestrate ephemeral tasks.

b) Backup and Recovery
Because EC2 runs on persistent virtual machines, you can take EBS snapshots to obtain physical database backups. Physical backups capture the actual database files at the block level. During restore, you're copying raw data back onto disk, not replaying SQL statements. The result is significantly faster and more predictable restore times compared to logical backups.

But still, there’s a catch:

• As previously noted, while EBS snapshots are crash-consistent by default, they are not application-consistent for live databases. Achieving a clean, reliable backup requires coordinating with the database (e.g., flushing writes or temporarily pausing activity).
• Binary logging must still be configured and managed to enable point-in-time recovery (PITR), introducing additional operational responsibility.

So, while EC2 solves many of the issues we saw with containers, it introduces its own trade-offs:

• The operational overhead remains significant. The team is responsible for everything below the database layer - patching, upgrades, monitoring, backups, and troubleshooting.
• High availability and scaling must be designed and implemented manually. This includes replication, failover strategies, and multi-AZ setups. For teams early in their cloud journey, the possibility of this architecture pattern becoming a burden was still very real.

But again, context matters.
For our client, this option was the closest match to their existing operating model. It aligned with the architecture they were familiar with and the expertise they had already built. So, while it didn’t eliminate operational complexity, it avoided introducing entirely new ones.
Because of that, it stood out as a strong and pragmatic candidate - bridging the gap between where they were and where they wanted to go.

Option 3: Fully Managed Database on RDS
Where EC2 gives you control, RDS takes that control away - on purpose.

Being a managed service, RDS fully controls the underlying database infrastructure. You simply choose a database engine. Select an instance class. Specify storage size. AWS handles the rest - the operating system, the MySQL installation, the storage layer, the backups, and the high availability configuration.

With RDS, the model shifts from managing database infrastructure to consuming database as a service.

a) Storage Management
With RDS, storage is automatically provisioned and managed by AWS.

• You don’t manage any volumes. Instead, you simply tell RDS how much storage you want (or set a maximum for auto-scaling), and it handles the rest. The underlying EBS volumes are managed by AWS - attached, formatted, and monitored without any action from you.

• Automatic storage scaling. Once enabled, RDS automatically increases storage when free space falls below a set threshold - without downtime.

• No volume sprawl. One database. One logical storage allocation. No tracking dozens or hundreds of volumes across tasks or instances.

In essence, with RDS, storage becomes something you can configure rather than something you operate.

b) Backup and Recovery
This is where RDS truly shines-and where it decisively beats both Fargate and EC2.

• Automated physical backups. Using AWS Backup, RDS takes physical snapshots of the underlying EBS volumes on a schedule you define (daily, by default).
• Point-in-time recovery (PITR) built-in. RDS automatically archives transaction logs (binary logs for MySQL) and allows you to restore to any point in the last 35 days, down to the second. No manual binary log shipping. No scripting. Just select a timestamp and click restore.
• Restore simplicity. Restoring a database from a snapshot or a point-in-time is a few clicks in the AWS console or a single API call. RDS launches a new RDS instance with the restored data within minutes. No need to mount volumes, replay binary logs, or run recovery procedures.

In addition to the above, RDS offers the following benefits:

• Multi-AZ and High Availability Deployments are natively supported.
• Routine database operations are handled for you. RDS handles patching for both the operating system and the MySQL engine during a pre-defined maintenance window.

So, is there a catch with RDS? Yes, the convenience comes with some trade-offs.

• Higher cost. Since you’re paying for the managed service premium, RDS is more expensive than running MySQL on EC2 with equivalent resources.
• Limited Control over Database parameters and the OS. You can modify parameters via custom parameter groups, but some low-level settings are restricted or require support tickets. Additionally, you do not have full access to the underlying OS.

Conclusion: The Ultimate Choice
So far, we've looked at three very different ways to host a MySQL database on AWS. We’ve also looked at a client scenario – one that speaks to this very choice of determining which platform is the best fit. Based on their requirements and the three hosting options we have discussed, which option do you think they would choose?

Better yet, which option would YOU choose if you were faced with a similar decision?

One of the biggest takeaways from this exercise is that architecture decisions are rarely about right vs wrong. Rather, they’re about trade-offs.

• Do you prioritise consistency and portability, even if it introduces operational complexity?
• Do you want full control and performance, even if it means additional management overhead?
• Or do you value simplicity and reliability, even if it comes at the cost of flexibility?

Truth is, there’s no universal answer - only the one that best fits your context. Some teams run stateful databases in container platforms all the time - Cassandra, CockroachDB, even PostgreSQL. They've built the tooling, automated the backups, and accepted the constraints. For them, containers are just another deployment target.
Other teams draw a hard line. Containers are for stateless application workloads only. The database belongs on a more stable infrastructure, whether that's a VM or a managed service.

But the question remains - just because you can run a database in a container… should you?

I'd love to hear your perspective.

• Have you run a production database in a container? How did it go?
• Would you draw the line at the database, or do you believe in "containers for everything"?
• Which of these three options would you have recommended for this client?

Drop a comment below or find me on LinkedIn. Let's have the conversation.