1 điểm bởi GN⁺ 4 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Một tài khoản AWS có phí sử dụng thường ngày dưới 5 USD đã hiển thị hóa đơn ước tính của tháng này là 1,7 tỷ USD
  • Do chênh lệch giữa mức sử dụng thực tế và số tiền hóa đơn quá lớn, tình huống này được xem là dữ liệu hóa đơn ước tính không chính xác
  • Người đăng đã tạo ticket hỗ trợ AWS khẩn cấp để xác minh và xử lý vấn đề
  • Có thể kiểm tra trạng thái dịch vụ AWS tại AWS Health Dashboard
  • Người đăng hỏi xem có người dùng nào gặp hiện tượng tương tự không, và sau đó cũng bổ sung một bài đăng Reddit liên quan

Hóa đơn ước tính bất thường

  • Hóa đơn AWS ước tính của tháng này hiển thị là 1,7 tỷ USD, nhưng phí sử dụng thường ngày của tài khoản này là dưới 5 USD
  • Người đăng cho rằng chênh lệch lớn như vậy xuất phát từ dữ liệu hóa đơn ước tính không chính xác, chứ không phải từ mức sử dụng thực tế

Xác minh và xử lý

  • Đã tạo ticket hỗ trợ AWS khẩn cấp để xác minh vấn đề
  • Có thể kiểm tra trạng thái dịch vụ tại AWS Health Dashboard
  • Người đăng hỏi những người dùng khác có gặp hiện tượng tương tự không, và sau đó chia sẻ bài đăng Reddit liên quan

1 bình luận

 
Ý kiến trên Hacker News
  • Tôi từng xử lý cùng một lỗi ở AWS, và nguyên nhân là lỗi cấu hình đơn vị. Họ định tính khoảng 5 cent cho mỗi GB, nhưng vì bỏ sót GB trong bảng giá nên hệ thống dùng đơn vị mặc định là byte, thành ra 5 cent mỗi byte, và chỉ trong vài giờ một số khách hàng đã thấy hóa đơn lên tới hàng triệu đô la
    Khoảng 2 giờ sáng tôi nhận cuộc gọi từ đội hỗ trợ, đến 3~4 giờ thì đã sửa xong và điều chỉnh lại hóa đơn, rồi lập tức gửi email xin lỗi. Giá trị mức sử dụng mà dịch vụ xuất ra không gắn trực tiếp với giá; mỗi SKU hay hạng mục tính phí được định nghĩa bằng một bảng giá gồm loại đơn vị, vùng và giá trên mỗi đơn vị. Hệ thống ghép bản ghi mức sử dụng với bảng giá dựa trên account ID, region, SKU, v.v., nên nếu chỉ định sai loại đơn vị thì phép chuyển đổi sẽ hỏng và sinh ra mức phí vô lý

    • Không có test nào à? Chỉ cần cấu hình sai một chi tiết tưởng như bình thường là có thể khiến hàng trăm nghìn quản trị viên phải bị gọi dậy lúc nửa đêm và lên cơn đau tim sao?
      Dĩ nhiên sẽ có người nói “đây không phải chi tiết bình thường đâu, Michael!” nhưng mà: https://www.youtube.com/watch?v=3fGHaVn5rGo
    • Tôi tự hỏi không biết hệ thống tính phí của AWS đến giờ còn dùng file CSV để truyền dữ liệu hay không. Hơn chục năm trước, khi tôi nhận ca trực đầu tiên ở AWS, có một kỹ sư “thông minh” nào đó đã chèn vào trường mô tả của dữ liệu vận hành một bản ghi thử nghiệm kiểu như “nếu cho dấu phẩy vào, trường này sẽ ra sao”, và quy trình tính phí đã vỡ tung
      Tôi nhìn bản ghi đó lan rộng và các region lần lượt thất bại theo cùng một cách, chỉ vì một người mà bữa tối của bao người khác bị phá hỏng. Hoàn toàn có thể dùng endpoint test, nhưng anh ta lại cố thử nghiệm ngay trên môi trường production
    • Chuyện này không phải để cười cho qua. Nếu ai đó có bệnh nền như tim mạch mà bất ngờ nhìn thấy mức phí như vậy, thì lo âu, sốc và cảm giác bất lực thực sự có thể dẫn đến tử vong
    • Đây chính là lý do người ta luôn muốn hệ thống fail loud thay vì chọn các giá trị mặc định ngu ngốc
    • Không biết có phải chuyện này xảy ra đúng ngày ổ EBS gp3 được phát hành không
  • Tôi nhận liền ba email cảnh báo rằng ngân sách đã vượt ngưỡng 18 đô la, kiểm tra thì thấy chi phí là 78 triệu đô la. Ban đầu tôi tưởng phishing nên đăng nhập thẳng vào tài khoản thật của mình, nhưng vẫn thấy 78 triệu đô, cú sốc tinh thần là rất lớn

    • Tôi muốn cá xem liệu mô tả của tin tuyển dụng này có bị sửa ngay trong hôm nay không: “Software Development Engineer II, AWS Invoicing”
      https://www.amazon.jobs/de/jobs/10428480/software-developmen...
      Kèm theo là mô tả công việc hào nhoáng về chuyện dùng generative AI, large language model, knowledge graph và agent architecture để chuẩn bị phát hành, điều phối cloud-native service và tự động hóa continuous verification
    • Hóa đơn của tôi là hơn 1 tỷ đô la. Lúc đầu tôi cũng suýt bỏ qua vì nghĩ là phishing, nhưng nó trông quá thật nên tôi đăng nhập trực tiếp vào AWS, và khi thấy khoản phải trả dự kiến thì suýt lên cơn đau tim
      Sau đó tôi tìm được banner thông báo sự cố ở trang hỗ trợ, nhưng tôi vẫn thắc mắc vì sao ngay trên trang thanh toán, nơi đang hiển thị rằng “bạn đang nợ 1 tỷ đô la”, lại không có banner cảnh báo nào
    • Tôi cũng thấy URL awstrack.me cực kỳ đáng ngờ, lại là lần đầu nhận loại cảnh báo này nên chắc mẩm là phishing. Tôi không bấm link mà vào thẳng console, thấy đúng là có sự cố hiển thị sai chi phí, nhưng chẳng thấy nói gì về email cảnh báo; tôi còn lo có khi kẻ tấn công lợi dụng lúc có sự cố để né phát hiện
      Sau khi kiểm tra log, tôi nhận ra chỉ là thông báo sự cố không liệt kê đầy đủ phạm vi ảnh hưởng, rồi lại quay đi pha cà phê. Lần sau chắc phải kiểm tra từ đây trước
    • Sửa lại câu đùa cũ thì: nếu hóa đơn AWS là 78 nghìn đô la thì đó là vấn đề của tôi, còn 78 triệu đô la thì là vấn đề của Amazon
    • Với tài khoản doanh nghiệp thì còn hiển thị mức phí hơn 3 nghìn tỷ đô la
  • Lỗi lần này quá lố nên có lẽ sẽ sớm được sửa, nhưng hồi đầu những năm 2010 tôi từng phát hiện một lỗi thật sự ẩn trong hóa đơn. AWS đã tính sai chiết khấu Reserved EC2 cho một số máy chủ, và dù tôi thường xuyên phân tích chi tiết sử dụng bằng bảng tính 18 tab thì số tiền vẫn không khớp, nên đã phải lần theo chênh lệch đó suốt nhiều tháng
    Ngay cả sau khi tìm ra nguyên nhân, tôi vẫn mất khá nhiều thời gian để thuyết phục AWS rằng hệ thống của họ sai, và trong lúc đó phần chênh lệch vẫn tiếp tục tích lũy. Sau 14 tháng tôi nhận được khoản hoàn 7.000 đô la, nghe nói còn phải cần phê duyệt từ người phụ trách AWS, và từ đó về sau tôi không còn thấy lỗi tính toán nào từ phía AWS nữa

    • Bản thân khoản credit 7.000 đô la lúc đó thật ra một PM hay director gần gũi với khách hàng cũng có thể cấp mà không cần giám sát nhiều. Vấn đề là quãng thời gian 14 tháng; chỉnh sửa trong cùng chu kỳ thanh toán thì dễ, kỳ ngay trước đó thì phiền nhưng vẫn thường gặp, còn nếu phải điều chỉnh sang các năm tài chính trước nữa thì phải qua bộ phận tài chính nên đau đầu hơn rất nhiều
    • Đồng nghiệp nghĩ tôi soi Cost Explorer quá kỹ, nhưng thời gian bỏ ra để tìm các khoản chi bất thường hầu như luôn hoàn toàn xứng đáng. Chắc chắn tôi không tiêu tốn đến lượng thời gian trị giá 7.000 đô la chỉ để lần ra lỗi này, và trong quá trình đó còn có khả năng tìm ra những cơ hội tối ưu chi phí lớn hơn nữa
      Tôi cũng không thích chuyện lãng phí tiền để làm du thuyền của Jeff Bezos to thêm
    • Gọi là “sẽ sớm được sửa” thì hơi quá, vì đã 12 tiếng rồi. Có vẻ không ai hiểu nổi đoạn code do agent viết ra rồi được đưa vào production
  • Có vẻ đơn vị lẽ ra phải là GB of storage consumed đã bị trộn với Bytes of storage consumed, gây ra lỗi lệch 2^30 lần
    “Phép tính này đáng để nghi ngờ. Tôi đã cố tra cứu định nghĩa trường nhưng kết nối tới máy chủ MCP thất bại, nên tôi đã đoán thay vì xác minh. Đó là lỗi của tôi. Nhưng hãy nhìn doanh thu tăng kìa!”

    • Người ta đưa 0.45, 1.67, 2.50 và bảo tính số tiền phải tính cho khách, nên tổng là 4.62, nhưng cũng có thể là một con số khác. Có thể phải nối chúng lại với nhau, và nếu dấu chấm có nghĩa là phép nhân thì 0 . 45 . 1 . 67 . 2 . 50 sẽ thành 3,015,000
      Nhân với 0 thì lẽ ra phải ra 0, nhưng không thể không tính phí gì cả, nên đáp án đúng là 3,015,000 nghìn đô la
    • Giờ thậm chí còn khó phân biệt liệu “Phép tính này đáng để nghi ngờ” là câu nhại hay phản hồi thật. Ngay cả khi bảo LLM viết ra một câu ngu ngốc đến mức nó tuyệt đối không thể thốt ra, thì có lẽ cũng không có giới hạn của sự ngu ngốc
    • Hôm nay tôi đưa cho tác tử cục bộ một file CSV có các đơn vị kích thước mà con người đọc được và bảo nó đếm số dòng theo từng khoảng GB, nhưng kỳ lạ là nó lại hiểu MB thành GB nên sai hoàn toàn. Nghĩ lại thì có lẽ tự tính bằng Excel còn nhanh hơn
    • Nếu là 2*30 thì ra 60, vậy chỉ cần trả 28,3 triệu đô la, nhưng ý định có lẽ là 2^30, và khi đó sẽ là 1.5 đô la
    • Vibe coding hệ thống tính cước để tăng doanh thu 9,000%, đúng là tư liệu tuyệt vời cho hồ sơ thăng chức
  • Sáng nay thấy email cảnh báo tính cước, tôi đã tưởng mình lỡ làm lộ khóa AWS và tiêu tới 437 tỷ đô la. May là tôi không có ngần ấy tiền, và cũng cảm ơn AWS vì đã bơm cho tôi lượng adrenaline chưa từng có dù chưa uống cà phê

    • Nếu tôi nợ AWS 437 nghìn đô la thì đó là vấn đề lớn của tôi, nhưng nếu là 437 tỷ đô la thì đó là vấn đề lớn của AWS
    • Có khi vì vụ này đã có người thực sự bị nhồi máu cơ tim hoặc tử vong. Việc Amazon hiển thị nguyên giá trị như vậy cho người dùng là cách xử lý vô trách nhiệm
    • Tôi đang định đi ngủ thì nhận được cảnh báo, và số tiền đó rõ ràng đã vượt quá giới hạn 16 đô la mà tôi đặt
    • Tôi đã phải vật lộn với AWS suốt hai tháng vì một tài khoản bị chiếm đoạt. Trước đó 3 năm liền chi phí hàng tháng của tôi chỉ khoảng 20 đô la, vậy mà tôi mất 20 nghìn đô la và còn nhận thêm các hóa đơn trị giá hàng chục nghìn đô la, trong khi AWS không giúp gì cho tới khi chính tôi tự chặn được vụ xâm phạm
      Sau giờ làm tôi đã phải thức trắng đêm học cách viết script hạ tầng AWS để kiểm soát vụ xâm phạm, nhưng vẫn bị từ chối đóng tài khoản, và họ cũng từ chối yêu cầu tôi ký thỏa thuận trách nhiệm chung để xem xét vụ việc. Cuối cùng tôi liên hệ văn phòng tổng chưởng lý bang, và từ đó họ gửi email trực tiếp cho AWS; chưa đầy 24 giờ sau một quản lý AWS gọi cho tôi, dọn dẹp tài khoản và hoàn lại 20 nghìn đô la. Thế mà họ vẫn nhất quyết không cho đóng tài khoản, nên có cảm giác là không có cách nào rời AWS hoàn toàn, và đây đúng là kiểu kinh doanh tệ hại nhất
    • Trường hợp của tôi là 500 triệu đô la, và tay tôi run đến mức gần như không nhập nổi mật khẩu
  • Chỉ cần báo với quản lý tài khoản rằng ngân sách đang khó khăn, rồi xin họ rộng lượng cho phép mỗi tháng trả góp vài tỷ đô la một cách thiện chí cho tới khi tình hình tài chính khá hơn

    • Không được tỏ ra yếu thế. Hãy đối mặt trực diện và làm thẻ tín dụng có hạn mức cao hơn
  • Nợ ngân hàng 100 đô la là vấn đề của tôi, nhưng nợ 1.7 tỷ đô la là vấn đề của ngân hàng

    • Khi vợ tôi phụ trách các sự kiện cho một công ty tầm trung ở chỗ làm cũ, sau sự kiện số dư Amex doanh nghiệp thường vượt 300 nghìn đô la. Trong thời gian cô ấy nghỉ thai sản, người phụ trách thay đã không thanh toán hóa đơn, nên khi quay lại thì số tiền quá hạn đã hơn 500 nghìn đô la, và email cùng voicemail từ Amex chất đống
      Ban đầu các tin nhắn còn lịch sự, rồi dần trở nên khẩn thiết hơn, nhưng chưa bao giờ chuyển sang đe dọa hay thù địch
    • Trò đùa này chỉ đúng khi bạn thực sự khiến AWS tốn 1.7 tỷ đô la. Nếu họ chỉ phát hóa đơn vô cớ thì vẫn là vấn đề của người dùng
    • Vậy thì câu hỏi tiếp theo là nếu nợ ngân hàng 1.7 nghìn tỷ đô la thì chuyện gì sẽ xảy ra
    • Với Elon Musk thì có thể không áp dụng
  • Có vẻ AWS thấy Anthropic tính nhầm 16 triệu đô la cho người dùng có mức sử dụng bằng 0, nên nghĩ rằng chẳng có lý do gì phải dừng lại ở mức vài triệu đô
    https://www.techtimes.com/articles/320266/20260712/anthropic...

    • Nếu startup kiểm toán hóa đơn AI Vaudit xem xét 34 triệu đô la hóa đơn của 60 khách hàng doanh nghiệp và phát hiện khoảng 1.7 triệu đô la bị tính quá, tức tỷ lệ lỗi khoảng 5%, thì đó là chuyện khá nghiêm trọng
  • Gần đây khi thanh toán ở Whole Foods, tôi nhận ra thẻ Chase Amazon Prime không còn được nhận diện tự động một cách ổn định nữa nên ưu đãi giảm giá không được áp dụng tự động. Tôi tự hỏi có bao nhiêu khách hàng vẫn thanh toán theo cách đã hoạt động tốt suốt nhiều năm và cuối cùng lại phải trả giá đầy đủ
    Theo nhân viên dịch vụ khách hàng tại cửa hàng, chuyện này đã thay đổi trong khoảng một năm qua, và họ đoán đó là tác dụng phụ ngoài ý muốn của việc bỏ tính năng thanh toán bằng lòng bàn tay. Không liên quan trực tiếp, nhưng nó khiến tôi nghĩ tới việc Amazon còn đang tính sai những gì nữa

    • Giờ là lúc có kiện tập thể hoặc hàng nghìn vụ kiện nhỏ. Dù có điều khoản trọng tài thì gánh nặng xử lý cũng sẽ rất lớn, nên hy vọng ai đó sẽ đưa ra quyết định đúng đắn và hoàn tiền tự động
    • Những lỗi nhỏ như thế này đang xuất hiện vô số trong các hệ thống vốn từng đơn giản và ổn định. Không phải tất cả đều do vibe coding, nhưng cũng khiến người ta tự hỏi có bao nhiêu trong số đó là kết quả của vibe coding
  • Có lần 20.000 USD phí bị rút thật khỏi tài khoản ngân hàng, và phải mất vài tháng cùng sự can thiệp của văn phòng tổng chưởng lý bang mới giải quyết xong để lấy lại tiền. Sau đó họ hoàn toàn không dùng bất kỳ sản phẩm AWS nào nữa và chuyển cả những việc nhỏ sang Azure
    Các vấn đề về tính phí của AWS đã kéo dài nhiều năm; có thể dễ dàng tìm thấy trên mạng những trường hợp tài khoản bị chiếm đoạt chạy máy chủ đào tiền mã hóa trong nhiều tháng khiến một sinh viên bị tính 60.000 USD mà AWS vẫn không phát hiện hoặc chặn được

    • AWS trên thực tế gần như là một nhà cung cấp dịch vụ công, nên nếu tiếp tục xử lý việc tính phí một cách cẩu thả thì cuối cùng cũng sẽ khó tránh khỏi việc bị quản lý ở mức tương ứng
    • Với các dịch vụ có chi phí biến động, luôn phải dùng thẻ có giới hạn chi tiêu
    • Việc phát hiện tài khoản bị chiếm đoạt không thể chính xác 100%. Con người nhìn trực tiếp thì có thể thấy rõ, nhưng không thể chủ động để con người rà soát mức sử dụng của mọi tài khoản
    • Bài học đầu tiên khi dùng dịch vụ của nhà cung cấp là đừng bao giờ bật thanh toán tự động. Sự tiện lợi hay giảm giá là không đáng kể so với rủi ro để nhà cung cấp tự ý rút sạch tiền trong tài khoản
    • Có một thời gian họ đặt một phần homelab trên AWS. Họ là giảng viên trong lớp học nơi sinh viên học về đám mây, và vì người dạy khuyến khích tạo môi trường thực hành nên họ cũng cài MediaWiki với stack LAMP trên EC2 free tier, nhưng dù cấu hình ban đầu không quá khó, cuối cùng vẫn rời đi mãi mãi vì hai lý do
      Thứ nhất, ngay cả đến hôm nay, việc bảo vệ đầy đủ một hệ thống Linux bình thường phơi ra Internet vẫn là điều gần như bất khả thi hoặc quá tốn công. Dù đã cài fail2ban và đóng nhiều cổng, các đợt tấn công spam vẫn đi vào ở tầng ứng dụng. Thứ hai, gần như không thể thực sự cưỡng chế trần chi tiêu đám mây theo từng chu kỳ thanh toán. Dù phần lớn thời gian vẫn nằm trong hạn mức miễn phí, chỉ cần sai một thiết lập hoặc tài nguyên tăng vọt là có thể phát sinh hóa đơn lớn rất khó khiếu nại; đặc biệt còn có thể do những nguyên nhân ngoài tầm kiểm soát, như người dùng bên ngoài tiêu thụ tài nguyên VPC và lưu lượng truyền ra ngoài. Vì vậy họ đã đóng tài khoản, và từ đó rất đồng cảm với các công ty bị buộc phải dùng đám mây thay cho hạ tầng tự sở hữu mà vẫn không thể kiểm soát chi phí