AWS Bedrock keys ได้รับการปกป้องโดย LLM gateway ภายใน ซึ่งช่วยให้ทุกทีมในบริษัทฟินเทคสามารถเรียกใช้งานโมเดลได้ โดยที่แต่ละคำขอจะถูกผูกไว้กับงบประมาณโทเคน (token budget) ของแต่ละทีม การเปลี่ยนแปลงนี้ช่วยหยุดพฤติกรรมการกระจาย IAM credentials ไปตาม repo และ notebook ต่างๆ ซึ่งเป็นนิสัยที่เคยเสี่ยงต่อการทำให้ค่าใช้จ่ายด้าน AI ของบริษัทหมดลงภายในบ่ายวันเดียว

ทำไมการแจกจ่าย AWS keys ถึงกลายเป็นเรื่องวุ่นวายอย่างรวดเร็ว

กลุ่มที่ไม่ใช่สายเทคนิคในองค์กรขอเข้าถึงโมเดลภาษาของบริษัทโดยตรง ในทางทฤษฎี คำตอบที่ง่ายที่สุดคือการเปิดใช้งานโมเดลใน AWS และมอบสิทธิ์ IAM ให้กับแต่ละกลุ่ม ใช้เวลาทำงานเพียงสิบนาที แก้ไขนโยบาย (policy) เล็กน้อย งานก็เสร็จสิ้น—อย่างน้อยก็ในทางทฤษฎี

ในทางปฏิบัติ การแจกจ่าย IAM credentials ก่อให้เกิดต้นทุนแฝงสามประการ:

  • Credential sprawl – คีย์ต่างๆ ไปตกค้างอยู่ในไฟล์ .env, CI pipelines, Jupyter notebooks และสคริปต์แบบ ad-hoc แต่ละสำเนาจะกลายเป็นจุดอ่อน (point of failure) เมื่อจำเป็นต้องมีการหมุนเวียนคีย์ (rotation)
  • Zero visibility – การใช้คีย์ร่วมกันเพียงคีย์เดียวทำให้ไม่ทราบว่าทีมใดหรือโค้ดส่วนไหนที่กำลังใช้งานอยู่ เมื่อเกิดลูปที่ทำงานไม่หยุด (runaway loop) งบประมาณทั้งหมดอาจถูกใช้จนหมดก่อนที่จะมีใครสังเกตเห็น
  • Operational overhead – การติดตามว่าใครมีสิทธิ์อะไร การยกเลิกสิทธิ์ และการตรวจสอบการใช้งาน (auditing) จะกลายเป็นกระบวนการที่ต้องทำด้วยมือและเสี่ยงต่อความผิดพลาดอย่างรวดเร็ว

ทีมฟินเทคตระหนักว่า "การแก้ปัญหาแบบด่วน" นี้จะกลายเป็นฝันร้ายด้านความปลอดภัยและค่าใช้จ่ายในไม่ช้า

เปลี่ยนมาสร้าง reverse-proxy gateway แทน

ทางออกคือการแทรก reverse proxy ขนาดเล็กไว้ระหว่างแอปพลิเคชันภายในทุกตัวกับ AWS Bedrock โดยตัว proxy จะเก็บ AWS credentials ของจริงไว้ในที่เดียวที่ปลอดภัยด้วย vault และออกโทเคนแบบอายุสั้นที่อ่านเข้าใจง่าย (เช่น lllkey_9f3c) ให้กับผู้เรียกใช้งาน

จุดสำคัญในการออกแบบ:

  • No AWS credentials leave the gateway – นักพัฒนาและบริการต่างๆ จะไม่เห็น IAM keys ของจริงเลย
  • Per-token policy enforcement – แต่ละโทเคนสามารถจำกัดให้ใช้ได้เฉพาะตระกูลโมเดล (model family) ที่กำหนด หรือจำกัดจำนวนโทเคนสูงสุดได้
  • Full audit trail – ทุกคำขอจะถูกบันทึก (log) พร้อมชื่อผู้ใช้งาน

วิธีที่ gateway ประมวลผลคำขอ

  1. Receive token – ไคลเอนต์จะแนบโทเคน llmkey_… ไว้ใน HTTP header
  2. Validate token – gateway จะตรวจสอบสถานะของโทเคน (ใช้งานได้, ไม่หมดอายุ) และตรวจสอบว่าคำขอนั้นยังอยู่ในงบประมาณที่ได้รับจัดสรรหรือไม่
  3. Model whitelist – ตรวจสอบว่าโมเดลที่ร้องขอได้รับอนุญาตสำหรับโทเคนนั้นหรือไม่
  4. Forward to Bedrock – คำขอจะถูกส่งไปยัง AWS โดยใช้ IAM credentials ที่จัดเก็บไว้
  5. Log and bill – การใช้งานโทเคน ชื่อโมเดล และการประมาณการค่าใช้จ่ายจะถูกเขียนลงในฐานข้อมูลกลางเพื่อการรายงานผล

เนื่องจากบริษัทฟินเทคต้องเก็บข้อมูลทั้งหมดไว้ภายในเครือข่ายของตนเอง การใช้บริการ SaaS จากบุคคลที่สามจึงไม่ใช่ทางเลือก

สิ่งที่บริษัทได้รับ

  • Model control – ทีมที่ต้องการเพียงโมเดลราคาถูกสามารถถูกจำกัดให้ใช้ได้เฉพาะโมเดลนั้น เพื่อป้องกันการใช้งานโมเดลรุ่นที่มีความสามารถสูงกว่าและราคาแพงกว่าโดยไม่ตั้งใจ
  • Budget protection – โทเคนจะมีขีดจำกัดโทเคน (hard token limit) เมื่อถึงขีดจำกัด gateway จะส่งข้อผิดพลาดกลับไปแทนที่จะแอบใช้เครดิตเพิ่มขึ้นเรื่อยๆ
  • Attribution for finance – แดชบอร์ดที่สร้างจากบันทึกการใช้งานจะแสดงให้เห็นอย่างชัดเจนว่าทีมใดหรือบริการใดใช้จ่ายด้าน AI ไปเท่าไหร่ เปลี่ยนจากสเปรดชีตที่คลุมเครือให้กลายเป็นรายงานที่โปร่งใส

เวิร์กโฟลว์การดำเนินงานยังเปลี่ยนไปด้วย ไม่ต้องมีนโยบาย IAM ใหม่ ไม่ต้องหมุนเวียนความลับ (secret rotation) และไม่มีความเสี่ยงที่คีย์จะหลุดเข้าไปใน version control

ข้อโต้แย้ง: ทำไมไม่ใช้ managed service

ข้อโต้แย้งทั่วไปคือการสร้าง gateway ขึ้นมาเองนั้นเพิ่มภาระด้านวิศวกรรมและการบำรุงรักษา ในกรณีของบริษัทฟินเทค ความจำเป็นในการเก็บทราฟฟิก AI และข้อมูลการใช้งานทั้งหมดไว้หลังไฟร์วอลล์ขององค์กรนั้นมีน้ำหนักมากกว่าความสะดวกสบายของโซลูชันจากบุคคลที่สาม การสร้าง proxy ภายในใช้เวลาพัฒนาเพียงช่วงสุดสัปดาห์เดียว แต่ช่วยกำจัดภาระในการทำความสะอาดคีย์และการใช้งบประมาณเกินกำหนดที่อาจตามมาจากการแจกจ่ายคีย์แบบเดิมๆ ได้นานหลายเดือน

บทสรุป

การแจกจ่ายคีย์ AWS Bedrock เป็นทางลัดที่กลายเป็นฝันร้ายด้านความปลอดภัยและงบประมาณอย่างรวดเร็ว การใช้ reverse-proxy gateway ขนาดเล็กที่สร้างขึ้นในเวลาเพียงหนึ่งสุดสัปดาห์ จะช่วยรวมศูนย์ credentials, บังคับใช้ขีดจำกัดของแต่ละทีม และให้ข้อมูลการตรวจสอบที่ฝ่ายการเงินต้องการ สำหรับองค์กรใดก็ตามที่ต้องการให้หลายกลุ่มทดลองใช้งาน LLMs โดยไม่สูญเสียการควบคุม แนวทางแบบ gateway นี้จะคุ้มค่าด้วยการช่วยหลีกเลี่ยงเหตุการณ์ไม่คาดคิดและทำให้เห็นภาพรวมการใช้จ่ายที่ชัดเจนขึ้น