Làm theo hướng dẫn chính thức của AWS Amplify và bị tính phí 1.100 USD

 (elliott-king.github.io)
1 điểm bởi GN⁺ 2024-11-15 | 1 bình luận | Chia sẻ qua WhatsApp
  • Sau khi thử nghiệm theo hướng dẫn chính thức về tích hợp OpenSearch của AWS Amplify, chi phí Amazon OpenSearch Service đã tăng lên tới 1.124,88 USD trong một tháng dù mức sử dụng không nhiều
  • Chi phí tích lũy vì OpenSearch domain do npx ampx sandbox tạo ra vẫn còn tồn tại sau khi sandbox bị dừng/xóa, rồi mỗi lần chạy tiếp theo lại thêm một domain mới
  • Cấu hình chính thức mặc định tạo instance r5.large.search, nhưng giá trị mặc định tối thiểu khoảng 134 USD/tháng này không được thể hiện rõ trong mã boilerplate hay hướng dẫn
  • AWS Support đã cung cấp credit một lần cho OpenSearch và storage, đồng thời yêu cầu thiết lập AWS Budgets để tránh tái diễn
  • Khi dùng Amplify cùng OpenSearch, cần tự kiểm tra các tài nguyên còn sót lại sau khi xóa sandbox và loại instance mặc định để tránh bị tính phí ngoài dự kiến

Khoản phí OpenSearch ngoài dự kiến

  • Sau khi làm theo hướng dẫn chính thức về tích hợp OpenSearch trong AWS Amplify, vài tuần sau hóa đơn AWS lên tới hơn 1.200 USD
  • Dịch vụ được ghi nhận trong yêu cầu Support là Amazon OpenSearch Service, với tổng chi phí trong tháng là 1.124,88 USD
  • Tác giả từng có kinh nghiệm dùng Amplify và OpenSearch vào năm 2020, và cho rằng với mục đích cá nhân thì thường đắt ở mức khoảng 50 USD/tháng, nhưng không đến mức 1.200 USD
  • AWS Customer Support sau khi xem xét chi tiết đã xử lý một billing adjustment dạng one time courtesy cho khoản phí ngoài dự kiến
  • Trong quá trình Support, credit cho OpenSearch và dịch vụ storage đã được cung cấp, đồng thời cũng bị yêu cầu thiết lập AWS Budgets
    • AWS Budgets có thể dự báo chi tiêu tương lai cho một dịch vụ cụ thể hoặc toàn bộ AWS, và gửi cảnh báo nếu dự kiến vượt ngân sách

Tài nguyên được tạo bởi hướng dẫn chính thức

  • Quickstart của Amplify tạo một ứng dụng đồ chơi để ghi chú TODO bằng mã do AWS cung cấp, và Amplify tạo cơ sở dữ liệu DynamoDB cùng các yêu cầu CRUD có xác thực
  • Có thể chạy cục bộ, nhưng Amplify cũng tạo kèm một domain có thể truy cập được
  • Ở bước thiết lập OpenSearch, người dùng viết boilerplate TypeScript để khai báo tài nguyên Amplify
    • Gán bảng DynamoDB vào một biến để tham chiếu trong pipeline
    • Tạo instance OpenSearch, index và indexMapping
    • Viết truy vấn để truy cập dữ liệu trong OpenSearch
    • Tạo OpenSearchIngestionService pipeline để sao chép từ DynamoDB sang OpenSearch
  • Cấu hình liên quan được quản lý bằng TypeScript/JavaScript trong repository cùng với mã frontend
  • npx ampx sandbox khởi chạy các dịch vụ AWS, phát hiện thay đổi cấu hình và tự động chỉnh sửa các dịch vụ AWS hiện có

Domain vẫn còn sau khi xóa sandbox

  • Cấu hình này bao gồm nhiều tài nguyên như cơ sở dữ liệu DynamoDB, 1 dịch vụ OpenSearch, 1 OSIS pipeline, IAM role, v.v.
  • Boilerplate chính thức mặc định tạo instance OpenSearch r5.large.search
    • Giá trị mặc định này không được thể hiện rõ trong mã boilerplate hay trong hướng dẫn
    • r5.large.search tốn tối thiểu 134 USD/tháng
  • Khi kết thúc một ngày làm việc và dừng sandbox bằng CTRL-C, một prompt hỏi có muốn xóa vĩnh viễn hay không xuất hiện, và người dùng có thể chọn Y
  • Lúc này DynamoDB bị xóa, nhưng nhìn trong AWS console thì OpenSearch domain vẫn còn nguyên
  • Ngày hôm sau, khi chạy lại npx ampx sandbox, một instance OpenSearch mới được tạo, và npx ampx sandbox delete cũng không xóa instance ban đầu
  • Nếu lặp lại quy trình này, nhiều OpenSearch domain của cùng một dự án sẽ còn lại trong nền và chi phí sẽ cộng dồn

Khả năng là lỗi và loại instance mặc định

  • Hành vi này trông giống một footgun nghiêm trọng, và tại thời điểm đó vẫn chưa được giải quyết ngay cả sau ticket AWS Support
  • Có các báo cáo lỗi liên quan đã cũ, nhưng không tìm thấy mục nào trong vòng 1 năm gần đây
  • Có khả năng OpenSearch domain được xóa đúng ở v1 nhưng không như vậy ở v2, tuy nhiên đây không phải nguyên nhân đã được xác nhận
  • Luồng hiện tại được chạy qua npx, chứ không phải Amplify CLI
  • Việc r5.large.search là loại máy mặc định cũng vẫn là một yếu tố rủi ro
    • Tác giả cho rằng nên để đây là trường bắt buộc, không có giá trị mặc định
    • Nếu hướng dẫn hiển thị r5.large.search là giá trị mặc định, người dùng sẽ dễ nhận biết hơn
    • Giá trị mặc định này không dành riêng cho Amplify mà là một phần của AWS CDK, nên tác giả không xem đây chỉ là trách nhiệm của đội Amplify

Lưu ý khi dùng Amplify và OpenSearch

  • Tác giả đã dự đoán rằng công cụ giúp tăng tốc phát triển công nghệ mới có thể đắt hơn bare metal, nhưng cho rằng khoản phí lần này đã vượt quá mức đó
  • Sử dụng budget console của AWS có thể giúp nhận cảnh báo khi chi tiêu dự kiến vượt ngân sách
  • Chỉ riêng việc làm theo phần OpenSearch cũng tạo ra IAM account, OpenSearch domain, OSIS pipeline, log group và S3 storage, khiến có nhiều tài nguyên ẩn
  • OpenSearch là dịch vụ thường được khách hàng doanh nghiệp dùng, nên có thể bị xem là dịch vụ “nâng cao”, và người dùng được kỳ vọng hiểu hệ sinh thái AWS tốt hơn
  • Tác giả dùng OpenSearch vì hỗ trợ truy vấn bounding-box geo_point, nhưng không chắc liệu một sản phẩm đơn giản hơn có làm được hay không
  • Theo cập nhật, hướng dẫn của AWS sau đó đã được sửa đổi; dù 3 tháng trước khi vấn đề được nêu lần đầu thì tài liệu chưa được cập nhật, có vẻ công việc PR tài liệu đã bắt đầu trước khi bài viết được công bố

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-11-15
Các ý kiến trên Hacker News

  • Cảnh báo thanh toán chẳng khác gì trò đùa; thực tế phải cung cấp giới hạn chi tiêu cứng
    Cũng cần cung cấp cách thiết lập giới hạn đó trong quá trình onboarding
    Việc xây dựng hoạt động kinh doanh trên những tấm séc trắng và các khoản phí ngoài ý muốn là đáng ngờ, và cũng tạo rào cản lớn cho việc áp dụng
    Càng thấy nhiều trường hợp kiểu “làm theo tutorial 20 phút rồi bị tính phí bằng cả số tiền tích cóp cả đời; lần này hỗ trợ khách hàng miễn cho, nhưng lần sau có vẻ họ sẽ lấy luôn cả nhà”, các lập trình viên càng không muốn khám phá sản phẩm AWS

    • Đây không chỉ là vấn đề của riêng AWS; nhìn chung các nhà cung cấp cloud dường như chỉ có hai loại
      Những nơi đẩy rủi ro sang khách hàng như AWS hay DigitalOcean, và những nơi bán các gói giá “không giới hạn”·“không đo đếm” đáng ngờ
      Cả hai đều không phải hình thức mong muốn
      Ước gì có nhà cung cấp cho phép lập kế hoạch dung lượng đúng đắn với các giới hạn rõ ràng, được ghi trong tài liệu, trong đó khách hàng chịu rủi ro về tính sẵn sàng nhưng nhà cung cấp chịu rủi ro tài chính
      Nếu không quá mức, tôi cũng sẵn sàng trả mức phí cố định cao hơn
    • Giới hạn chi tiêu cứng gần như phản tác dụng đối với khách hàng doanh nghiệp, nhóm khách hàng cốt lõi của AWS
      Hầu như không có khoản phí ngoài ý muốn nào, nếu rẻ, lại tệ hơn việc gây downtime hoặc mất dữ liệu ở một ứng dụng quan trọng
      Chỉ cần tồn tại dưới dạng tùy chọn thì đội kế toán cũng có thể gây áp lực buộc dùng, và khi có vấn đề, nó có nguy cơ dẫn đến sự cố mất dữ liệu
      Điều này có thể hợp lý với các nhà cung cấp cloud tập trung vào lập trình viên độc lập hoặc doanh nghiệp vừa và nhỏ
    • Trong các bình luận HN đã nhiều lần có người nói rằng mã thanh toán của AWS là một đống spaghetti code khổng lồ, nên nội bộ rất sợ đụng vào các thay đổi lớn
      Đây thuộc nhóm thông tin nội bộ khá thú vị mà tôi biết được ở đây
    • Tôi từng quan tâm đến AWS, nhưng vì những lý do như thế này mà chưa bao giờ thực sự dấn thân vào
      Dùng VPS rẻ và tính phí cố định thì an toàn hơn là phải hối tiếc
    • Cần phải quản lý bằng quy định
      Yêu cầu Amazon làm gì đó không có nhiều ý nghĩa
      Cần dùng luật để buộc Amazon và các công ty khác tôn trọng tiền của người dùng
      Về cơ bản, doanh nghiệp không làm những việc tốt cho đạo đức hay nền kinh tế, mà làm những việc kiếm ra tiền

  • So ra thì chuyện này nhỏ hơn, nhưng khi cố triển khai app lên ECS, tôi nhận hóa đơn 100 đô la và quyết định không bao giờ dùng AWS nữa
    Lỗi khiến dịch vụ không chạy là vấn đề phía app của tôi, nhưng log CloudWatch chỉ hiện khoảng 20%, nên để lấy được log tôi phải redeploy năm lần, sửa xong rồi lại redeploy thêm năm lần nữa
    Mỗi lần triển khai thất bại đều bị tính phí, và sau khoảng hai ngày vật lộn, tôi xóa tài khoản rồi triển khai lên DigitalOcean App Platform
    Ở đó deployment cũng thất bại vì lỗi app, nhưng lần nào log cũng hiện ra, tôi sửa và chạy được trong vòng 10 phút, tổng phí chỉ vài cent
    Từ ngày đó tôi tự hứa nếu có lựa chọn thì tuyệt đối không dùng AWS và cũng không khuyến nghị AWS

    • Tôi chỉ từng dùng Azure, nhưng ECS có vẻ tương đương Azure Container Apps
      Với mục đích phát triển·kiểm thử, mô hình tính phí theo mức tiêu thụ rất rẻ
      Không biết với workload lớn thì thế nào, nhưng tính phí theo mỗi lần deployment thì thật kỳ lạ
    • Tôi bỏ AWS sau khi biết không thể triển khai container trực tiếp lên EC2 như GCP
      Với dự án lớn thì hỗ trợ có thể tốt hơn, nhưng với quy mô nhỏ đến trung bình thì GCP tốt hơn nhiều
      Nó có các thành phần nền tảng phù hợp với cách dùng container hiện nay, và còn có BigQuery

  • Có vẻ có lỗi rõ ràng trong script mà lệnh npx đó chạy
    Tác giả nói đúng; nếu là tutorial thì 100% phải chọn tài nguyên rẻ nhất, và khi chạy script con delete thì phải dọn dẹp tài nguyên
    Kỳ vọng rằng sau khi chạy những thứ như thế, lập trình viên phải rà soát toàn bộ tài khoản AWS một cách hoang tưởng để tìm tài nguyên lang thang là không công bằng
    Nếu một startup vận hành kiểu này, liệu người ta có bỏ qua bằng câu “chuyện này vốn hay xảy ra, nên phải cẩn thận” không?
    Tôi không hiểu vì sao lại áp dụng tiêu chuẩn khác cho AWS

    • Điều khó chịu nhất ở AWS chính là điểm đó
      Không có cách nào dễ dàng để xem tất cả tài nguyên mà hiện tại tôi đang phải trả tiền
      Nếu có thì tôi cũng chưa tìm ra
      Khi không có một cái nhìn tổng quan dễ hiểu, tôi cảm thấy mình không kiểm soát hoàn toàn tài khoản của mình
    • Khi phải dùng thứ gì đó mới, điều đầu tiên tôi kiểm tra là liệu có thể nhận hóa đơn cố định hằng tháng hay không
      Tôi cũng xem nếu dùng vượt mức đó thì chuyện gì xảy ra, và có thể giới hạn các khoản phí ngoài dự kiến hay không
      Nếu không được thì tôi tìm thứ khác
      Sau thay đổi về tính phí Google Maps vài năm trước, chúng tôi cũng rất thận trọng với việc để mình bị trói sâu vào các dịch vụ Google “miễn phí”, và cuối cùng việc đó đã tốn rất nhiều tiền
    • Liệu có cách đơn giản nào để liệt kê tất cả tài nguyên tồn tại trong một tài khoản AWS không?
      Tôi luôn phải kiểm tra theo từng dịch vụ, từng region; việc đó vừa nhàm chán vừa dễ sai
    • Với Amazon, họ có thể dễ dàng kiếm 1000 đô la, nên đây không phải bug mà là feature
      Ngay cả nếu họ coi đó là bug, nó cũng sẽ có độ ưu tiên thấp hơn nhiều so với những việc khác trực tiếp ảnh hưởng đến lãi lỗ của họ
    • Tôi đồng ý rằng kỳ vọng lập trình viên kiểm tra một cách hoang tưởng là không công bằng
      Tuy nhiên, trên thực tế thì điều đó hợp lý
      Khi xây dựng thứ gì đó trên AWS, tôi đối xử với AWS như một tổ chức tài chính thù địch đã mất kiểm soát

  • Vì những trường hợp như thế này mà tôi đã trì hoãn việc tìm hiểu sâu về AWS suốt mấy năm nay
    Cần có một chương trình đào tạo tiêu chuẩn cho phép mọi người thử nghiệm miễn phí mà không yêu cầu thông tin thẻ tín dụng
    Thay vào đó, có vẻ có những nhân viên văn phòng tính toán rằng họ có thể moi vài nghìn đô la từ khắp nơi nhờ “lỗi của người dùng”
    Những khoản tính phí như vậy cũng khó tranh chấp, thậm chí có trường hợp hoàn toàn không thể
    Chắc không chỉ mình tôi tránh môi trường AWS vì nỗi sợ hợp lý rằng một hóa đơn khổng lồ có thể xuất hiện

    • Trong tình huống như vậy, việc AWS không hoàn tiền là rất bất thường, nên khó xem đây là chiến lược vắt vài nghìn đô la từ lỗi người dùng
      Nhiều khả năng họ cho rằng xử lý hoàn tiền ít gánh nặng hơn việc cung cấp các hướng dẫn chính xác và rẻ
      Điều đó không biện minh cho hành vi này, nhưng tôi từng được hủy cả khoản phí 600 đô la phát sinh hợp lệ khi dùng AWS Textract
      Khi đó tôi đang làm việc tại một công ty trị giá hàng tỷ đô la
    • Tôi nghĩ lý do mọi người rơi vào tình huống thanh toán như thế này là vì họ thực ra không tìm hiểu sâu về AWS
      Bảng giá dễ truy cập và không phải lúc nào cũng dễ hiểu, nhưng phần lớn chi phí tăng gần như tuyến tính nên tương đối dễ thử nghiệm
      Tốt nhất nên tránh các dịch vụ wrapper như AWS Amplify, CloudFormation và các loại Stack
      Cứ dùng trực tiếp các dịch vụ cốt lõi là được
      Mọi dịch vụ đều có API, và việc lấy API key gắn với IAM user cũng đơn giản như bấm nút
      Phần còn lại có thể quản lý bằng caching phù hợp và căn chỉnh mô hình chi phí với mô hình doanh thu
      Hãy làm sao để chi phí của dịch vụ tự động mở rộng trở thành một tỷ lệ gần như cố định của doanh thu, bất kể nhu cầu hiện tại
      Băng thông là cơn ác mộng thực sự trên AWS, nhưng console có cung cấp tự động các mức giảm giá dài hạn, và qua đại diện kinh doanh thì còn có thể nhận chiết khấu hợp đồng tốt hơn một chút
      Vì vậy tôi cho rằng nên tránh EC2; băng thông nội bộ của EC2 cũng đắt hơn, nên dùng trực tiếp Lambda + S3 + CloudFront thì tốt hơn
      Sau khoảng 3 tháng, khi triển khai tính năng mới hướng tới người dùng, tôi đã có thể dự đoán khá dễ tổ hợp dịch vụ nào hiệu quả chi phí nhất
    • A Cloud Guru / Pluralsight có tính năng gọi là “Cloud Playground” hoặc “sandboxes”
      Có thể chúng phục vụ mục đích đó, nhưng tôi chưa dùng trực tiếp nên không chắc
    • Số tiền phát sinh từ kiểu lỗi người dùng này có lẽ chỉ là muối bỏ bể so với toàn bộ AWS
      Theo kinh nghiệm của tôi, AWS thiên về tránh các vấn đề có thể gây chi phí lớn hơn do tổn hại danh tiếng
      AWS không rẻ, và trong một số trường hợp đặc biệt đắt kinh khủng, như phí truyền dữ liệu, nhưng tôi không nghĩ cách của họ là lừa khách hàng vô tình chi thêm vài trăm đô la

  • Đúng chất AWS
    Vài tháng trước tôi làm theo hướng dẫn quick start SageMaker chính thức để chạy Llama 2; đúng là nó khởi động rất nhanh, nhưng hôm sau nhìn lại thì thấy đang tốn 400 đô la mỗi ngày
    Tôi đã được hủy khoản tính phí, nhưng chắc chắn học được rằng không nên tin các hướng dẫn chính thức

    • SageMaker là một trong những sản phẩm gây thất vọng nhất xét từ góc độ sản phẩm, và là một ví dụ rõ ràng về enshittification
      Vào giai đoạn đầu của sản phẩm, khoảng 2017–2018, việc cấu hình khá trực quan
      Notebook instance, inference, REST API để serving, một chút EFS, và việc S3 là trung tâm của dịch vụ đều rất rõ ràng
      Giá cũng ở dạng khép kín nên không có gì gây sốc
      Tổng thể có cảm giác như DigitalOcean, và ngay cả data scientist có kiến thức nền tảng về hạ tầng cùng chút tò mò cũng có thể tạo cấu hình rẻ, dễ dự đoán và đơn giản
      Giờ thì có Wrangler, Feature Store, RStudio; trải nghiệm người dùng của notebook console thì khủng khiếp, còn bên trong nhiều dịch vụ di chuyển dữ liệu qua lại và tính phí việc đó

  • Vì hoàn cảnh, tôi phải gửi yêu cầu HTTP thô thay vì dùng SDK cồng kềnh của AWS; với header content-type: application/json thì thất bại, còn content-type: application/x-amz-json-1.0 thì thành công
    Tôi thật sự mong họ thôi những thứ vô nghĩa kiểu này

    • Gần như mọi phần của AWS mà tôi từng đụng tới trong sự nghiệp đều cho tôi cảm giác tương tự
      Quá cồng kềnh, quá phức tạp hoặc có quá nhiều cách tự triển khai kỳ quặc mà không đem lại lợi ích rõ ràng
    • Nói thật thì đó là chi tiết nội bộ bị rò rỉ ra ngoài
      Vì trong nội bộ, phần lớn app dùng Coral framework cũ và dùng định dạng JSON này, với dạng input, output và error được định nghĩa rõ

  • Mọi hướng dẫn chính thức của AWS đều được thiết kế để khiến bạn dùng càng nhiều dịch vụ AWS càng tốt, và rủi ro chi tiêu cũng tăng tương ứng
    Cần nhìn những gì AWS khuyến nghị—tức default của GUI, công cụ CLI, hướng dẫn, kiến trúc đề xuất—một cách cực kỳ phê phán
    Có lý do mà trong công ty tồn tại một vị trí lương cao để hướng dẫn đồng nghiệp dùng AWS sao cho hiệu quả chi phí và ít rủi ro

    • Đúng vậy
      Với các triển khai nhỏ hoặc thử nghiệm, phần đắt nhất hầu như luôn là các thứ phụ trợ, hoặc các dịch vụ mới nhất được khuyến nghị thay vì những lựa chọn đơn giản hơn

  • Nếu bạn đang dùng OpenSearch vì truy vấn bounding box geo_point, vậy PostgreSQL + PostGIS thì sao?
    https://postgis.net/docs/using_postgis_query.html

  • Tôi nghĩ kiểu thiết lập không ma sát này, trải nghiệm người dùng/giao diện kém trực quan, tâm lý ít cảnh giác khi đăng ký thẻ tín dụng, và tính phí gộp giữa các dịch vụ như AWS Batch + Lambda + EC2 là một phần của mô hình kinh doanh
    Không biết diễn đạt thế nào, nhưng nó giống một công viên giải trí hiện đại: bạn trả vé vào cổng rồi phải trả riêng cho mọi trò chơi, thậm chí cả nhà vệ sinh

    • Tôi cũng cảm thấy vậy
      Mô hình tính phí cloud chuyển trách nhiệm sang người dùng dưới danh nghĩa “linh hoạt” và “tùy chỉnh”
      Hãy tưởng tượng một công ty cho thuê xe tính phí từng bộ phận theo mili-giây—vòng quay trục cam động cơ, vòng quay lốp, hoạt động gạt mưa, thời gian sưởi ghế—rồi nói rằng khách hàng “kiểm soát” mức sử dụng và ngân sách vì có thể đặt cảnh báo cho từng hạng mục
      Ngay từ mặc định, đó đã là một mô hình chi phí thù địch và nguy hiểm với người dùng