เลิกคัดลอก AWS access keys ไปวางในไฟล์ .env ของคุณเสียที
เราทุกคนต่างเคยผ่านสถานการณ์แบบนั้นมาแล้ว มันเป็นเวลาดึกดื่น คุณกำลังดีบั๊กข้อผิดพลาดเรื่องสิทธิ์ของ Lambda และ AI assistant ของคุณก็เอาแต่สร้างชื่อบริการหรือ ARN พร้อมกับ account ID สมมติขึ้นมาเรื่อยๆ คุณต้องการให้โมเดลเห็นทรัพยากรจริงๆ ของคุณ เพื่อที่มันจะได้หยุดเดาสุ่มและเริ่มแก้ไขปัญหาเสียที ด้วยความจนใจ คุณจึงหยิบ access key มาวางลงในไฟล์ environment แล้วป้อนให้ agent มันใช้งานได้จริง ความรู้สึกโล่งอกถาโถมเข้ามา แต่พอเช้าวันใหม่มาถึง คุณก็ตระหนักได้ว่าความลับนั้นถูกทิ้งไว้ใน shell history, terminal scrollback หรือที่แย่กว่านั้นคืออยู่ใน commit ที่เพิ่ง push ไปยัง repository ส่วนกลาง
นี่คือความวุ่นวายที่ Model Context Protocol ถูกสร้างขึ้นมาเพื่อป้องกันโดยเฉพาะ
MCP สร้างสะพานเชื่อมมาตรฐานระหว่าง AI agent ของคุณกับระบบภายนอก แทนที่จะส่งมอบข้อมูลรับรอง (credentials) แบบดิบๆ และหวังว่า agent จะไม่ทำข้อมูลรั่วไหล คุณจะเชื่อมต่อผ่านเซิร์ฟเวอร์ที่ควบคุมได้ ซึ่งจะจัดการเรื่องการยืนยันตัวตน (authentication) กำหนดขอบเขตสิทธิ์ (scopes permissions) และเก็บคีย์ของคุณให้พ้นจากหน้าต่างแชทอย่างสิ้นเชิง
สำหรับ AWS ในปัจจุบันคุณมี MCP server อย่างเป็นทางการให้เลือกสองแบบ การเลือกผิดอาจทำให้ agent ของคุณตาบอด หรือไม่ก็ให้สิทธิ์เข้าถึงมากเกินไปโดยขาดการควบคุมที่เพียงพอ
รู้ความแตกต่าง: ความรู้ (Knowledge) vs. การลงมือทำ (Hands)
ตัวเลือกแรกคือ AWS Knowledge MCP Server ให้คิดซะว่าเป็นวิศวกรอาวุโสที่ท่องจำเอกสาร AWS ได้ทั้งหมด แต่ไม่มีข้อมูลการเข้าสู่ระบบบัญชีของคุณ มันถูกออกแบบมาให้เป็นแบบ read-only โดยจะอ้างอิงเอกสารอย่างเป็นทางการของ AWS เพื่อให้ agent เข้าใจไวยากรณ์ API ที่แท้จริง ชื่อบริการที่ถูกต้อง และแนวทางปฏิบัติที่ดีที่สุด (best practices) ในปัจจุบัน
คุณไม่จำเป็นต้องมีบัญชี AWS เพื่อใช้งานมัน คุณไม่ต้องเชื่อมต่อมันเข้ากับโครงสร้างพื้นฐานของคุณ คุณจะเรียกใช้งานมันเมื่อคุณกำลังร่างแผนผังโครงสร้าง (architecture diagram) เรียนรู้บริการใหม่ๆ อย่าง ECS หรือ EventBridge หรือตรวจสอบว่าการเรียก API บางอย่างยังทำงานเหมือนที่คุณจำได้เมื่อสองปีก่อนหรือไม่ มันช่วยหยุดไม่ให้ agent เดาสุ่ม หากคุณสั่งให้มันเขียน Terraform สำหรับ S3 bucket policy มันจะรู้ฟิลด์ที่แท้จริงและค่าที่ถูกต้อง เพราะมันดึงข้อมูลมาจากแหล่งอ้างอิง ไม่ใช่จากข้อมูลที่ใช้เทรนซึ่งอาจจะหยุดอัปเดตไปเมื่อปีที่แล้ว
ตัวเลือกที่สองคือ AWS MCP Server (Managed) ตัวนี้จะมอบ "มือ" ให้กับ agent ของคุณ ไม่ใช่แค่ "ความจำ" ด้วยการยืนยันตัวตนที่เหมาะสม มันสามารถตรวจสอบ CloudWatch logs ของคุณ, ลิสต์ S3 buckets, อ่าน schema ของ DynamoDB table, ตรวจสอบ IAM policies ที่ผูกกับ role หรือตรวจสอบว่า security groups ไหนที่เปิดสู่สาธารณะ (internet) มันทำงานบนบัญชีจริงของคุณ ซึ่งทำให้มันทรงพลังมากสำหรับการแก้ไขปัญหาในระบบ production หรือการปรับปรุงโครงสร้างพื้นฐานที่ใช้งานอยู่ (live infrastructure)
Managed server จะไม่ยอมรับคีย์ที่มีอายุการใช้งานยาวนาน (long-lived keys) มันยืนยันตัวตนผ่าน OAuth โดยการลงชื่อเข้าใช้ผ่านเบราว์เซอร์ หรือผ่าน AWS CLI โดยใช้การลงนามแบบ SigV4 ทุกการเรียกใช้เครื่องมือ (tool call) จะเกิดขึ้นด้วย token ที่มีอายุการใช้งานสั้น ทุกการกระทำจะทิ้งร่องรอยไว้ใน CloudTrail และ agent จะทำงานอยู่ภายใต้ขอบเขตของ IAM ที่คุณกำหนดไว้เท่านั้น มันไม่สามารถออกนอกขอบเขตสิทธิ์ที่ได้รับ เพราะมันถูกควบคุมโดย policy engine ชุดเดียวกับที่ควบคุมผู้ใช้หรือ role อื่นๆ ในองค์กรของคุณ
นี่คือกฎเหล็กที่ควรจำไว้: เซิร์ฟเวอร์หนึ่งให้ความรู้แก่อัน agent ของคุณ อีกเซิร์ฟเวอร์หนึ่งให้การลงมือทำ ใช้ Knowledge server เมื่อคุณกำลังศึกษาหรือออกแบบ และใช้ Managed server เมื่อคุณกำลังปฏิบัติการหรือซ่อมแซม
ทำไม AWS ถึงแนะนำ Managed Server สำหรับงานส่วนใหญ่
ตอนนี้ AWS กำลังผลักดันให้ผู้ใช้ส่วนใหญ่ไปใช้ Managed MCP Server เพียงตัวเดียว แทนที่จะรันทั้งสองตัวควบคู่กันไป Managed server ได้รวมเอาบริบทของเอกสารที่ Knowledge server เคยมีไว้แล้ว ดังนั้นมันจึงจัดการได้ทั้งข้อมูลอ้างอิงและการดำเนินการในบัญชีจริงภายใต้ endpoint เดียวกัน
การรันเซิร์ฟเวอร์ทั้งสองพร้อมกันอาจทำให้ประสบการณ์การใช้งานแย่ลงได้ agent จะได้รับคำจำกัดความของเครื่องมือ (tool definitions) ที่ซ้ำซ้อนกัน และอาจสับสนว่าควรจะเรียกใช้การค้นหาข้อมูลจากเอกสารแบบ read-only หรือเรียกใช้ API จริงกับบัญชีของคุณ ความลังเลนั้นจะทำให้การตอบสนองช้าลงและอาจเกิดข้อผิดพลาดในการเลือกเครื่องมือเป็นครั้งคราว การรวมมาใช้เพียง Managed server จะช่วยให้การตั้งค่าของคุณง่ายขึ้นและทำให้ agent โฟกัสได้ดีขึ้น
การตั้งค่า Managed Server ด้วย OAuth
การทำให้ Managed server เริ่มทำงานใช้เวลาประมาณห้านาที แต่ขั้นตอนต่างๆ นั้นสำคัญมาก เพราะนี่คือการเชื่อมต่อโดยตรงกับบัญชีของคุณ
ขั้นตอนที่ 1: เตรียม IAM identity ของคุณ
Create or select a dedicated IAM role or user. Do not use your Root account. Attach the managed policy named AWSMCPSignInOAuthAccessPolicy to it. This policy grants only the permissions required to initiate the OAuth sign-in flow for MCP access. It does not grant broad administrative rights by itself. The actual capabilities your agent will have are determined by the rest of the IAM policies you attach to that identity. If you want the agent to read CloudWatch logs but never touch IAM or billing, build a custom policy that allows logs:DescribeLogGroups and logs:FilterLogEvents and nothing else.
Step 2: Configure your client
Add the official AWS MCP server URL to your client configuration. This works with Claude Desktop, Claude Code, and Kiro. In your MCP settings file, register the server endpoint so the client knows where to route AWS-related tool calls.
Step 3: Authenticate through your browser
The first time the agent tries to invoke an AWS tool, your operating system opens a browser window. Sign in with the same IAM identity you prepared in Step 1. The OAuth flow returns a short-lived token to the MCP server. You will not see a secret key. You will not paste anything into a configuration file. The token refreshes automatically and expires quickly.
Step 4: Verify the trust boundary
Once authenticated, open CloudTrail and confirm that actions appear under the identity you created. You should see events like ListBuckets or DescribeInstances tied to that specific IAM user or role. If you see Root account activity, you did something wrong and should revoke the session immediately.
If OAuth does not fit your workflow, the Managed server also supports SigV4 authentication through your existing AWS CLI credentials. That path skips the browser pop-up, but you still benefit from the MCP server handling the signing and session management rather than exposing raw credentials to the agent.
Security Habits That Actually Matter
An MCP server is only as safe as the IAM identity behind it.
Start with least privilege. Your agent does not need AdministratorAccess to fix a misrouted API Gateway integration. Give it exactly the read or write permissions required for the current task, and rotate or revoke them when the job is done. If you are using a role, set a short session duration. If you are using a user, enable MFA wherever your tooling allows it.
Never authorize as the Root user. Root bypasses service control policies and enjoys unrestricted access across the entire account. If the agent misinterprets a prompt and attempts to delete resources, you want that request blocked by a boundary policy. Root has no such guardrails.
Finally, treat the agent like a new intern who follows instructions perfectly but lacks common sense. It will execute what you ask, literally and immediately. If you tell it to "clean up unused security groups," it might terminate the one attached to your production database because it matched the broad criteria you gave it. Review any destructive commands before confirming them, especially when the agent has write access.
The Real Takeaway
You do not need to trade security for usefulness. The Managed AWS MCP Server lets your AI assistant see your real infrastructure, correct its own hallucinations, and operate within the same IAM framework that governs the rest of your team. You get live context without dropping secrets into environment files. Set up the OAuth flow, lock down the permissions, and let the agent work with its eyes open and its hands tied to your policies.