Khi nào nên rời cloud về on-prem? Bài toán repatriation

Sau 3 năm "lên mây", hóa đơn cloud của công ty bạn tăng gấp 4 lần trong khi hệ thống vẫn chạy y nguyên như ngày đầu. Giám đốc tài chính đặt câu hỏi: "Sao không mua máy chủ đặt ở công ty cho rẻ?" — và đội IT bắt đầu tính chuyện rời cloud về on-prem. Đây không phải chuyện hiếm: làn sóng "repatriation" (đưa workload từ public cloud về hạ tầng tự quản) đang được nhiều CIO cân nhắc lại.

Nhưng rời cloud không phải lúc nào cũng đúng — làm sai còn tốn kém hơn ở lại. Bài viết này giúp bạn nhận diện 5 dấu hiệu cho thấy đã đến lúc xem xét, tính đúng bài toán TCO, và có lộ trình chuyển về an toàn nếu quyết định đi tiếp.

Rời cloud về on-prem: repatriation là gì? (Không phải "bỏ cloud")

Cloud repatriation là việc di chuyển ứng dụng, dữ liệu hoặc workload từ public cloud về lại hạ tầng on-premises (máy chủ tại doanh nghiệp), private cloud, hoặc colocation tại datacenter. Điểm quan trọng cần nhấn mạnh: đây không phải là từ bỏ cloud, mà là sự hiệu chỉnh chiến lược — đưa một số workload cụ thể về nơi chúng vận hành kinh tế hơn, trong khi các workload khác vẫn ở lại cloud.

Kết quả phổ biến nhất của repatriation không phải "tất cả về on-prem" mà là mô hình hybrid: workload ổn định, tốn tài nguyên về hạ tầng tự quản; workload biến động, cần co giãn nhanh ở lại public cloud. Rất ít doanh nghiệp rút toàn bộ.

Hiểu đúng bản chất này giúp tránh hai cực đoan: "cloud là tương lai, cấm bàn chuyện về" và "cloud đắt, về hết cho rẻ". Đáp án nằm ở từng workload cụ thể.

Rời cloud về on-prem: 5 dấu hiệu cho thấy nên xem xét rời cloud

1. Hóa đơn cloud tăng phi mã trong khi workload không đổi. Hệ thống chạy ổn định 24/7, lưu lượng gần như không đổi, nhưng bill mỗi quý một cao hơn vì tăng giá, thêm dịch vụ phụ trợ, hoặc cấu hình thừa từ ngày đầu migrate chưa ai rà soát. Với workload ổn định, chi phí cloud tích lũy 3–5 năm thường vượt xa chi phí mua phần cứng tương đương.

2. Phí egress (dữ liệu truyền ra) chiếm tỷ trọng lớn. Nhiều nhà cung cấp quốc tế tính phí khá cao cho mỗi GB dữ liệu đi ra khỏi cloud. Với hệ thống có lưu lượng ra lớn — video, file download, API phục vụ nhiều client — phí egress có thể thành khoản mục lớn nhất hóa đơn.

3. Workload ổn định, ít cần co giãn. Database lõi, ERP, lưu trữ file nội bộ — chạy 24/7 với tải trọng đều đặn. Lợi thế lớn nhất của cloud là co giãn linh hoạt, nhưng nếu bạn không bao giờ cần co giãn, bạn đang trả tiền cho tính năng không dùng đến.

4. Yêu cầu chủ quyền dữ liệu và tuân thủ. Một số ngành (tài chính, y tế, cơ quan nhà nước) quy định chặt chẽ về nơi lưu trữ dữ liệu. Khi dữ liệu bắt buộc ở trong nước trên hạ tầng kiểm soát được, đưa về on-prem hoặc colocation trong nước giúp đơn giản hóa tuân thủ.

5. Vấn đề độ trễ với hệ thống nội bộ. Ứng dụng cần giao tiếp thời gian thực với thiết bị, máy móc trong nhà máy hoặc văn phòng sẽ chạy tốt hơn khi đặt gần — độ trễ từ cloud về mạng nội bộ có thể trở thành nút thắt cổ chai với các hệ thống điều khiển, camera AI, IoT.

Nếu hệ thống của bạn "dính" từ 2 dấu hiệu trở lên, đã đến lúc ngồi xuống tính bài toán TCO một cách nghiêm túc.

Rời cloud về on-prem: bảng so sánh: workload nào nên về, workload nào nên ở lại

Nguyên tắc vàng: workload ổn định, "nặng" tài nguyên → về; workload biến động, cần co giãn → ở lại. Đừng bao giờ quyết định theo cảm tính "cho cả hệ thống" — hãy đánh giá từng workload riêng lẻ.

Tính TCO đúng cách trước khi quyết định

Sai lầm phổ biến nhất là so sánh "giá thuê cloud mỗi tháng" với "giá mua server một lần" — phép so sánh thiếu một nửa chi phí. TCO đầy đủ cho 3 năm gồm:

TCO on-prem/colocation = giá mua phần cứng + license + điện + làm mát + phí colocation (hoặc không gian đặt máy) + băng thông + nhân sự vận hành + bảo trì/thay thế linh kiện + chi phí migrate về.

TCO cloud = phí compute + storage + egress + băng thông + dịch vụ phụ trợ (load balancer, backup, monitoring...) + nhân sự quản trị cloud + chi phí migrate đi (nếu có).

Ví dụ (minh họa — con số giả định, không phải báo giá thực): một cụm database tốn 30 triệu đồng/tháng trên public cloud quốc tế (đã gồm egress). Phương án về: mua 2 server vật lý 400 triệu (khấu hao 3 năm ≈ 11 triệu/tháng) + colocation 8 triệu/tháng + license, điện, nhân sự vận hành ~6 triệu/tháng → tổng ~25 triệu/tháng. Tiết kiệm khoảng 5 triệu/tháng, tương đương 180 triệu/3 năm — chưa kể hết khấu hao thì chi phí còn giảm tiếp.

Nhưng cũng có trường hợp ngược lại: nếu đội IT mỏng, chi phí thuê quản trị hoặc rủi ro downtime có thể "ăn" hết phần tiết kiệm. Hãy tính trung thực cả chi phí nhân sự và rủi ro — TCO đẹp trên giấy mà thiếu người vận hành thì vô nghĩa.

3 lựa chọn đích đến khi rời cloud

"Về on-prem" không chỉ có một nghĩa. Tùy năng lực và quy mô, bạn có 3 đích đến:

1. On-prem thuần (phòng server tại doanh nghiệp). Ưu điểm: kiểm soát tuyệt đối, không phí thuê chỗ đặt. Nhược điểm: tự lo điện dự phòng, làm mát, PCCC, an ninh vật lý — rất tốn kém nếu làm đúng chuẩn. Chỉ phù hợp khi đã có phòng server đạt chuẩn hoặc quy mô đủ lớn.

2. Colocation tại datacenter. Mang máy chủ đến đặt tại trung tâm dữ liệu chuyên nghiệp (chuẩn Tier III, ISO 27001). Đây là "điểm ngọt" cho đa số doanh nghiệp Việt Nam: hưởng hạ tầng điện, làm mát, an ninh, PCCC chuẩn quốc tế với chi phí chỉ bằng một phần nhỏ so với tự xây, vẫn toàn quyền sở hữu và quản trị phần cứng. SunCloud cung cấp colocation tại datacenter Tier III ở Hà Nội từ 1/4 rack đến nguyên rack, hỗ trợ kỹ thuật 24/7/365.

3. Private cloud. Dựng môi trường cloud riêng trên phần cứng của mình với nền tảng ảo hóa như VMware/OpenStack — giữ được sự linh hoạt kiểu cloud nhưng chi phí cố định và dữ liệu trong tầm kiểm soát. Phù hợp với doanh nghiệp có đội IT mạnh và nhiều workload cần quản lý tập trung.

Nhiều doanh nghiệp chọn kết hợp: workload nhạy cảm về colocation/private cloud, workload biến động ở lại public cloud — mô hình hybrid kinh điển.

Lộ trình repatriation 5 bước an toàn

Rời cloud là một dự án migration ngược — cần kỷ luật tương tự như khi "lên mây":

Bước 1: Kiểm kê và phân loại workload. Liệt kê toàn bộ workload trên cloud, đánh giá từng cái: về, ở lại, hay cần phân tích thêm.

Bước 2: Tính TCO chi tiết cho từng nhóm "về". Tính cho chu kỳ 3 năm, gồm cả chi phí migrate và vận hành. Chỉ "về" những workload có TCO tốt hơn rõ rệt (biên an toàn ít nhất 20–30%).

Bước 3: Chuẩn bị đích đến. Mua sắm phần cứng, ký hợp đồng colocation, dựng môi trường đích và kiểm thử kỹ. Thiết lập kết nối giữa cloud cũ và hạ tầng mới để đồng bộ dữ liệu.

Bước 4: Migrate theo đợt, song song chạy thử. Chuyển từng workload theo thứ tự ưu tiên (ít quan trọng trước, lõi sau), chạy song song hai môi trường để đối chiếu. Có kế hoạch rollback cho mỗi đợt.

Bước 5: Tối ưu và đóng cloud cũ. Sau khi hệ thống mới ổn định, rà soát kỹ trước khi hủy tài nguyên cloud cũ — kiểm tra backup, DNS, các tích hợp ngầm. Rất nhiều hóa đơn "ma" sinh ra từ tài nguyên cũ quên chưa xóa.

4 rủi ro hay bị bỏ qua khi rời cloud

1. Chi phí migrate bị đánh giá thấp. Egress fee để "rút" dữ liệu lớn ra khỏi cloud quốc tế có thể rất cao — với vài chục TB, phí chuyển ra đôi khi đủ mua thêm server. Tính khoản này vào TCO ngay từ đầu.

2. Thiếu người vận hành. Trên cloud, vá phần cứng hay thay ổ hỏng lúc 2h sáng là việc của nhà cung cấp. Về on-prem, đó là việc của đội bạn. Nếu đội IT mỏng, hãy tính chi phí thuê quản trị hoặc chọn colocation có dịch vụ remote hands.

3. Mất tính co giãn. Đợt cao điểm đột xuất sẽ không còn nút "scale" thần kỳ. Cần dự phòng capacity hoặc giữ một phần burst trên cloud theo mô hình hybrid.

4. Ràng buộc kỹ thuật (lock-in ngược). Ứng dụng "dính" sâu vào dịch vụ đặc thù của nhà cung cấp (managed database, serverless...) rất khó gỡ ra — chi phí refactor có thể lớn hơn mọi khoản tiết kiệm. Với những workload này, đáp án đúng đôi khi là... ở lại.

Khi nào KHÔNG nên rời cloud?

Để công bằng, có những trường hợp rời cloud là quyết định sai: startup/tăng trưởng nhanh chưa biết 6 tháng nữa cần bao nhiêu tài nguyên; đội IT nhỏ hoặc không có; workload gắn chặt dịch vụ cloud đặc thù mà refactor tốn kém hơn lợi ích; nhu cầu mở rộng đa vùng/quốc tế; và trường hợp "sếp thấy bill cao" nhưng nguyên nhân thực sự là quản lý kém (tài nguyên thừa, thiếu FinOps) — hãy rightsizing và tối ưu trước khi nghĩ đến chuyện "về".

Checklist quyết định: có nên repatriation?

Trả lời 6 câu hỏi sau trước khi trình ban lãnh đạo: (1) Workload nào cụ thể sẽ về? (2) TCO 3 năm rẻ hơn bao nhiêu %, có biên an toàn ≥20%? (3) Phí egress rút dữ liệu về là bao nhiêu, đã tính vào TCO chưa? (4) Ai vận hành hạ tầng mới? (5) Đích đến là on-prem thuần, colocation hay private cloud — vì sao? (6) Kế hoạch rollback nếu migrate thất bại là gì?

Trả lời trôi chảy cả 6 câu là sẵn sàng. Còn lúng túng ở câu nào, hãy phân tích thêm — dự án repatriation chuẩn bị kỹ luôn rẻ hơn dự án phải làm lại.

Kết luận

Rời cloud về on-prem không phải "thất bại của cloud" mà là dấu hiệu trưởng thành trong quản trị hạ tầng: đưa mỗi workload về nơi nó vận hành kinh tế nhất. Nhưng hãy tính đúng TCO (đừng quên egress, nhân sự vận hành và chi phí migrate), đánh giá từng workload riêng lẻ, và luôn có kế hoạch rollback. Với đa số doanh nghiệp, đáp án cuối cùng sẽ là hybrid — một phần về colocation/private cloud trong nước, một phần ở lại public cloud.

Nếu bạn đang cân nhắc đưa một phần workload về hạ tầng trong nước, SunCloud có thể tư vấn phương án phù hợp: từ thuê Cloud Server, Dedicated Server đến Colocation tại datacenter Tier III ở Hà Nội — giúp bạn so sánh TCO một cách trung thực trước khi quyết định. Liên hệ hotline 083 979 3434 hoặc truy cập suncloud.vn để được tư vấn miễn phí.

Câu hỏi thường gặp

Repatriation có nghĩa là bỏ hoàn toàn public cloud không?

Không. Thực tế phổ biến là chỉ đưa một số workload cụ thể về (thường là workload ổn định, tốn tài nguyên), các workload khác vẫn ở lại cloud. Kết quả thường là mô hình hybrid chứ không phải rút toàn bộ.

Chi phí lớn nhất khi rời cloud quốc tế là gì?

Thường là phí egress — phí truyền dữ liệu ra khỏi cloud để về hạ tầng mới. Với dữ liệu lớn (hàng chục TB), khoản này có thể rất đáng kể và phải được tính vào TCO ngay từ bước lập kế hoạch.

Nên về on-prem thuần hay colocation?

Đa số doanh nghiệp vừa và nhỏ nên chọn colocation: được hưởng datacenter chuẩn Tier III (điện dự phòng, làm mát, an ninh, PCCC) với chi phí thấp hơn nhiều so với tự xây phòng server đạt chuẩn. On-prem thuần chỉ hợp lý khi đã có sẵn cơ sở đạt chuẩn.

Migrate về mất bao lâu?

Tùy quy mô: vài workload đơn giản có thể xong trong vài tuần; hệ thống phức tạp với database lớn, nhiều tích hợp có thể kéo dài vài tháng. Nên migrate theo đợt, chạy song song để đối chiếu, không nên "cắt" một lần.

Có nên giữ lại một phần trên cloud sau khi về không?

Nên. Giữ lại các workload biến động, môi trường dev/test và hệ thống DR dự phòng trên cloud là thực hành phổ biến. Mô hình hybrid cho bạn chi phí tối ưu của on-prem và sự linh hoạt của cloud cùng lúc.

Làm sao biết bill cloud cao là do "cloud đắt" hay do "quản lý kém"?

Rà soát trước khi quyết định: kiểm tra tài nguyên nhàn rỗi (rightsizing), cấu hình thừa từ ngày đầu, dịch vụ phụ trợ không dùng đến. Nếu sau khi tối ưu mà bill vẫn cao bất hợp lý với workload ổn định, lúc đó mới tính đến repatriation.