# AgentCore: AWS lo phần nào, FDE còn phải kiểm tra gì

> Demo agent thì ai cũng làm được. Cái khó là được security team của khách cho lên production. AgentCore giải quyết đúng chỗ đó, nhưng vẫn còn vài khoảng trống bạn phải kiểm tra trước khi hứa với khách.

Bản gốc: https://fdetimes.net/vi/cong-cu/amazon-bedrock-agentcore-fde-trien-khai-agent-tren-aws-cua-khach/

AWS công bố bản preview của Amazon Bedrock AgentCore ngày 16/7/2025. Đến 13/10/2025, sản phẩm chính thức GA. Trang sản phẩm giới thiệu nó bằng một khẩu hiệu ngắn: mọi framework, mọi model, bảo mật ở quy mô lớn.

Với FDE, khẩu hiệu đó không quan trọng bằng những câu hỏi bạn sẽ nghe ở buổi họp thứ ba với khách. Đến lúc ấy prompt đã ổn và demo đã chạy được. Người ngồi đối diện giờ là security team, và họ hỏi ba câu: agent chạy ở đâu, ai được phép gọi nó, và khi có sự cố thì xem log ở đâu.

AgentCore trả lời ba câu đó bằng ba thành phần: Runtime, Identity và Observability. Nếu nắm rõ từng phần làm được gì và chưa làm được gì, bạn sẽ đi từ pilot lên production trên AWS của khách nhanh hơn nhiều.

**Điểm mấu chốt:** Agent chỉ thật sự lên production khi security team của khách gật đầu, chứ không phải khi demo chạy.

## Nó làm gì, và không hứa gì?

Tài liệu của AWS mô tả AgentCore là một nền tảng dạng module để build, deploy và vận hành agent. Nó dùng được với bất kỳ framework và foundation model nào, và bạn không phải tự quản lý hạ tầng.

Mission Cloud, một đối tác bán dịch vụ triển khai AgentCore, cho biết nền tảng gồm bảy dịch vụ managed. Đối tác này có lợi ích thương mại khi nói vậy, nên con số bảy chỉ nên hiểu là cách họ đếm.

Bài này chọn ra ba dịch vụ gắn với ba câu hỏi của security team, chứ không đi hết sản phẩm. Hai capability khác là Gateway và Agent Registry chỉ được nhắc tới ở phần audit bên dưới.

Runtime không bắt bạn bỏ code đang có. Bạn viết agent bằng framework nào cũng được, và agent có thể trao đổi với tool hoặc agent khác qua MCP (Model Context Protocol) hay A2A (Agent to Agent). Vì thế, nếu khách đã có sẵn một agent, việc đầu tiên là chuyển nơi nó chạy, chứ không phải viết lại.

## Một ví dụ: chọn đúng loại compute

Thử hình dung bạn làm cho một công ty logistics và cần đưa hai agent lên production. Agent thứ nhất là trợ lý cho nhân viên kho, mỗi phiên hỏi đáp chỉ vài phút. Agent thứ hai đối soát hoá đơn qua đêm, mỗi lần chạy mất khoảng 10 tiếng.

Runtime có hai loại compute. Với microVM, mỗi session người dùng chạy trong một microVM riêng, có CPU, memory và filesystem tách biệt. Khi session kết thúc, microVM bị huỷ rồi làm sạch. Hai nhân viên kho vì thế không bao giờ dùng chung môi trường, nên agent thứ nhất hợp với loại này.

Agent thứ hai thì khác. Session trên microVM kéo dài tối đa 8 giờ, nên job 10 tiếng sẽ bị cắt ngang ở giờ thứ tám. Instances cho phép session kéo dài tới 14 ngày và chạy trên hạ tầng EC2 do AWS quản lý, nằm ngay trong account của khách. Bộ phận compliance thường muốn nghe đúng điều này.

Vì vậy, hãy đo thời lượng session thật trước khi chọn compute, đừng đoán. Một con số đo sai ở bước discovery có thể buộc bạn làm lại cả kiến trúc.

## Identity: không bắt khách đổi IdP

Phần xác thực tích hợp sẵn trong Runtime do AgentCore Identity đảm nhận. Mỗi agent được gán một danh tính riêng, và hệ thống tích hợp với identity provider mà doanh nghiệp đang dùng, như Okta, Microsoft Entra ID hay Amazon Cognito. Theo AWS, khách không phải chuyển người dùng sang hệ thống mới hay xây lại luồng đăng nhập.

Đây là điểm nên đưa lên đầu khi trình bày với khách. Trong ví dụ logistics, nhân viên kho đăng nhập bằng tài khoản Okta họ vẫn dùng hằng ngày, còn agent đối soát có danh tính riêng, tách khỏi danh tính của con người.

## Observability có sẵn, nhưng audit còn thiếu

AgentCore xuất telemetry theo định dạng tương thích OpenTelemetry, nên dữ liệu đổ được vào stack monitoring khách đang chạy. Metrics, spans và logs được lưu trong Amazon CloudWatch thuộc account của khách. Có sẵn dashboard cho số session, độ trễ, lượng token tiêu thụ và lỗi.

Phần cần cảnh giác là audit. Tài liệu của AWS ghi rõ CloudTrail hiện mới phủ một số capability, cụ thể là Gateway và Agent Registry. Một ngân hàng hay bệnh viện có thể yêu cầu mọi lời gọi API đều để lại dấu vết. Khi đó, bạn phải nêu khoảng trống này ngay trong buổi họp, đừng để khách tự phát hiện sau go-live.

Trước buổi review bảo mật, hãy lập một bảng: một cột là yêu cầu audit của khách, cột kia là những gì CloudTrail đang ghi được. Mang bảng đó vào phòng họp sẽ khiến khách tin bạn hơn nhiều so với một câu hứa "AWS lo hết".

## Ba lỗi dễ mắc khi đưa agent lên AgentCore

Lỗi đầu tiên là đoán thời lượng session. Một job bạn nghĩ chỉ chạy 6 tiếng nhưng thực tế kéo sang 9 tiếng sẽ vượt giới hạn 8 giờ của microVM, và lỗi đó thường chỉ lộ ra khi dữ liệu thật của khách đổ vào.

Lỗi thứ hai là hứa audit đầy đủ chỉ vì đã có CloudWatch. Telemetry giúp bạn debug, còn CloudTrail mới là thứ compliance hỏi tới, và nó chưa phủ hết các capability.

Lỗi thứ ba là viết lại agent của khách cho "hợp" với nền tảng. Runtime nhận mọi framework và model, nên phần việc đáng tốn công là nơi chạy, danh tính và log, chứ không phải logic agent khách đã kiểm chứng.

## Học gì trước, và kể lại thế nào trong CV?

Nếu mới bắt đầu, hãy học Runtime trước: hai loại compute, giới hạn session và cách đưa một agent viết bằng framework quen thuộc lên đó. Sau đó là Identity với một IdP thật, rồi đến đọc trace trong CloudWatch. Nên học MCP và A2A song song, vì đây là những protocol không gắn riêng với AWS.

Trong CV, dòng "đã dùng AgentCore" gần như không nói lên gì. Hãy kể ba quyết định. Bạn đã chọn compute dựa trên thời lượng session đo được. Bạn đã nối agent vào IdP của khách và tách danh tính của agent khỏi danh tính của người dùng.

Và bạn đã chỉ ra khoảng trống audit trước khi go-live. Nếu chưa có khách thật, hãy dựng lại ví dụ hai agent ở trên trong một account thử nghiệm và viết README giải thích từng lựa chọn.

Công cụ sẽ thay đổi, nhưng ba câu hỏi vẫn giữ nguyên giá trị: agent chạy ở đâu, ai được gọi nó, và mọi thứ có được ghi lại không. FDE trả lời trôi chảy được cả ba sẽ là người được mời quay lại ở dự án tiếp theo.

**Thử ngay tuần này:**

- Chọn một agent bạn đang làm, đo xem session dài nhất kéo bao lâu, rồi so với giới hạn 8 giờ của microVM và 14 ngày của Instances
- Hỏi khách (hoặc team platform ở công ty bạn) đang dùng IdP nào và stack monitoring nào, rồi phác thảo cách nối AgentCore Identity và telemetry OpenTelemetry vào đó
- Đọc phần CloudTrail trong tài liệu observability của AgentCore và ghi lại những capability nào chưa có audit log

## Nguồn

- [Amazon Bedrock AgentCore - AWS](https://aws.amazon.com/bedrock/agentcore/)

- [Introducing Amazon Bedrock AgentCore: Securely deploy and operate AI agents at any scale (preview)](https://aws.amazon.com/blogs/aws/introducing-amazon-bedrock-agentcore-securely-deploy-and-operate-ai-agents-at-any-scale/)

- [What is Amazon Bedrock AgentCore?](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/what-is-bedrock-agentcore.html)

- [Host agent or tools with Amazon Bedrock AgentCore Runtime](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/agents-tools-runtime.html)

- [Observability, audit logging, and tracing for your agents](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/observability.html)

- [What is Amazon Bedrock AgentCore? AI Agent Platform for Enterprise Deployment](https://www.missioncloud.com/blog/what-is-amazon-bedrock-agentcore-ai-agent-platform-for-enterprise-deployment)