Chuyển từ AWS Route 53 sang Bunny DNS để tiết kiệm chi phí và tăng quyền kiểm soát

Vincent Bernat gần đây đã ghi lại quá trình di chuyển hạ tầng blog cá nhân của anh từ Amazon Web Services (AWS) sang Bunny.net. Được công bố vào ngày 6 tháng 11 năm 2026, nghiên cứu tình huống này làm nổi bật cách chuyển đổi từ Route 53 và CloudFront sang các dịch vụ DNS và CDN của Bunny đã giúp giảm chi phí hàng tháng từ 5 đô la xuống còn 1 đô la. Quyết định này được thúc đẩy bởi mức phí cao cho các truy vấn xác định vị trí địa lý và kiểm tra sức khỏe (health checks) trên AWS, cùng với mong muốn sử dụng một nhà cung cấp có trụ sở tại châu Âu.

Điều gì đã xảy ra

Trước đó, Bernat dựa vào Amazon CloudFront để phân phối nội dung và Route 53 để định tuyến DNS theo nhận thức địa lý. Cấu hình này hướng độc giả đến máy chủ phục vụ nội dung gần nhất, tối ưu hóa các chỉ số hiệu suất. Tuy nhiên, mô hình giá cả tỏ ra đắt đỏ đối với một trang web cá nhân có lượng truy cập thấp. Route 53 tính phí theo mỗi zone, theo mỗi triệu truy vấn xác định vị trí địa lý và theo mỗi lần kiểm tra sức khỏe, cộng thêm chi phí cho các khóa Key Management Service (KMS) cần thiết để ký DNSSEC. Khi phát hiện rằng Bunny DNS cung cấp các phản hồi có thể lập trình được và gần như miễn phí cho tới 500 tên miền, anh đã quyết định di chuyển.

Quá trình chuyển đổi bao gồm việc di chuyển phân phối nội dung sang Bunny CDN và triển khai logic DNS phức tạp bằng cách sử dụng tính năng DNS có thể lập trình của Bunny. Tính năng này cho phép người dùng chạy JavaScript trên mỗi truy vấn DNS để tính toán phản hồi một cách động. Bernat sử dụng khả năng này để trả về địa chỉ IP của hai máy chủ gần nhất từ đội hình toàn cầu gồm bảy máy ảo NixOS của anh. Cấu hình này cung cấp tính dư thừa, cho phép trình duyệt dự phòng sang máy chủ thứ hai nếu máy chính không khả dụng. Anh quản lý hạ tầng này bằng CDK Terraform và OpenTofu, triển khai các trạng thái mục tiêu được định nghĩa trong TypeScript.

Một thách thức lớn nảy sinh liên quan đến các thử thách ACME DNS để lấy chứng chỉ TLS. Khác với Route 53, Bunny DNS không thể hạn chế quyền truy cập vào một zone duy nhất bằng các chính sách kiểm soát truy cập chi tiết, cũng như không thể xuất bản các bản ghi DS cần thiết cho bảo mật DNSSEC trên các zone ủy quyền. Để giải quyết vấn đề này, Bernat đã thay thế Route 53 cho zone cụ thể acme.luffy.cx bằng Hickory DNS, một máy chủ DNS an toàn bộ nhớ được viết bằng Rust. Anh lưu trữ zone cha luffy.cx trên deSEC, một nhà cung cấp DNS phi lợi nhuận, để quản lý các bản ghi DS cần thiết. Cách tiếp cận lai này duy trì bảo mật trong khi tận dụng định tuyến chi phí thấp của Bunny cho lưu lượng truy cập chung.

Chi tiết chính

• Chi phí hạ tầng hàng tháng giảm từ 5 USD xuống còn 1 USD sau khi di chuyển từ AWS sang Bunny.net.
• Bunny DNS hỗ trợ phản hồi JavaScript có thể lập trình, cho phép logic định tuyến địa lý tùy chỉnh mà không phải trả phí cao cấp.
• Tác giả vận hành bảy máy ảo NixOS trên toàn cầu, bao gồm các địa điểm ở Paris, Singapore và Sydney.
• Hickory DNS được triển khai để xử lý các thử thách ACME DNS-01 vì Bunny thiếu các điều khiển truy cập zone chi tiết.
• deSEC được sử dụng để lưu trữ zone cha và xuất bản các bản ghi DS, do Bunny DNS không hỗ trợ chúng.
• Hiệu suất vẫn tương đương với AWS, mặc dù Bunny CDN hiện chưa hỗ trợ HTTP/3.

Bối cảnh

GeoDNS là một kỹ thuật phân giải tên miền thành các địa chỉ IP khác nhau dựa trên vị trí địa lý của người dùng. Kỹ thuật này giảm độ trễ bằng cách hướng lưu lượng truy cập đến máy chủ gần nhất. Các nhà cung cấp truyền thống như AWS tính phí rất cao cho tài nguyên tính toán cần thiết để xác định các vị trí này và giám sát tình trạng máy chủ. DNS có thể lập trình nâng cao hơn nữa bằng cách cho phép các nhà phát triển chèn logic tùy chỉnh vào quy trình phân giải. Thay vì dựa vào các quy tắc định trước, máy chủ DNS thực thi mã để quyết định trả về IP nào, mang lại sự linh hoạt lớn hơn cho các cấu hình đa khu vực phức tạp.

Các thử thách ACME DNS-01 là phương pháp được các cơ quan chứng nhận như Let’s Encrypt sử dụng để xác minh quyền sở hữu tên miền. Máy chủ phải chứng minh rằng nó kiểm soát tên miền bằng cách tạo ra một bản ghi DNS cụ thể. Quá trình này thường yêu cầu cập nhật tự động các zone DNS. Các tiêu chuẩn bảo mật như DNSSEC dựa vào các bản ghi DS (Delegation Signer) để thiết lập chuỗi tin cậy giữa zone cha và zone con. Không phải tất cả các nhà cung cấp DNS đều hỗ trợ xuất bản các bản ghi này hoặc cho phép cập nhật động qua các giao thức bảo mật, đòi hỏi các giải pháp lai khi di chuyển khỏi các nhà cung cấp đám mây lớn.

Tại sao điều này quan trọng

Đối với các nhóm chạy phần mềm tự host, khóa nhà cung cấp (vendor lock-in) và giá cả khó lường là những mối lo ngại thường trực. Các nhà cung cấp đám mây lớn thường đóng gói các tính năng thiết yếu như kiểm tra sức khỏe và định tuyến địa lý vào các gói cao cấp. Nghiên cứu tình huống này chứng minh rằng các lựa chọn thay thế khả thi tồn tại cho các hoạt động quy mô nhỏ đến trung bình. Bằng cách tận dụng DNS có thể lập trình, các kỹ sư có thể xây dựng logic định tuyến tinh vi mà không phải trả tiền cho các dịch vụ quản lý cấp doanh nghiệp. Điều này giảm bớt gánh nặng vận hành và chi phí đồng thời duy trì tính sẵn sàng cao thông qua các cơ chế dự phòng tùy chỉnh.

Tuy nhiên, việc di chuyển cũng nêu bật những đánh đổi. Rời xa các hệ sinh thái tích hợp như AWS có nghĩa là mất đi khả năng tương tác liền mạch giữa các dịch vụ. Các kỹ sư phải tự tay lấp đầy các khoảng trống, chẳng hạn như sử dụng các công cụ bên thứ ba cho quản lý chứng chỉ hoặc các nhà cung cấp riêng biệt cho DNSSEC. Điều này làm tăng độ phức tạp và đòi hỏi kiến thức sâu hơn về các giao thức DNS và tiêu chuẩn bảo mật. Các nhóm phải cân nhắc giữa khoản tiết kiệm chi phí và nỗ lực kỹ thuật cần thiết để duy trì các kiến trúc lai này. Đối với nhiều người, lợi ích tài chính biện minh cho trách nhiệm kỹ thuật bổ sung, đặc biệt khi sử dụng các công cụ hạ-tầng-như-mã-hóa (infrastructure-as-code) để tự động hóa việc triển khai.

Bạn có thể làm gì

• Đánh giá chi phí DNS hiện tại của bạn, tập trung vào các khoản phí cho kiểm tra sức khỏe và truy vấn xác định vị trí địa lý.
• Thử nghiệm các nhà cung cấp DNS có thể lập trình để xem liệu logic tùy chỉnh có thể thay thế các tính năng định tuyến quản lý đắt đỏ hay không.
• Sử dụng các công cụ hạ-tầng-như-mã-hóa như Terraform hoặc OpenTofu để quản lý cấu hình DNS một cách nhất quán.
• Triển khai lựa chọn máy chủ dư thừa trong các phản hồi DNS để cải thiện thời gian hoạt động mà không cần kiểm tra sức khỏe bên ngoài.
• Xem xét chiến lược thử thách ACME của bạn để đảm bảo nhà cung cấp DNS mới hỗ trợ các bản cập nhật động cần thiết.
• Theo dõi chặt chẽ các chỉ số hiệu suất sau khi di chuyển để xác minh rằng cải thiện độ trễ đáp ứng kỳ vọng.