·

AWS MCP Là Gì?

Tìm hiểu AWS MCP là gì và cách nó giúp AI agent quản lý tài nguyên cloud và điều tra hạ tầng.

Nếu bạn đã quen với việc dùng AI agent (Claude Code, Cursor, Gemini CLI...) để đọc code, chạy test, sửa bug trong repo, thì AWS MCP chính là bước tiếp theo: cho AI agent "nhìn thấy" và tương tác trực tiếp với hạ tầng đang chạy trên AWS — thay vì bạn phải tự mở console, tự copy log, tự paste vào chat để hỏi AI. AWS MCP (AWS Model Context Protocol server) là một MCP server đóng vai trò cầu nối giữa AI agent và AWS API, cho phép agent gọi các thao tác đọc/kiểm tra tài nguyên AWS một cách có kiểm soát, an toàn, và có audit trail rõ ràng. Bài này sẽ đi từ khái niệm, các tool cốt lõi, cách xác thực, tới việc thiết kế quyền truy cập sao cho AI agent hữu ích mà không trở thành rủi ro bảo mật.

Bộ Công Cụ AWS MCP Cốt Lõi: S3, Lambda, EC2, CloudWatch và IAM Reads

Về bản chất, AWS MCP server là một tiến trình chạy local (hoặc container) sử dụng AWS SDK (thường là boto3 cho Python hoặc AWS SDK for JavaScript) để gọi AWS API, rồi expose các thao tác đó dưới dạng "tool" theo chuẩn MCP (Model Context Protocol — giao thức chuẩn hoá cách AI model gọi tool bên ngoài). AI agent (client) không gọi trực tiếp AWS API; nó gọi tool của MCP server, MCP server mới là bên thực sự cầm credentials và gọi AWS.

Các tool phổ biến nhất mà một AWS MCP server thường expose, nhóm theo service:

  • S3: list_buckets, list_objects (theo prefix), get_object_metadata (size, content-type, last-modified — không tự động đọc nội dung file lớn), get_bucket_policy, get_bucket_encryption.
  • Lambda: list_functions, get_function_configuration (runtime, memory, timeout, env vars — thường mask giá trị secret), invoke_function (thường bị giới hạn hoặc yêu cầu xác nhận riêng), tail_logs (đọc CloudWatch Logs của function theo thời gian thực).
  • EC2: describe_instances, describe_security_groups, describe_vpcs, describe_subnets — chủ yếu là các lệnh describe_* (chỉ đọc), không có terminate_instances hay modify_* trong bộ tool mặc định.
  • CloudWatch: get_metric_data, get_metric_statistics, describe_alarms, start_query/get_query_results cho CloudWatch Logs Insights (chạy query dạng SQL-like trên log).
  • IAM: list_roles, list_policies, get_role_policy, simulate_principal_policy (mô phỏng xem một principal có được phép thực hiện action X không) — đây LUÔN là nhóm chỉ-đọc (read-only), không có tool nào tạo/sửa/xoá IAM entity.

Điểm quan trọng: một AWS MCP server được thiết kế đúng chuẩn sẽ mặc định nghiêng về read-only. Các thao tác có khả năng thay đổi trạng thái hệ thống (write/mutate) thường bị tách riêng, yêu cầu flag đặc biệt khi cấu hình, hoặc bị loại bỏ hoàn toàn khỏi bộ tool.

Mẹo: Khi review một AWS MCP server mới (tự viết hoặc dùng open-source), việc đầu tiên nên làm là liệt kê toàn bộ tool nó expose và đánh dấu tool nào là read (Describe*, List*, Get*) và tool nào là write (Create*, Delete*, Put*, Update*, Invoke*). Đừng tin vào tên server, hãy tự audit danh sách action thật.

Xác Thực AWS MCP: Profile, SSO, Assumed Role và Cấu Hình Region

AWS MCP server không tự "biết" AWS account nào để gọi — nó dùng đúng cơ chế xác thực chuẩn của AWS SDK, đọc theo thứ tự: biến môi trường → file credentials → file config → IAM role (nếu chạy trên EC2/ECS). Có ba cách phổ biến để cấp quyền cho MCP server trong môi trường dev:

1. AWS profile tĩnh (named profile) — dùng cho máy cá nhân, ít khuyến khích cho production account:

[ai-agent-readonly]
aws_access_key_id = AKIA...
aws_secret_access_key = ...

[profile ai-agent-readonly]
region = ap-southeast-1
output = json

2. AWS SSO (IAM Identity Center) — khuyến nghị cho môi trường công ty, vì credential có thời hạn ngắn (thường 1-12 giờ) và không lưu access key tĩnh:

[profile ai-agent-sso]
sso_start_url = https://your-org.awsapps.com/start
sso_region = ap-southeast-1
sso_account_id = 123456789012
sso_role_name = ReadOnlyForAIAgent
region = ap-southeast-1

Trước khi dùng, cần chạy aws sso login --profile ai-agent-sso để mở browser xác thực; sau đó MCP server chỉ cần trỏ AWS_PROFILE=ai-agent-sso là dùng được token đã cache.

3. Assumed Role qua STS — dùng khi AI agent cần truy cập account khác (ví dụ agent chạy ở account "tooling" nhưng cần đọc log ở account "production"):

{
  "RoleArn": "arn:aws:iam::999999999999:role/AIAgentCrossAccountReadOnly",
  "RoleSessionName": "ai-agent-session",
  "ExternalId": "unique-shared-secret",
  "DurationSeconds": 3600
}

Cấu hình region nên đặt rõ ràng trong ~/.aws/config hoặc biến AWS_REGION/AWS_DEFAULT_REGION, tránh để MCP server tự suy luận sai region (một lỗi rất phổ biến: agent describe instance ở us-east-1 trong khi hệ thống thật chạy ở ap-southeast-1, dẫn tới kết luận sai "không có resource nào").

Mẹo: Luôn tạo một profile/role riêng đặt tên rõ ràng như ai-agent-readonly hoặc ai-agent-sso, đừng tái sử dụng profile cá nhân của bạn (profile có full quyền admin). Việc tách riêng giúp bạn revoke quyền của AI agent bất cứ lúc nào mà không ảnh hưởng tới quyền làm việc bình thường của chính bạn.

AI Có Thể Tự Động Hoá Gì Trên AWS — Và Những Operation Nào Cần Giữ Human-Gated

Đây là phần quan trọng nhất về mặt tư duy vận hành, không phải kỹ thuật. AWS MCP mở ra khả năng rất lớn, nhưng "làm được" không có nghĩa là "nên để AI tự làm không cần người duyệt".

Nhóm an toàn để AI tự động hoàn toàn (không cần human-gated — không cần người phê duyệt trước khi thực hiện):
- Đọc CloudWatch Logs, metrics, alarms để chẩn đoán sự cố.
- Đọc cấu hình Lambda function, security group, VPC để hiểu kiến trúc hệ thống.
- Giải thích lỗi (ví dụ giải thích một AccessDenied error, giải thích tại sao Lambda timeout).
- Đề xuất fix dưới dạng diff/PR — AI viết ra thay đổi nhưng không tự apply.
- Tạo báo cáo cost breakdown, security posture summary.

Nhóm cần human-gated (con người phải review và bấm approve) — không nên để agent tự thực thi:
- Bất kỳ action Delete*, Terminate* (xoá bucket, terminate EC2 instance, xoá Lambda function).
- Sửa Security Group, Network ACL, hoặc bất kỳ thay đổi network access.
- Sửa IAM policy/role — vì đây là vector leo thang quyền (privilege escalation) kinh điển, nếu AI vô tình cấp quyền sai có thể mở lỗ hổng nghiêm trọng.
- Thay đổi liên quan tới billing, Reserved Instance, Savings Plan.
- Deploy trực tiếp lên production (invoke Lambda production, update function code) mà không qua CI/CD pipeline có review.

Nguyên tắc thực dụng: nếu action đó là idempotent và reversible (đọc log, đọc config) → an toàn để tự động. Nếu action irreversible hoặc ảnh hưởng tới availability/security → luôn có con người ở giữa, dù AI đề xuất đúng đến 99%.

Mẹo: Thiết lập một quy ước rõ ràng trong team: "AI agent có quyền propose, con người có quyền execute." Cụ thể hoá bằng cách để AI luôn xuất ra lệnh AWS CLI hoặc Terraform diff thay vì tự gọi API write — bạn review dòng lệnh đó trước khi copy-paste chạy, tạo ra một bước kiểm tra thủ công gần như miễn phí.

Thiết Kế IAM Least-Privilege Cho AI Agent

Least-privilege (đặc quyền tối thiểu) là nguyên tắc: chỉ cấp đúng quyền cần dùng, không hơn. Với AI agent, nguyên tắc này càng quan trọng vì agent có thể bị prompt injection (bị "dụ" thực hiện hành động ngoài ý muốn thông qua nội dung độc hại trong log/file mà nó đọc được), nên giới hạn "bán kính nổ" (blast radius) là lớp phòng thủ bắt buộc.

Ví dụ một IAM policy read-only thực tế cho AI agent, cấp quyền đúng những service đã nêu ở trên, đồng thời deny rõ ràng các action nguy hiểm dù chúng vốn không nằm trong Allow:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowReadOnlyObservability",
      "Effect": "Allow",
      "Action": [
        "s3:ListBucket",
        "s3:GetBucketPolicy",
        "s3:GetBucketEncryption",
        "s3:GetObjectAttributes",
        "lambda:ListFunctions",
        "lambda:GetFunctionConfiguration",
        "lambda:GetFunction",
        "ec2:Describe*",
        "cloudwatch:GetMetricData",
        "cloudwatch:GetMetricStatistics",
        "cloudwatch:DescribeAlarms",
        "logs:StartQuery",
        "logs:GetQueryResults",
        "logs:FilterLogEvents",
        "iam:ListRoles",
        "iam:ListPolicies",
        "iam:GetRolePolicy",
        "iam:SimulatePrincipalPolicy"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": { "aws:RequestedRegion": "ap-southeast-1" }
      }
    },
    {
      "Sid": "ExplicitDenyMutations",
      "Effect": "Deny",
      "Action": [
        "iam:Put*", "iam:Attach*", "iam:Create*", "iam:Update*", "iam:Delete*",
        "ec2:Terminate*", "ec2:Delete*", "ec2:Modify*", "ec2:Reboot*",
        "s3:Delete*", "s3:PutBucketPolicy",
        "lambda:Delete*", "lambda:UpdateFunctionCode", "lambda:Invoke*"
      ],
      "Resource": "*"
    }
  ]
}

Vài lưu ý khi thiết kế policy này trong thực tế:

  • Nên gắn policy vào một IAM role riêng (không phải IAM user với access key tĩnh), rồi cho MCP server assume role đó qua SSO hoặc sts:AssumeRole — access key tĩnh dễ leak vào log, vào history file, vào commit nhầm.
  • Dùng Condition để giới hạn theo region, theo tag resource (aws:ResourceTag), giảm thiểu việc agent "đi lạc" sang account/region không liên quan.
  • Statement Deny tường minh (explicit deny) luôn thắng Allow, nên dù sau này ai đó vô tình thêm quyền Allow rộng hơn ở policy khác, action nguy hiểm vẫn bị chặn — đây là lớp phòng thủ theo chiều sâu (defense in depth).
  • Định kỳ rotate credentials (nếu dùng static key) và review CloudTrail log của riêng role này để phát hiện bất thường — vì mọi API call của agent đều đi qua CloudTrail giống một user bình thường.

Mẹo: Test policy bằng iam:SimulatePrincipalPolicy hoặc IAM Policy Simulator trước khi gán cho role thật — mô phỏng thử các action nguy hiểm (ec2:TerminateInstances, iam:CreateAccessKey) để chắc chắn chúng bị Deny, tránh trường hợp bạn nghĩ đã chặn nhưng thực ra JSON viết sai syntax nên không có hiệu lực.

Lưu Ý Khi Triển Khai

Trước khi cắm AWS MCP vào workflow hàng ngày, hãy rà lại checklist ngắn sau:

  • Tạo riêng profile/role cho AI agent, không tái sử dụng credential cá nhân hoặc credential admin.
  • Ưu tiên AWS SSO hoặc assumed role có thời hạn ngắn hơn static access key.
  • Rà soát toàn bộ tool mà MCP server expose, xác nhận không có action write nằm ngoài dự kiến.
  • Áp dụng IAM least-privilege với explicit deny cho các action phá hoại.
  • Thiết lập quy tắc human-gated rõ ràng cho team: action nào AI được tự làm, action nào bắt buộc người duyệt.
  • Bật CloudTrail logging cho role của agent để có audit trail độc lập, không phụ thuộc vào log của chính AI agent.

Mẹo: Ghi lại toàn bộ quyết định về scope quyền (cái gì được phép, cái gì không) thành một file AI_AGENT_POLICY.md trong repo hạ tầng — không chỉ để tuân thủ security review, mà còn giúp thành viên mới trong team hiểu ngay giới hạn của AI agent mà không cần đọc lại toàn bộ IAM JSON.

Tiếp AWS MCP với Claude Code CLI and VS Code