Di chuyển từ AWS sang Hetzner, cắt giảm 76% chi phí đám mây

 (digitalsociety.coop)
9 điểm bởi GN⁺ 2025-10-18 | 1 bình luận | Chia sẻ qua WhatsApp
  • Bằng cách di chuyển từ AWS và DigitalOcean sang Hetzner, chi phí đám mây đã giảm 76% trong khi năng lực tài nguyên tăng gấp 3
  • Trước đây đã sử dụng song song hai dịch vụ đám mây dựa trên độ ổn định của AWS và sự đơn giản của DigitalOcean
  • Sau khi hết credit miễn phí, chi phí vận hành vượt quá 449 USD/tháng, khiến nhóm bắt đầu tìm kiếm các lựa chọn thay thế như Hetzner
  • Để cắt giảm chi phí, nhóm đã xây dựng stack đám mây tự quản lý kết hợp Kubernetes dựa trên Talos Linux, CloudNativePG, Ingress NGINX, ExternalDNS, cert-manager và nhiều thành phần khác
  • Sử dụng máy chủ ARM shared vCPU và lưu trữ tương thích S3 của Hetzner để mở rộng tài nguyên ở quy mô lớn mà vẫn duy trì hiệu năng và độ ổn định
  • Dù mức độ thuận tiện trong quản trị có giảm đôi chút, đây vẫn là một đám mây thay thế trong khu vực châu Âu có hiệu quả chi phí/hiệu năng rất nổi bật

Bối cảnh

  • Mọi phần mềm do DigitalSociety phát triển đều chạy trên hạ tầng đám mây
  • Trước khi di chuyển, hạ tầng chính được vận hành trên cả AWS (quản lý các dịch vụ cốt lõi, xác thực, email, v.v.) và DigitalOcean (dịch vụ nhẹ hơn, giám sát, Kubernetes)
  • AWS được chọn vì sự quen thuộc sau hơn 15 năm sử dụng và độ ổn định API cao
  • DigitalOcean được chọn nhờ môi trường Kubernetes đơn giản, control plane miễn phí và hiệu quả chi phí
  • Ban đầu chỉ dùng DigitalOcean, nhưng với SaaS chuyên dữ liệu như tap cần nhiều tài nguyên và thêm credit, nên nhóm đã tận dụng credit startup của AWS (1.000 USD)

Hết credit và gánh nặng chi phí

  • Nhờ Fargate của AWS (chạy container serverless), giai đoạn đầu có thể triển khai với chi phí thấp, nhưng do tap là dịch vụ chuyên dữ liệu nên để duy trì hiệu năng cần tối thiểu 2x CPU và 4 GiB RAM
  • Theo mức giá của Fargate, một container với cấu hình này tốn hơn 70 USD/tháng; cộng thêm hai worker instance và các hạ tầng khác thì tổng chi phí tăng lên 449,50 USD/tháng
  • Số credit miễn phí được cấp đã hết trước cả 6 tháng, trở thành một gánh nặng chi phí cố định nghiêm trọng đối với một startup tự bỏ vốn

Quá trình tìm kiếm phương án thay thế

  • Để giảm mạnh chi phí vận hành và tăng tính độc lập về công nghệ, nhóm đã tìm kiếm các nhà cung cấp đám mây đặt tại Anh/châu Âu
  • Bị thu hút bởi mức giá cạnh tranh của Hetzner, nhóm quyết định di chuyển khỏi cả AWS lẫn DigitalOcean dù phải chấp nhận môi trường VPS tự quản lý và độ phức tạp vận hành cao hơn
  • Vì phần lớn dịch vụ vốn đã chạy trên Kubernetes, nhóm đã dựng một cụm Kubernetes tự quản trên Hetzner nhờ khả năng triển khai cụm đơn giản của Talos Linux
  • Dù không còn các dịch vụ Managed DB như trên AWS hay DigitalOcean, nhóm đã dùng CloudNativePG để tích hợp và quản lý an toàn cụm PostgreSQL trong môi trường Kubernetes (giám sát, sao lưu, ứng phó sự cố, v.v.)

Stack hạ tầng mới

  • Hetzner: sử dụng máy chủ ARM, block storage, load balancer, mạng, firewall, lưu trữ đối tượng tương thích S3
  • Talos Linux: tự động hóa vận hành bằng cách quản lý node Kubernetes thông qua cấu hình khai báo
  • CloudNativePG: khai báo cụm DB trong Kubernetes manifest và hỗ trợ tích hợp sao lưu tự động, ứng phó sự cố, v.v.
  • Ingress NGINX Controller: quản lý tập trung định tuyến HTTP trong cụm
  • ExternalDNS: tự động liên kết DNS với tài nguyên ingress
  • cert-manager: tự động cấp chứng chỉ TLS cho HTTPS
  • Toàn bộ hạ tầng được mã hóa bằng Terraform và Helm, đồng thời triển khai tự động qua GitHub Actions để hiện thực hóa DevOps

So sánh chi phí

  • Chi phí hàng tháng trước khi chuyển: AWS + DigitalOcean = 559,36 USD
  • Chi phí hàng tháng sau khi chuyển: Hetzner = 132,96 USD (−76%)
  • Mức tăng tài nguyên:
    • CPU: 12 vCPU → 44 vCPU (+367%)
    • RAM: 24 GiB → 88 GiB (+367%)
    • Dù tài nguyên tăng lên, tổng chi phí hàng tháng vẫn rẻ hơn rất nhiều

Thách thức và bài học trong quá trình di chuyển

  • Network zone của Hetzner không hoàn toàn giống với Availability Zone của AWS
    • AWS có nhiều availability zone trong một region, và private networking được kết nối rộng ở cấp region
    • Hetzner có nhiều location nằm dưới một network zone (eu-central), và độ trễ mạng giữa các location này khá lớn
    • Trên thực tế, nhóm đã quan sát qua monitoring rằng việc phân tán sang nhiều location gây ra các vấn đề như suy giảm hiệu năng
    • Để thay thế, nhóm dùng Placement Group trong một location duy nhất (Nuremberg) nhằm tăng khả năng phục hồi sự cố bằng cách phân tán máy chủ vật lý
  • Ngay cả dịch vụ dựa trên container cũng không dễ di chuyển
    • Khi chuyển môi trường từ AWS ECS sang Kubernetes, việc sửa các script tự động hóa cho toàn bộ cấu hình (đặc biệt là triển khai file config) mất nhiều thời gian hơn dự kiến
    • Cuối cùng, nhóm cải thiện hệ thống quản lý file config và tích hợp cấu hình nhạy cảm bằng Kustomize, giúp tăng khả năng truy vết và thuận tiện khi rà soát

Kết luận

  • Hetzner không phải dịch vụ managed dễ dùng, nhưng là lựa chọn cực kỳ hiệu quả cho các đội ngũ có khả năng tự vận hành
  • Tự vận hành giúp giành quyền kiểm soát chi tiết cấu hình, đồng thời tối đa hóa hiệu năng trên chi phí
  • Cách làm này tạo nền tảng để tiếp tục phát triển và vận hành tap, một SaaS chuyên dữ liệu, với chi phí hợp lý và hiệu năng ổn định

Bài viết liên quan

1 bình luận

 
GN⁺ 2025-10-18
Ý kiến Hacker News

  • Tôi muốn nhấn mạnh rằng mức cải thiện hiệu năng cảm nhận được khi triển khai trực tiếp trên bare metal thực sự rất lớn. Với dịch vụ của chúng tôi, hiệu năng tăng gấp 2 lần và cho ra mức vận hành ổn định, dễ dự đoán. Có nhiều lý do cho điều đó:

    • Độ trễ thấp: khi tự quản lý mạng trực tiếp, bạn không phải chia sẻ mạng phức tạp của các trung tâm dữ liệu quy mô lớn nên độ trễ giảm hơn 10 lần

    • Tối ưu cache: triển khai tối ưu theo phần cứng giúp tận dụng đầy đủ hiệu năng thực sự của các CPU đời mới

    • Dùng NVMe chuyên dụng: tốc độ disk IO cực kỳ cao

    • Một lợi ích nữa là gần như không cần autoscaler. Phần cứng cùng mức giá mạnh hơn 10 lần, tốc độ cũng nhanh gấp 2, nên chạy full-size hợp lý hơn. Toàn bộ hệ thống ổn định và dễ quản lý hơn

    • Cũng không cần lo phí S3. Chỉ cần gắn ổ NVMe 15TB vào từng server rồi chạy cụm MinIO/garage. Chúng tôi đang xử lý 20GiB/giây và 50 nghìn API call mỗi giây trên cụm 10 node. Nếu là S3 thì riêng API call thôi đã thành mức phí đáng kinh ngạc $20~$250 mỗi giây

    • Chỉ phát sinh phí cố định hàng tháng

    • Và còn có lưu trữ tốc độ cao giá rẻ, chạy các instance PostgreSQL lớn với chi phí thấp, đồng thời giảm rất nhiều các ràng buộc và màn vật lộn thường gặp trên cloud

    • Dù có đầu tư vào cấu trúc như vậy thì chi phí vẫn chỉ bằng 1/10 so với AWS

    • Nếu tự quản lý là gánh nặng, thì bên chúng tôi (https://lithus.eu) có thể quản lý thay với giá bằng một nửa AWS và còn hỗ trợ DevOps. Liên hệ qua adam@, xem domain

    • Bối cảnh kỹ thuật: bare metal là cách chạy trực tiếp trên máy chủ vật lý thật, không phải 'ảo hóa (VM)'

    • Tôi thực sự mong chúng ta vượt qua thời kỳ cũ kiểu 'cứ thêm máy là nhanh hơn' và 'chi phí chẳng đáng kể'. Trong sự nghiệp của tôi, thời .NET từng có lúc một server một cabinet chịu được đến hàng triệu người dùng. Sau đó khi chuyển sang một công ty dùng cloud, container và microservice Node, tôi ngày nào cũng sống trong mớ hỗn độn của hóa đơn và vấn đề hiệu năng, nghĩ lại đôi khi vẫn còn rùng mình

    • Có cảm giác thay đổi lúc nào cũng lặp lại. Nhìn công ty chúng tôi thì việc không chạy theo công nghệ mới lại giống như đang đứng ở tuyến đầu của xu hướng local cloud/edge/IDC nội bộ

    • Dùng S3 API giống như gọt hành. Càng dùng càng chảy nước mắt

    • Làm bare metal thì phải có nhân sự chuyên trách cho quản lý mạng, bảo mật, giám sát, vá lỗi, cập nhật... Chi phí nhân lực kiểu này chỉ hiệu quả khi đạt đến một quy mô nhất định. Vì vậy với doanh nghiệp vừa và nhỏ thì cloud vẫn có lợi hơn về bảo mật và chi phí vận hành

    • Ngay cả trên AWS, chính AWS cũng ghi trong tài liệu rằng mức cấp phát 1 vCPU của Lambda thực tế chỉ tương đương khoảng 50%. Tỷ lệ có cải thiện khi tăng cấp phát bộ nhớ và CPU, nhưng không phải lúc nào cũng cho 100% hiệu năng

  • Từ lâu tôi đã nghĩ rằng nếu dùng server riêng thì có thể tối đa hóa hiệu quả. Tôi đang vận hành vài node trên Hetzner, và ngay cả server cũ 3 năm tuổi thuê qua đấu giá cũng cho hiệu năng khác hẳn VM. Phần cứng server được tối ưu theo số core và IO, còn đa số cloud thì overcommit phần cứng. Thậm chí cả disk IO cũng dùng đủ kiểu mẹo như chạy trên NAS rồi giả lập thành local disk. Phần lớn startup không cần mức ảo hóa quá mức hay loại đĩa dựa trên NAS như vậy. Ngược lại, thuê server ở nơi như Hetzner có thể đi xa hơn nhiều với chi phí thấp hơn. Tôi tò mò ở Bắc Mỹ, nhất là Canada, có nhà cung cấp nào cho mức giá/chất lượng kiểu Hetzner không. Tôi biết OVH rồi, nếu có nơi nào tương tự thì mong được giới thiệu

    • Có vẻ nhiều người nghĩ phải lập tức bắt chước kiến trúc kỹ thuật mà Google hay Facebook làm. Chúng tôi vận hành khá giản dị trên VPS châu Âu. Nhưng người mới vào công ty lần nào cũng bảo phải bắt đầu dự án di chuyển lên cloud. Lần nào tôi cũng phải thuyết phục kiểu: "thực ra chúng ta cũng đang dùng cloud rồi, và tôi sẽ không cho bạn làm một dự án migration lên cloud chỉ để làm đẹp CV đâu"

    • Tôi có ghi lại benchmark thực tế về hiệu năng CPU giữa cloud và server bare metal, có thể tham khảo https://jan.rychter.com/enblog/cloud-server-cpu-performance-comparison-2019-12-12

    • Một trang tôi mới tìm thấy gần đây có thể hữu ích: https://vpspricetracker.com, ý tưởng rất ấn tượng. Phần lớn nhà cung cấp được liệt kê ở đây cũng có cung cấp server riêng

    • Nếu ý bạn là 'chất lượng kiểu Hetzner tại Mỹ, không nhất thiết phải là thương hiệu nội địa', thì bản thân Hetzner cũng có 2 trung tâm dữ liệu tại Mỹ

    • Với Canada, một số nhà cung cấp đáng tham khảo là https://www.hostpapa.ca/, https://www.cacloud.com/, https://www.keepsec.ca/, https://www.canspace.ca/

  • Bên tôi cũng đang trải qua xu hướng tương tự. Nhiều team chuyển sang Hetzner và kinh ngạc trước hiệu năng/giá thành, nhưng rồi nhận ra phải tự xây lại toàn bộ phần vận hành Postgres như backup, failover, monitoring... Vì vậy chúng tôi đã tự tạo một dịch vụ Postgres managed chạy trực tiếp trên Hetzner. Vẫn giữ cấu trúc tối ưu phần cứng tương tự, nhưng có thêm high availability (HA), backup, và point-in-time recovery (PITR). Nó là mã nguồn mở, chạy rất sát phần cứng, và không có các bẫy chi phí ẩn như phí I/O hay data outbound thường gặp trên AWS. Nếu tò mò có thể xem blog 1, 2

    • Vì lý do này mà tôi thấy Big Cloud, đặc biệt là PaaS và managed SQL, có sức hấp dẫn rất lớn (các team dev tôi tư vấn cũng vậy). Ngay cả khi chưa có nhiều kinh nghiệm vận hành, người ta vẫn yên tâm hơn khi backup/khôi phục database, vá lỗi, giới hạn truy cập, quản lý port, phát hiện bất thường, ứng phó tấn công DoS... đều được xử lý tự động. Xét cả về chính trị lẫn kỹ thuật, dùng các công ty cloud nổi tiếng cũng tạo cảm giác an toàn về mặt tâm lý

    • Nếu gặp vấn đề với Postgres tự cấu hình và tự quản lý, thì https://www.elephant-shed.io/ có thể đáng tham khảo

  • Điều thú vị là các bài viết hay bình luận kiểu này gần như không đưa ra bối cảnh khi khuyên người khác. Bạn đang vận hành một bản tin nhà thờ trong thời gian rảnh, hay là một enterprise SaaS lưu lượng rất cao với khách hàng toàn cầu? Chỉ riêng điều đó đã làm thay đổi hoàn toàn yêu cầu. Nếu không giải thích môi trường của mình, thì các lời khuyên về giá, hiệu năng, hay độ sẵn sàng gần như vô nghĩa. Lý do hạ tầng web trở nên phức tạp quá mức cũng là vì mọi người cứ làm theo lời khuyên của nhau dù yêu cầu thực tế rất khác nhau

    • Tôi muốn bổ sung vào ý 'làm theo lời khuyên một cách thiếu phê phán khi nhu cầu khác nhau chỉ khiến thực tế phức tạp hơn'. Có công ty mà account manager cloud còn chen vào bữa trưa của các sếp C-level để thúc đẩy dùng AWS. Trong quá trình đó, kiến trúc sư của AWS được cử trực tiếp đến team chúng tôi và đương nhiên chỉ đề xuất những lựa chọn serverless đắt nhất. Nhưng rốt cuộc thì lần nào cũng phải redeploy Docker OS image, và vẫn phải quản lý liên tục chẳng khác gì vá lỗi trên server bare metal thông thường

    • Ngay cả Pastebin cá nhân của tôi cũng không sống nổi nếu không chạy trên bare metal (đùa thôi)

    • Đây đúng là một ví dụ điển hình về bộ mặt của ngành IT

    • Yêu cầu, trình độ kỹ thuật, cấu trúc chi phí, miền vấn đề đều khác nhau hoàn toàn. Hetzner và AWS nhìn bề ngoài giống như cloud, nhưng thực tế là hai dịch vụ hoàn toàn khác. Tôi nói điều này với tư cách người đã dùng cả hai

    • Hoàn toàn đồng ý. Tôi cũng đã viết ý kiến của mình thành blog, có thể xem tại https://news.ycombinator.com/item?id=45616366. Tóm lại là: "hãy hiểu các nhà cung cấp hosting qua một bảng giá trải từ DIY đến enterprise, và nếu không dùng vẫn ổn (YAGNI) thì đừng cố chọn"

  • Tôi đã vận hành SaaS trên Hetzner hơn 10 năm. Phần cứng hoàn toàn riêng, cụm đặt tại trung tâm dữ liệu Đức và Phần Lan, quản lý bằng ansible. Kết nối VPN giữa các server dùng vpncloud (phần mềm này thực sự rất tuyệt). Phí hosting hàng tháng thấp hơn rất nhiều so với AWS và các bên tương tự, còn tốc độ server thì nhanh hơn hẳn. Cấu trúc đơn giản và chỉ cần một số ít server là đủ chịu tải. Khi cần thì chỉ việc thêm server, nhưng vì là bare metal nên không phải kiểu mở rộng trong vài phút. Chỉ cần lên kế hoạch trước vài giờ hoặc vài ngày là được. Cơ sở dữ liệu dùng cấu trúc phân tán RethinkDB (sắp chuyển sang FoundationDB) để dự phòng sự cố

    • Tôi cũng đang vận hành khá giống như vậy với rethinkdb. Nhưng tôi tò mò vì sao anh lại chọn FoundationDB. RethinkDB vẫn đang được bảo trì và thỉnh thoảng vẫn có tính năng mới. Cộng đồng người dùng trên Slack vẫn sống hơn tôi nghĩ

    • Thật vui khi thấy vẫn còn người dùng RethinkDB

    • Anh nối trực tiếp giữa trung tâm Hetzner DE/FI bằng vpncloud à? Tôi tưởng Hetzner cũng tự cung cấp tính năng đó với giá rẻ

  • Gần đây tôi đã hỗ trợ khá nhiều team chuyển từ AWS sang Hetzner (và Netcup), và điều khiến mọi người ngạc nhiên nhất không phải là chi phí hay hiệu năng bản thân nó, mà là việc kiến trúc trở nên đơn giản hơn hẳn khi gỡ bỏ 15 lớp trừu tượng quản lý (dịch vụ). Không còn phải đau đầu với S3/EFS/FSx, Lambda cold start, hay EBS burst credit. Chỉ cần triển khai Docker lên NVMe nhanh là chạy ngay. Tất nhiên sẽ cần thêm một chút năng lực DevOps như monitoring, backup, patching... Nhưng các công việc vận hành này một khi đã tự động hóa thì không phải thứ thay đổi hàng tuần. Ở Elestio, chúng tôi tập trung vào sự đơn giản hóa này, cung cấp stack managed hoàn chỉnh cho hơn 400 phần mềm mã nguồn mở trên bất kỳ cloud nào (bao gồm cả CI/CD). Có thể phủ đến production ở Hetzner hay nơi khác https://elest.io (lưu ý: tôi làm ở Elestio và cung cấp dịch vụ mã nguồn mở multi-cloud)

    • Tôi tò mò về dịch vụ Postgres managed của bạn. Nó có hỗ trợ streaming replica và streaming backup không, hay chỉ lưu dump lên s3?

  • Hồi đầu sự nghiệp tôi từng làm ở một công ty cực tốt, nhưng khi đó cần một phiên bản Postgres mà RDS chưa hỗ trợ nên tôi đã phải tự thiết lập Postgres trên EC2 nhiều lần. Đó là thời Docker còn chưa tồn tại, nên càng về sau càng chỉ thấy tốn thời gian. Ngay khi RDS hỗ trợ phiên bản đó thì mọi thứ dễ hơn hẳn. Tôi vẫn còn nhớ rất rõ những đêm phải ngồi cài Postgres lặp đi lặp lại đến 3 giờ sáng. Bài viết này hay đấy, nhưng cuối cùng thì cũng chỉ tiết kiệm được vài trăm đô mỗi tháng. Chỉ cần một kỹ sư tốn 1 giờ quản lý mỗi tháng thôi là có thể xóa sạch khoản tiết kiệm đó. Nếu bất ngờ gặp sự cố thì số tiền tiết kiệm cả năm có khi mất sạch trong một ngày. Với dự án cá nhân mà thời gian không quá quan trọng và cần server cấu hình lớn, thì vận hành bare metal có thể tốt hơn. Nhưng cuối cùng giá trị thời gian của tôi vẫn cao hơn. Ví dụ blog Ghost nếu dùng hosting chính thức thì chỉ $10/tháng, còn cũng có thể chạy nhiều cái trên instance Hetzner. Nhưng rồi đến lúc có gì đó hỏng, tôi lại tự hỏi liệu trả thêm $20 có đáng hơn việc bỏ ra 2~3 giờ để sửa không

  • Ưu điểm lớn nhất của (một số) dedicated server Hetzner là băng thông không giới hạn. Tôi đang host một trang nặng về hình ảnh, và từ sau khi chuyển sang Hetzner, suốt 3 năm nay tôi chỉ trả đúng phí cố định và có thể ngủ yên vào ban đêm

  • Hetzner rõ ràng có giới hạn khi mở rộng quy mô. Chúng tôi cũng từng chạy hàng trăm VM trên nền Hetzner ở giai đoạn đầu, và vào lúc cao điểm phải mở rộng lên hơn một nghìn. Khi đó các vấn đề bắt đầu xuất hiện: thỉnh thoảng bị cấp IP nằm trong blacklist nên gặp khó khi kết nối tới AWS, Google (đặc biệt là S3). Thậm chí có lúc khu vực của chúng tôi không còn VM để cấp nữa, nên việc cấp mới bị dừng hẳn. Kết quả là, nếu không cần mở rộng ở quy mô lớn thì Hetzner rất tuyệt, nhưng khi thật sự cần scale thì chúng tôi phải kết hợp thêm dịch vụ khác

    • Việc cạn hẳn tài nguyên VM trong một khu vực có lẽ không chỉ là vấn đề của một cloud cụ thể nào. GCP vài năm trước cũng từng như vậy. Nếu yêu cầu hàng trăm VM cùng lúc vào giờ cao điểm thì có vẻ cloud nào cũng thấy nặng

    • Chuyện Microsoft chặn dịch vụ của Hetzner và Scaleway thì khá nổi tiếng https://www.linkedin.com/posts/jeroen-jacobs-8209391_something-interesting-happened-today-it-activity-7382774062164516864-GSKT/. Tôi chưa biết AWS hay GCP cũng làm vậy, nhưng cũng không quá bất ngờ. Big cloud biện minh cho kiểu hành vi phản cạnh tranh này bằng cái cớ 'chặn spam đi vào', nhưng thực tế không phải thế

    • Có thể ở đây đang lẫn giữa người dùng phần cứng Hetzner thật (Server Auction, v.v.) và người dùng server ảo (VM). Server vật lý thật vượt trội hơn nhiều về hiệu năng/giá thành, còn VM dù không mang tính đột phá thì vẫn rẻ hơn đối thủ

    • Tranh luận này là về sản phẩm Hetzner Cloud (VM). Sản phẩm cloud ra mắt tương đối gần đây so với dedicated server. Nhiều người tìm đến Hetzner chủ yếu là vì giá trị của dedicated server

    • Tôi thực sự tò mò không biết đó là dịch vụ gì mà cần tới hàng trăm hay hàng nghìn VM như vậy, và vì sao lại dùng VM thay vì dedicated server. VM cấu hình lớn nhất của Hetzner được nói là có (48 core, 192GB RAM, 960GB SSD), nên tôi rất tò mò kiểu nhu cầu nào lại cần đến mức đó

  • Tôi có lý do để dùng Hetzner, nhưng cũng có vài điểm cần lưu ý. Độ sẵn sàng của nó có phần kém AWS, và độ đa dạng region cũng ít hơn. Vì vậy tôi rất khuyên nên dùng cùng Cloudflare. Ở Hetzner thì vận hành hệ thống lõi (K8s), còn dữ liệu để trên R2/D1/KV và xử lý phân tán bằng Edge Durable Objects. Chúng tôi shard dữ liệu khách hàng theo từng DO để vừa giảm tải cho cơ sở dữ liệu lõi vừa tăng hiệu quả bảo mật

    • AWS cũng từng có khá nhiều sự cố diện rộng ngoài dự đoán. Cuối cùng thì nếu không thiết kế multi-region, vấn đề độ sẵn sàng về mặt cấu trúc vẫn rất khó tránh

    • Tôi cũng thiết kế kiểu chạy phần lõi trên dedicated server của Hetzner, nhân đôi lưu trữ, rồi thêm edge node toàn cầu trên OVH để dùng như CDN riêng của mình

    • Nếu dữ liệu khách hàng nằm ở edge, vậy cụ thể 'lõi' ở đây là gì?