Đừng dán các AWS access key vào tệp .env của bạn nữa.
Tất cả chúng ta đều đã từng trải qua tình huống đó. Đã khuya, bạn đang gỡ lỗi một lỗi quyền Lambda, và trợ lý AI của bạn cứ liên tục tự chế ra các tên dịch vụ hoặc ARN với các ID tài khoản giả tưởng. Bạn muốn mô hình nhìn thấy các tài nguyên thực tế của mình để nó ngừng ảo tưởng và bắt đầu sửa lỗi. Trong cơn tuyệt vọng, bạn lấy một access key, thả nó vào một tệp môi trường, và đưa nó cho agent. Nó hoạt động. Cảm giác nhẹ nhõm ập đến. Thế rồi sáng hôm sau tới, và bạn nhận ra bí mật đó đang nằm trong lịch sử shell, terminal scrollback, hoặc tệ hơn là trong một commit vừa được đẩy lên một kho lưu trữ dùng chung.
Đây chính xác là mớ hỗn độn mà Model Context Protocol được tạo ra để ngăn chặn.
MCP tạo ra một cầu nối tiêu chuẩn giữa AI agent của bạn và các hệ thống bên ngoài. Thay vì bàn giao các thông tin xác thực thô và hy vọng agent không làm rò rỉ chúng, bạn kết nối thông qua một máy chủ được kiểm soát, giúp xử lý xác thực, phân cấp quyền hạn và giữ cho các key của bạn hoàn toàn nằm ngoài cửa sổ chat.
Đối với AWS, hiện tại bạn có hai MCP server chính thức để lựa chọn. Chọn sai một cái có thể khiến agent của bạn bị "mù" hoặc cấp cho nó quá nhiều quyền truy cập mà thiếu sự giám sát.
Hiểu sự khác biệt: Kiến thức so với Khả năng thực thi
Lựa chọn đầu tiên là AWS Knowledge MCP Server. Hãy coi nó như một kỹ sư dày dạn kinh nghiệm, người đã ghi nhớ toàn bộ thư viện tài liệu AWS nhưng không có thông tin đăng nhập cho tài khoản của bạn. Nó được thiết kế theo chế độ chỉ đọc (read-only), tham chiếu đến các tài liệu AWS chính thức để giúp agent nắm vững cú pháp API thực tế, tên dịch vụ chính xác và các thực hành tốt nhất (best practices) hiện tại.
Bạn không cần tài khoản AWS để sử dụng nó. Bạn không kết nối nó với cơ sở hạ tầng của mình. Bạn khởi chạy nó khi đang phác thảo sơ đồ kiến trúc, học một dịch vụ mới như ECS hoặc EventBridge, hoặc xác nhận xem một lệnh gọi API cụ thể có còn hoạt động như bạn nhớ từ hai năm trước hay không. Nó ngăn agent đoán mò. Nếu bạn yêu cầu nó viết Terraform cho một S3 bucket policy, nó sẽ biết các trường (fields) thực tế và các giá trị hợp lệ vì nó đang lấy dữ liệu từ nguồn chính thống, chứ không phải từ dữ liệu huấn luyện đã bị ngắt quãng từ năm ngoái.
Lựa chọn thứ hai là AWS MCP Server (Managed). Lựa chọn này mang lại cho agent của bạn "đôi tay", chứ không chỉ là trí nhớ. Với xác thực phù hợp, nó có thể kiểm tra các CloudWatch logs của bạn, liệt kê các S3 buckets, đọc schema bảng DynamoDB, kiểm tra các IAM policies được gắn vào một role, hoặc xác minh xem security group nào đang mở cho internet. Nó hoạt động trên tài khoản thực của bạn, điều này giúp nó trở nên mạnh mẽ trong việc khắc phục các sự cố production hoặc tái cấu trúc (refactoring) cơ sở hạ tầng đang chạy.
Managed server từ chối các key có thời hạn dài. Nó xác thực thông qua OAuth qua đăng nhập trình duyệt, hoặc thông qua AWS CLI bằng cách sử dụng chữ ký SigV4. Mọi lệnh gọi công cụ (tool call) đều diễn ra với các token ngắn hạn, mọi hành động đều để lại dấu vết trong CloudTrail, và agent hoạt động nghiêm ngặt trong các ranh giới IAM mà bạn xác định. Nó không thể đi chệch ra ngoài các quyền hạn của mình vì nó bị ràng buộc bởi cùng một công cụ quản lý chính sách (policy engine) điều hành mọi người dùng hoặc role AWS khác trong tổ chức của bạn.
Đây là quy tắc vàng cần nhớ: một máy chủ cung cấp cho agent kiến thức, máy chủ còn lại cung cấp cho nó khả năng thực thi. Sử dụng Knowledge server khi bạn đang nghiên cứu hoặc thiết kế. Sử dụng Managed server khi bạn đang vận hành hoặc sửa chữa.
Tại sao AWS khuyến nghị Managed Server cho hầu hết các tác vụ
AWS hiện đang hướng hầu hết người dùng về phía Managed MCP Server duy nhất thay vì chạy cả hai song song. Managed server đã hấp thụ bối cảnh tài liệu mà Knowledge server cung cấp, vì vậy nó xử lý cả tài liệu tham khảo và các hành động trên tài khoản thực dưới một endpoint duy nhất.
Chạy cả hai máy chủ cùng lúc thực tế có thể làm giảm trải nghiệm. Agent nhận được các định nghĩa công cụ chồng chéo và có thể bị nhầm lẫn về việc nên gọi một lệnh tra cứu tài liệu chỉ đọc hay một API thực tế đối với tài khoản của bạn. Sự do dự đó tạo ra phản hồi chậm hơn và thỉnh thoảng xảy ra lỗi lựa chọn công cụ. Việc hợp nhất về Managed server giúp đơn giản hóa cấu hình của bạn và giữ cho agent tập trung.
Thiết lập Managed Server với OAuth
Việc chạy Managed server chỉ mất khoảng năm phút, nhưng các bước thực hiện rất quan trọng vì đây là một kết nối trực tiếp đến tài khoản của bạn.
Bước 1: Chuẩn bị danh tính IAM của bạn
Tạo hoặc chọn một IAM role hoặc user chuyên dụng. Không sử dụng tài khoản Root. Gắn managed policy có tên AWSMCPSignInOAuthAccessPolicy vào đó. Policy này chỉ cấp các quyền cần thiết để bắt đầu luồng đăng nhập OAuth cho quyền truy cập MCP. Bản thân nó không cấp các quyền quản trị rộng rãi. Các khả năng thực tế mà agent của bạn có sẽ được quyết định bởi các IAM policy khác mà bạn gắn vào danh tính đó. Nếu bạn muốn agent đọc CloudWatch logs nhưng không bao giờ chạm vào IAM hay billing, hãy xây dựng một custom policy chỉ cho phép logs:DescribeLogGroups và logs:FilterLogEvents mà không cho phép gì khác.
Bước 2: Cấu hình client của bạn
Thêm URL AWS MCP server chính thức vào cấu hình client của bạn. Điều này hoạt động với Claude Desktop, Claude Code và Kiro. Trong tệp cài đặt MCP, hãy đăng ký server endpoint để client biết nơi điều hướng các lệnh gọi tool liên quan đến AWS.
Bước 3: Xác thực thông qua trình duyệt
Lần đầu tiên agent cố gắng gọi một AWS tool, hệ điều hành của bạn sẽ mở một cửa sổ trình duyệt. Hãy đăng nhập bằng chính IAM identity mà bạn đã chuẩn bị ở Bước 1. Luồng OAuth sẽ trả về một token có thời hạn ngắn cho MCP server. Bạn sẽ không thấy secret key. Bạn cũng sẽ không phải dán bất cứ thứ gì vào tệp cấu hình. Token sẽ tự động làm mới và hết hạn nhanh chóng.
Bước 4: Xác minh ranh giới tin cậy (trust boundary)
Sau khi đã xác thực, hãy mở CloudTrail và xác nhận rằng các hành động xuất hiện dưới danh tính mà bạn đã tạo. Bạn sẽ thấy các sự kiện như ListBuckets hoặc DescribeInstances gắn liền với IAM user hoặc role cụ thể đó. Nếu bạn thấy hoạt động của tài khoản Root, bạn đã làm sai điều gì đó và nên thu hồi session ngay lập tức.
Nếu OAuth không phù hợp với quy trình làm việc của bạn, Managed server cũng hỗ trợ xác thực SigV4 thông qua các AWS CLI credentials hiện có của bạn. Cách này sẽ bỏ qua cửa sổ pop-up trình duyệt, nhưng bạn vẫn được hưởng lợi từ việc MCP server xử lý việc ký (signing) và quản lý session thay vì để lộ credentials thô cho agent.
Những thói quen bảo mật thực sự quan trọng
Một MCP server chỉ an toàn tương đương với IAM identity đứng sau nó.
Hãy bắt đầu với nguyên tắc đặc quyền tối thiểu (least privilege). Agent của bạn không cần AdministratorAccess để sửa một lỗi tích hợp API Gateway bị điều hướng sai. Hãy cấp cho nó chính xác các quyền đọc hoặc ghi cần thiết cho tác vụ hiện tại, và hãy xoay vòng (rotate) hoặc thu hồi chúng khi công việc hoàn tất. Nếu bạn đang sử dụng một role, hãy thiết lập thời gian session ngắn. Nếu bạn đang sử dụng một user, hãy bật MFA bất cứ nơi nào công cụ của bạn cho phép.
Đừng bao giờ ủy quyền dưới tư cách người dùng Root. Root bỏ qua các service control policies và có quyền truy cập không giới hạn trên toàn bộ tài khoản. Nếu agent hiểu sai một prompt và cố gắng xóa tài nguyên, bạn sẽ muốn yêu cầu đó bị chặn bởi một boundary policy. Root không có các rào chắn (guardrails) như vậy.
Cuối cùng, hãy đối xử với agent như một thực tập sinh mới, người tuân thủ hướng dẫn một cách hoàn hảo nhưng thiếu khả năng phán đoán thông thường. Nó sẽ thực hiện chính xác những gì bạn yêu cầu, một cách máy móc và ngay lập tức. Nếu bạn bảo nó "dọn dẹp các security groups không sử dụng", nó có thể sẽ chấm dứt cái đang gắn với cơ sở dữ liệu production của bạn vì nó khớp với các tiêu chí rộng mà bạn đã đưa ra. Hãy xem xét bất kỳ lệnh phá hủy (destructive commands) nào trước khi xác nhận chúng, đặc biệt là khi agent có quyền ghi.
Kết luận thực tế
Bạn không cần phải đánh đổi bảo mật để lấy sự hữu dụng. Managed AWS MCP Server cho phép trợ lý AI của bạn thấy được cơ sở hạ tầng thực tế, tự sửa lỗi ảo giác (hallucinations) của chính nó và hoạt động trong cùng một khung IAM quản lý phần còn lại của nhóm bạn. Bạn có được ngữ cảnh trực tiếp mà không cần đưa các secrets vào các tệp môi trường. Hãy thiết lập luồng OAuth, thắt chặt các quyền và để agent làm việc với "đôi mắt mở to" và "đôi tay bị ràng buộc" bởi các chính sách của bạn.