[Series Bedrock AgentCore] Bài 2: Amazon Bedrock AgentCore — AgentCore Gateway

Tiếp nối bài 1 về AgentCore Runtime.

Lưu ý về nguồn: Toàn bộ số liệu quota/giá trong tài liệu này được đối chiếu trực tiếp với trang Quotas for Amazon Bedrock AgentCore và Amazon Bedrock AgentCore Pricing tại thời điểm biên soạn. AgentCore là dịch vụ cập nhật rất nhanh (tính năng mới gần như mỗi 2–3 tuần) — SA nên re-verify trước khi khoá quyết định kiến trúc, đặc biệt là bảng region support và quota search 25 TPM.

1. Executive Summary

AgentCore Gateway là managed tool server: nó biến API (REST/OpenAPI, Smithy, API Gateway), AWS Lambda, MCP server có sẵn, và các built-in connector (Slack, Jira, Salesforce, Zendesk, Asana, Web Search…) thành tool mà agent khám phá và gọi được qua Model Context Protocol (MCP) — không cần viết wrapper, không cần tự quản hạ tầng broker.

Bài toán Gateway giải là bài toán tổ hợp (M×N): nếu có M agent và N hệ thống backend, mô hình "mỗi agent tự tích hợp mỗi backend" sinh ra M × N điểm tích hợp — mỗi điểm có auth riêng, schema riêng, retry riêng, không ai audit được agent nào đang gọi gì. Gateway nén nó về M + N: agent chỉ cần nói MCP với Gateway; Gateway thay mặt agent nói "ngôn ngữ gốc" (REST/Lambda invoke/Smithy/MCP) với từng backend.

Ba năng lực lõi tạo nên giá trị của Gateway:

Gateway còn có một lớp "governance" ít được nói tới nhưng quan trọng cho production: Gateway Interceptors (Lambda chạy trước/sau mỗi lời gọi để transform, redact, hoặc chặn request/response), tích hợp AgentCore Policy (Cedar) để enforce quyền truy cập tool theo kiểu deterministic, và Guardrails chạy ngay tại tầng Gateway để chặn prompt injection/harmful content/rò rỉ dữ liệu nhạy cảm — nằm ngoài vòng lặp reasoning của agent nên agent không "lách" được.

Mô hình giá hoàn toàn theo mức dùng, không phí cố định: $0,005/1.000 lệnh gọi (ListTools, InvokeTool, Ping), $0,025/1.000 lượt Semantic Search (đắt gấp 5 lần invoke thường), $0,02/100 tool được index/tháng, cộng thêm $0,006/GB nếu traffic egress qua VPC. Ví dụ chính thức của AWS cho một HR assistant: 50 triệu interaction/tháng, 200 tool, tỉ lệ 1 search + 4 InvokeTool mỗi interaction → tổng ~$2.250/tháng cho riêng Gateway.

Khi nào nên dùng: có ≥ 2 agent cần dùng chung một bộ tool, cần audit/governance tập trung, muốn "MCP-hoá" hệ thống enterprise hiện có mà không đụng code nghiệp vụ, hoặc cần outbound auth phức tạp (3LO thay mặt user) mà tự build sẽ tốn hàng tháng engineering.

Khi nào không nên dùng: 1 agent, 1–2 tool đơn giản, không có yêu cầu governance — gọi thẳng SDK/API sẽ rẻ và đơn giản hơn; overhead của Gateway (thêm 1 network hop + 1 dòng chi phí) chỉ trả giá xứng đáng khi quy mô đủ lớn.

2. Concept & Core Principles

2.1 What? — Định nghĩa chính xác

Một Gateway là một resource có endpoint riêng:

Data plane (runtime access):
https://{gateway-Id}.gateway.bedrock-agentcore.{Region}.amazonaws.com

ARN:
arn:aws:bedrock-agentcore:{Region}:{Account}:gateway/{gateway-Id}

Control plane (quản lý):
bedrock-agentcore-control.{Region}.amazonaws.com

Service principal:
bedrock-agentcore.amazonaws.com

Transport: MCP Streamable HTTP

Khi tạo Gateway, một workload identity cho chính Gateway đó được tự động tạo — đây là nền tảng để Gateway tự xác thực khi gọi ra backend hoặc khi tích hợp với Identity.

Một Gateway gắn nhiều Gateway Target — backend mà Gateway kết nối tới — thuộc 3 category:

(a) MCP target — chế độ aggregation. Nhiều target loại này được gộp thành một virtual MCP server duy nhất: client chỉ thấy một tools/list hợp nhất, có capability synchronization (tự phát hiện tool mới khi backend đổi), có semantic tool search, và hỗ trợ 3-legged OAuth (3LO) ở cấp target. Các loại MCP target:

• Lambda function — business logic tuỳ ý; Gateway invoke rồi dịch response sang MCP.
• API Gateway REST API — tích hợp trực tiếp API Gateway sẵn có.
• OpenAPI 3.0 spec — REST API → tool; operationId của mỗi operation trở thành tên tool (bắt buộc phải có, thiếu là nguyên nhân số 1 khiến tool "biến mất").
• Smithy model — AWS service hoặc API tuỳ chỉnh; Gateway có Smithy model dựng sẵn cho một số AWS service.
• MCP server (remote) — kết nối MCP server đã có; hỗ trợ tools (bắt buộc), prompts và resources (tuỳ chọn), và hỗ trợ elicitation (server có thể yêu cầu thêm thông tin từ người dùng giữa chừng).
• Built-in integration templates & connectors — 1-click cho Salesforce, Slack, Jira, Asana, Zendesk, và Web Search Tool (index web riêng của AWS, zero data egress, $7/1.000 query).

(b) HTTP target — direct proxy. Gửi traffic thẳng tới target theo path-based routing — không aggregation, không dịch giao thức, không semantic search. Dùng cho: AgentCore Runtime agent khác, dịch vụ A2A, MCP server ngoài, hoặc bất kỳ HTTP endpoint nào qua passthrough.

(c) Inference target. Định tuyến traffic LLM tới nhiều model provider qua một endpoint duy nhất, chọn provider dựa trên field model trong request — agent có một interface nhất quán cho Bedrock, OpenAI, Anthropic mà không cần biết chi tiết từng provider.

2.2 Why? — Ba áp lực kỹ thuật buộc phải có Gateway

(1) Tool sprawl phá vỡ khả năng chọn tool của LLM. Khi agent có 100+ tool, nhồi hết definition vào system prompt mỗi turn gây ba hậu quả: token cost tăng tuyến tính theo số tool, latency tăng, và độ chính xác chọn tool giảm vì LLM nhầm lẫn giữa các tool có tên/mục đích gần giống. Semantic tool search đảo ngược mô hình: từ "nạp hết rồi để LLM tự chọn" sang "search theo ý định rồi chỉ nạp tool liên quan" — giữ context nhỏ mà độ chính xác cao hơn.

(2) Auth cho agent phức tạp hơn auth cho service thông thường. Một microservice gọi service khác dùng một credential cố định. Một agent, trong cùng một vòng reasoning, có thể cần: gọi Slack thay mặt user A (3LO), gọi Jira thay mặt user A (3LO khác), và gọi internal database bằng service credential (2LO/IAM) — ba credential, hai mô hình quyền, một reasoning loop. Tự xây cái này là một token vault + OAuth orchestration + refresh logic, tốn hàng tháng engineering nếu làm đúng.

(3) Không có điểm kiểm soát tập trung = không có governance. Nếu mỗi agent tự gọi thẳng API, câu hỏi "agent nào được phép xoá dữ liệu production?" không có nơi nào trả lời được một cách nhất quán. Gateway là điểm duy nhất để Cedar Policy chặn tool call trước khi execute, để Guardrails quét input/output ngoài vòng lặp của agent (agent không thể "lý luận vòng qua" một guardrail nằm ở tầng hạ tầng), và để Interceptor Lambda áp logic tuỳ biến (tenant isolation, redaction, audit).

2.3 How? — Nguyên lý vận hành ở tầng cao

1. Agent (MCP client) kết nối tới Gateway endpoint, xác thực bằng OAuth JWT hoặc SigV4 (inbound).
2. Agent gọi tools/list (hoặc x_amz_bedrock_agentcore_search nếu dùng semantic search) để khám phá tool.
3. Gateway tổng hợp tool từ mọi MCP target đã gắn (hoặc trả kết quả search theo ngữ nghĩa).
4. Agent gọi tools/call với tên tool cụ thể.
5. (Tuỳ chọn) Request Interceptor chạy trước, có thể transform/redact/chặn request.
6. Gateway trao đổi outbound credential phù hợp (IAM SigV4, OAuth 2LO, OAuth 3LO, hoặc API Key) và gọi backend thật theo giao thức gốc của target đó.
7. (Tuỳ chọn) AgentCore Policy (Cedar) đánh giá quyền trước khi Gateway thực sự invoke — có thể ALLOW/DENY dựa trên identity, tool, tham số.
8. Backend trả kết quả; Gateway dịch ngược sang MCP response.
9. (Tuỳ chọn) Response Interceptor và Guardrails xử lý response (lọc tool không được phép thấy, redact dữ liệu nhạy cảm, chặn nội dung có hại) trước khi trả về agent.

2.4 Pros / Cons / Trade-offs

Pros

• Loại bỏ hoàn toàn công sức viết wrapper MCP cho từng API/Lambda hiện có.
• Auth hai chiều (inbound + outbound) quản lý tập trung, hỗ trợ cả 2LO lẫn 3LO thay mặt người dùng.
• Semantic search giữ context nhỏ khi số tool lớn, cải thiện độ chính xác chọn tool.
• Governance tập trung: Policy (Cedar) + Interceptor + Guardrails đều nằm ở tầng hạ tầng, ngoài tầm với của agent.
• Mô hình giá pay-per-use, không phí cố định, không hạ tầng phải patch/scale thủ công.
• 1-click connector cho các SaaS phổ biến giúp rút ngắn thời gian tích hợp ban đầu.

Cons

• Thêm một network hop → tăng latency (thường nhỏ nhưng cần đo trong hệ thống latency-sensitive).
• HTTP target không có aggregation/semantic search — dễ nhầm khi thiết kế nếu không hiểu rõ 2 chế độ.
• Semantic search quota mặc định khá thấp (25 giao dịch/phút) — có thể là nút thắt cổ chai ở quy mô lớn nếu không xin tăng quota sớm.
• Region coverage hẹp hơn Bedrock lõi — một số Region chỉ hỗ trợ Gateway/Identity/Memory, không có Policy/Evaluations.
• Cost model có nhiều dòng nhỏ (invoke, search, index, egress) — dễ bị "chết vì ngàn vết cắt" nếu không mô hình hoá trước khi go-live.

Trade-offs cốt lõi: bạn đánh đổi một chi phí vận hành nhỏ và một hop mạng để lấy governance tập trung, auth quản lý sẵn, và khả năng discover tool ở quy mô. Với 2–3 tool cho 1 agent, đây là overhead thuần không đáng. Với 50+ tool và nhiều team dùng chung, không có Gateway gần như không có cách nào quản lý auth và audit nhất quán.

2.5 Best Practice

• Tách Gateway theo trust boundary, không theo team hay theo tiện lợi tổ chức — một Gateway = một biên bảo mật.
• Chỉ bật semantic search cho gateway thực sự có nhiều tool (>15–20); với ít tool, liệt kê trực tiếp qua tools/list rẻ hơn và không đụng quota 25 TPM.
• Review mô tả tool (tool description) như review API contract — mô tả mơ hồ là nguyên nhân hàng đầu khiến agent chọn sai tool.

2.6 Common Mistakes

• Quên operationId khi định nghĩa OpenAPI target → tool không xuất hiện, không có lỗi rõ ràng.
• Gắn một target với nhiều outbound credential khác nhau — một target chỉ nhận một credential provider; cần tách target nếu backend cần nhiều kiểu auth.
• Thiết kế timeout backend dài hơn hoặc gần bằng 15 phút timeout mặc định của Gateway → agent bị treo, connection không giải phóng đúng lúc.
• Không đặt PrivateLink cho traffic nội bộ, khiến traffic đi qua Internet công cộng dù backend là service nội bộ.

2.7 Real-world Example

Một ngân hàng khu vực có 12 team, mỗi team muốn xây agent riêng nhưng dùng chung ~80 API nội bộ (core banking, CRM, KYC). Trước Gateway: mỗi team tự viết OAuth client, tự quản secret, không ai biết agent nào gọi API xoá/ghi dữ liệu nào. Sau khi đưa toàn bộ 80 API vào 3 Gateway (tách theo domain: retail banking, KYC/compliance, CRM), mỗi Gateway áp Cedar Policy riêng theo domain, bật Interceptor để tenant-isolate theo chi nhánh, và bật Guardrails để chặn prompt injection từ nội dung tài liệu khách hàng được nạp vào agent. Kết quả: thời gian onboard một agent mới từ ~6 tuần (tự tích hợp) xuống còn ~3 ngày (chỉ cần thêm workload identity + xin quyền qua Cedar).

3. Architecture Deep Dive

3.1 Sơ đồ khối tổng quát

1. Thành phần phía bên trái: AI Agent (MCP Client)

• Agent: Đóng vai trò là một AI Agent tích hợp MCP Client (Model Context Protocol).
• Giao tiếp: Agent gửi các yêu cầu thông qua endpoint /mcp sử dụng kết nối streamable-http. Các thao tác chính bao gồm: Liệt kê công cụ (List tools), Gọi công cụ (Invoke tool), và Tìm kiếm (Search).
• Inbound Auth: Yêu cầu xác thực đầu vào bằng OAuth token.

2. Thành phần trung tâm: AgentCore Gateway

• Vai trò chính: Là cổng giao tiếp trung tâm (Gateway) nhận các yêu cầu từ Agent, xử lý định tuyến và chuyển tiếp đến các hệ thống tài nguyên mục tiêu phía bên phải.
• Bảo mật và Xác thực (Outbound Auth): Quản lý việc xác thực đầu ra bằng các cơ chế như IAM, API key, hoặc Token tùy thuộc vào loại tài nguyên đích.

3. Thành phần phía bên phải: APIs, tools, resources (Mục tiêu)

Hệ thống hỗ trợ kết nối với 3 loại target chính tương ứng với các nhóm công cụ khác nhau:

• Smithy Target: Kết nối tới các công cụ (Tool 1, Tool 2, Tool 3) dựa trên mô hình Smithy model, sử dụng xác thực IAM.
• OpenAPI Target: Kết nối tới các dịch vụ RESTful (Tool 4, Tool 5, Tool 6) dựa trên OpenAPI schema, sử dụng xác thực qua API key hoặc Token.
• AWS Lambda Target: Kết nối tới các hàm xử lý (Tool 7, Tool 8, Tool n) dạng AWS Lambda function, sử dụng xác thực IAM.

4. Thành phần bên dưới và hỗ trợ

• AgentCore Identity:
  • Phối hợp với Identity Provider bên ngoài để thực hiện Inbound/Outbound Auth.
  • Cung cấp các tính năng bảo mật nâng cao như: Kho lưu trữ mã thông báo bảo mật (Secure token vault), Lưu trữ cache token (Token caching), Định danh workload (Workload identity), Bộ ủy quyền OAuth2 (OAuth2 authorizer), và Nhà cung cấp thông tin xác thực tài nguyên (Resource credentials provider).
• CloudWatch: Dùng để giám sát, ghi log và theo dõi hoạt động của toàn bộ hệ thống.

3.2 Hai chế độ hoạt động

Đây là quyết định kiến trúc quan trọng nhất khi thiết kế với Gateway:

Chọn sai — ví dụ gắn một service cần semantic discovery làm HTTP target — sẽ khiến tool "vô hình" với search mà không có cảnh báo rõ ràng.

3.3 Networking & Isolation

• PrivateLink: Gateway hỗ trợ invocation qua AWS PrivateLink, cho phép agent/client trong VPC gọi Gateway mà không ra Internet công cộng.
• VPC egress cho target: Lambda target tự động gọi được resource trong VPC (không cần cấu hình thêm) nếu Lambda đã có VPC config; API Gateway và MCP server (chạy trên AgentCore Runtime) cũng hỗ trợ egress vào VPC theo các mẫu hình tương tự. Nên giới hạn execution role của Gateway theo nguyên tắc least-privilege — chỉ được invoke đúng Lambda/API dự kiến.
• Invocation logging: xuất log qua CloudWatch, S3, hoặc Data Firehose — nền tảng cho audit trail và cho Interceptor/Policy debug.

3.4 Lớp governance xếp chồng (defense in depth)

Thứ tự thực thi trong một request điển hình: Inbound Authorizer → Request Interceptor → Cedar Policy → Outbound Auth → Backend → Response Interceptor → Guardrails → Client. Mỗi lớp độc lập, ghi log riêng, cho phép audit chính xác lớp nào chặn/biến đổi request nào — đây là khác biệt lớn so với việc nhồi toàn bộ logic kiểm soát vào code agent.

4. Request Flow từng bước

Ví dụ: một agent hỗ trợ nhân viên gọi tool "tra cứu trạng thái đơn hàng" được expose qua OpenAPI target, có Interceptor và Policy bật.

Bước 1 — Kết nối & xác thực inbound. Agent (MCP client) mở kết nối Streamable HTTP tới https://{gateway-id}.gateway.bedrock-agentcore.{region}.amazonaws.com/mcp, gửi kèm Authorization: Bearer {JWT} (nếu inbound = OAuth) hoặc ký SigV4 (nếu inbound = IAM). Gateway xác thực aud/client_id/scope của JWT so với cấu hình authorizer.

Bước 2 — Khám phá tool. Agent gọi tools/list, hoặc nếu gateway bật semantic search, gọi tools/call với tool đặc biệt x_amz_bedrock_agentcore_search kèm natural-language query (vd: "tra cứu đơn hàng theo mã khách hàng"). Gateway trả tập tool liên quan nhất thay vì toàn bộ danh sách.

Bước 3 — Gọi tool. Agent gọi tools/call với tên tool cụ thể và tham số theo JSON Schema đã được publish.

Bước 4 — Request Interceptor (nếu có). Lambda REQUEST interceptor nhận payload mcp.gatewayRequest, có thể: đổi JWT lấy tenant-scoped credential, tiêm thêm context (vd: geography, tenant_id), hoặc trả thẳng transformedGatewayResponse để chặn sớm mà không cần gọi backend.

Bước 5 — Đánh giá Policy (Cedar), nếu bật. Policy Engine đánh giá identity gọi + tool + tham số theo policy đã định nghĩa/generate, trả ALLOW hoặc DENY. DENY → Gateway trả lỗi 403 ngay, không gọi backend.

Bước 6 — Trao đổi outbound credential. Tuỳ cấu hình target: lấy IAM role của Gateway (SigV4), lấy OAuth 2LO token (machine-to-machine), thực hiện OAuth 3LO on-behalf-of (OBO) token exchange qua AgentCore Identity (nếu cần thay mặt user cụ thể), hoặc lấy API Key đã lưu trong credential provider.

Bước 7 — Gọi backend thật. Gateway dịch MCP request sang giao thức gốc (REST call với schema OpenAPI tương ứng operationId, Lambda Invoke, hoặc AWS API call qua Smithy) và gửi tới target.

Bước 8 — Nhận response từ backend, Gateway dịch ngược sang định dạng MCP.

Bước 9 — Response Interceptor (nếu có). Lambda RESPONSE interceptor có thể lọc field nhạy cảm, lọc tool không được phép xuất hiện trong tools/list, hoặc thêm metadata.

Bước 10 — Guardrails (nếu bật). Kiểm tra output cho prompt injection, nội dung có hại, hoặc rò rỉ dữ liệu nhạy cảm — độc lập với vòng reasoning của agent.

Bước 11 — Trả kết quả cho agent, đồng thời Gateway ghi invocation log (CloudWatch/S3/Firehose) cho toàn bộ vòng đời request để phục vụ audit và observability.

5. Thành phần chính và vai trò

6. Thiết kế theo AWS Well-Architected Framework

Áp dụng 6 trụ cột (bao gồm Generative AI Lens) vào thiết kế Gateway:

Operational Excellence

• Quản lý toàn bộ cấu hình Gateway/Target/Interceptor bằng IaC (CDK có LambdaInterceptor/Gateway construct alpha, hoặc CloudFormation/Terraform) — tránh cấu hình tay qua console cho production.
• Version hoá target: khi đổi OpenAPI spec hay Lambda logic, tạo target mới thay vì sửa tại chỗ để rollback an toàn.
• Dùng AgentCore CLI (@aws/agentcore) cho vòng đời phát triển local (hot reload) trước khi deploy.

Security

• Tách inbound (ai gọi Gateway) khỏi outbound (Gateway gọi gì bằng credential nào) — không bao giờ dùng chung một credential cho cả hai chiều.
• Bật Cedar Policy cho mọi tool có khả năng gây tác động nghiệp vụ (ghi/xoá dữ liệu, giao dịch tài chính).
• Dùng Interceptor cho tenant isolation trong kiến trúc multi-tenant — không tin tưởng agent tự declare tenant_id.
• Bật Guardrails ở tầng Gateway cho các tool nhận input từ nội dung không tin cậy (tài liệu, email, trang web) để chặn prompt injection trước khi nó chạm backend.

Reliability

• Đặt timeout backend ngắn hơn đáng kể so với 15 phút mặc định của Gateway để tránh agent bị treo chờ.
• Theo dõi sát quota "concurrent target operations" (5/gateway) khi CI/CD deploy nhiều target song song — vượt quota làm deployment fail ngẫu nhiên, dễ bị hiểu nhầm là lỗi code.
• Idempotency ở tầng backend (Lambda/API) vì retry ở tầng agent/MCP client có thể lặp lại lời gọi.

Performance Efficiency

• Bật semantic search chỉ khi số tool đủ lớn (>15–20) để tránh tốn quota 25 TPM cho lợi ích không đáng kể.
• Ưu tiên inline schema (≤1 MB) cho tool nhỏ; dùng S3-based schema (≤10 MB) cho OpenAPI spec lớn để tránh vượt giới hạn payload.

Cost Optimization

• Theo dõi tỉ lệ Search API / InvokeTool — Search đắt gấp 5 lần; nếu agent luôn biết tên tool cần gọi (workflow cố định), bỏ qua semantic search và gọi thẳng tools/call.
• Index chỉ những tool thực sự cần semantic discovery; tool nội bộ ít dùng có thể không cần index để giảm phí $0,02/100 tool/tháng.

Sustainability / GenAI Lens

• Governance tập trung (Policy + Guardrails + Interceptor) giảm số lần agent phải "thử lại" do lỗi quyền hoặc nội dung không phù hợp — gián tiếp giảm số lần gọi model dư thừa.
• Semantic search giảm token nạp vào context mỗi turn, giảm chi phí và energy footprint của phần suy luận LLM so với việc nhồi toàn bộ tool definition.

7. Security Best Practices

Inbound

• Ưu tiên OAuth (JWT) cho kịch bản multi-tenant/nhiều client ứng dụng; dùng IAM (SigV4) khi caller thuần nội bộ AWS (agent khác trên Runtime, service AWS). Tránh "no authorization" ngoài môi trường dev/test.
• Kiểm tra chặt aud/client_id/scope trong JWT — 401/403 phổ biến nhất tới từ mismatch giữa authorizer cấu hình và token thực tế client gửi.

Outbound

• Ưu tiên OAuth 3LO (user-delegated) cho mọi tool chạm dữ liệu cá nhân của người dùng cụ thể (email, tài liệu cá nhân, hệ thống HR) — không dùng credential dùng chung (2LO/IAM) cho các trường hợp này để tránh agent "leo thang" quyền vượt phạm vi user cho phép.
• Với 3LO, đảm bảo ứng dụng client surface đúng authorization URL cho người dùng consent lần đầu — thiếu bước này là nguyên nhân phổ biến khiến 3LO "không hoạt động" ở lần chạy đầu tiên.
• Không nhúng secret/API key trực tiếp trong code Lambda hay biến môi trường target — dùng credential provider của Identity.

Interceptor & Policy

• Dùng Request Interceptor để đổi JWT lấy tenant-scoped credential và tiêm context (geography, tenant, role) — không tin agent tự khai các trường này.
• Dùng Cedar Policy làm lớp kiểm soát deterministic (ai được gọi tool nào) độc lập với Interceptor (kiểm soát dynamic/nghiệp vụ) — kết hợp cả hai cho các tool nhạy cảm (ví dụ: query dữ liệu tài chính theo khu vực địa lý).
• Chỉ bật passRequestHeaders khi Interceptor thực sự cần đọc header gốc — hạn chế bề mặt lộ thông tin.

Network

• Bật PrivateLink cho mọi Gateway phục vụ traffic nội bộ doanh nghiệp; tránh để traffic quản trị/nhạy cảm đi qua Internet công cộng.
• Giới hạn execution role của Gateway theo nguyên tắc least-privilege — chỉ invoke đúng Lambda/API/service cần thiết, không cấp quyền rộng "invoke bất kỳ Lambda nào".

Guardrails

• Bật Guardrails cho input của tool nhận nội dung không tin cậy (tài liệu upload, kết quả web search, email) để chặn prompt injection ở tầng hạ tầng — không phụ thuộc vào việc agent "tự nhận biết" nội dung độc hại.
• Bật Guardrails cho output nếu tool trả về dữ liệu có khả năng chứa PII/thông tin nhạy cảm cần redact trước khi vào context của LLM.

Sai lầm thường gặp cần tránh

• Cấp một target nhiều credential khác nhau bằng cách "chỉnh sửa nhiều lần" — API chỉ chấp nhận một credential provider mỗi target; giải pháp đúng là tách thành nhiều target.
• Bỏ qua audit log invocation vì "tính sau" — nên bật ngay từ ngày đầu vì log lịch sử không thể tái tạo.

8. Performance & Scalability

8.1 Bảng quota cần nhớ (nguồn: AWS Service Quotas, chính xác tại thời điểm biên soạn)

Quota nguy hiểm nhất: 25 TPM cho search-based tool-call. Nếu kiến trúc dựa nhiều vào semantic search (agent luôn search trước khi gọi), quota này dễ trở thành nút thắt ở quy mô production trước cả các quota khác — nên đưa vào capacity planning và xin tăng ngay từ giai đoạn thiết kế, không đợi tới khi throttle thật.

8.2 Chiến lược tối ưu hiệu năng

• Giảm phụ thuộc semantic search khi có thể: nếu workflow của agent tương đối cố định (biết trước cần gọi tool nào), gọi thẳng tools/call theo tên thay vì luôn search trước — vừa nhanh hơn (bớt 1 round-trip) vừa tránh quota 25 TPM.
• Field bắt buộc (required) rõ ràng trong schema tool để giảm số lần agent gọi tool với tham số thiếu, tránh vòng lặp retry.
• Batch hoá thiết kế Lambda target: với các tác vụ có thể gộp nhiều bước, gộp logic trong một Lambda thay vì buộc agent gọi nhiều tool tuần tự — giảm số round-trip qua Gateway.
• Theo dõi CloudWatch metrics của Gateway (invocation count, latency, error rate theo target) để phát hiện target nào đang là nút thắt trước khi throttle xảy ra trên diện rộng.
• Streaming response: với target hỗ trợ response streaming, bật enableResponseStreaming để giảm time-to-first-byte cho tool trả dữ liệu lớn; lưu ý Response Interceptor khi đó phải xử lý theo isStreamingResponse.

8.3 Scalability theo chiều ngang

Vì Gateway là managed/serverless, không có khái niệm "scale cụm" thủ công — giới hạn thực sự nằm ở quota TPS/TPM theo API và số concurrent connection. Khi một domain nghiệp vụ có traffic vượt trội (ví dụ: 1 phòng ban tạo 80% traffic toàn hệ thống), cân nhắc tách Gateway riêng cho domain đó để cô lập quota, tránh một team "ăn hết" quota chung của account.

9. Cost Optimization

9.1 Bảng giá đầy đủ (nguồn: AWS Bedrock AgentCore Pricing)

9.2 Ví dụ tính toán chính thức của AWS (HR Assistant)

• 50 triệu interaction/tháng, 200 tool, tỉ lệ trung bình 1 lượt search + 4 lượt InvokeTool mỗi interaction.
• Tool indexing: 200 tool × $0,02/100 ≈ $0,04/tháng.
• Search API: 50 triệu × $0,025/1.000 = $1.250/tháng.
• InvokeTool: 200 triệu (50tr × 4) × $0,005/1.000 = $1.000/tháng.
• Tổng: ~$2.250,04/tháng — riêng cho Gateway, chưa gồm model inference, Runtime compute, hay VPC egress.

9.3 Đòn bẩy tối ưu chi phí

• Search vs. Invoke là đòn bẩy lớn nhất: vì Search đắt gấp 5 lần, mọi thiết kế giảm được số lần agent phải "hỏi Gateway nên gọi tool nào" (bằng cách cố định workflow, cache kết quả search phía agent trong cùng session, hoặc gọi thẳng tên tool đã biết) đều giảm chi phí trực tiếp và đáng kể hơn so với việc tối ưu InvokeTool.
• Index có chọn lọc: chỉ index tool thực sự cần semantic discovery; tool được gọi theo tên cố định trong code không cần index, giảm phí $0,02/100 tool/tháng ở catalog lớn (VD: 10.000 tool = $2/tháng nếu index toàn bộ — có thể giảm đáng kể nếu chỉ index phần cần).
• Giám sát VPC egress: với agent gọi nhiều tới backend nằm trong VPC khác region hoặc trả payload lớn, $0,006/GB có thể cộng dồn nhanh ở traffic cao — cân nhắc đặt Gateway/target cùng region với backend.
• Tránh gọi trực tiếp Identity API ngoài luồng Runtime/Gateway trừ khi thực sự cần kịch bản tự triển khai — routing auth qua Runtime/Gateway loại bỏ hẳn dòng phí $0,010/1.000 request.
• Mô hình hoá chi phí trước go-live: dùng công thức trên với số liệu traffic dự kiến (số interaction, tỉ lệ search/invoke, số tool) để dự báo hoá đơn Gateway trước khi cam kết kiến trúc, tránh bất ngờ ở Cost Explorer sau khi go-live.

10. Monitoring & Observability

10.1 Nguồn dữ liệu quan sát

• Invocation logging: xuất chi tiết từng lời gọi Gateway (tool nào, target nào, thời gian, kết quả) qua CloudWatch Logs, S3, hoặc Amazon Data Firehose — nền tảng cho cả debug lẫn compliance audit.
• CloudWatch metrics theo gateway/target: invocation count, latency, lỗi theo target — giúp phát hiện target nào đang chậm hoặc lỗi nhiều nhất mà không cần trace toàn hệ thống.
• Log theo từng lớp governance: mỗi lớp (Inbound Authorizer, Request Interceptor, Cedar Policy, Response Interceptor) ghi log độc lập — cho phép trả lời chính xác câu hỏi "request bị chặn ở lớp nào, vì lý do gì" thay vì chỉ thấy lỗi 403 chung chung.
• AgentCore Observability (dịch vụ riêng, tích hợp OpenTelemetry): correlation trace xuyên suốt agent → Gateway → target, đặc biệt quan trọng trong kiến trúc multi-agent nơi một request có thể đi qua nhiều Gateway/Runtime.

10.2 Alarm nên thiết lập

• Alarm trên tỉ lệ lỗi 403 tăng đột biến (dấu hiệu policy/authorizer misconfiguration mới deploy, hoặc tấn công dò quyền).
• Alarm trên latency P99 theo từng target (phát hiện backend suy giảm hiệu năng trước khi ảnh hưởng trải nghiệm agent).
• Alarm khi tiệm cận quota search 25 TPM hoặc quota concurrent connections 1.000 — cảnh báo sớm trước khi throttle xảy ra.
• Alarm trên tỉ lệ lỗi từ một target cụ thể (phát hiện backend đổi API mà không thông báo — nguyên nhân phổ biến khiến agent "im lặng thất bại").

10.3 Common mistake trong observability

• Bật Interceptor/Policy nhưng không log quyết định ALLOW/DENY/transform → khi có sự cố production, không thể tái dựng lại "vì sao request này bị chặn/biến đổi" — nên coi log ở mỗi lớp là bắt buộc, không phải tuỳ chọn.
• Không gắn correlation ID xuyên suốt từ agent qua Gateway tới backend trong kiến trúc multi-agent → debug trở thành gần như bất khả thi khi có nhiều agent gọi chéo nhau qua cùng Gateway.

11. Production Best Practices

Thiết kế trước khi build

• Vẽ trước bản đồ trust boundary: agent nào, team nào, tool nào — quyết định số lượng Gateway cần tách trước khi tạo target đầu tiên.
• Xác định rõ target nào cần MCP aggregation (cần discovery/semantic search) và target nào chỉ cần HTTP direct proxy (latency-sensitive, đã có MCP sẵn) — tránh thiết kế lại giữa chừng.

Vận hành

• Quản lý Gateway/Target/Interceptor bằng IaC (CDK bedrock_agentcore_alpha module, CloudFormation, hoặc Terraform khi provider hỗ trợ) — không thao tác tay trên console cho môi trường production.
• Thiết lập pipeline CI/CD tôn trọng quota "5 concurrent target operations/gateway" — deploy tuần tự hoặc theo batch nhỏ để tránh fail ngẫu nhiên.
• Version hoá OpenAPI spec / Lambda logic bằng cách tạo target mới thay vì sửa target đang chạy, để rollback tức thời khi cần.

Review vòng đời tool

• Coi mô tả tool (tool description) là một phần của API contract cần review trước khi publish — mô tả trùng lặp/mơ hồ là nguyên nhân phổ biến khiến agent liên tục chọn sai tool (tool shadowing).
• Với MCP server target có capability sync, dùng Cedar Policy allowlist để kiểm soát tool mới xuất hiện tự động — tránh tình huống tool mới "lọt" vào production mà không ai review.

Resilience

• Đặt timeout backend ngắn hơn rõ rệt so với 15 phút mặc định của Gateway; timeout dài gây agent bị treo và connection pool cạn kiệt.
• Idempotency ở backend cho mọi tool có side-effect (ghi/xoá dữ liệu) vì retry ở tầng MCP client có thể lặp gọi.

Go-live checklist tối thiểu

• Invocation logging đã bật và đã kiểm tra log thực sự chảy về đích mong muốn.
• Đã mô hình hoá chi phí Search API vs Invocation API ở traffic dự kiến.
• Đã stress-test để xác nhận không chạm quota 25 TPM search hoặc 1.000 concurrent connections ở tải đỉnh.
• Guardrails và Policy đã được test với input độc hại (prompt injection mẫu) trước khi go-live, không chỉ test happy path.

12. So sánh với các giải pháp tương đương

Khi nào chọn gì:

• Chọn AgentCore Gateway khi hệ thống chạy chủ yếu trên AWS, cần governance production-grade (audit, policy, outbound auth phức tạp), và có ≥ 2 agent/team dùng chung tool.
• Chọn tool system gốc của framework (LangChain/CrewAI) khi đang ở giai đoạn prototype, một agent, không cần chia sẻ tool cross-team.
• Chọn Composio hoặc SaaS toolkit tương tự khi mục tiêu chính là tích hợp nhanh các SaaS phổ biến (Slack, Gmail, Notion…) mà không cần gateway hoá toàn bộ MCP server nội bộ.
• Chọn tự host MCP server / API gateway bên thứ ba khi kiến trúc multi-cloud là yêu cầu cứng và không được khoá vào AWS.

13. Use Cases thực tế

Hiện đại hoá API doanh nghiệp. Bọc hệ thống REST/SOAP cũ (core banking, ERP, CRM nội bộ) thành MCP tool qua OpenAPI/Smithy target mà không sửa code nghiệp vụ — rút ngắn thời gian "MCP-hoá" từ hàng tháng xuống còn vài ngày.

Nền tảng tool dùng chung đa agent (Gateway-centric platform). Một tổ chức có hàng trăm API nội bộ và hàng chục team muốn xây agent riêng: thay vì mỗi team tự wrap API, một (hoặc vài) Gateway trung tâm expose toàn bộ tool, mỗi team chỉ cần xin workload identity + quyền qua Cedar Policy.

HR/IT Service Desk Assistant. Gộp nhiều hệ thống nội bộ (ticketing, HRIS, knowledge base) thành một bộ tool duy nhất cho agent hỗ trợ nhân viên, với Interceptor lọc thông tin nhân sự theo quyền của người hỏi.

Tích hợp đối tác B2B trả phí. Kết hợp Outbound OAuth (3LO/2LO) với AgentCore Payments để agent tự thanh toán truy cập API của bên thứ ba theo mô hình pay-per-call.

Grounding bằng Web Search. Gắn Web Search Tool connector vào Gateway để agent có thông tin thời sự (giá cổ phiếu, tin tức, phiên bản phần mềm mới) mà không cần tự tích hợp search API bên thứ ba, tự quản key hay tự parse kết quả.

Multi-tenant SaaS agent. Dùng Request Interceptor để trao đổi JWT của từng tenant lấy credential tenant-scoped, kết hợp Cedar Policy theo tenant/geography, và Response Interceptor để đảm bảo mỗi khách hàng chỉ thấy đúng tool và dữ liệu họ được phép truy cập — mẫu hình được chính AWS minh hoạ cho một "lakehouse data agent" đa người thuê.

14. Checklist dành cho Solution Architect

Thiết kế

• Xác định trust boundary và số lượng Gateway cần tách (không tách theo tiện lợi tổ chức, tách theo ranh giới bảo mật).
• Với mỗi backend: xác định loại target phù hợp — MCP (cần aggregation/semantic search) hay HTTP (cần latency thấp, đã có MCP/A2A sẵn).
• Thiết kế Inbound Auth: OAuth JWT (multi-tenant/nhiều ứng dụng) hay IAM SigV4 (nội bộ AWS thuần).
• Thiết kế Outbound Auth theo từng target: IAM / OAuth 2LO / OAuth 3LO / API Key — xác định target nào cần thay mặt người dùng cụ thể (3LO).

Bảo mật & Governance

• Bật AWS PrivateLink cho toàn bộ traffic nội bộ.
• Áp AgentCore Policy (Cedar) cho mọi tool có khả năng gây tác động nghiệp vụ.
• Cấu hình Request/Response Interceptor cho tenant isolation, redaction, hoặc custom auth nếu kiến trúc multi-tenant.
• Bật Guardrails cho tool nhận input từ nguồn không tin cậy hoặc trả output có khả năng chứa dữ liệu nhạy cảm.
• Viết mô tả tool rõ ràng, có review trước khi publish; version hoá target thay vì sửa tại chỗ.

Hiệu năng & Vận hành

• Đặt timeout backend ngắn hơn 15 phút mặc định của Gateway.
• Xác nhận capacity planning không chạm quota search 25 TPM và quota 1.000 concurrent connections ở tải đỉnh dự kiến; xin tăng quota sớm nếu cần.
• Bật invocation logging + tích hợp Observability (OpenTelemetry/CloudWatch) trước go-live.
• Quản lý toàn bộ cấu hình Gateway bằng IaC; tôn trọng quota 5 concurrent target operations khi thiết kế CI/CD.

Chi phí

• Mô hình hoá chi phí Search API vs Invocation API ở quy mô traffic dự kiến trước khi go-live.
• Xác định danh sách tool thực sự cần index cho semantic search — không index toàn bộ catalog nếu không cần thiết.
• Xác nhận Gateway/target đặt cùng region với backend để tránh phí VPC egress không cần thiết.

Phụ lục — Region support (theo AWS Supported Regions, đối chiếu 31/07/2026)