Hai năm trước bọn mình có một client chạy pipeline embedding trên AWS và endpoint inference fine-tune trên Azure OpenAI, vì lúc đó quota fine-tuning họ cần chỉ có trên Azure. Mỗi request phải băng qua internet công cộng hai lần — một lần lấy context, một lần lấy kết quả trả về — qua một VPN tunnel do một kỹ sư của bọn mình dựng lên mà không ai muốn đụng vào lần thứ hai. Nó chạy được. Nhưng cũng là phần dễ hỏng nhất trong cả stack, và postmortem nào suốt sáu tháng cũng có một dòng: “packet loss ở đoạn cross-cloud.”
Đó chính xác là dạng vấn đề mà AWS Interconnect – multicloud với Azure được xây để loại bỏ, và nó vào public preview âm thầm từ tháng 8. Mình dành cả buổi chiều đọc kiến trúc thay vì đọc thông cáo báo chí, vì thông cáo báo chí nói nhẹ hơn nhiều so với cái thật sự đáng chú ý ở đây.
Nó là gì, cụ thể
Một kết nối riêng, được cấp phát giữa một region AWS và một region Azure, thiết lập qua console, CLI, hoặc Azure portal chỉ vài click, thay vì quá trình vài tuần tự sắp xếp cross-connect tại trung tâm colocation. Mỗi link chạy mã hóa IEEE 802.1AE MACsec giữa router biên của AWS và Azure — mã hóa ở tầng phần cứng trên chặng vật lý, không phải thứ chồng thêm ở tầng ứng dụng. Mỗi kết nối cấp phát bốn đường logic độc lập qua các cơ sở interconnect và router tách biệt về mặt vật lý, nên mất một site hay bảo trì router trên một đường không làm sập kết nối.
Hiện có ở bốn region: US East (N. Virginia), US West (N. California), Asia Pacific (Sydney), và Europe (Frankfurt). AWS đưa ra mục tiêu độ sẵn sàng 99.99% — nói rõ đây là mục tiêu thiết kế trong giai đoạn preview, chưa phải SLA có hợp đồng.
# Hình dạng sơ bộ khi cấp phát qua AWS CLI (minh họa — kiểm tra API hiện tại để lấy tham số chính xác)
aws directconnect create-interconnect-multicloud \
--partner-cloud azure \
--azure-region eastus \
--bandwidth 1Gbps \
--region us-east-1Con số thật sự quan trọng: 1 Gbps
Đối tác trong giai đoạn preview bị giới hạn ở 1 gigabit. So với tier 500 Mbps miễn phí AWS đã cho các đối tác GA — một tier mà Azure chưa chạm tới. Nếu bạn hình dung đây là đường ống để chuyển dữ liệu training hay di chuyển checkpoint nhiều terabyte giữa các cloud, thì không phải, chưa phải, không phải ở băng thông này.
Cái nó tốt cho: traffic dạng request-response. Cuộc gọi inference. Truy vấn RAG lấy một vector match từ cloud này rồi sinh câu trả lời ở cloud kia. Traffic metadata và control-plane giữa các service tình cờ nằm trên cloud khác nhau vì một quota của vendor, một vụ mua lại, hay một yêu cầu compliance ghim một workload vào một nhà cung cấp cụ thể. Đó là use case hẹp hơn nhiều so với cái tên “multicloud networking” nghe có vẻ, và cũng chính là use case đã gây đau đầu cho bọn mình.
Vì sao đây là câu chuyện hạ tầng AI, không chỉ là networking
Stack AI đa model giờ mặc định là đa vendor, dù team có tính vậy hay không. Bạn fine-tune ở đâu có cả quota lẫn base model mình cần. Bạn chạy vector search ở đâu dữ liệu warehouse sẵn có đang nằm. Bạn gọi API của ba nhà cung cấp khác nhau từ cùng một tầng orchestration vì không vendor nào bao trọn được embedding, generation, và evaluation đều tốt như nhau. Sự phân mảnh đó từng có nghĩa là mọi cuộc gọi cross-cloud đi qua internet công cộng, qua phí egress ở cả hai đầu, với độ trễ và packet loss mà bạn không làm gì được ngoài retry mạnh hơn.
Một đường link riêng, dự phòng, mã hóa mặc định giữa AWS và Azure — hai cloud mà phần lớn workload AI doanh nghiệp thật sự đang trải rộng ra — biến “pipeline RAG của bọn mình chạy trên hai nhà cung cấp cloud” từ một rủi ro kiến trúc thành một chi tiết triển khai nhàm chán. Đó là một dịch chuyển thật sự, dù giới hạn ở 1 Gbps, vì với traffic dạng inference thì 1 Gbps không phải nút thắt cổ chai. Logic retry ở tầng ứng dụng và phân giải DNS qua internet công cộng mới là nút thắt cổ chai, và những cái đó biến mất.
Mình sẽ làm gì với cái này ngay bây giờ
Mình sẽ không đưa một workload production lên một dịch vụ đang nói rõ là preview với SLA kiểu “mục tiêu chứ không đảm bảo.” Đó là cái bẫy dễ mắc: demo chạy tốt, câu chuyện dự phòng bốn đường nghe chắc chắn, rồi sáu tuần sau bạn đã xây một sự phụ thuộc vào thứ mà AWS vẫn có thể thay đổi hình dạng trước khi lên GA.
Cái mình sẽ làm — và đang làm với client trong câu chuyện ở đầu bài — là thiết lập interconnect ở môi trường staging ngay bây giờ, ở một trong bốn region được hỗ trợ, và bắt đầu định tuyến traffic inference không quan trọng qua đó. Đo độ trễ và packet loss thật so với VPN tunnel mà nó sẽ thay thế. Xây runbook cho các tình huống lỗi trước khi có sự cố buộc bạn phải viết nó trong lúc áp lực. Khi nó lên GA với SLA thật và tier 500 Mbps miễn phí của Azure mở rộng ra, bạn muốn đã biết sẵn câu trả lời là “chuyển hết” hay “cái này chỉ giúp cho truy vấn RAG, phần còn lại vẫn giữ VPN.”
Sai lầm đắt nhất trong multicloud không phải là chọn sai hai nhà cung cấp. Mà là lần đầu tiên phát hiện ra hình dạng thật của traffic cross-cloud của mình ngay giữa một sự cố, thay vì vào một chiều thứ Ba yên tĩnh với môi trường staging và chẳng có gì đang cháy.