Claude Code là một trong những agentic coding tool phổ biến nhất hiện nay, chạy được cả ở terminal (CLI) và làm extension ngay trong VS Code. Khi kết hợp với AWS MCP, bạn có một trợ lý có thể vừa đọc code trong repo, vừa đọc log/metric/config thật của hệ thống đang chạy trên AWS trong cùng một context — điều mà trước đây bạn phải tự chuyển qua chuyển lại giữa terminal, AWS console và editor. Bài này hướng dẫn cài đặt, và đi qua các workflow debug thực tế: từ chẩn đoán lỗi Lambda, kiểm tra resource, tới xử lý lỗi IAM permission.
Cài Đặt và Kết Nối AWS MCP với Claude Code
Claude Code quản lý MCP server qua file cấu hình .mcp.json ở root project (scope project) hoặc qua lệnh claude mcp add (scope user, áp dụng cho mọi project). Với AWS MCP, cách nhanh nhất là dùng package chạy qua uvx hoặc npx tuỳ server bạn chọn (ví dụ AWS Labs cung cấp một số MCP server chính thức dạng Python, cài qua uvx).
Bước 1 — cài AWS CLI và đăng nhập SSO trước (MCP server sẽ dùng credentials có sẵn từ máy bạn):
aws configure sso --profile ai-agent-sso
aws sso login --profile ai-agent-sso
aws sts get-caller-identity --profile ai-agent-sso
Bước 2 — thêm MCP server vào Claude Code bằng CLI:
claude mcp add aws-mcp \
--env AWS_PROFILE=ai-agent-sso \
--env AWS_REGION=ap-southeast-1 \
-- uvx awslabs.core-mcp-server@latest
Hoặc khai báo trực tiếp trong .mcp.json ở root repo nếu muốn commit config cho cả team (không commit credential, chỉ commit tên profile):
{
"mcpServers": {
"aws-mcp": {
"command": "uvx",
"args": ["awslabs.core-mcp-server@latest"],
"env": {
"AWS_PROFILE": "ai-agent-sso",
"AWS_REGION": "ap-southeast-1"
}
}
}
}
Bước 3 — khởi động Claude Code, kiểm tra server đã connect bằng lệnh /mcp trong CLI, sẽ thấy trạng thái aws-mcp: connected và danh sách tool khả dụng. Trong VS Code, extension Claude Code đọc chung file .mcp.json, chỉ cần reload window sau khi thêm server.
Mẹo: Chạy
claude mcp listđể xem toàn bộ MCP server đã đăng ký theo từng scope (local/project/user) — rất dễ nhầm khi bạn add server ở scope user nhưng lại nghĩ nó nằm trong.mcp.jsoncủa project, dẫn tới việc đồng nghiệp clone repo không thấy server nào cả.
Truy Vấn CloudWatch Logs và Metrics để Chẩn Đoán Lỗi Lambda
Đây là use case xuất hiện gần như hàng ngày: một Lambda function bắt đầu lỗi 500, và bạn cần biết lý do trong vài phút chứ không phải nửa giờ đào log trên console. Với AWS MCP đã connect, bạn có thể prompt trực tiếp bằng ngôn ngữ tự nhiên:
Prompt: "Function order-processing-prod đang bị lỗi tăng đột biến trong 30 phút
qua. Lấy log lỗi gần nhất từ CloudWatch Logs, và lấy metric Errors, Duration,
Throttles trong 1 giờ qua để tôi xem pattern lỗi."
Claude Code sẽ gọi tool tương ứng (ví dụ get_metric_data cho CloudWatch metrics, start_query/get_query_results cho CloudWatch Logs Insights) và trả về bảng tổng hợp. Với log lớn, nên hướng dẫn AI dùng CloudWatch Logs Insights query thay vì kéo toàn bộ raw log — vừa nhanh hơn, vừa tránh vượt context window (cửa sổ ngữ cảnh — lượng token tối đa model xử lý một lần):
Prompt: "Chạy Logs Insights query trên log group
/aws/lambda/order-processing-prod trong 1 giờ qua, lọc theo
'ERROR' hoặc 'Task timed out', group theo error message, đếm số lần xuất hiện,
sort giảm dần."
Query CloudWatch Logs Insights tương đương mà agent sẽ dùng bên dưới có dạng:
fields @timestamp, @message
| filter @message like /ERROR/ or @message like /Task timed out/
| stats count(*) as occurrences by @message
| sort occurrences desc
| limit 20
Sau khi có kết quả, AI thường tự đối chiếu với đoạn code liên quan trong repo (nếu bạn đang mở project đó trong Claude Code), giúp bạn có ngay giả thuyết root cause — ví dụ "connection pool tới RDS bị exhausted vì timeout config thấp hơn thời gian query thực tế".
Mẹo: Luôn giới hạn time range trong prompt (ví dụ "1 giờ qua", "từ 14:00 đến 14:30") — nếu không, agent có thể mặc định query toàn bộ log group từ đầu, vừa chậm, vừa tốn context window một cách không cần thiết với dữ liệu cũ không liên quan.
Kiểm Tra S3 Bucket, EC2 Instance và Security Group từ Terminal
Ngoài Lambda, một workflow phổ biến khác là dùng AI để nhanh chóng "vẽ lại" bức tranh hạ tầng hiện tại mà không cần mở AWS console. Ví dụ khi onboarding vào một hệ thống mới, hoặc trước khi review một thay đổi infra:
Prompt: "Liệt kê toàn bộ S3 bucket trong account, đánh dấu bucket nào chưa
enable encryption hoặc có bucket policy cho phép public access."
Prompt: "Describe tất cả EC2 instance đang running trong region
ap-southeast-1, kèm instance type, security group, và public IP nếu có.
Instance nào có public IP mà security group mở port 22 hoặc 3389 ra
0.0.0.0/0 thì highlight riêng."
Đây chính là giá trị thực sự của AWS MCP so với việc tự đọc console: AI có thể tổng hợp thông tin từ nhiều API call (describe_instances, describe_security_groups) rồi tự đối chiếu chéo, việc mà nếu làm tay bạn phải mở nhiều tab, note lại instance ID, rồi tra riêng từng security group.
Với EC2, một prompt hữu ích khác khi debug network:
Prompt: "Instance i-0abcd1234ef567890 không kết nối được tới RDS
db-prod-01. Kiểm tra security group của cả EC2 instance và RDS instance,
xem inbound/outbound rule có cho phép traffic giữa hai bên trên port 5432
không."
Mẹo: Khi hỏi về security group, luôn yêu cầu AI trả về dạng bảng rõ ràng (source, port, protocol, direction) thay vì mô tả bằng văn xuôi — dữ liệu network rule rất dễ đọc sai nếu chỉ nhìn qua câu chữ, bảng giúp bạn tự verify nhanh và tránh AI "diễn giải" sai một rule phức tạp.
Prompting AI để Giải Thích và Sửa Lỗi IAM Permission Denial
Lỗi AccessDenied là một trong những lỗi gây mất thời gian nhất khi làm việc với AWS, vì thông báo lỗi thường chỉ nói "bạn không có quyền" mà không nói rõ thiếu quyền gì, ở đâu. AWS MCP với tool iam:SimulatePrincipalPolicy giúp AI chẩn đoán chính xác việc này thay vì đoán mò.
Prompt: "Lambda function report-generator-prod bị lỗi:
'AccessDenied: User is not authorized to perform: s3:PutObject on resource
arn:aws:s3:::reports-bucket-prod/*'. Kiểm tra execution role của function
này, xem policy hiện tại có action s3:PutObject không, và đề xuất policy
statement cần thêm — nhưng ĐỪNG tự áp dụng, chỉ đưa ra JSON để tôi review."
AI sẽ:
1. Gọi get_function_configuration để lấy execution role ARN của Lambda.
2. Gọi get_role_policy/list_attached_role_policies để lấy toàn bộ policy đang gán.
3. Gọi iam:SimulatePrincipalPolicy để xác nhận đúng là action s3:PutObject trên resource đó bị Deny hoặc không nằm trong Allow.
4. Đề xuất một policy statement bổ sung, dạng JSON, để bạn tự review và apply qua Terraform/console — không tự động chạy iam:PutRolePolicy.
Ví dụ statement AI thường đề xuất:
{
"Sid": "AllowPutReportObjects",
"Effect": "Allow",
"Action": ["s3:PutObject"],
"Resource": "arn:aws:s3:::reports-bucket-prod/*"
}
Đây là ví dụ điển hình của nguyên tắc "AI propose, người execute" đã nói ở bài trước: việc sửa IAM luôn đi qua review, vì cấp dư quyền dù chỉ một chút cũng là rủi ro bảo mật lâu dài.
Mẹo: Khi nhờ AI đề xuất IAM policy fix, luôn thêm yêu cầu "resource ARN cụ thể, không dùng wildcard
*nếu không cần thiết" trong prompt — nếu không, AI có xu hướng đề xuất policy rộng nhất để "chắc chắn hết lỗi", đúng nhưng không least-privilege.
Lưu Ý Khi Sử Dụng
- Cấu hình
.mcp.jsonở scope project và commit vào repo (không commit credential) để cả team dùng chung setup AWS MCP. - Luôn giới hạn time range khi query CloudWatch để tránh tốn context window và trả kết quả không liên quan.
- Yêu cầu AI trả dữ liệu network/security dạng bảng để tự kiểm tra dễ hơn.
- Với mọi đề xuất sửa IAM, luôn giữ nguyên tắc AI chỉ đề xuất, con người review và tự apply.
Mẹo: Sau một buổi debug dài với AWS MCP, dùng chính Claude Code để tự viết lại tóm tắt root cause + fix thành một đoạn postmortem ngắn — bạn đã có toàn bộ log, metric, và policy trong context, việc tận dụng lại để viết báo cáo gần như không tốn thêm công.