Dịch vụ Object Storage tại Việt Nam: So sánh giá, egress và độ trễ

Vì sao "giá rẻ theo GB" chưa đủ khi chọn object storage cho ứng dụng web? Câu trả lời ngắn gọn: khi web của bạn có traffic thực, chi phí egress và request thường vượt xa chi phí lưu trữ thuần túy. Một dịch vụ niêm yết 900đ/GB/tháng nhưng tính 999đ cho mỗi GB tải ra hoàn toàn có thể đắt hơn một giải pháp có giá storage cao hơn một chút, nếu ứng dụng của bạn phục vụ hàng triệu request GET mỗi ngày.

Bài viết này xây dựng một framework để bạn tự đánh giá và lựa chọn: cách tính TCO thực sự, kiến trúc giảm độ trễ bằng CDN, playbook migration S3-compatible, và checklist đo latency có thể kiểm chứng được.

Object storage là gì và khác gì file/block storage khi tối ưu web?

Object storage lưu dữ liệu dưới dạng "object" trong "bucket", mỗi object đi kèm metadata tùy chỉnh và được truy xuất qua HTTP/HTTPS theo URL. Không có cấu trúc thư mục thực sự, không có filesystem mount, không có inode — đây là điểm khác biệt cốt lõi so với file storage (NFS/CIFS) và block storage (ổ đĩa ảo).

Với ứng dụng web, điều đó có nghĩa là:

• File tĩnh (ảnh, CSS, JS, video, PDF), dataset AI, log, backup đều phù hợp dùng object storage.
• Không phù hợp cho database cần ghi random hoặc filesystem chia sẻ giữa nhiều process.

Về kiến trúc: khi traffic nhỏ và người dùng tập trung gần data center, bạn có thể gọi thẳng từ trình duyệt xuống origin object storage. Khi traffic lớn hơn hoặc người dùng phân tán, CDN đứng trước làm lớp cache là bắt buộc — chỉ khi CDN miss mới gọi về origin. Lựa chọn này ảnh hưởng trực tiếp đến cả chi phí egress và latency người dùng cuối.

Đọc thêm: Object Storage cho Big Data & AI: Hướng dẫn kiến trúc, tối ưu chi phí và triển khai doanh nghiệp 2026

Tiêu chí chọn "giá tốt + độ trễ thấp" tại Việt Nam

1. Chi phí TCO: không chỉ là đồng/GB/tháng

TCO (Total Cost of Ownership) của object storage gồm ít nhất 4 cấu phần:

Lưu ý VAT: hầu hết nhà cung cấp tại Việt Nam tính thêm 10% VAT trên bảng giá niêm yết, nên giá thực tế trả có thể khác. Luôn kiểm tra điều kiện và ngưỡng miễn phí trước khi ký hợp đồng.

2. Độ trễ: vị trí data center quan trọng hơn bạn nghĩ

Object storage đặt tại Hà Nội hay TP.HCM phục vụ người dùng nội địa rõ ràng nhanh hơn bucket đặt ở Singapore hay Tokyo, đặc biệt với file nhỏ (ảnh thumbnail, file JSON) vì round-trip time chiếm phần lớn độ trễ tổng. Khi dùng CDN phía trước, vị trí CDN node quan trọng hơn vị trí origin — nếu CDN có node tại Hà Nội và TP.HCM, cache hit từ CDN cho latency dưới 10ms, bất kể origin đặt ở đâu.

3. Tính tương thích S3 API

S3 API (Amazon S3-compatible interface) là tiêu chuẩn thực tế của ngành. Nếu nhà cung cấp hỗ trợ S3-compatible, bạn có thể dùng ngay:

• AWS CLI: aws s3 cp, aws s3 sync với --endpoint-url tùy chỉnh
• rclone: công cụ sync đa nền tảng, hỗ trợ hàng chục storage backend
• Các SDK phổ biến: boto3 (Python), AWS SDK (Java, Go, JS)
• WordPress plugin, Laravel Flysystem, v.v.

Thiếu S3-compatible nghĩa là bạn phải viết lại code tích hợp mỗi khi đổi nhà cung cấp — đây là chi phí ẩn đáng kể.

Các tính năng S3 cần kiểm tra thêm: presigned URL (cho upload trực tiếp từ browser), multipart upload (cho file lớn), versioning, server-side encryption, CORS policy.

4. SLA và độ tin cậy

Các chỉ số cần hỏi nhà cung cấp:

• Durability: tỷ lệ bảo toàn dữ liệu, thường nêu dạng "99.999999999%" (11 nines)
• Uptime SLA: 99.9% hay 99.99%? Downtime 4.4 giờ/năm so với 52 phút rất khác nhau cho production
• Replication: đồng bộ single-zone hay multi-zone? Nếu zone sập thì dữ liệu vẫn truy xuất được không?
• Audit log: có log truy xuất/xóa để debug và compliance không?

5. Quy trình triển khai và migration

Chi phí ẩn cuối cùng là thời gian kỹ sư. Nhà cung cấp có tài liệu migration rõ ràng, hỗ trợ S3-compatible và endpoint ổn định sẽ giảm đáng kể thời gian này.

So sánh nhanh các nhà cung cấp object storage phổ biến tại Việt Nam

Bảng dưới tổng hợp từ thông tin công khai trên trang của từng nhà cung cấp tại thời điểm tháng 8/2026. Giá chưa bao gồm VAT, có thể thay đổi, và thường có điều kiện đi kèm.

Lưu ý quan trọng: giá thực tế phụ thuộc vào volume, pattern truy cập (hot vs cold), tỷ lệ cache hit khi có CDN, và điều khoản hợp đồng cụ thể. Luôn yêu cầu bảng giá đầy đủ bao gồm egress và request fee trước khi quyết định.

Nguồn: trang web chính thức của từng nhà cung cấp, truy cập tháng 8/2026.

Bảng giá mẫu và cách tự tính chi phí tháng (TCO calculator)

Dưới đây là 3 kịch bản minh họa. Bạn có thể thay số của mình vào để ước tính.

Kịch bản 1: Website content tĩnh nhỏ

• Dung lượng lưu trữ: 100GB
• Egress/tháng: 500GB (tải ra, ví dụ dùng CDN thấp, request origin nhiều)
• GET request: 5 triệu/tháng

Với giá mẫu 530đ/GB storage + giả sử 200đ/GB egress + phí request:

Storage: 100 × 530đ = 53.000đ
Egress: 500 × 200đ = 100.000đ
Chi phí request (nếu có): cộng thêm tùy nhà cung cấp

Bài học: với site nhỏ nhưng egress cao (không dùng CDN), egress cost vượt storage cost từ 2–3x trở lên.

Kịch bản 2: Nền tảng media 1TB + traffic cao

• Dung lượng lưu trữ: 1TB
• Egress/tháng: 5TB (video streaming, không có CDN)
• GET request: 50 triệu/tháng

Đây là kịch bản egress-heavy. Nếu nhà cung cấp tính 999đ/GB egress, chỉ riêng 5TB egress đã là 4.995.000đ, trong khi storage 1TB ở 530đ/GB chỉ 542.720đ. Egress chiếm 90% tổng chi phí — đây chính là lý do CDN cache là ưu tiên số một cho media platform.

Kịch bản 3: 10TB backup/lưu trữ lạnh

• Dung lượng lưu trữ: 10TB (archive/cold)
• Egress/tháng: < 100GB (restore hiếm khi)
• Request: thấp

Với lưu trữ lạnh/archive, chi phí storage chiếm phần lớn. Nếu nhà cung cấp hỗ trợ lifecycle rule để tự động chuyển object sang cold class, bạn có thể giảm 30–60% chi phí storage so với để toàn bộ ở hot tier.

Cách dùng lifecycle để tối ưu chi phí

Lifecycle rule cho phép bạn định nghĩa: "object không truy cập trong 30 ngày, chuyển sang cold tier; không truy cập trong 90 ngày, chuyển sang archive." Điều này hoàn toàn tự động và không cần thay đổi code ứng dụng. Nhà cung cấp hỗ trợ lifecycle S3-compatible thường dùng cú pháp XML tương tự AWS S3.

Để chọn đúng class, hãy đo access pattern thực tế qua access log storage trong ít nhất 2 tuần trước khi cấu hình lifecycle. Đừng đoán.

Cách tối ưu độ trễ cho ứng dụng web khi dùng object storage

Kiến trúc khuyến nghị

Browser → CDN (cache hit: ~5-15ms) → [cache miss] → Origin Object Storage (50-150ms nội địa)

Quy tắc cơ bản: CDN làm lớp cache phía trước, origin object storage chỉ nhận request khi CDN miss. Với tỷ lệ cache hit 90%+ trên content tĩnh (ảnh, CSS, JS), phần lớn người dùng nhận response từ CDN node gần nhất trong vài chục ms, không phụ thuộc vào latency origin.

GreenNode vận hành hạ tầng với 6 availability zones tại Hà Nội, TP.HCM và Bangkok cùng 20+ CDN node khu vực, giúp giảm đáng kể time-to-first-byte cho người dùng cuối tại Việt Nam mà không cần định tuyến ra ngoài khu vực.

Thiết lập headers quan trọng

Để CDN cache hiệu quả, object storage cần trả về đúng headers:

• Cache-Control: max-age=31536000, immutable cho asset có hash trong filename (bundle.abc123.js)
• Cache-Control: max-age=3600 cho asset thay đổi theo giờ (ảnh sản phẩm, thumbnail)
• ETag hoặc Last-Modified để CDN/browser xác nhận freshness mà không cần tải lại toàn bộ file
• Content-Encoding: gzip hoặc br nếu CDN/proxy hỗ trợ compression
• Access-Control-Allow-Origin cho CORS (bắt buộc nếu web app gọi storage từ domain khác)

Chiến lược file naming và upload lớn

File naming ảnh hưởng đến cache invalidation: dùng content-hash trong tên file (image.abc123.webp) thay vì timestamp giúp CDN cache lâu hơn và giảm revalidation request.

Với file lớn (> 100MB), dùng multipart upload: chia file thành các part 5–100MB, upload song song, và object storage ghép lại. Điều này giảm thời gian upload đáng kể và cho phép resume khi bị ngắt.

Checklist đo latency thực tế

Trước khi kết luận dịch vụ "nhanh" hay "chậm", hãy đo theo các chỉ số sau:

• p95/p99 latency GET từ nhiều điểm đo trong VN (Hà Nội, TP.HCM, Đà Nẵng): dùng curl -w "%{time_total}" hoặc công cụ như k6, Locust
• Time-to-first-byte (TTFB) của CDN so với direct origin: nên thấp hơn ít nhất 50–70% khi CDN hit
• Cache hit ratio: CDN thường cung cấp dashboard. Target > 85% với content tĩnh
• So sánh trước/sau khi bật CDN: chụp p95 TTFB trước và sau khi bật CDN cache để có số liệu kiểm chứng
• Egress thực tế/tuần đầu: theo dõi traffic từ origin để ước tính chi phí thực

Hướng dẫn migration nhanh cho người dùng S3-compatible (playbook)

Quy trình 7 bước

Bước 1: Inventory — liệt kê tất cả bucket, object, ACL policy, CORS config, và lifecycle rule hiện tại. Export danh sách object kèm checksum (MD5/ETag).

Bước 2: Tạo bucket mới — tạo bucket trên nhà cung cấp mới với cùng cấu trúc tên. Kiểm tra region/endpoint đúng trước khi sync.

Bước 3: Mapping ACL/policy — chuyển đổi policy từ nguồn sang đích. Lưu ý: cú pháp policy JSON của các nhà cung cấp S3-compatible có thể khác nhau ở một số chi tiết (Principal, Resource ARN format).

Bước 4: Dry-run — chạy aws s3 sync --dryrun hoặc rclone check để xem danh sách file sẽ được copy mà không thực sự copy.

Bước 5: Sync incremental — copy dữ liệu, ưu tiên hot data trước. Ví dụ lệnh mẫu:

# Dùng AWS CLI với endpoint tùy chỉnh
aws s3 sync s3://source-bucket s3://dest-bucket \
  --source-region <region-nguon> \
  --endpoint-url https://<endpoint-dich> \
  --no-progress

# Dùng rclone (cần cấu hình rclone.conf cho cả 2 remote)
rclone sync source-remote:bucket dest-remote:bucket --progress --checksum

Bước 6: Validate checksum — so sánh ETag/MD5 của object nguồn và đích. rclone check làm điều này tự động. Với AWS CLI, dùng --checksum-algorithm để bật kiểm tra.

Bước 7: Chuyển traffic theo phase — đổi DNS/CDN origin hoặc biến môi trường STORAGE_ENDPOINT trong ứng dụng theo từng service, không chuyển tất cả cùng lúc. Giữ dữ liệu nguồn thêm 7–14 ngày sau khi traffic chuyển hoàn toàn.

Checklist lỗi thường gặp khi migration

Câu hỏi thường gặp: Object storage nào rẻ và độ trễ thấp cho web ở Việt Nam?

Có phải chỉ cần chọn giá rẻ nhất theo GB là đủ không?

Không. Giá storage chỉ là một phần của TCO. Với ứng dụng web có traffic thực, egress fee và request fee thường chiếm 60–80% tổng hóa đơn. Onie Cloud, ví dụ, niêm yết storage 399đ/GB nhưng egress 999đ/GB (nguồn: trang Onie Cloud, tháng 8/2026). Nếu ứng dụng của bạn egress nhiều, chi phí thực tế sẽ rất khác so với ước tính chỉ từ giá storage.

Egress là gì và ảnh hưởng gì đến web?

Egress (băng thông tải ra) là lưu lượng data rời khỏi hệ thống storage về phía internet hoặc sang hệ thống khác. Mỗi khi trình duyệt người dùng tải ảnh, video, hay file từ object storage, bạn bị tính egress fee. Với CDN, egress từ origin giảm mạnh vì CDN cache phần lớn request, chỉ cache miss mới gọi về origin.

S3-compatible có nghĩa là gì với ứng dụng?

S3-compatible nghĩa là nhà cung cấp triển khai S3 API của Amazon Web Services. Ứng dụng dùng AWS SDK, boto3, hoặc AWS CLI có thể kết nối bằng cách đổi endpoint_url mà không cần viết lại logic. Đây là yếu tố quyết định tốc độ tích hợp và chi phí kỹ sư khi đổi nhà cung cấp.

Làm sao giảm độ trễ khi dùng object storage?

Ba bước: (1) chọn nhà cung cấp có data center nội địa gần người dùng, (2) đặt CDN phía trước với cache-control headers đúng, (3) dùng content-hash trong filename để cache CDN không expire sớm. Đây là kiến trúc giảm TTFB hiệu quả nhất, thường từ 150–300ms xuống còn 10–30ms với tỷ lệ cache hit cao.

Có cần lifecycle để tối ưu chi phí không?

Có, đặc biệt với ứng dụng lưu nhiều data log, backup, hoặc media archive. Lifecycle rule tự động chuyển object sang cold/archive tier sau X ngày không truy cập, giảm 30–60% chi phí storage mà không cần thay đổi code. Nhà cung cấp S3-compatible thường hỗ trợ lifecycle XML tương thích AWS.

SLA và durability thường cam kết ở mức nào?

Các nhà cung cấp lớn thường cam kết durability 99.999999999% (11 nines), tức xác suất mất data cực thấp nhờ replication multi-zone. Uptime SLA thường từ 99.9% (tương đương tối đa 8.7 giờ downtime/năm) đến 99.99% (52 phút). Với production workload, hãy yêu cầu SLA cụ thể bằng văn bản và hiểu rõ cơ chế compensation nếu vi phạm SLA.

Nhận tư vấn chọn cấu hình theo workload của bạn

Không có cấu hình "tốt nhất" chung cho mọi ứng dụng. GreenNode Object storage cung cấp object storage hiệu năng cao với S3-compatible API, triển khai trên 6 availability zones tại Hà Nội, TP.HCM và Bangkok, phù hợp cho cả ứng dụng web cần low-latency lẫn AI pipeline xử lý dữ liệu lớn.

Để đề xuất phương án tối ưu cho workload cụ thể của bạn, chúng tôi cần 5 thông tin:

1. Dung lượng hot/cold: bao nhiêu GB/TB data "nóng" (truy cập thường xuyên) và "lạnh" (archive/backup)?
2. Egress dự kiến: ước tính GB/TB tải ra mỗi tháng, có dùng CDN không?
3. Số request/tháng: PUT/GET/LIST ước tính, đặc biệt với web có nhiều request nhỏ.
4. Loại nội dung: ảnh sản phẩm, video streaming, file PDF, dataset AI, hay backup?
5. Yêu cầu bảo mật/tuân thủ: có cần data residency tại VN, audit log, encryption at rest, hay tuân thủ theo ngành (tài chính, y tế)?

Gửi thông tin qua trang liên hệ GreenNode hoặc gọi hotline để được tư vấn kiến trúc và chi phí theo workload thực tế. Đội ngũ kỹ thuật tại Hà Nội và TP.HCM hỗ trợ 24/7 bằng tiếng Việt.

Nếu bạn đang xây dựng pipeline AI hoặc cần object storage tích hợp với Kubernetes và database, hãy tìm hiểu GreenNode để hiểu cách Object storage kết hợp với VKS (managed Kubernetes) và các dịch vụ dữ liệu khác trong cùng một kiến trúc khu vực.