Nội dung được biên soạn lại từ Anh Nguyen - kèm nguồn bài viết (nếu có)

Trong vài năm làm quản lý hệ thống và xây dựng website thương mại điện tử, có một chủ đề mình nhận thấy nhiều người… hiểu sai hoặc bỏ qua hoàn toàn: S3 Storage Class trong Amazon Web Services (AWS).

Chúng ta dùng AWS để backup site vì độ bền dữ liệu “11 số 9”, nhưng nếu cấu hình storage class sai – bạn sẽ phải trả mức phí rất cao, hoặc tệ hơn, backup của bạn không thể restore ngay khi bạn cần.

Vì vậy hôm nay, mình chia sẻ lại toàn bộ trải nghiệm, phân tích và best practices khi dùng S3 để lưu backup WordPress/WooCommerce/PHP app.

1. Storage Class là gì và tại sao bạn phải quan tâm?

Mỗi file trong S3 sẽ được đặt trong một loại storage class. Class đó quyết định:

• File được nhân bản ở bao nhiêu nơi?
• Tốc độ tải và restore?
• Chi phí lưu trữ bao nhiêu?
• Có bị tính phí tối thiểu 30–180 ngày không?
• Có bị tính phí khi truy xuất (retrieval fee) không?

Nếu bạn chọn class chuẩn, bạn sẽ:

• Tiết kiệm 40–90% chi phí,
• Luôn có bản backup sẵn sàng restore,
• Không bị tính phí ẩn của Glacier/IA.

Nếu chọn sai? Bạn có thể mất vài trăm nghìn – vài triệu phí lưu trữ, hoặc tệ hơn là phải chờ 12 tiếng để bung file backup khi website đang chết.

2. Bảng so sánh nhanh tất cả S3 Storage Class

2.1. S3 Standard

• Dùng cho: dữ liệu truy cập thường xuyên, cần restore ngay lập tức.
• Tốc độ truy cập: nhanh nhất (millisecond).
• Độ bền: 11 số 9 (99.999999999%).
• Độ sẵn sàng: rất cao (99.99%).
• Chi phí: cao nhất trong các class S3 phổ biến.
• Phí thêm: không có phí khôi phục.

Hợp cho:

• Backup ngày hôm nay / ngày hôm qua – lúc site crash là cần ngay bản này.

2.2. S3 Standard-IA (Infrequent Access)

• Dùng cho: dữ liệu đọc không thường xuyên nhưng khi cần vẫn muốn lấy ngay lập tức.
• Tốc độ truy cập: gần như Standard.
• Độ sẵn sàng: thấp hơn chút (99.9%).
• Chi phí lưu trữ/GB: rẻ hơn Standard.
• Phí thêm: có phí truy cập/GB khi đọc dữ liệu.
• Tối thiểu lưu: ~30 ngày (bị charge tối thiểu 30 ngày).

Hợp cho:

• Backup 1–3 ngày gần nhất, khi vẫn có khả năng phải restore nhưng không đọc hàng ngày.
• File lớn, đọc ít.

2.3. S3 One Zone-IA

• Giống Standard-IA nhưng:
  • Dữ liệu chỉ lưu trong 1 AZ thay vì nhiều AZ.
  • Rẻ hơn Standard-IA.
  • Rủi ro hơn nếu AZ gặp sự cố.

Hợp cho:

• Backup mà bạn chấp nhận rủi ro mất luôn nếu hạ tầng AWS lỗi 1 AZ (thường là hiếm).
• Không nên dùng nếu bucket này là backup duy nhất của bạn.

2.4. S3 Intelligent-Tiering

• Dùng cho: không biết chính xác pattern truy cập.
• AWS tự move object giữa các tier (frequent / infrequent / archive…) dựa trên hành vi.
• Có phí monitoring nhỏ nhưng giảm công cấu hình.
• Chi phí tổng hợp thường ổn nếu dữ liệu được truy cập thất thường.

Với backup:

• Không thực sự cần; behavior của backup rất rõ (đa phần không đụng lại, chỉ khi sự cố).
• Cấu hình Lifecycle rule chủ động thường rẻ & kiểm soát tốt hơn.

2.5. S3 Glacier Instant Retrieval

• Dùng cho: dữ liệu truy cập rất ít, nhưng khi cần thì vẫn muốn lấy ngay (ms).
• Tốc độ: gần như Standard/IA.
• Chi phí: rẻ hơn Standard-IA, nhưng có phí truy cập/khôi phục.
• Tối thiểu lưu: ~90 ngày.

Hợp cho:

• Backup tầm 3–30 ngày tuổi, vẫn muốn restore nhanh nhưng likelihood restore thấp.
• Rất hợp cho backup trung hạn.

2.6. S3 Glacier Flexible Retrieval (trước đây là Glacier)

• Dùng cho: archive dài hạn, không cần khôi phục ngay.
• Tốc độ restore:
  • Expedited: vài phút (đắt).
  • Standard: vài giờ.
  • Bulk: vài giờ đến ~12h, rẻ nhất.
• Chi phí lưu trữ: rẻ hơn Glacier Instant.
• Tối thiểu lưu: ~90 ngày.

Hợp cho:

• Backup tháng trước/tháng kia, phòng tình huống rất xấu (bị hack, xoá nhầm lâu không phát hiện).
• Không phù hợp cho bản backup bạn muốn kéo về ngay lúc site down.

2.7. S3 Glacier Deep Archive

• Dùng cho: archive dài hạn, gần như không bao giờ phải dùng, nhưng cần lưu trữ tuân thủ / phòng cháy nổ dữ liệu.
• Tốc độ restore: thường từ vài giờ đến 12–24h (tùy mode).
• Chi phí lưu trữ: rẻ nhất, cực kỳ rẻ.
• Tối thiểu lưu: ~180 ngày.

Hợp cho:

• Backup lâu đời: bản tháng, bản năm, chống tai nạn lớn (hacker, xoá toàn bộ, lỗi human).
• Không dùng cho backup cần gấp trong ngày.

2.8. Reduced Redundancy Storage (RRS)

Class cũ, ít dùng, ít lợi so với IA/One Zone-IA hiện tại. Bỏ qua, không dùng.

3. Sai lầm phổ biến khi backup website lên S3

❌ 1. Đưa tất cả backup vào Standard-IA

• IA rẻ hơn Standard, nhưng bắt buộc phải lưu tối thiểu 30 ngày.
• Nếu bạn delete sau 7 ngày → AWS vẫn charge đủ 30 ngày.

❌ 2. Chuyển sang Glacier hoặc Deep Archive quá sớm

• Glacier → tối thiểu 90 ngày
• Deep Archive → tối thiểu 180 ngày
• Dùng cho backup 7–10 ngày là sai hoàn toàn → bạn tốn tiền nhiều hơn.

❌ 3. Dùng One Zone-IA cho backup duy nhất

• One Zone-IA chỉ lưu file trong 1 AZ (1 data center) trong region.
• Nếu AZ đó gặp sự cố, bạn có thể mất hết backup.
• Không đáng để đánh đổi.

4. Chiến lược backup tối ưu dành cho website

Với một website, có 2 câu hỏi chính:

• RTO (Recovery Time Objective): Site down, bạn chấp nhận chết tối đa bao lâu? 5 phút? 1 giờ?
• RPO (Recovery Point Objective): Chấp nhận mất tối đa bao nhiêu data? (ví dụ mất 24h order, hay 1h order?)

Thường với online store nhỏ–vừa:

• RTO: càng nhanh càng tốt, < 1 giờ là lý tưởng.
• RPO: mất tối đa 1 ngày data (order có thể sync lại từ platform, mail, v.v.).

Sau nhiều lần test và tối ưu chi phí, đây là blueprint dùng tốt nhất cho website:

4.1. Lớp 1: Hot Backup – cần restore ngay lập tức

Mục tiêu: Site chết hôm nay → kéo bản đêm qua / sáng nay về trong vài phút.

Bạn backup hàng ngày và backup gần nhất luôn cần lấy được ngay lập tức. Standard cho phép restore trong vài giây.

Storage class đề xuất:

• Ngày 0: S3 Standard
• Ngày 1: S3 Standard-IA hoặc vẫn Standard nếu truy cập nhiều.

Độ tuổi: Ngày 0 – 1

Cách làm:

• Cron backup lên S3 hằng ngày (hoặc 2 lần/ngày nếu traffic/order lớn).
• Lifecycle rule:
• Không transition trong 24h đầu.
• Sau 1 ngày → chuyển sang Standard-IA.
• Xoá sau 2 ngày (tuỳ bạn).

4.2. Lớp 2: Warm Backup – độ tuổi 3–30 ngày

Mục tiêu: Phát hiện lỗi, hack, malware… muộn vài ngày, cần quay lại bản trước đó 3–10 ngày nhưng vẫn muốn restore khá nhanh.

Storage class đề xuất:

• Day 2–7 (hoặc 2–30): Glacier Instant Retrieval Hoặc nếu muốn rẻ hơn nữa nhưng chấp nhận restore chậm hơn:

• Day 7–30: Glacier Flexible Retrieval

  hoặc

• Standard-IA (nếu muốn tải lại không phí retrieval)

Dùng khi:

• Site bị hack từ vài ngày trước
• Có lỗi không phát hiện ngay
• Plugin gây corrupt dữ liệu

Lifecycle rule gợi ý:

• 30 days → chuyển sang Standard-IA
• 60 days → chuyển sang Glacier Instant Retrieval

4.3. Lớp 3: Cold Backup – lưu dài hạn 3–12 tháng

Mục tiêu: Gặp kịch bản xấu nhất: bị hack âm thầm 1–2 tháng mới phát hiện, cần bản 2–6 tháng trước.

Storage class đề xuất: Glacier Deep Archive

Dành cho phương án cuối — cực rẻ, phòng trường hợp:

• Bị xoá sạch dữ liệu hosting
• Bị hacker nắm site 2–6 tháng
• Muốn audit lại site cũ
• Nguyên nhân lỗi phát sinh từ nhiều tháng trước

Cách dùng:

• Mỗi tháng giữ 1 bản snapshot (full backup), upload thẳng vào Deep Archive hoặc:
  • Dùng Lifecycle rule: sau 60–90 ngày, chuyển các object cũ sang Deep Archive.
• Có thể giữ 6–12 bản monthly (tức 6–12 tháng).

Lifecycle rule:

• 180 ngày → Deep Archive
• 365 ngày → Delete

Tại sao không dùng One Zone-IA?

Nhiều bạn hỏi:

“Tôi ở Việt Nam, region Singapore, vậy dùng One Zone-IA có sao đâu?”

One Zone-IA → file chỉ lưu trong 1 AZ Standard-IA → file lưu trên nhiều AZ trong region

Điều này nghĩa là:

• Nếu 1 AZ gặp sự cố, Standard/IA vẫn sống
• One Zone-IA có thể mất sạch dữ liệu

Backup là lưới cứu sinh cuối cùng. Đừng đánh cược vào sự may rủi của 1 AZ.

5. Thực tế cấu hình S3 Lifecycle như nào?

Nếu bạn dùng daily backup (7 ngày), cấu hình hợp lý nhất là:

Bucket 1: Daily backups (7 ngày)

• Class upload: Standard
• Lifecycle:
  • Delete after 7 days

→ Không transition vì thời gian sống < 30 ngày.

Bucket 2: Monthly backups (1–12 tháng)

• 30 days → chuyển sang Standard-IA
• 60 days → chuyển sang Glacier Deep Archive
• Expire after 365–720 days

Đây mới là nơi bạn tiết kiệm chi phí mạnh.

Thực hành cấu hình trên S3 Lifecycle ngay như sau:

(1) Giữ file ở STANDARD / STANDARD_IA trong 1 ngày đầu

Bạn không cần đặt rule cho “Day 0–1” vì file upload mặc định đã nằm ở STANDARD. Không cần “transition” xuống STANDARD IA — file tự nằm ở class ban đầu bạn upload.

Nếu muốn chuyển sang STANDARD_IA ngay trong ngày thứ 1, tạo rule:

• Transition to STANDARD_IA
• After 1 day

(2) Chuyển sang Deep Archive từ ngày thứ 2

Trong phần Transitions, chọn:

• Transition to Glacier Deep Archive
• Days after upload: 2

→ Hiệu quả: Backup của ngày hôm kia sẽ tự chuyển vào Deep Archive.

(3) Xóa backup sau 7 ngày

Trong phần Expiration:

• Expire current versions of objects
• Days after upload: 7

7. Tiết kiệm được bao nhiêu?

Dựa trên thực tế sử dụng:

• Standard: ~0.023 USD/GB/tháng
• Glacier Deep Archive: ~0.00099 USD/GB/tháng

=> Nếu bạn giữ 12 bản backup tháng (ví dụ 2GB mỗi bản):

• Standard: 12 × 2GB × 0.023 ≈ 0.55 USD/tháng
• Deep Archive: 12 × 2GB × 0.00099 ≈ 0.024 USD/tháng

Tiết kiệm: ~ 95%+ chi phí, nhưng vẫn giữ dữ liệu cực kỳ an toàn.

8. Kết luận

Nếu bạn đang backup website lên S3 mà chưa phân loại rõ storage class, bạn đang:

• Hoặc tốn quá nhiều tiền,
• Hoặc không thể restore khi cần,
• Hoặc vô tình đặt backup vào rủi ro mất dữ liệu.

Chiến lược tốt nhất:

• ✔ 1–2 ngày đầu → STANDARD
• ✔ 3–30 ngày → Glacier Instant Retrieval / Standard-IA
• ✔ 30–365 ngày → Glacier Deep Archive
• ✔ Dưới 30 ngày → Không dùng IA/Glacier (vì AWS tính phí tối thiểu)

Trải nghiệm tốt nhất từ thực hành — Anh Nguyen