AWS Builder Center
From Development to Deployment: Choosing the Right Database Strategy

From Development to Deployment: Choosing the Right Database Strategy

Discover how Amazon RDS eliminates database maintenance overhead and follow a hands-on CLI tutorial to deploy a secure, scalable database in production with automated backups and monitoring.

The scenario: Moving beyond local development

You're building a new application – maybe it's a social media app, an e-commerce site, or a blog platform. During development, you've been using SQLite for simplicity or running MySQL in a Docker container on your laptop. Everything works well locally.
But now you're ready to deploy and let real users access your application. Your local SQLite file or Docker container can't handle multiple concurrent users, provide reliable backups, or stay online when your laptop is turned off. You need a production-ready database solution that's always available and can scale with your users.
This is when every developer faces the critical question: "Should I manage my own database or use a managed service?"

The common dilemma: Control vs Convenience

Your requirements likely include secure user data storage, handling relationships between different data types, supporting your expected user base (maybe 50-500 users initially), ensuring reliable backups, and keeping costs reasonable for your project budget.
To meet these requirements, you have two main options:
Option 1: Self-Managed Database
Set up MySQL or PostgreSQL on an EC2 instance. You get full control over configuration, but you're responsible for everything: installation, security, backups, updates, monitoring.
Option 2: Amazon RDS
Use AWS managed database service - Amazon Relational Database Service (Amazon RDS). AWS handles the operational tasks while you focus on your application logic and schema design.

The reality of self-managed databases

Self-managed databases often seem appealing initially - you know MySQL or PostgreSQL already, you want full control over configuration, and you assume it should be cheaper. But there's a hidden reality most developers don't account for initially. Here's what installing and managing your own database actually involves:
Initial setup (Estimated 4-8 hours):
Getting started requires installing and configuring MySQL or PostgreSQL, setting up proper user accounts and permissions, configuring automated backups, establishing security settings and access controls, and setting up monitoring and alerting. This foundational work is time-consuming but essential for production readiness.
Ongoing maintenance (Estimated 10-15 hours/month):
Monthly responsibilities include applying security patches to Operating System (OS) and database, monitoring disk space and performance, verifying backup integrity, handling scaling when traffic grows, troubleshooting performance issues, and planning and executing maintenance windows. This ongoing operational burden compounds over time as your application grows.
The Real Question: Do you want to spend 15+ hours per month on database administration, or would you rather focus on building features that users care about?

What Amazon RDS actually provides

RDS uses familiar database engines (MySQL, PostgreSQL, etc.) and runs them as managed services. It’s not just "MySQL or PostgreSQL in the cloud" – it's a comprehensive database platform that handles operational complexity while delivering real benefits:
Automated Operations:
RDS handles database installation and initial configuration in just 30 minutes versus 4-6 hours for manual setup. The service provides daily automated backups with point-in-time recovery, security patches applied automatically during maintenance windows, built-in monitoring through CloudWatch, and easy scaling with minimal downtime. These automated capabilities eliminate the operational overhead that consumes developer time.
Built-in Security:
RDS provides VPC isolation by default, encryption at rest and in transit, integration with AWS IAM for access control, and AWS security best practices built-in. These security measures are automatically configured and maintained by AWS, eliminating the complexity of implementing enterprise-grade security yourself.
Reliability Features:
Enterprise-level reliability includes Multi-Availability Zone (AZ) deployments for automatic failover, read replicas for scaling read operations, enterprise-grade backup and recovery, and automated backup retention and management. AWS manages these reliability features as part of the service, handling the underlying infrastructure complexity.
Cost & Time Benefits:
RDS offers  db.t3.micro  free tier eligibility for 12 months, zero time spent configuring backups or planning maintenance windows, and the ability to focus on features instead of infrastructure. By eliminating database administration overhead, RDS lets you invest your time in building what differentiates your application.
What You Still Control:
You retain full control over database schema and application logic, query optimization and indexing, user management within the database, backup retention policies, and maintenance window timing. RDS manages the infrastructure while preserving your application-level decision-making authority.

Hands-on CLI tutorial: Learn RDS step-by-step

Before diving into the highlights, here's the complete hands-on CLI tutorial that walks you through setting up RDS with production best practices:
What the full tutorial covers:
  • Prerequisites and setup - AWS CLI configuration and permissions
  • VPC and networking - Security groups, subnets, and proper isolation
  • RDS instance creation - Using AWS CLI with security best practices
  • Secure connection setup - Bastion host pattern for database access
  • Real database operations - Creating schemas, tables, and testing
  • Production considerations - Multi-AZ, encryption, monitoring
  • Complete cleanup - Avoiding ongoing charges
Estimated time: 45 minutes
The rest of this blog post highlights key concepts and decisions from the tutorial to help you understand why RDS makes sense for your applications.

Setting up RDS: Key highlights from the tutorial

Understanding the network foundation

Every production RDS setup needs proper networking. Your database should never be publicly accessible:
Bash
# Check for a default VPC
VPC_ID=$(aws ec2 describe-vpcs --filters "Name=isDefault,Values=true" --query "Vpcs[0].VpcId" --output text)
echo "Default VPC ID: $VPC_ID"
Essential networking components:
  • VPC: Your isolated network environment
  • Subnets: RDS requires at least two in different availability zones
  • Security Groups: Act as virtual firewalls controlling access
  • DB Subnet Group: Defines which subnets RDS can use
The following diagram shows the RDS network architecture with VPC subnets and security group relationships.
Network architecture diagram showing RDS database in private subnet and EC2 instance in public subnet within a VPC, with security groups controlling access between components across two availability zones.


Implementing security best practices

Create security groups as the foundation for least privilege access:
Bash
# Create security group for RDS database
RDS_SECURITY_GROUP_NAME="rds-db-sg"
RDS_SECURITY_GROUP_ID=$(aws ec2 create-security-group \
--group-name $RDS_SECURITY_GROUP_NAME \
--description "Security group for RDS database access" \
--vpc-id $VPC_ID \
--query "GroupId" --output text)
echo "Created RDS security group: $RDS_SECURITY_GROUP_ID"
Bash
# Create security group for EC2 bastion host
EC2_SECURITY_GROUP_NAME="ec2-bastion-sg"
EC2_SECURITY_GROUP_ID=$(aws ec2 create-security-group \
--group-name $EC2_SECURITY_GROUP_NAME \
--description "Security group for EC2 bastion host" \
--vpc-id $VPC_ID \
--query "GroupId" --output text)
echo "Created EC2 security group: $EC2_SECURITY_GROUP_ID"
These security groups will be configured to ensure your database only accepts connections from authorized sources, no direct internet access to your database, and clear separation between application and database access. This layered security approach follows AWS best practices for database protection.

Creating your RDS instance

The actual database creation is straightforward once networking is configured:
Bash
DB_INSTANCE_ID="mydb-tutorial"
aws rds create-db-instance \
--db-instance-identifier $DB_INSTANCE_ID \
--db-instance-class db.t3.micro \
--engine mysql \
--master-username adminuser \
--manage-master-user-password \
--allocated-storage 20 \
--vpc-security-group-ids $RDS_SECURITY_GROUP_ID \
--db-subnet-group-name $DB_SUBNET_GROUP_NAME \
--backup-retention-period 7 \
--no-publicly-accessible \
--no-multi-az
echo "DB instance creation initiated: $DB_INSTANCE_ID"
What this accomplishes:
The command creates an RDS managed MySQL instance with the latest stable version, uses  db.t3.micro  (eligible for AWS Free Tier), generates a secure password stored in AWS Secrets Manager, configures 7-day automated backup retention, and places the database in private subnets only.
The process takes about 10 minutes – significantly faster than manual MySQL installation and configuration.

Connecting securely through a bastion host

Since your RDS instance is private (as it should be), you need a secure way to connect for administration:
Bash
# Create user data script to install MySQL client
USER_DATA=$(cat << 'EOF'
#!/bin/bash
yum update -y
yum install mysql -y
echo "MySQL client installation completed" > /tmp/mysql-install.log
EOF
)

# Launch the EC2 instance
INSTANCE_ID=$(aws ec2 run-instances \
--image-id $AMI_ID \
--count 1 \
--instance-type t2.micro \
--key-name $KEY_NAME \
--security-group-ids $EC2_SECURITY_GROUP_ID \
--subnet-id $SUBNET_ID \
--associate-public-ip-address \
--user-data "$USER_DATA" \
--tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=RDS-Bastion-Host}]' \
--query "Instances[0].InstanceId" \
--output text)
echo "Launched EC2 bastion host: $INSTANCE_ID"

Once your bastion host is running, follow these secure connection steps:
  1. Connect to the bastion host via SSH:  ssh -i ${KEY_NAME}.pem ec2-user@$PUBLIC_IP 
  1. From the bastion host, connect to your RDS MySQL database:  mysql -h $DB_ENDPOINT -P $DB_PORT -u $DB_USER -p 
  1. Enter the password when prompted:  Enter password: [paste the password from $DB_PASSWORD] 
The following diagram shows the secure connection flow from your laptop through the bastion host to the private RDS instance.
Connection flow diagram showing secure path from corporate data center laptop through AWS Direct Connect and Internet Gateway to EC2 bastion host in public subnet, then to RDS database in private subnet within AWS VPC.


Building your application schema

Once connected, you can create your application's database structure. Here's an example for a typical web application:
SQL
-- Create a test database
CREATE DATABASE testdb;

-- Use the test database
USE testdb;

-- Create a test table
CREATE TABLE users (
id INT AUTO_INCREMENT PRIMARY KEY,
name VARCHAR(50) NOT NULL,
email VARCHAR(100),
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

-- Insert some test data
INSERT INTO users (name, email) VALUES
('Alice Johnson', 'alice@example.com'),
('Bob Smith', 'bob@example.com'),
('Carol Davis', 'carol@example.com');

-- Query the data
SELECT * FROM users;

-- Show table structure
DESCRIBE users;

-- Exit MySQL
EXIT;

Your database performs reliably, and you have confidence that your data is secure and automatically backed up. But you might still have questions about choosing RDS over self-managed databases.

Common concerns and realistic answers

Q: "What if I want to switch providers later?"
A: Your application code remains portable. You're using standard MySQL or PostgreSQL, so migrating to another provider or self-managed setup is always possible.
Q: "Is it really cheaper?"
A: For most applications, yes. When you factor in your time, monitoring tools, backup storage, and the cost of downtime, RDS often costs less than self-managed alternatives.
Q: "What if I need custom configuration?"
A: RDS parameter groups allow extensive customization. For specialized use cases requiring deeper customization, you can always migrate to self-managed later.
Q: "How do I handle scaling?"
A: RDS makes scaling straightforward – both vertical (larger instances) and horizontal (read replicas). It’s much easier than managing replication yourself.

Scaling with RDS as your application grows

As your application succeeds, you have clear upgrade options:
Phase 1: Single Instance (Starting Out)
Begin with db.t3.micro or db.t3.small instances using single-AZ deployment and automated backups. This configuration handles initial development and small user bases cost-effectively.
Phase 2: High Availability (Growing user base)
Upgrade to Multi-AZ deployment for automatic failover, larger instance classes ( db.t3.medium ,  db.m5.large ), and CloudWatch alarms and monitoring. This phase ensures reliability as your user base grows.
Phase 3: Scale for performance (Established application)
Implement read replicas for scaling read operations, RDS Proxy for connection pooling, and Performance Insights for query optimization. These features handle increased traffic and complex query patterns.
Phase 4: Advanced features (Enterprise scale)
Transition to Amazon Aurora (AWS cloud-native database engine) for advanced capabilities, cross-region backups for disaster recovery, and Aurora Global Database for global applications. This phase supports enterprise-level requirements and global reach.

Ready to build with confidence?

You don't need to choose between learning database administration and shipping your application. RDS provides a solid foundation that grows with your project while letting you focus on what makes your application unique.
Your next steps:
  1. Start the tutorial - Follow the  complete CLI setup guide  to get hands-on experience
  1. Build your schema - Create your application's database structure using the patterns you've learned
  1. Deploy with confidence - Launch knowing your data is secure, backed up, and scalable
What you've gained:
  • A reliable database setup that takes under an hour and scales as you grow
  • Time to focus on what differentiates your application
  • Reliable backups and security without the overhead
Ready to share your experience? We'd love to hear how RDS accelerated your development process. Connect with other builders in the comments below.
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article