AWS RDS là gì? Tại Sao Bạn Nên Ngừng Tự Cài MySQL/PostgreSQL Trên EC2

Tôi đã từng rất tự hào khi tự cài PostgreSQL trên một con EC2 t3.medium. Cảm giác làm chủ hoàn toàn database — cấu hình từng tham số postgresql.conf, tự viết script backup lúc 3 giờ sáng, tự xử lý replication. Cho đến một ngày server die lúc khách hàng đang thanh toán, tôi mất 4 tiếng để restore từ backup thủ công trong khi support ticket tràn vào như lũ. Đó là lúc tôi thực sự hiểu AWS RDS sinh ra để làm gì.

AWS RDS là gì? Giải thích như bạn chưa biết gì về Cloud

AWS RDS (Relational Database Service) là dịch vụ database quan hệ được quản lý hoàn toàn (fully managed) bởi Amazon. Nói đơn giản: bạn chỉ cần nói "tôi muốn một database MySQL 8.0, 4 vCPU, 16 GB RAM" — AWS sẽ lo toàn bộ phần còn lại: cài đặt, vá lỗi, backup, monitoring, failover.

Hãy hình dung thế này: thay vì tự xây nhà (EC2 + tự cài MySQL), bạn thuê căn hộ dịch vụ cao cấp (RDS). Bạn vẫn sở hữu không gian sống đó và quyết định dùng nó thế nào, nhưng chủ nhà lo điện nước, sửa chữa, bảo trì. Bạn chỉ cần sống và làm việc.

RDS hỗ trợ 6 database engine: MySQL, PostgreSQL, MariaDB, Oracle, Microsoft SQL Server, và Amazon Aurora (engine độc quyền của AWS tương thích MySQL/PostgreSQL nhưng nhanh hơn 5x). Với thị trường Việt Nam, MySQL và PostgreSQL là 2 lựa chọn phổ biến nhất.

Tự cài MySQL trên EC2 vs AWS RDS: So sánh thực tế không tô vẽ

Đây là bảng so sánh tôi ước mình được đọc từ 3 năm trước:

Backup và Recovery: Tự cài MySQL trên EC2, bạn phải viết cron job chạy mysqldump, đẩy lên S3, kiểm tra file backup có hỏng không, test restore định kỳ. Với RDS, automated backup bật mặc định — lưu 7-35 ngày, point-in-time recovery đến từng giây, test restore chỉ cần vài click.

High Availability: EC2 một mình thì chết là chết. Muốn HA phải tự dựng replication, proxy, monitor và tự viết failover script. RDS Multi-AZ tự động duy trì một instance standby ở Availability Zone khác — khi primary die, failover xảy ra trong 60-120 giây mà không cần can thiệp tay.

Security Patches: Mỗi lần CVE mới xuất hiện, tự cài nghĩa là bạn phải theo dõi, lên lịch maintenance window, cập nhật rồi test. RDS có option auto minor version upgrade — AWS lo. Với critical patch, AWS thông báo trước và tự áp dụng trong maintenance window.

Chi phí thực sự: db.t3.medium RDS khoảng $50-70/tháng. EC2 t3.medium tương đương chỉ $30. Nhưng tính thêm giờ engineer setup/maintain: nếu bạn tốn 8 giờ/tháng x $30/giờ = $240 — RDS rẻ hơn nhiều.

Hướng dẫn tạo RDS Instance trong 10 phút

Trước khi bắt đầu, hãy đảm bảo bạn đã có VPC với ít nhất 2 subnet ở 2 AZ khác nhau (yêu cầu bắt buộc của RDS). Nếu chưa có, dùng Default VPC là đủ để test.

Bước 1: Vào AWS Console → RDS → Create database. Chọn "Standard create" để kiểm soát được các tùy chọn quan trọng (không chọn "Easy create" vì nó ẩn nhiều setting cần thiết).

Bước 2: Chọn engine. Chọn MySQL hoặc PostgreSQL tùy stack của bạn. Version: luôn chọn version mới nhất trong major version bạn đang dùng (ví dụ MySQL 8.0.36 thay vì 8.0.28).

Bước 3: Chọn template. "Free tier" để test miễn phí (db.t3.micro, không có Multi-AZ). "Production" để bật Multi-AZ tự động.

Bước 4: Đặt tên, username, password. Credentials này là master user — lưu ngay vào AWS Secrets Manager hoặc password manager, không để trong code.

Bước 5: Chọn instance class. Bắt đầu với db.t3.medium (2 vCPU, 4 GB RAM) cho app nhỏ-vừa. Có thể scale up sau mà không cần downtime đáng kể.

Bước 6: Storage. GP3 SSD, 20 GB là đủ để bắt đầu. Bật "Storage autoscaling" với threshold 85% để tránh đầy đĩa bất ngờ.

Bước 7: Connectivity. Đây là bước quan trọng nhất về bảo mật:

• VPC: chọn VPC production của bạn
• "Public access": chọn No — database không bao giờ nên expose ra internet
• Security group: tạo mới, chỉ cho phép inbound từ Security Group của EC2/ECS app server

Bước 8: Additional configuration. Đặt tên database ban đầu, bật "Automated backups" (7 ngày), chọn maintenance window lúc traffic thấp nhất (thường 2-4 AM giờ Việt Nam = 19-21 UTC).

Click "Create database" — sau 5-10 phút, instance sẽ sẵn sàng. Lấy endpoint từ Console và kết nối từ app server của bạn. Lưu ý: endpoint có dạng mydb.xxxxxxxx.ap-southeast-1.rds.amazonaws.com — đây là DNS name, không phải IP.

Mẹo quan trọng: KHÔNG connect vào RDS từ máy local qua public internet. Dùng bastion host hoặc AWS Systems Manager Session Manager để tunnel an toàn khi cần query trực tiếp. Bật "Public access" chỉ để debug rồi tắt ngay — đây là lỗi bảo mật nghiêm trọng nhiều team mắc phải.

3 Sai Lầm Phổ Biến Khi Dùng RDS Lần Đầu

1. Để database trong Public Subnet và bật Public Access. Tôi thấy pattern này ở khá nhiều startup Việt Nam. Database expose ra internet = mời hacker vào nhà. Luôn đặt RDS trong Private Subnet, chỉ cho app server trong cùng VPC kết nối vào.

2. Dùng master user cho application. Master user có full quyền trên toàn bộ database. Hãy tạo một database user riêng cho app, chỉ có quyền SELECT/INSERT/UPDATE/DELETE trên schema cần thiết. Khi bị breach, thiệt hại được giới hạn tối đa.

3. Không test restore backup bao giờ. Backup có đó nhưng chưa chắc restore được. Schedule 1 buổi/quý để test restore vào môi trường staging. Đây là bài kiểm tra thực tế duy nhất cho disaster recovery plan của bạn.

FAQ — Những câu hỏi gai góc về RDS

Q: RDS có thể bị downtime không? Nếu có thì bao lâu?

A: Có. Multi-AZ failover mất 60-120 giây — trong thời gian đó connection sẽ bị ngắt. Single-AZ instance khi có sự cố có thể mất lâu hơn. Ngoài ra, có scheduled maintenance window có thể gây downtime ngắn. Hãy thiết kế app có connection retry logic.

Q: RDS có đắt không? Khi nào nên tự cài thay vì dùng RDS?

A: RDS đắt hơn EC2 tương đương khoảng 30-40% về compute. Tuy nhiên tính engineer time và rủi ro, RDS thường rẻ hơn với team nhỏ dưới 5 người. Tự cài chỉ hợp lý khi bạn có DBA chuyên nghiệp, cần cấu hình rất đặc biệt, hoặc workload cực lớn cần tối ưu từng byte.

Q: Làm sao migrate database từ EC2 sang RDS không downtime?

A: Dùng AWS Database Migration Service (DMS) — setup replication liên tục từ EC2 sang RDS, khi lag gần về 0 thì switch app sang endpoint mới. Downtime thực tế chỉ vài giây. Cần test kỹ schema compatibility trước, đặc biệt với stored procedures và triggers phức tạp.

Góc nhìn thực tế: Khi nào nên bắt đầu với RDS?

Nếu bạn đang xây dựng một ứng dụng mới — bắt đầu với RDS ngay từ đầu, đừng để mình rơi vào cái bẫy "tự cài cho rẻ" rồi sau này phải migrate đau đầu. Chi phí ban đầu cao hơn một chút nhưng bạn mua được thứ quý giá hơn: thời gian và sự yên tâm.

Nếu bạn đang chạy MySQL/PostgreSQL trên EC2 — đánh giá lại xem team bạn có đủ năng lực và thời gian để duy trì an toàn không. Bài tiếp theo trong series này sẽ hướng dẫn chi tiết cách tạo RDS và kết nối từ local trong 10 phút thực hành.