Mở đầu — vì sao bài này quan trọng
Trong thực tế đi làm, bạn sẽ hiếm khi gặp một doanh nghiệp "100% cloud" ngay từ đầu. Đa số các công ty vừa và lớn — đặc biệt tại Việt Nam như ngân hàng, bảo hiểm, sản xuất, logistics — đều đang vận hành một chân ở trung tâm dữ liệu (data center) truyền thống của họ, và một chân đang thò dần sang cloud. Trạng thái "hai chân hai nơi" đó chính là hybrid cloud, và câu hỏi kỹ thuật quan trọng nhất của nó không phải là "chạy cái gì ở đâu", mà là "làm sao nối hai thế giới đó lại với nhau một cách nhanh, an toàn, và ổn định".
Đây là lý do bài học về connectivity (kết nối) trở nên cực kỳ thực dụng. Một kiến trúc hybrid vẽ đẹp trên slide nhưng nối bằng Internet công cộng với độ trễ lúc 20ms lúc 300ms sẽ khiến ứng dụng ngân hàng core banking timeout, khiến bản sao dữ liệu (replication) bị trễ hàng giờ, và khiến đội vận hành mất ngủ. Ngược lại, nếu bạn hiểu rõ ba "con đường" nối on-prem với cloud — Site-to-Site VPN, Direct Connect / Dedicated Interconnect, và SD-WAN / mô hình lai — bạn sẽ thiết kế được hệ thống mà latency ổn định, băng thông đủ dùng, và chi phí hợp lý.
Bài này tập trung riêng vào lớp kết nối vật lý và mạng giữa on-prem và cloud. Chúng ta sẽ không đi lại phần khái niệm public/private/hybrid cloud (đã có ở Bài 4), cũng không đào sâu VPC nội bộ (Bài 19) hay Transit Gateway (Bài 40). Ở đây, trọng tâm là: đường ống nào nối data center của bạn với VPC trên cloud, và chọn đường ống đó thế nào cho đúng.
Khái niệm cốt lõi
Vì sao doanh nghiệp phải làm hybrid (chứ không "all-in cloud")
Trước khi bàn cách nối, hãy hiểu vì sao người ta buộc phải giữ một phần on-prem — vì chính lý do này quyết định yêu cầu kết nối:
- Ứng dụng legacy chưa migrate được. Một hệ thống ERP hay core banking chạy 15 năm, phụ thuộc phần cứng cũ, database Oracle với license đắt đỏ, hoặc thậm chí là mainframe. Migrate nó lên cloud là dự án nhiều năm và rủi ro. Trong thời gian đó, phần cloud mới (web, mobile, analytics) vẫn phải gọi ngược về database on-prem.
- Compliance và data residency. Nhiều quy định yêu cầu dữ liệu nhạy cảm phải nằm trong lãnh thổ hoặc trong data center của chính doanh nghiệp. Ở Việt Nam, Nghị định 13/2023 về bảo vệ dữ liệu cá nhân và các yêu cầu của Ngân hàng Nhà nước khiến nhiều tổ chức tài chính giữ dữ liệu gốc on-prem, chỉ đẩy phần xử lý phi nhạy cảm lên cloud.
- Ứng dụng nhạy latency phải gần thiết bị. Nhà máy sản xuất có hệ thống điều khiển (SCADA/MES) cần latency dưới vài mili-giây tới máy móc — không thể để nó gọi qua cloud tận Singapore. Phần điều khiển ở lại on-prem, chỉ đẩy dữ liệu cảm biến lên cloud để phân tích.
- Chi phí đã đầu tư (sunk cost) vào hạ tầng. Doanh nghiệp vừa mua dàn server 3 năm trước, khấu hao chưa xong, nên tận dụng tiếp trong khi mở rộng bằng cloud.
Ba con đường kết nối on-prem ↔ cloud
1. Site-to-Site VPN (IPsec VPN qua Internet)
VPN dựng một "đường hầm" mã hóa (IPsec tunnel) chạy trên chính đường Internet công cộng bạn đang có. Ở phía cloud, bạn tạo một VPN Gateway (AWS gọi là Virtual Private Gateway / Transit Gateway VPN, GCP gọi là Cloud VPN, Azure gọi là VPN Gateway). Ở phía on-prem, bạn cần một thiết bị Customer Gateway — thường là firewall/router như Cisco, Fortinet, pfSense.
- Ưu điểm: dựng nhanh (vài giờ), rẻ (chỉ trả phí gateway theo giờ + data transfer), không cần kéo cáp vật lý.
- Nhược điểm: chạy trên Internet nên latency và độ ổn định phụ thuộc chất lượng đường mạng; băng thông mỗi tunnel thường giới hạn (khoảng 1.25 Gbps trên AWS mỗi tunnel); dữ liệu tuy được mã hóa nhưng vẫn đi qua hạ tầng công cộng.
- Dùng khi nào: giai đoạn đầu, môi trường dev/test, backup connection, hoặc lượng traffic nhỏ.
Đây là đường cáp riêng vật lý nối data center (hoặc điểm hiện diện của bạn tại một colocation) thẳng vào mạng của nhà cung cấp cloud, không đi qua Internet công cộng.
- Ưu điểm: latency thấp và cực kỳ ổn định (jitter nhỏ), băng thông cam kết cao (1/10/100 Gbps), bảo mật hơn vì traffic không ra Internet, và chi phí data transfer ra ngoài (egress) thường rẻ hơn đáng kể so với qua Internet.
- Nhược điểm: tốn thời gian thiết lập (vài tuần đến vài tháng vì phải kéo cáp/thuê port tại colocation), chi phí cố định hàng tháng cho port, và thường cần qua một đối tác kết nối (partner) nếu data center của bạn không nằm sẵn tại điểm colocation của cloud.
- Điểm quan trọng: bản thân đường Direct Connect không mã hóa ở lớp ứng dụng — nó chỉ là đường riêng. Nếu cần mã hóa, người ta chạy thêm IPsec/MACsec bên trên.
- Dùng khi nào: production, traffic lớn/liên tục, ứng dụng nhạy latency, hoặc yêu cầu compliance không cho traffic ra Internet.
Thực tế phổ biến nhất là kết hợp: dùng Direct Connect làm đường chính (primary) và một Site-to-Site VPN làm đường dự phòng (backup/failover). Khi cáp riêng có sự cố, traffic tự động chuyển qua VPN — chậm hơn nhưng vẫn thông. Nhiều doanh nghiệp còn dùng SD-WAN để tự động chọn đường tối ưu giữa nhiều kết nối, và quản lý tập trung nhiều chi nhánh.
Các khái niệm mạng bạn phải nắm khi kết nối
- BGP (Border Gateway Protocol): giao thức định tuyến động dùng để hai bên "trao đổi" xem mạng nào nằm ở đâu. Cả VPN lẫn Direct Connect thường dùng BGP để tự động biết route và tự failover.
- ASN (Autonomous System Number): "số định danh" cho mỗi bên trong BGP. Bạn khai báo ASN của on-prem và của cloud.
- VLAN / Virtual Interface (VIF): trên một đường Direct Connect vật lý, bạn có thể chia nhiều "giao diện ảo" — private VIF nối vào VPC, public VIF nối tới dịch vụ công khai của cloud.
- Không được trùng dải IP (CIDR overlap): đây là lỗi kinh điển. Nếu on-prem dùng 10.0.0.0/16 và VPC cloud cũng dùng 10.0.0.0/16, routing sẽ loạn. Phải quy hoạch dải IP không chồng lấn ngay từ đầu.
- MTU và MSS clamping: VPN thêm header mã hóa nên gói tin dễ vượt kích thước tối đa, gây rớt gói khó chịu. Thường phải chỉnh MTU/MSS.
Tình huống thực tế
Ví dụ 1 — Ngân hàng thương mại tại Hà Nội: core banking on-prem, digital banking trên cloud
Một ngân hàng cỡ vừa muốn ra mắt app mobile banking mới với trải nghiệm hiện đại. Họ quyết định: hệ thống core banking giữ nguyên on-prem (do quy định của Ngân hàng Nhà nước và vì core chạy trên Oracle Exadata rất khó migrate), còn toàn bộ lớp digital (API gateway, microservices, app backend) đặt trên cloud ở region Singapore.
Vấn đề: mỗi giao dịch chuyển khoản trên app đều phải gọi ngược về core on-prem để kiểm tra số dư và ghi sổ. Ban đầu họ thử Site-to-Site VPN cho nhanh. Kết quả: giờ cao điểm, latency dao động 40–180ms, thi thoảng tunnel rớt vài giây khiến giao dịch timeout. Với ngân hàng, một giao dịch treo là khủng hoảng niềm tin.
Họ chuyển sang Direct Connect 1 Gbps qua một đối tác viễn thông trong nước, kéo cáp riêng từ data center ở Hà Nội tới điểm colocation kết nối cloud. Latency ổn định còn khoảng 15–20ms, jitter gần như bằng 0. Đồng thời họ giữ lại đường VPN cũ làm backup, cấu hình BGP để tự failover. Chi phí Direct Connect khoảng vài nghìn USD/tháng — nhưng so với rủi ro treo giao dịch, đây là khoản đáng chi.
Bài học: với ứng dụng giao dịch nhạy latency và cần độ ổn định cao, VPN chỉ nên là bước khởi động hoặc đường backup. Production thực sự cần dedicated connection, và luôn phải có đường thứ hai để failover.
Ví dụ 2 — Nhà máy sản xuất ở Bình Dương: IoT tại nhà máy, analytics trên cloud
Một nhà máy điện tử có hàng nghìn cảm biến trên dây chuyền. Hệ thống điều khiển máy móc (MES) bắt buộc ở lại on-prem vì cần latency dưới 5ms — không thể phụ thuộc cloud tận nước ngoài. Nhưng ban lãnh đạo muốn dùng cloud để phân tích dữ liệu sản xuất, dự đoán hỏng hóc thiết bị (predictive maintenance).
Giải pháp của họ: dữ liệu cảm biến được gom tại một edge gateway trong nhà máy, rồi đẩy theo batch mỗi vài phút lên object storage trên cloud qua một Site-to-Site VPN băng thông vừa phải. Vì đây là traffic một chiều, không nhạy latency (phân tích chạy sau, không realtime tới từng mili-giây), nên VPN qua Internet là đủ và tiết kiệm — không cần Direct Connect đắt tiền.
Họ quy hoạch dải IP cẩn thận: nhà máy dùng 172.16.0.0/16, VPC cloud dùng 10.20.0.0/16 — không chồng lấn. Họ cũng bật nén dữ liệu trước khi truyền để giảm băng thông.
Bài học: không phải hybrid nào cũng cần đường xịn. Hãy phân loại traffic theo yêu cầu latency và khối lượng. Traffic phân tích một chiều, chấp nhận trễ vài phút → VPN là lựa chọn hợp lý về chi phí. Đừng "chém" Direct Connect cho mọi thứ.
Ví dụ 3 — Công ty logistics khu vực Đông Nam Á: multi-site về một cloud
Một công ty giao vận có kho ở TP.HCM, Bangkok và Jakarta, mỗi nơi có hệ thống quản lý kho (WMS) riêng, cần đồng bộ về một nền tảng điều phối trung tâm trên cloud. Nối riêng lẻ từng site bằng VPN thủ công thành ra rối rắm khi số site tăng.
Họ triển khai SD-WAN: mỗi site có một thiết bị SD-WAN, tự động dựng tunnel về cloud và chọn đường mạng tốt nhất (site nào có đường cáp quang tốt thì ưu tiên, đường kém thì dùng backup). Về phía cloud, thay vì mỗi VPN nối riêng vào một VPC, họ cho tất cả đổ về một hub trung tâm rồi phân phối tới các VPC — giảm số kết nối phải quản lý (ý tưởng hub-and-spoke, sẽ học kỹ ở Bài 40).
Bài học: khi có nhiều site, đừng nối kiểu "mạng nhện" từng cặp một. Hãy dùng mô hình hub tập trung và cân nhắc SD-WAN để quản lý số lượng kết nối lớn một cách tự động và có failover.
Hướng dẫn từng bước
Giả sử bạn cần nối một data center on-prem với một VPC trên cloud. Quy trình chung như sau:
- Kiểm kê và quy hoạch dải IP. Liệt kê tất cả dải IP đang dùng on-prem. Chọn dải IP cho VPC cloud không chồng lấn với on-prem. Đây là bước quan trọng nhất và khó sửa nhất về sau.
- Xác định yêu cầu traffic. Ước lượng: băng thông cần bao nhiêu? Latency yêu cầu bao nhiêu? Traffic một chiều hay hai chiều? Có yêu cầu compliance cấm ra Internet không? Trả lời được những câu này thì mới chọn được VPN hay Direct Connect.
- Bắt đầu bằng VPN để chứng minh (PoC). Dựng Site-to-Site VPN trước vì nhanh và rẻ: tạo VPN Gateway phía cloud, khai báo Customer Gateway (IP public của firewall on-prem), tạo tunnel, cấu hình IPsec (pre-shared key hoặc chứng chỉ).
- Cấu hình định tuyến. Chọn static routing (khai tay các dải mạng) cho hệ thống đơn giản, hoặc BGP cho hệ thống cần tự động và failover. Với BGP, khai báo ASN hai bên và để hai gateway tự trao đổi route.
- Kiểm thử kỹ. Ping, đo latency, đo băng thông thực (không chỉ tin thông số lý thuyết), và chủ động test failover: rút đường chính xem traffic có tự chuyển qua backup không.
- Nâng cấp lên Direct Connect nếu cần. Khi production đòi hỏi ổn định/băng thông cao: làm việc với đối tác kết nối, thuê port, kéo cáp tới colocation, tạo Virtual Interface (private VIF vào VPC), rồi chuyển VPN thành đường backup.
- Giám sát liên tục. Theo dõi trạng thái tunnel, băng thông, latency, và cảnh báo khi tunnel down (phần monitoring chi tiết ở Bài 33).
Lỗi thường gặp & mẹo
- Trùng dải IP (CIDR overlap): lỗi phổ biến nhất và đau đớn nhất. Luôn quy hoạch IP trước. Nếu lỡ trùng, phải dùng NAT để dịch địa chỉ — rắc rối và khó debug.
- Coi VPN như production vĩnh viễn: VPN qua Internet ổn cho khởi động và backup, nhưng đừng để ứng dụng nhạy latency phụ thuộc nó lâu dài. Khi thấy user than "app lúc nhanh lúc chậm", rất có thể đường VPN là thủ phạm.
- Không có đường backup: dựng mỗi một tunnel/một đường Direct Connect rồi mừng vì nó chạy. Đến khi đứt cáp, cả hệ thống hybrid tê liệt. Luôn thiết kế ít nhất hai đường và test failover định kỳ.
- Quên rằng Direct Connect không tự mã hóa: nó là đường riêng, không phải đường mã hóa. Nếu compliance yêu cầu mã hóa end-to-end, phải bật thêm IPsec/MACsec bên trên.
- Bỏ qua chi phí egress (data transfer ra): truyền dữ liệu từ cloud về on-prem tốn tiền, và qua Internet còn đắt hơn qua Direct Connect. Với hệ thống replicate liên tục, phí này có thể lớn bất ngờ. Ước tính trước.
- Lỗi MTU/MSS: ping nhỏ thì thông nhưng truyền file lớn lại treo — kinh điển do MTU. Mẹo: cấu hình MSS clamping trên gateway để tránh phân mảnh gói.
- Mẹo bảo mật: đừng nối phẳng toàn bộ hai mạng vào nhau. Chỉ mở đúng các dải/cổng cần thiết bằng route và security group, theo nguyên tắc tối thiểu quyền.
Bài tập thực hành
- Phân tích tình huống: Cho một công ty fintech có database khách hàng bắt buộc ở on-prem (do quy định), còn API backend chạy trên cloud và gọi database này ~500 lần/giây với yêu cầu latency dưới 30ms. Hãy đề xuất: nên dùng VPN hay Direct Connect? Có cần đường backup không? Giải thích lý do dựa trên yêu cầu latency và tính sẵn sàng.
- Quy hoạch IP: On-prem của bạn đang dùng 10.0.0.0/16. Hãy chọn một dải CIDR phù hợp cho VPC cloud sao cho không chồng lấn, đủ chỗ cho khoảng 1000 máy chủ, và viết ra dải bạn chọn.
- Thiết kế kết nối: Vẽ (bằng lời hoặc sơ đồ) kiến trúc kết nối cho một doanh nghiệp có 3 chi nhánh và 1 cloud region, sao cho: có failover, giảm số kết nối phải quản lý, và mỗi site đều có đường dự phòng. Nêu rõ bạn dùng công nghệ gì (VPN/Direct Connect/SD-WAN) ở mỗi chỗ.
- Bắt lỗi: Một đồng nghiệp báo "VPN đã lên xanh, ping được nhưng copy file lớn qua thì treo". Hãy nêu ít nhất hai nguyên nhân khả dĩ và cách kiểm tra từng nguyên nhân.
Tóm tắt
Hybrid cloud tồn tại vì lý do rất thực tế: ứng dụng legacy chưa migrate, yêu cầu compliance/data residency giữ dữ liệu on-prem, và ứng dụng nhạy latency phải gần thiết bị. Chính những lý do đó tạo ra nhu cầu nối on-prem với cloud một cách nhanh, an toàn và ổn định.
Bạn có ba con đường chính: Site-to-Site VPN (nhanh, rẻ, chạy qua Internet, hợp cho khởi động và backup), Dedicated Connection như Direct Connect / Interconnect / ExpressRoute (đường cáp riêng, latency thấp và ổn định, hợp cho production và traffic lớn), và mô hình lai / SD-WAN (kết hợp cả hai, tự failover, quản lý nhiều site). Nguyên tắc chọn: bám theo yêu cầu latency, băng thông, compliance và ngân sách — đừng mặc định dùng đường đắt cho mọi thứ, cũng đừng để production nhạy latency treo lơ lửng trên VPN.
Về kỹ thuật, hãy nhớ mấy điều sống còn: quy hoạch IP không chồng lấn, dùng BGP cho định tuyến động và failover, luôn có đường backup và test failover, hiểu rằng Direct Connect không tự mã hóa, và cảnh giác với các lỗi âm thầm như MTU/MSS và chi phí egress. Nắm vững lớp kết nối này, bạn đã đặt được nền móng vững chắc cho mọi kiến trúc hybrid — thứ mà gần như doanh nghiệp lớn nào ở Việt Nam cũng đang cần.