RDS, Aurora & ElastiCache
Nếu phải chọn một chương quyết định điểm số, đây là chương đó. Cặp Read Replica vs Multi-AZ xuất hiện dày đặc trong đề thật, và gần như luôn dưới dạng scenario bắt bạn phân biệt "scale đọc" với "chịu lỗi".
RDS Overview
RDS = Relational Database Service — dịch vụ database quan hệ được AWS quản lý, dùng SQL để truy vấn.
Bảy engine được hỗ trợ
PostgreSQL · MySQL · MariaDB · Oracle · Microsoft SQL Server · IBM Db2 · Amazon Aurora (bản độc quyền của AWS).
MongoDB không phải là engine của RDS — nó là NoSQL. Đề rất hay đưa MongoDB vào danh sách để bắt bạn loại ra. Nhu cầu NoSQL trên AWS thì dùng DynamoDB hoặc DocumentDB.
Vì sao dùng RDS thay vì tự cài database trên EC2
- Tự động cấp phát và vá lỗi hệ điều hành
- Backup liên tục và khôi phục về một thời điểm bất kỳ (Point in Time Restore)
- Bảng giám sát dựng sẵn
- Read Replica để tăng hiệu năng đọc
- Multi-AZ để chịu lỗi
- Cửa sổ bảo trì cho việc nâng cấp, khả năng scale dọc và ngang
- Lưu trữ nằm trên EBS (gp2/gp3 hoặc io1/io2)
Không SSH được vào instance RDS. Đây là cái giá của dịch vụ quản lý. Nếu bắt buộc phải vào máy, xem mục 9.3 (RDS Custom) hoặc tự cài database trên EC2.
RDS Storage Auto Scaling
Tự động tăng dung lượng khi database sắp đầy, không cần downtime. Bạn đặt Maximum Storage Threshold làm trần.
Điều kiện kích hoạt: dung lượng trống dưới 10% tổng cấp phát, tình trạng đó kéo dài ít nhất 5 phút, và đã 6 tiếng kể từ lần mở rộng gần nhất. Hỗ trợ mọi engine của RDS.
Một ứng dụng ghi log sự kiện người dùng vào RDS, lượng dữ liệu tăng thất thường theo chiến dịch marketing. Không có auto scaling thì đội vận hành phải canh dung lượng và mở rộng thủ công lúc nửa đêm — chậm tay là database ngừng ghi. Bật Storage Auto Scaling với trần 500 GB: hệ thống tự nới khi còn dưới 10% trống, và trần đó vẫn chặn được trường hợp bug ghi log vô hạn làm hóa đơn bùng nổ.
Read Replicas vs Multi-AZ
Đây là cặp khái niệm ra thi nhiều nhất chương. Chúng trông giống nhau (đều là bản sao database) nhưng giải hai bài toán hoàn toàn khác nhau.
| Read Replicas | Multi-AZ | |
|---|---|---|
| Mục đích | Scale khả năng đọc | Chịu lỗi / high availability |
| Kiểu replication | ASYNC → eventually consistent | SYNC → luôn nhất quán |
| Đọc được không | Được — đó là mục đích | KHÔNG — standby không phục vụ đọc hay ghi |
| Connection string | Phải đổi — mỗi replica có endpoint riêng | Giữ nguyên — một DNS name duy nhất |
| Số lượng | Tối đa 15 | 1 standby |
| Phạm vi | Cùng AZ, khác AZ, hoặc khác region | Một AZ khác trong cùng region |
| Failover | Thủ công (promote thành database độc lập) | Tự động, ứng dụng không cần can thiệp |
1. Multi-AZ KHÔNG dùng để scale đọc — standby nằm im, không phục vụ truy vấn nào. Đề hỏi "giải pháp nào KHÔNG phù hợp cho website đọc nhiều" thì đáp án chính là Multi-AZ.
2. Read Replica KHÔNG dùng cho disaster recovery — nó không tự failover.
3. Chỉ Multi-AZ giữ nguyên connection string. Read Replica sinh endpoint mới, ứng dụng phải sửa để trỏ tới.
Người dùng sửa bài viết trên mạng xã hội rồi tải lại trang và thấy nội dung cũ. Không phải lỗi ứng dụng: lệnh ghi đi vào database chính, còn lệnh đọc rơi vào một read replica chưa kịp nhận bản sao. Đó chính là eventual consistency do replication bất đồng bộ. Cách xử lý thường dùng: cho các truy vấn cần dữ liệu mới nhất đọc thẳng từ primary, phần còn lại mới đẩy sang replica.
Read Replica: đội BI chạy truy vấn phân tích nặng bất kể giờ nào, làm database production chậm hẳn. Dựng một read replica ở AZ khác và trỏ ứng dụng phân tích vào đó — production không còn bị ảnh hưởng, và đây cũng là phương án rẻ nhất vì chỉ tốn thêm một instance.
Multi-AZ: AZ chứa database chính mất điện. Standby ở AZ khác tự động lên thay trong 1–2 phút, ứng dụng không phải sửa dòng cấu hình nào vì DNS name không đổi.
Chi phí truyền dữ liệu
Thông thường truyền dữ liệu giữa các AZ trong AWS là mất tiền. Nhưng với RDS Read Replica trong cùng một region, AWS không tính phí này. Replica khác region thì có tính phí.
Chuyển từ Single-AZ sang Multi-AZ là thao tác không downtime — chỉ cần bấm "modify", không phải dừng database. Bên trong, AWS chụp snapshot, khôi phục thành standby rồi thiết lập đồng bộ.
Read Replica cũng bật được Multi-AZ cho chính nó — đây là mấu chốt của câu hỏi DR xuyên region ở mục dưới.
Yêu cầu: region chính sập thì database ở region khác phải sẵn sàng cho cả đọc lẫn ghi, và bản DR đó phải có tính sẵn sàng cao. Đáp án: tạo Read Replica ở region khác, rồi bật Multi-AZ trên chính Read Replica đó. Khi cần, promote replica thành database độc lập để ghi được.
RDS Custom
Chỉ dành cho Oracle và Microsoft SQL Server. Nó cho bạn toàn quyền quản trị hệ điều hành và database bên dưới: cấu hình sâu, cài patch riêng, bật tính năng gốc của engine, và truy cập được EC2 bên dưới qua SSH hoặc SSM Session Manager.
| RDS thường | RDS Custom |
|---|---|
| AWS quản lý toàn bộ OS và database, bạn không SSH được | Bạn có quyền admin đầy đủ, SSH được vào máy |
Trước khi tùy biến, hãy tắt Automation Mode và chụp snapshot — vì can thiệp tay có thể phá vỡ cơ chế tự động của AWS.
"Cần tùy biến toàn diện Oracle trên AWS nhưng vẫn muốn hưởng tiện ích dịch vụ quản lý" → RDS Custom for Oracle. Nếu đề chỉ nói "chạy Oracle bình thường" thì là RDS for Oracle; nếu nói "toàn quyền, tự lo mọi thứ" thì là Oracle trên EC2.
Backup, Snapshot & Aurora Cloning
Hai loại sao lưu
| Automated Backups | Manual DB Snapshots | |
|---|---|---|
| Ai kích hoạt | Tự động hàng ngày trong backup window | Bạn tự bấm |
| Transaction log | Sao lưu mỗi 5 phút → khôi phục về bất kỳ thời điểm nào | Không |
| Thời gian giữ | 1–35 ngày, đặt 0 để tắt | Giữ bao lâu tùy ý |
"Cần lưu backup dài hạn cho mục đích tuân thủ và kiểm toán" → Manual / On-Demand Snapshot, vì automated backup tối đa chỉ 35 ngày. Với Aurora, automated backup còn không thể tắt.
Database RDS đã stop vẫn tính tiền lưu trữ. Nếu định dừng lâu, hãy chụp snapshot rồi xóa database, khi cần thì khôi phục lại — rẻ hơn nhiều.
Aurora Database Cloning
Tạo một Aurora cluster mới từ cluster đang có, nhanh hơn hẳn snapshot rồi restore. Cơ chế: copy-on-write — ban đầu bản sao dùng chung volume dữ liệu với bản gốc, chỉ khi có thay đổi thì mới ghi dữ liệu mới ra vùng riêng.
Đội phát triển cần chạy một loạt test vừa đọc vừa ghi trên dữ liệu production, và cần ngay. Read replica không dùng được vì chỉ đọc. Test thẳng trên production thì ảnh hưởng khách hàng. Snapshot rồi restore thì mất hàng giờ với database lớn. Aurora Cloning dựng ra bản sao ghi được trong vài phút và gần như không tốn thêm dung lượng lúc đầu — đây là đáp án chuẩn cho tình huống "cần môi trường staging từ production ngay bây giờ".
RDS Security
Mã hóa at-rest
- Dùng KMS, AES-256, khai báo ngay lúc tạo database.
- Nếu master không mã hóa thì Read Replica cũng không thể mã hóa.
- Oracle và SQL Server còn có TDE (Transparent Data Encryption).
Giống hệt quy trình của EBS ở Section 7: chụp snapshot → copy snapshot và bật mã hóa → khôi phục database từ snapshot đã mã hóa → chuyển ứng dụng sang database mới rồi xóa cái cũ. Không có nút bật mã hóa trực tiếp trên database đang chạy.
Mã hóa in-flight
Dùng chứng chỉ SSL. Muốn bắt buộc dùng SSL: PostgreSQL đặt rds.force_ssl=1 trong parameter group; MySQL dùng lệnh GRANT ... REQUIRE SSL.
Bảo mật mạng & quản lý truy cập
- RDS thường nằm trong private subnet, không public.
- Kiểm soát bằng Security Group, giống EC2.
- IAM policy quyết định ai được quản trị RDS qua API — khác với việc đăng nhập vào database.
IAM Database Authentication
Cho phép đăng nhập vào database bằng danh tính IAM thay vì mật khẩu riêng.
| Đặc điểm | Chi tiết |
|---|---|
| Engine hỗ trợ | MySQL và PostgreSQL (cùng Aurora tương ứng) |
| Engine KHÔNG hỗ trợ | Oracle |
| Cơ chế | Không dùng mật khẩu; lấy auth token qua IAM và RDS API, token sống 15 phút |
| Lợi ích | Quản lý người dùng tập trung bằng IAM, kết nối bắt buộc mã hóa SSL, dùng được IAM Role cho EC2 |
Công ty vừa chuyển MySQL từ on-premise lên RDS, có 30 lập trình viên và mỗi người đã có sẵn một IAM user. Tạo 30 tài khoản database riêng nghĩa là 30 mật khẩu phải quản lý, và khi ai đó nghỉ việc thì phải nhớ xóa ở cả hai nơi. Bật IAM Database Authentication: xóa IAM user là mất luôn quyền vào database, không sót đường nào.
RDS Proxy
Proxy database được AWS quản lý, đứng giữa ứng dụng và RDS để gom và chia sẻ connection.
| Lợi ích | Chi tiết |
|---|---|
| Giảm tải database | Ít connection mở hơn → đỡ tốn CPU và RAM, giảm timeout |
| Giảm thời gian failover | Tới 66% — proxy giữ kết nối sống trong lúc database chuyển đổi |
| Vận hành | Serverless, tự co giãn, sẵn sàng cao (multi-AZ) |
| Bảo mật | Bắt buộc IAM Authentication, lưu credential trong Secrets Manager |
| Phạm vi truy cập | Không bao giờ public — chỉ truy cập được từ trong VPC |
| Sửa code | Hầu hết ứng dụng không cần sửa gì |
Có 100 EC2 instance cùng kết nối tới một RDS. Mỗi lần AWS bảo trì database, toàn bộ ứng dụng mất rất lâu mới kết nối lại được vì logic retry viết kém. Sửa 100 ứng dụng thì tốn công và rủi ro. RDS Proxy đứng giữa: nó chịu trách nhiệm giữ và tái lập kết nối, cắt thời gian failover xuống tới 66% mà không phải sửa dòng code nào.
Trường hợp thứ hai rất phổ biến: Lambda. Mỗi lần gọi hàm là một kết nối mới, hàng nghìn lần gọi đồng thời sẽ làm cạn connection pool của database — RDS Proxy sinh ra chính cho tình huống này.
Amazon Aurora
Aurora là công nghệ độc quyền của AWS, không mã nguồn mở. Nó tương thích với MySQL và PostgreSQL — driver hiện có dùng được ngay như đang nói chuyện với MySQL hoặc Postgres thật.
| Chỉ số | Con số |
|---|---|
| Hiệu năng | Nhanh hơn ~5 lần MySQL trên RDS, ~3 lần PostgreSQL trên RDS |
| Lưu trữ | Tự lớn theo bước 10 GB, tới 128 TB |
| Read Replica | Tối đa 15, độ trễ replica dưới 10 ms |
| Chi phí | Đắt hơn RDS khoảng 20% nhưng hiệu quả hơn |
| Failover | Gần như tức thì, dưới 30 giây cho master |
Kiến trúc lưu trữ — điểm làm nên Aurora
- 6 bản sao dữ liệu trải trên 3 AZ
- Cần 4/6 bản để ghi, 3/6 bản để đọc
- Tự phục hồi bằng replication ngang hàng, dữ liệu chia nhỏ trên hàng trăm volume
Hai endpoint cần nhớ
| Endpoint | Trỏ tới đâu |
|---|---|
| Writer Endpoint | Luôn trỏ tới master hiện tại — master đổi thì endpoint tự trỏ sang máy mới |
| Reader Endpoint | Tự cân bằng tải giữa toàn bộ read replica |
Với RDS, mỗi read replica có một endpoint riêng và ứng dụng phải tự chia tải. Với Aurora, chỉ cần trỏ vào Reader Endpoint là xong — thêm hay bớt replica đều trong suốt với ứng dụng.
Aurora nâng cao
Aurora Serverless
Database tự khởi tạo và tự co giãn theo mức dùng thật, trả tiền theo giây. Không cần dự trù công suất.
Đội phát triển cần một bản thu nhỏ của ứng dụng production để thử nghiệm, thỉnh thoảng chạy tải nặng nhưng đa số thời gian không ai dùng. Chạy Aurora thường nghĩa là trả tiền 24/7 cho một cụm ngồi không. Aurora Serverless tự thu về gần như không khi rảnh và bung lên khi có người test — đúng bài toán "workload thất thường, tối ưu chi phí".
Global Aurora
| Đặc điểm | Chi tiết |
|---|---|
| Cấu trúc | 1 region chính (đọc/ghi) + tối đa 5 region phụ (chỉ đọc) |
| Replica mỗi region phụ | Tối đa 16 |
| Độ trễ replication | Dưới 1 giây |
| Thời gian promote region khác | RTO dưới 1 phút |
"Cần bản sao database ở region khác phòng khi region chính gặp thảm họa" → Aurora Global Database. Đây cũng là cách giảm độ trễ cho người dùng ở châu lục khác. RDS Read Replica xuyên region cũng làm được nhưng Aurora Global là phương án được khuyến nghị.
Custom Endpoints
Định nghĩa một nhóm con các instance làm endpoint riêng — ví dụ gom các replica cấu hình mạnh để chạy truy vấn phân tích, tách khỏi các replica phục vụ ứng dụng. Khi đã dùng custom endpoint thì reader endpoint thường không còn được dùng nữa.
Các tính năng khác cần biết tên
- Replica Auto Scaling — tự thêm bớt read replica theo tải
- Aurora Multi-Master — mọi node đều ghi được, dành cho yêu cầu ghi liên tục không gián đoạn
- Backtrack — tua ngược dữ liệu về một thời điểm mà không cần dùng backup
- Aurora Machine Learning — gọi SageMaker hoặc Comprehend ngay trong câu SQL, dùng cho phát hiện gian lận, gợi ý sản phẩm, phân tích cảm xúc
ElastiCache
ElastiCache là Redis hoặc Memcached được quản lý — database trong bộ nhớ, hiệu năng rất cao, độ trễ rất thấp.
Hai công dụng chính: giảm tải cho database với workload đọc nhiều, và giúp ứng dụng trở thành stateless bằng cách đưa session ra ngoài.
Dùng ElastiCache đòi hỏi sửa code ứng dụng khá nhiều — phải tự viết logic đọc cache trước, ghi cache sau. Đây là điểm khác biệt so với Read Replica (chỉ đổi connection string).
Redis vs Memcached — bảng phải thuộc
| Redis | Memcached | |
|---|---|---|
| Multi-AZ + auto failover | Có | Không |
| Read Replica | Có — scale đọc và tăng sẵn sàng | Không có replication |
| Bền dữ liệu | Có (AOF persistence) | Không — mất là mất |
| Backup & restore | Có | Không |
| Kiểu dữ liệu | Sets và Sorted Sets | Chỉ key-value đơn giản |
| Kiến trúc | Đơn luồng | Đa luồng, chia dữ liệu qua nhiều node (sharding) |
Cần độ bền, sẵn sàng cao, backup, cấu trúc dữ liệu phong phú → Redis. Cần cache thuần túy, đa luồng, sharding, mất cũng không sao → Memcached. Trong đề thi, Redis xuất hiện nhiều hơn hẳn.
Ba mẫu sử dụng (caching patterns)
| Mẫu | Cách hoạt động | Nhược điểm |
|---|---|---|
| Lazy Loading | Đọc miss thì lấy từ database rồi mới nạp vào cache | Dữ liệu có thể cũ (stale) |
| Write Through | Ghi vào database thì ghi luôn vào cache | Không bị stale, nhưng cache chứa cả dữ liệu chẳng ai đọc |
| Session Store | Lưu session tạm trong cache kèm TTL | — |
Ứng dụng chạy trên ASG sau ALB, người dùng liên tục bị đăng xuất. Bật sticky session thì lo một số instance quá tải. Giải pháp chuẩn: lưu session vào ElastiCache. Mọi instance đều đọc được cùng một session, ứng dụng thành stateless, ASG thoải mái thêm bớt máy. RDS cũng lưu được session nhưng chậm hơn nhiều; EBS thì mặc định không chia sẻ giữa các instance.
Game cần xếp hạng người chơi theo thời gian thực theo điểm số. Dùng RDS thì mỗi lần điểm đổi phải sắp xếp lại cả bảng, không kịp. Redis Sorted Sets giữ sẵn thứ tự: mỗi lần thêm hoặc cập nhật điểm, phần tử tự nằm đúng vị trí trong danh sách. Đây là ứng dụng kinh điển nhất của Redis và xuất hiện gần như chắc chắn trong đề.
Bảo mật ElastiCache
- IAM Authentication cho Redis — đăng nhập bằng danh tính IAM (user, role). Đây là đáp án khi đề hỏi "cho phép truy cập bằng IAM identity".
- IAM policy trên ElastiCache chỉ dùng cho bảo mật ở mức API của AWS, không kiểm soát được truy cập ứng dụng.
- Redis AUTH — đặt mật khẩu/token khi tạo cluster, thêm một lớp bảo vệ trên Security Group, hỗ trợ mã hóa SSL.
- Memcached dùng xác thực kiểu SASL.
Danh sách port
Khóa học có riêng một bài chỉ để liệt kê port. Đề thi hỏi trực tiếp, không cần suy luận.
| Nhóm | Dịch vụ | Port |
|---|---|---|
| Thông dụng | FTP | 21 |
| SSH | 22 | |
| SFTP | 22 (dùng chung SSH) | |
| HTTP | 80 | |
| HTTPS | 443 | |
| Database | PostgreSQL | 5432 |
| MySQL | 3306 | |
| MariaDB | 3306 (giống MySQL) | |
| Oracle RDS | 1521 | |
| MS SQL Server | 1433 | |
| Aurora | Tùy engine tương thích | 5432 nếu PostgreSQL, 3306 nếu MySQL |
Ba số dễ lẫn: 3306 MySQL/MariaDB · 5432 PostgreSQL · 1521 Oracle · 1433 SQL Server. Nhớ theo cặp: hai chữ M dùng chung 3306; Oracle 1521 và SQL Server 1433 đều bắt đầu bằng 1.
Map từ khóa & cheat sheet
| Đề nhắc đến… | Nghĩ ngay tới |
|---|---|
| "chịu được sự cố một AZ", "high availability" | RDS Multi-AZ |
| "truy vấn phân tích làm chậm production" | Read Replica |
| "website đọc nhiều, giải pháp nào KHÔNG phù hợp" | Multi-AZ (nó không scale đọc) |
| "cập nhật xong không thấy dữ liệu mới ngay" | Replication bất đồng bộ của Read Replica |
| "không muốn đổi connection string" | Multi-AZ |
| "bản sao ở region khác cho DR" | Aurora Global Database |
| "DR xuyên region, phải ghi được và HA" | Read Replica khác region + bật Multi-AZ trên replica đó |
| "database dùng rất ít, tối ưu chi phí" | Aurora Serverless |
| "cần bản sao production để test đọc ghi ngay" | Aurora Cloning |
| "backup dài hạn để audit" | Manual snapshot (automated tối đa 35 ngày) |
| "100 EC2 kết nối chậm sau bảo trì" | RDS Proxy (giảm failover tới 66%) |
| "Lambda mở quá nhiều kết nối database" | RDS Proxy |
| "lập trình viên đăng nhập database bằng IAM user" | IAM Database Authentication (không hỗ trợ Oracle) |
| "người dùng phải đăng nhập lại, không muốn sticky session" | Lưu session vào ElastiCache |
| "bảng xếp hạng thời gian thực" | ElastiCache for Redis — Sorted Sets |
| "tùy biến toàn diện Oracle nhưng vẫn muốn dịch vụ quản lý" | RDS Custom for Oracle |
| "MongoDB" | Không phải RDS — DynamoDB hoặc DocumentDB |
Cheat sheet 90 giây
- RDS engine: PostgreSQL, MySQL, MariaDB, Oracle, SQL Server, Db2, Aurora — không có MongoDB.
- Không SSH được vào RDS, trừ RDS Custom (chỉ Oracle và SQL Server).
- Read Replica: tối đa 15, ASYNC, đọc được, phải đổi connection string, không dùng cho DR.
- Multi-AZ: SYNC, standby không đọc được, giữ nguyên connection string, tự failover.
- Read Replica cùng region miễn phí phí truyền dữ liệu; khác region thì tính phí.
- Backup tự động 1–35 ngày; cần lâu hơn thì dùng manual snapshot.
- Mã hóa: master không mã hóa thì replica cũng không thể mã hóa. Muốn mã hóa database cũ: snapshot → copy có mã hóa → restore.
- IAM DB Authentication: MySQL và PostgreSQL có, Oracle không; token sống 15 phút.
- RDS Proxy: giảm failover tới 66%, không public, rất hợp với Lambda.
- Aurora: 6 bản sao / 3 AZ, ghi cần 4/6, đọc cần 3/6; lưu trữ tới 128 TB; nhanh hơn MySQL ~5 lần; đắt hơn RDS ~20%.
- Aurora Global: 1 primary + tối đa 5 secondary region, replication dưới 1 giây, RTO dưới 1 phút.
- Redis có replica, backup, Multi-AZ, Sorted Sets. Memcached đa luồng, sharding, không bền, không backup.
- Port: 3306 MySQL/MariaDB · 5432 PostgreSQL · 1521 Oracle · 1433 SQL Server.
Sáu câu tự kiểm tra trước khi qua file quiz
1. Website tin tức đọc nhiều ghi ít, database quá tải. Giải pháp nào KHÔNG giúp được?
2. Tính năng nào của RDS không bắt bạn đổi connection string?
3. Database RDS chưa mã hóa, muốn tạo read replica có mã hóa. Được không?
4. Aurora lưu bao nhiêu bản sao dữ liệu và trên mấy AZ?
5. Cần backup giữ 3 năm cho mục đích kiểm toán. Dùng gì?
6. Engine RDS nào không hỗ trợ IAM Database Authentication?
Đáp án: (1) Multi-AZ — standby không phục vụ đọc; ElastiCache và Read Replica đều giúp được. (2) Multi-AZ — DNS name không đổi dù database nào đang hoạt động. (3) Không — master chưa mã hóa thì replica không thể mã hóa. (4) 6 bản sao trên 3 AZ, ghi cần 4/6, đọc cần 3/6. (5) Manual snapshot, vì automated backup tối đa 35 ngày. (6) Oracle — chỉ MySQL và PostgreSQL hỗ trợ.