After preparing the backend security group in the previous step, the next important task in the vProfile re-architecture project was creating the database layer. In this stage, the focus moved to AWS RDS, which gives us a managed relational database without having to install and maintain MySQL manually on EC2.
This part of the project helped me understand how a database fits into a private application architecture. The database should be available to the application, but it should not be exposed to the public internet.
Why Use RDS Instead of Installing MySQL on EC2?
It is possible to run a database on EC2, but that means handling installation, backups, patching, monitoring, and recovery manually. RDS reduces that operational work and gives a much cleaner setup for a project like this.
Using RDS gives several advantages:
- Managed database operations
- Automated backups and easier recovery
- Better integration with VPC networking and security groups
- Cleaner separation between app and database layers
How the Database Fits into the Architecture
In this re-architected setup, the database is one part of the private backend layer. The application talks to it from inside the AWS network rather than over the public internet.
That means the database should be reachable only from trusted internal resources, especially the application instances.
Step 1: Start Creating the RDS Instance
The instructor moved to the RDS service in AWS and started the database creation wizard. The database was created in the same project environment so it could later be connected to Elastic Beanstalk and the other backend services.
- Open AWS Management Console
- Go to RDS
- Click Create database
- Select the appropriate engine for the application
Since vProfile uses a relational database, the goal here was to launch a managed MySQL-style backend rather than building it from scratch on a virtual machine.
Step 2: Keep the Database Private
One of the most important design decisions was making sure the RDS instance stayed private. A production-style database should not be publicly open unless there is a very specific reason and strong controls around it.
That private design depends on two things:
- Using the correct VPC and subnet placement
- Attaching the right backend security group
Step 3: Use a DB Subnet Group
RDS needs to know which subnets it can use. This is where a DB subnet group becomes important. It tells AWS where the database can live inside the VPC.
The subnet group should use private subnets so the database stays away from direct public access.
This separation makes the network cleaner and helps enforce the layered architecture.
Step 4: Attach the Backend Security Group
In the previous blog step, a backend security group was created to control trusted communication between backend resources. This same group is important here because the database should use it as part of the private backend layer.
The idea is:
- Backend resources can communicate internally when needed
- The application layer can later be allowed through SG rules
- The database remains blocked from random public traffic
Step 5: Set Initial Database Configuration
During creation, the database also needs core configuration such as instance name, database name, master username, and password. These values are important because the application will later use them in its connection settings.
At this stage, it is important to store securely:
- Database endpoint
- Database name
- Username
- Password
- Port number
The application cannot connect correctly unless these details match the configuration it expects.
Step 6: Launch and Verify the Instance
Once the settings were reviewed, the RDS instance was created. After AWS finished provisioning it, the key task was checking that the instance was available and that its endpoint could be used by the application layer later.
At this point, the database is not something a user visits in a browser. Instead, verification is about making sure:
- The instance status is healthy
- The database lives in the intended VPC and subnets
- The correct security group is attached
- The endpoint is ready for application use
Why This Step Matters in the Project
This is the point where the architecture starts becoming more realistic. Instead of a single machine doing everything, the application is being separated into layers, each with its own role.
That separation gives several benefits:
- Better security through isolation
- Clearer responsibility for each service
- Easier scaling and maintenance
- A more production-style cloud design
Common Mistakes to Avoid
- Do not make the database publicly accessible by mistake
- Do not attach the wrong security group
- Do not lose the DB endpoint and credentials
- Do not place the database in the wrong subnet group
What I Learned from This Step
- RDS is much more than just "database hosting"
- Subnet groups are important for private placement
- Security groups control who can reach the database
- Application architecture becomes stronger when layers are separated
- Private databases are a core part of secure cloud design
Conclusion
This step moved the vProfile re-architecture project closer to a real production layout. The RDS instance was created inside the right private network boundary, connected to the backend security design, and prepared for later application connectivity.
After this, the next steps can focus on wiring the application to the database and continuing the rest of the backend service setup in a much more structured way.