AWS re/Start Lab · Bases de Datos

Build Your DB Server and Interact With Your DB Using an App

This lab introduces Amazon RDS through a practical workflow. It builds the network prerequisites for a managed database, launches a Multi-AZ MySQL instance, and then connects a web application to that database so the data can be tested from the browser.

Lab Summary

Created a dedicated DB Security Group, defined a DB Subnet Group across two private subnets, launched a Multi-AZ MySQL RDS instance named lab-db, copied the endpoint, and used the address book web application to persist data through the managed database.

Network Preparation

Created the database security group and subnet group required before the RDS launch.

RDS Deployment

Configured a Multi-AZ MySQL instance with the lab credentials and captured the generated endpoint.

Application Test

Connected the web application to the database and verified persistence through the address book interface.

Step-by-Step Walkthrough

The workflow moved from infrastructure setup to application validation, which is the normal path when introducing a managed database service.

01

Create the security group and subnet group for RDS

  • Opened VPC > Security Groups and created DB Security Group inside the Lab VPC.
  • Added an inbound rule of type MySQL/Aurora (3306) with Web Security Group as the source, so only the web server tier could reach the database port.
  • Moved to RDS > Subnet groups and created DB Subnet Group using two subnets in different Availability Zones, which is required for Multi-AZ deployment.
02

Launch the Multi-AZ RDS instance

  • Started a standard RDS creation flow with the MySQL engine and the Dev/Test template.
  • Selected Multi-AZ DB Instance, set the identifier to lab-db, used the credentials main and lab-password, and chose the db.t3.medium class.
  • Attached the instance to the Lab VPC, removed the default security group, selected DB Security Group, disabled enhanced monitoring, and set the initial database name to lab.
  • Waited until the instance became available and then copied the generated RDS endpoint from the connectivity section.
Multi-AZ was the key difference in this lab. It adds a standby replica in another Availability Zone to improve availability and durability, even though the application still connects through a single endpoint.
03

Connect the web application to the database

  • Opened the web server address in the browser and selected the RDS section of the sample application.
  • Entered the copied endpoint, the database name lab, the username main, and the password lab-password.
  • Submitted the form and waited for the application to initialize the database-backed address book.
  • Tested the application by adding, editing, and removing contacts, confirming that the data was being persisted through the RDS instance.

Command Reference

Main services and settings that made the managed database reachable from the application.

svc

DB Security Group

Allows inbound MySQL/Aurora traffic on port 3306 only from the Web Security Group.

svc

DB Subnet Group

Tells Amazon RDS which subnets can host the database instance, using at least two Availability Zones.

cfg

Multi-AZ DB Instance

Creates a primary database and a synchronously replicated standby instance in another Availability Zone.

cfg

Initial database name: lab

Creates the starting database schema used later by the web application.

cfg

RDS Endpoint

The application uses this hostname to establish the database connection.

Key Learnings

What Was Actually Learned

Amazon RDS simplifies database administration, but network permissions still have to be designed correctly.
A DB subnet group is mandatory because the database must know which private subnets and Availability Zones it can use.
The final validation should happen from the application side, not only from the RDS console, because the real goal is end-to-end connectivity.

Technical Conclusion

This lab connected infrastructure thinking with application behavior. Creating the RDS instance was only part of the task. The full success condition was that the web application could authenticate, initialize the schema, and persist records through the managed database.

The most useful takeaway was understanding how several AWS layers combine here: VPC security, subnet placement, managed database settings, and application configuration. If any of those layers is misconfigured, the app will not reach the data layer.