Choosing a database is a comparatively long-term commitment for any organization including startups. Even if you code an app within a distributed system, it captures all changes as a database.
Hence, database migration is the most complex task in workload migration. And even more complex to migrate with zero downtime.
Making an informed decision while choosing a database is as essential as you choose your core team.
In this blog, we walk through the factors you should consider while choosing an AWS database.
The first thing you need to decide is whether you want a relational database or a non-relational database.
If you decide you want to go for a relational database, the next thing comes as ‘do you want to be managed or unmanaged?’ If you want to manage your database by yourself or let AWS manage the same with auto-scaling, monitoring nodes, etc.
If you want an unmanaged database, then you can use the MySQL/Postgres database.
If you want a managed database, then you need to decide whether you have consistent traffic or you have a variable traffic spike like the morning is low and at night it is high.
If you have consistent traffic, then I will suggest that you go for AWS Aurora. If you are not sure about the traffic spike, then go for Aurora serverless.
If you want to go for Non-Relational, then the next question is whether you want to use the database for analytics, business intelligence, and text searching, then go for Elasticsearch DB.
If this is not the case, then do you want transaction workload i.e., multiple updates on multiple tables or multiple changes to this database from several users?
If you want transaction workload, then a new question arises: do you want to scale or want to have an auto-scaling (adding or removing nodes) feature when load increases to balance the load on the database?
If you don’t want scale, then go for DocumentDB even though DocumentDB is a little hands-on and easy-to-to use. Use DynamoDB if you need to scale and it is a serverless key-value database. Here, the scaling is managed by AWS.
Let’s go back to transaction workload. So if you don’t need this then again a question arises: do you need pub/sub message(Publish/subscribe messaging, is a form of asynchronous service-to-service communication) and replication (scale database reads and to have highly available clusters).
If this is the case, then go for Redis. If you want multithreading (the ability to execute multiple processes simultaneously by scaling the computer capacity), then go for Memcached.
How do we set up an AWS Relational Database for one of our customers?
The client wanted to migrate their on-premise database to the cloud and we set up an Amazon Relational Database Services (RDS) for them with no hassle.
Architecture:
For the storage of the data one RDS Cluster is set up with one read replica of engine MySQL. The load on the primary DB instance can be reduced by routing read queries from applications to the read replica. To prevent access from the outside world, a database is created inside a private subnet.
To check the status of the RDS Cluster just search RDS in the AWS console and click on RDS.
After clicking on RDS you will be landed on the page as shown below. There you can see the database instance & its read replica.
- To check the database configurations click on the database & see details like number of connections, class, region etc.
The Autoscaling feature for the database is enabled, currently, it’s 20 GiB but it can be increased to a maximum of 100 GiB automatically when the load increases. Also, the storage is encrypted with an AWS KMS key.
To increase the maximum limit of storage click on Modify.
Then go to the storage section & increase the limit as much as you want in the Maximum storage threshold field.
Monitoring:
For monitoring of the database, jump to the Monitoring section where you can monitor activities like database connections, CPU utilization, free memory, etc.
Maintenance & Backup Period:
To check the maintenance & backup window, click on the Maintenance & backups tab.
Select the right AWS Database with us.
For more information
Bharat Nainani
Cloud Champion
Bharat is a techno enthu with passion about new-age high techs. He is an incredible resource with AWS, Kubernetes, and Red Hat certificates. In his free time, Bharat loves to sketch, draw and write blogs on upcoming technologies.
Deepak Shah
Cloud Champion
Deepak is an adept cloud engineer who loves to write about upcoming technologies. He is a Red Hat Certified Specialist in Containers and Kubernetes. He is also an athlete and loves hip hop music.
