Last time we became familiar with the handiwork of setting up MySQL locally, navigating databases via command line, and exposing your database to external access. While badass, it has come to my attention that most people don’t bother doing things this way. Unless you’re getting deep into some heavy architecture, most people opt to use cloud services such as AWS to set up databases which are intended to be interacted with by multiple services.

A perfect example is one we ran into over the weekend while working on this very blog. We’re running a Ghost instance, which is respectably complex production-ready app. For a bunch of guys just looking to make some stupid blog widgets, it became obvious that reverse engineering the undocumented inner workings of an open source node app was a rabbit hole of complexity.

Hosting on AWS

In our case, AWS is useful for enforcing separation of concerns. Instead of building new logic into a live app, we can build that logic elsewhere in a way that’s reusable across multiple apps.

The end goal here is simply to read/write to a database. That said, there’s still a fair amount of complexity involved. We’ll need to leverage the following AWS services:

• RDS (Relational Database Service): A cloud hosted database
• API Gateway: An interface for building APIs
• Lambda: The necessary serverless connector between RDS and Gateway
• IAM: Amazon’s god-awful user and policy manager

For now, all we’re going to worry about is RDS.

#mysql #aws rds #cloud