Các khóa AWS Bedrock hiện đã được bảo vệ bởi một gateway LLM nội bộ, cho phép mọi nhóm trong một công ty fintech có thể gọi các mô hình, nhưng mỗi yêu cầu đều được gắn với một hạn mức token theo từng nhóm. Thay đổi này giúp chấm dứt tình trạng rải rác các thông tin xác thực IAM khắp các kho lưu trữ (repos) và notebook, một thói quen vốn đã đe dọa làm cạn kiệt ngân sách AI của công ty chỉ trong một buổi chiều.

Tại sao việc cấp phát các khóa AWS lại nhanh chóng trở thành một mớ hỗn độn

Các nhóm không chuyên về kỹ thuật trong tổ chức đã yêu cầu quyền truy cập trực tiếp vào các mô hình ngôn ngữ của công ty. Trên lý thuyết, câu trả lời đơn giản nhất là kích hoạt các mô hình trong AWS và cấp cho mỗi nhóm một quyền IAM. Chỉ mất mười phút làm việc, vài chỉnh sửa chính sách, và công việc coi như xong—ít nhất là về mặt lý thuyết.

Trên thực tế, việc cấp phát các thông tin xác thực IAM tạo ra ba chi phí ẩn:

  • Sự phân tán thông tin xác thực (Credential sprawl) – Các khóa kết thúc trong các tệp .env, các pipeline CI, Jupyter notebooks và các tập lệnh tùy biến. Mỗi bản sao đều trở thành một điểm yếu khi cần phải xoay vòng (rotation) khóa.
  • Không có khả năng giám sát (Zero visibility) – Một khóa dùng chung duy nhất sẽ không cho biết nhóm nào hoặc đoạn mã nào đang tạo ra lưu lượng sử dụng. Khi một vòng lặp mất kiểm soát bắt đầu, toàn bộ ngân sách có thể bị tiêu thụ hết trước khi bất kỳ ai kịp nhận ra.
  • Gánh nặng vận hành (Operational overhead) – Việc theo dõi ai có quyền gì, thu hồi quyền truy cập và kiểm tra việc sử dụng nhanh chóng trở thành một quy trình thủ công và dễ sai sót.

Đội ngũ fintech nhận ra rằng "giải pháp nhanh chóng" này sẽ sớm trở thành một cơn ác mộng về bảo mật và chi phí.

Thay vào đó, hãy xây dựng một reverse-proxy gateway

Giải pháp là chèn một reverse proxy nhẹ giữa mọi ứng dụng nội bộ và AWS Bedrock. Proxy này giữ các thông tin xác thực AWS thực sự tại một vị trí duy nhất được bảo mật bằng vault và cấp các token có thời hạn ngắn, dễ đọc đối với con người (ví dụ: lllkey_9f3c) cho bên gọi.

Các điểm thiết kế chính:

  • Không có thông tin xác thực AWS nào rời khỏi gateway – Các nhà phát triển và dịch vụ không bao giờ nhìn thấy các khóa IAM thực sự.
  • Thực thi chính sách theo từng token – Mỗi token có thể được giới hạn trong một dòng mô hình cụ thể hoặc một số lượng token tối đa.
  • Nhật ký kiểm tra đầy đủ – Mọi yêu cầu đều được ghi nhật ký kèm theo tên định danh.

Cách gateway xử lý một yêu cầu

  1. Nhận token – Client đính kèm token llmkey_… vào HTTP header.
  2. Xác thực token – Gateway kiểm tra trạng thái của token (đang hoạt động, chưa hết hạn) và liệu yêu cầu có nằm trong hạn mức được phân bổ hay không.
  3. Danh sách trắng mô hình (Model whitelist) – Nó xác nhận mô hình được yêu cầu được phép sử dụng cho token đó.
  4. Chuyển tiếp tới Bedrock – Yêu cầu được gửi tới AWS bằng cách sử dụng các thông tin xác thực IAM đã lưu trữ.
  5. Ghi nhật ký và tính phí – Việc sử dụng token, tên mô hình và ước tính chi phí được ghi vào một cơ sở dữ liệu trung tâm để báo cáo.

Vì công ty fintech phải giữ tất cả dữ liệu bên trong mạng nội bộ của mình, nên các giải pháp SaaS của bên thứ ba không được xem xét.

Những gì công ty đạt được

  • Kiểm soát mô hình – Các nhóm chỉ cần mô hình chi phí thấp có thể được giới hạn ở mô hình đó, ngăn chặn việc vô tình sử dụng các biến thể đắt tiền, có năng lực cao hơn.
  • Bảo vệ ngân sách – Các token có giới hạn token cứng. Khi chạm giới hạn, gateway sẽ trả về lỗi thay vì âm thầm tiêu thụ thêm tín dụng.
  • Phân bổ chi phí cho tài chính – Một bảng điều khiển (dashboard) được xây dựng dựa trên nhật ký sử dụng sẽ hiển thị chính xác nhóm hoặc dịch vụ nào đã chi bao nhiêu cho AI, biến một bảng tính mơ hồ thành một báo cáo minh bạch.

Quy trình vận hành cũng thay đổi. Không cần các chính sách IAM mới, không cần xoay vòng bí mật (secret rotation), và không có rủi ro rò rỉ khóa vào hệ thống quản lý phiên bản (version control).

Lập luận phản bác: tại sao không sử dụng dịch vụ được quản lý (managed service)

Một phản đối phổ biến là việc xây dựng một gateway tùy chỉnh sẽ làm tăng nỗ lực kỹ thuật và bảo trì. Trong trường hợp của công ty fintech này, nhu cầu giữ tất cả lưu lượng AI và dữ liệu sử dụng đằng sau tường lửa của doanh nghiệp quan trọng hơn sự tiện lợi của một giải pháp bên thứ ba. Proxy nội bộ chỉ cần một cuối tuần để phát triển, nhưng nó đã loại bỏ hàng tháng trời dọn dẹp thông tin xác thực và các khoản vượt ngân sách vốn sẽ xảy ra nếu theo cách tiếp cận phân phối khóa ngây thơ.

Bài học rút ra

Việc cấp phát các khóa AWS Bedrock là một con đường tắt nhanh chóng biến thành cơn ác mộng về bảo mật và ngân sách. Một reverse-proxy gateway khiêm tốn—được xây dựng trong một cuối tuần—giúp tập trung hóa các thông tin xác thực, thực thi các giới hạn theo từng nhóm và cung cấp nhật ký kiểm tra mà bộ phận tài chính cần. Đối với bất kỳ tổ chức nào muốn cho phép nhiều nhóm thử nghiệm với LLM mà không mất quyền kiểm soát, cách tiếp cận gateway sẽ tự bù đắp chi phí thông qua việc tránh được các sự cố và mang lại khả năng hiển thị chi tiêu rõ ràng hơn.