After learning how to run applications on EC2, I started thinking about something I had never really questioned before.
Where does all the data actually go?
When a user creates an account, where is that account stored?
When someone places an order, where does the order information live?
When I update my profile, how does the application remember that change the next time I log in?
As a MERN developer, I already understood the idea of a database.
I had worked with MongoDB and Mongoose.
But AWS made me think about the bigger question:
How do you run and manage a database reliably in the cloud?
That's when I started learning about Amazon RDS.
The Problem I Started With
Imagine I deploy my backend on an EC2 instance.
My application is running perfectly.
A user signs up.
Their information needs to be saved somewhere.
So my application needs a database.
The basic idea looks like this:
User
│
▼
Backend
│
▼
Database
At first, this seems simple.
But then I started thinking about everything that comes with managing a real database.
Someone has to:
- Install the database
- Configure it
- Manage updates
- Take backups
- Monitor it
- Handle failures
- Protect it
- Recover it when something goes wrong
That's a lot of responsibility.
And this is where managed database services become useful.
So What Is Amazon RDS?
The simplest way I understand Amazon RDS is:
Amazon RDS is a managed relational database service from AWS.
Instead of manually setting up and maintaining a relational database server yourself, AWS manages much of the underlying database infrastructure for you.
RDS supports database engines such as:
- MySQL
- PostgreSQL
- MariaDB
- Oracle
- SQL Server
- Amazon Aurora
So instead of spending most of my time managing the database server itself, I can focus more on my application and the data.
Running a Database Yourself vs RDS
This comparison helped me understand the difference.
If I Manage Everything Myself
Imagine I launch an EC2 instance and install MySQL manually.
EC2
│
├── Operating System
├── MySQL
├── Configuration
├── Updates
├── Backups
└── Monitoring
Now I'm responsible for all of it.
With Amazon RDS
With RDS, the architecture becomes much simpler:
Application
│
▼
Amazon RDS
│
▼
Relational Database
AWS handles much of the underlying infrastructure.
That doesn't mean I have no responsibility.
I still need to think about:
- Database design
- Queries
- Users and permissions
- Security
- Application configuration
- Cost
But AWS takes care of many infrastructure-level tasks.
A Real-World Example
Imagine I build an online store.
A customer creates an account.
Then they add a product to their cart.
Finally, they place an order.
The application needs to store information such as:
Customer
│
├── Account
│
├── Orders
│
├── Products
│
└── Inventory
A relational database is useful for this kind of structured data.
The application architecture could look like:
User
│
▼
Frontend
│
▼
Backend API
│
▼
Amazon RDS
The frontend doesn't directly communicate with the database.
The backend handles that communication.
Why Shouldn't Users Connect Directly to the Database?
This was another thing that became clear to me while learning AWS.
Imagine this:
Internet Users
│
▼
Database
That would be a terrible architecture.
You don't want random internet users connecting directly to your database.
Instead, we want:
Internet Users
│
▼
Frontend
│
▼
Backend API
│
▼
Amazon RDS
The backend controls how the application communicates with the database.
Security Groups can also be configured so the database only accepts connections from the backend resources that actually need access.
That creates a much safer architecture.
What Happens If the Database Fails?
This is where managing databases gets interesting.
Imagine my application has thousands of users.
Everything is working.
Then suddenly, the database server experiences a failure.
What happens to the application?
If I manually manage the database, I have to think about how to recover it.
RDS provides features designed to improve database availability and recovery.
One important feature is Multi-AZ deployment.
Multi-AZ
With Multi-AZ, AWS can maintain a standby database instance in another Availability Zone.
A simplified example:
AWS Region
│
┌──────────┴──────────┐
│ │
▼ ▼
Availability Zone A Availability Zone B
│ │
▼ ▼
Primary RDS Standby RDS
The application normally communicates with the primary database.
If a failure occurs, AWS can fail over to the standby.
What I found interesting here is that high availability isn't simply about having a backup file.
It's about designing the system so it can continue operating when something goes wrong.
What About Backups?
Another thing I started appreciating about managed databases is backups.
Imagine I accidentally delete important data.
Without a backup strategy, recovering it could become a nightmare.
RDS provides automated backup capabilities and supports database snapshots.
So instead of thinking:
"I'll configure backups later."
I can make backups part of the infrastructure from the beginning.
That was another important mindset shift for me.
What If My Application Gets Bigger?
Let's say my application starts with:
100 users
Then it grows to:
10,000 users
And eventually:
1,000,000 users
The database now has much more work to handle.
Eventually, database scaling becomes its own engineering problem.
Depending on the workload, there are different ways to improve database performance and capacity.
For example:
- Increasing the database instance size
- Using read replicas
- Adding caching
- Optimizing queries
- Choosing the right database architecture
So scaling isn't only about EC2.
The database needs to scale too.
RDS With Everything I've Learned So Far
This was probably the most useful part for me.
I've already learned about:
- Route 53
- CloudFront
- Elastic Load Balancer
- EC2
- Auto Scaling
- Security Groups
Now I can finally see where the database fits into the bigger picture.
A simplified AWS architecture could look like this:
Users
│
▼
Route 53
│
▼
CloudFront
│
▼
Load Balancer
│
▼
Auto Scaling Group
│
▼
EC2 Instances
│
▼
Amazon RDS
Each service has a different responsibility.
Route 53 helps users find the application.
CloudFront helps deliver content efficiently.
Load Balancer distributes incoming traffic.
Auto Scaling adjusts the number of EC2 instances.
EC2 runs the application.
RDS stores the relational data.
Seeing all these pieces together made AWS feel much less like a list of services and more like an actual system.
One Thing I Finally Understood
Before learning AWS, I mostly thought about databases from the application developer's perspective.
I would:
Create Database
↓
Connect Backend
↓
Write Queries
↓
Done
But production systems are different.
Now I have to ask:
What happens if it fails?
↓
How are backups handled?
↓
Who can access it?
↓
Can it scale?
↓
How do I keep it available?
Those questions become increasingly important as an application grows.
The Bigger Picture
After learning EC2, ELB, Auto Scaling, and RDS, I started seeing cloud architecture differently.
It's not about memorizing:
"EC2 does this."
"RDS does that."
It's about understanding how the pieces work together.
For example:
Users
│
▼
Route 53
│
▼
CloudFront
│
▼
Load Balancer
│
▼
Auto Scaling
│ │
▼ ▼
EC2 EC2
│ │
└──┬───┘
│
▼
Amazon RDS
Now the architecture actually tells a story.
Users arrive.
Traffic is routed.
Content is delivered.
Requests are distributed.
Servers scale.
The application runs.
Data is stored.
That's when AWS started making much more sense to me.
What Changed My Perspective
Before learning AWS, I thought about databases mainly as something my application connects to.
Now I understand that the database itself is an important part of the architecture.
Questions like:
What happens if the database fails?
How do I protect it?
How do I back it up?
How will it handle more users?
How do I make it highly available?
These aren't just database questions.
They're system design questions.
And that's probably the biggest thing RDS taught me.
Final Thoughts
When I first started learning AWS, EC2 was exciting because I could actually see my application running on a cloud server.
But RDS taught me something different.
Running an application is only one part of the system.
The application also needs somewhere reliable to store the information that makes it useful.
And managing that database involves much more than simply creating a database and connecting to it.
That's where managed services like Amazon RDS become valuable.
For me, the biggest lesson was simple:
A database isn't just where data lives. It's part of the architecture that needs to be designed for security, availability, backups, and growth.
The more I learn AWS, the more I realize that building software isn't only about making the application work.
It's about making sure the entire system can keep working when real users start depending on it.
🚀 What I'm Learning Next
The more AWS services I learn, the more I realize that each one solves a different piece of the same puzzle.
EC2 taught me where applications can run.
ELB taught me how traffic can be distributed.
Auto Scaling taught me how applications can adapt to demand.
And RDS taught me where the application's important data can live reliably.
The next step is understanding how these pieces work together in a real application.
I'm continuing to document my AWS learning journey by taking the concepts I learn and explaining them in the simplest way I can.
If you're learning AWS too, I hope this made Amazon RDS a little easier to understand.
Happy learning! 🚀
Top comments (0)