AWS Bedrock Agent와 Azure AI Agent Service를 운영 관점에서 비교하기

요약

Agentic AI를 실제 업무에 붙이기 시작하면 질문은 금방 바뀝니다. 처음에는 "어떤 모델을 쓸까?"를 고민하지만, 운영 단계에서는 "이 에이전트가 어떤 도구를 호출했고, 어떤 권한으로 실행됐으며, 장애가 났을 때 어디서 추적할 수 있는가?"가 더 중요해집니다.

이번 글에서는 AWS의 Amazon Bedrock Agents 및 Bedrock AgentCore와 Azure의 Azure AI Foundry Agent Service를 운영자 관점에서 비교합니다. 단순 기능 목록보다 런타임, 권한, 도구 연결, 관측성, 배포 흐름을 기준으로 어느 상황에 어떤 접근이 더 자연스러운지 정리합니다.

이런 분들을 위한 글

클라우드 인프라, DevOps, 플랫폼 엔지니어링, AI 서비스 운영을 담당하면서 Agentic AI 도입을 검토하는 분들을 위한 글입니다.

특히 AWS 중심 조직에서 Bedrock 기반 에이전트를 검토하거나, Microsoft 365와 Azure 기반 업무 자동화에서 Azure AI Foundry Agent Service를 살펴보는 실무자에게 도움이 되도록 작성했습니다.

왜 지금 Agent 서비스 비교가 필요한가

Agentic AI는 단순 챗봇과 다릅니다. 사용자의 질문에 답만 하는 것이 아니라, 외부 API를 호출하고, 사내 문서를 검색하고, 코드나 쿼리를 실행하고, 다른 에이전트와 협업할 수 있습니다. 그래서 운영 관점에서는 AI 모델보다 "실행 경계"가 더 중요해집니다.

예를 들어 장애 대응 에이전트를 만든다고 가정해보겠습니다. 이 에이전트가 CloudWatch 경보를 읽고, Kubernetes 상태를 확인하고, 티켓을 생성하고, 필요한 경우 배포 파이프라인을 멈출 수 있다면 더 이상 단순한 검색 도구가 아닙니다. 실제 운영 권한을 가진 자동화 주체가 됩니다.

이때 클라우드 에이전트 플랫폼을 고르는 기준은 다음처럼 바뀝니다.

• 어떤 런타임에서 에이전트를 실행하는가
• 사내 API와 도구를 어떤 방식으로 연결하는가
• 에이전트와 사용자의 권한을 어떻게 분리하는가
• 모델 호출, 도구 호출, 실패 원인을 어디까지 추적할 수 있는가
• 기존 클라우드 운영 체계와 얼마나 자연스럽게 연결되는가

AWS와 Azure 모두 Agentic AI를 위한 관리형 기능을 강화하고 있지만, 두 플랫폼의 출발점과 강점은 조금 다릅니다.

두 플랫폼의 큰 방향

AWS는 Bedrock Agents를 통해 모델, 지식 기반, 액션 그룹, 가드레일을 묶어 멀티스텝 작업을 수행하는 구조를 제공합니다. 여기에 Bedrock AgentCore가 더해지면서 에이전트 런타임, 메모리, 게이트웨이, 관측성 같은 운영 구성 요소가 강조되고 있습니다.

Azure는 Azure AI Foundry Agent Service를 중심으로 관리형 에이전트, Hosted agent, Responses API, Microsoft Entra ID, Application Insights, Microsoft 365 및 Copilot 생태계 연결을 강조합니다. Microsoft Learn 기준으로 Foundry Agent Service는 에이전트 호스팅, 스케일링, ID, 관측성, 엔터프라이즈 보안 기능을 관리형으로 제공하는 플랫폼으로 설명됩니다.

쉽게 말하면 AWS는 AWS 서비스와 운영 계정 안에서 에이전트를 안전하게 실행하고 추적하는 쪽이 자연스럽고, Azure는 Entra ID, Microsoft 365, Azure AI Foundry, Copilot 생태계와 연결된 업무형 에이전트 운영에 강점이 있습니다.

운영 기준별 비교

비교 기준	AWS Bedrock Agents / AgentCore	Azure AI Foundry Agent Service
기본 방향	AWS 기반 에이전트 실행, 도구 호출, 지식 기반, 가드레일, AgentCore 운영 구성 요소	Foundry 기반 관리형 에이전트, Hosted agent, Responses API, Microsoft 생태계 통합
런타임	Bedrock Agents와 AgentCore Runtime을 중심으로 구성	Prompt agent와 Hosted agent 구조. Hosted agent는 문서 기준 public preview
도구 연결	Action group, Lambda, API, Knowledge Bases, AgentCore Gateway 등 AWS 친화적 연결	Built-in tools, custom functions, MCP 서버, Azure Functions MCP webhook, Microsoft 365 계열 도구 연결
권한 모델	IAM role, resource-based policy, service role, AgentCore Identity 중심	Microsoft Entra ID, RBAC, managed identity, On-Behalf-Of 인증 흐름 중심
관측성	Bedrock trace, CloudWatch, AgentCore Observability, ADOT/OpenTelemetry 계측	Agent tracing, metrics, Application Insights, Foundry Observability
적합한 조직	AWS 운영 계정, CloudWatch, IAM, Lambda, EKS, Bedrock을 이미 쓰는 조직	Azure, Entra ID, Microsoft 365, Copilot, Application Insights 중심 조직
주의할 점	IAM 경계, action group 권한, trace 보관과 민감정보 관리가 중요	Entra 권한, OBO 인증, Microsoft 365 데이터 접근 범위, preview 기능 상태 확인이 중요

이 표만 보면 비슷한 기능을 다른 이름으로 제공하는 것처럼 보일 수 있습니다. 하지만 실제 운영에서는 차이가 꽤 큽니다. 에이전트는 결국 조직의 권한 체계, 로그 체계, 배포 체계, 데이터 거버넌스 안으로 들어와야 하기 때문입니다.

AWS 관점: IAM과 CloudWatch 안으로 들어오는 에이전트

AWS에서 Bedrock Agents를 사용할 때 핵심은 "에이전트가 어떤 작업을 할 수 있는가"입니다. Bedrock Agents는 사용자 요청을 해석하고, 필요한 경우 action group을 호출하거나 Knowledge Bases를 조회해 응답을 만듭니다. AWS 문서에서는 agent trace를 통해 오케스트레이션 단계, action group 호출, knowledge base 조회, 실패 이유 등을 확인할 수 있다고 설명합니다.

운영자 입장에서는 이 trace가 중요합니다. AI가 이상한 답을 했는지보다 더 중요한 질문은 "어떤 API를 호출하려 했고, 어떤 입력값으로 실패했는가"이기 때문입니다.

AWS 쪽 설계에서 특히 봐야 할 포인트는 세 가지입니다.

첫째, IAM role을 너무 넓게 주지 않아야 합니다. 에이전트가 Lambda를 통해 운영 API를 호출한다면 Lambda 실행 role, Bedrock agent service role, action group 호출 권한을 나눠 봐야 합니다. 기존 서버리스 보안 점검과 비슷하지만, 에이전트는 사용자의 자연어 입력에 따라 실행 경로가 달라질 수 있다는 점이 다릅니다.

둘째, CloudWatch와 OpenTelemetry 기반 관측성을 처음부터 고려해야 합니다. AgentCore 문서에서는 session 수준의 기본 메트릭을 CloudWatch에서 볼 수 있고, agent code에 ADOT 계측을 추가하면 custom metric, log, span을 수집할 수 있다고 설명합니다. 즉, 운영 환경에서는 "대시보드가 있는가"보다 "우리 에이전트 코드와 도구 호출이 추적 가능한 형태로 계측되어 있는가"가 중요합니다.

셋째, AWS 서비스와의 근접성이 장점입니다. CloudWatch, Lambda, IAM, S3, OpenSearch, EKS, Bedrock Knowledge Bases 같은 자원을 이미 운영 중인 조직이라면 에이전트 권한과 로그를 기존 AWS 운영 체계 안에서 관리하기 쉽습니다. 반대로 Microsoft 365나 사내 SaaS 중심 워크플로우가 많다면 도구 연결과 사용자 위임 인증을 별도로 설계해야 합니다.

Azure 관점: Entra ID와 업무 시스템 통합을 앞세운 에이전트

Azure AI Foundry Agent Service의 핵심은 관리형 에이전트 경험과 Microsoft 생태계 연결입니다. Microsoft Learn 문서에서는 Agent Service가 prompt agent와 Hosted agent를 제공한다고 설명합니다. Prompt agent는 포털, SDK, REST API로 정의하고 Foundry가 실행합니다. Hosted agent는 LangGraph, OpenAI Agents SDK, Microsoft Agent Framework 등으로 작성한 코드를 Foundry에서 실행하는 방식이며, 문서 기준 public preview입니다.

운영자 입장에서 눈에 띄는 부분은 identity와 observability입니다. Foundry Agent Service는 Microsoft Entra identity, RBAC, content filters, virtual network isolation, Application Insights 통합을 주요 구성 요소로 설명합니다. MCP 서버 연결에서도 agent managed identity, project managed identity, OAuth On-Behalf-Of 같은 인증 옵션을 제공합니다.

이 구조는 Microsoft 365, SharePoint, Teams, Copilot, Entra ID를 이미 쓰는 조직에 유리합니다. 예를 들어 업무 문서 검색, 내부 승인 흐름, IT 서비스 요청 자동화, 개발 도구 연결처럼 사용자 권한과 조직 디렉터리 맥락이 중요한 시나리오에서는 Azure 쪽이 자연스럽습니다.

다만 주의할 점도 있습니다. Hosted agent, 일부 tool, multi-agent workflow처럼 preview 상태인 기능은 운영 적용 전에 region, SLA, 제한 사항, 보안 검토 기준을 확인해야 합니다. 또한 On-Behalf-Of 방식은 사용자의 권한을 에이전트 실행에 반영할 수 있다는 장점이 있지만, 잘못 설계하면 "사용자가 볼 수 있는 모든 것을 에이전트도 볼 수 있는" 구조가 될 수 있습니다.

실무에서 선택 기준은 무엇인가

두 서비스를 비교할 때 "어느 쪽이 더 좋은가"라고 묻기보다 "우리 에이전트가 어디에서 실행되고, 무엇을 건드릴 것인가"를 먼저 봐야 합니다.

AWS Bedrock 쪽이 자연스러운 경우는 다음과 같습니다.

• 운영 대상이 AWS 계정, AWS API, CloudWatch, Lambda, EKS, S3, OpenSearch 중심이다.
• IAM 기반 권한 분리와 계정 단위 통제가 이미 잘 잡혀 있다.
• 에이전트가 인프라 상태 조회, 운영 자동화, AWS 리소스 조치에 가깝다.
• Bedrock Knowledge Bases, Guardrails, CloudWatch 관측성과 함께 관리하고 싶다.

Azure AI Foundry 쪽이 자연스러운 경우는 다음과 같습니다.

• Microsoft 365, Teams, SharePoint, Entra ID 기반 업무 환경이 중요하다.
• 사용자 위임 권한, 조직 디렉터리, RBAC, 업무 데이터 접근 범위가 핵심이다.
• Azure AI Foundry, Application Insights, Azure Functions, Copilot 생태계와 연결하고 싶다.
• 다수의 업무형 에이전트를 등록, 배포, 추적, 거버넌스하는 방향을 검토한다.

혼합 환경도 가능합니다. 예를 들어 AWS에서 운영되는 서비스의 장애 데이터를 Azure 기반 업무 에이전트가 요약하거나, Azure 업무 시스템의 요청을 AWS 운영 자동화로 넘길 수 있습니다. 다만 이 경우에는 양쪽 클라우드의 인증, 감사 로그, 네트워크 경계, 데이터 반출 기준이 모두 설계 대상이 됩니다.

운영자가 반드시 확인해야 할 체크리스트

• 에이전트가 호출할 수 있는 도구 목록을 문서화한다.
• 각 도구 호출에 필요한 최소 권한을 IAM role 또는 Entra RBAC 기준으로 나눈다.
• 사용자 권한과 에이전트 실행 권한을 같은 것으로 취급하지 않는다.
• 모델 호출, 도구 호출, 외부 API 호출, 최종 응답을 하나의 trace로 따라갈 수 있는지 확인한다.
• 에이전트가 실패했을 때 재시도, 중단, 사람 승인, 롤백 기준을 정한다.
• preview 기능은 region, SLA, 제한 사항, 변경 가능성을 따로 기록한다.
• 운영 로그에 개인정보, 토큰, 내부 문서 원문이 과도하게 남지 않는지 점검한다.
• 비용은 모델 호출 비용만 보지 말고 tool 호출, 검색, 코드 실행, 런타임, 관측성 저장 비용까지 함께 본다.

흔한 실수

가장 흔한 실수는 에이전트를 "조금 똑똑한 챗봇"으로만 보는 것입니다. 운영 자동화에 연결된 에이전트는 API client, workflow engine, privileged identity의 성격을 함께 가집니다. 따라서 배포 전 보안 검토와 로그 설계가 필요합니다.

두 번째 실수는 trace를 나중에 붙이려는 것입니다. 에이전트 장애는 일반 애플리케이션 오류보다 재현이 어렵습니다. 같은 질문처럼 보여도 모델 응답, 검색 결과, tool 상태, 권한 상태에 따라 실행 경로가 달라질 수 있습니다. 처음부터 trace와 span 단위로 추적할 수 있게 만들어야 합니다.

세 번째 실수는 클라우드 선택을 모델 성능만으로 결정하는 것입니다. 모델 품질은 중요하지만, 운영 환경에서는 identity, tool integration, audit, observability, release process가 장기적인 유지보수 비용을 결정합니다.

정리

AWS Bedrock Agents와 Azure AI Foundry Agent Service는 모두 Agentic AI를 운영 환경에 올리기 위한 관리형 플랫폼입니다. 하지만 AWS는 IAM, CloudWatch, Bedrock, AWS API 중심의 운영 자동화와 잘 맞고, Azure는 Entra ID, Microsoft 365, Foundry, Application Insights 중심의 업무형 에이전트 운영과 잘 맞습니다.

결국 선택 기준은 단순합니다. 에이전트가 주로 AWS 리소스를 조작한다면 AWS 쪽 운영 체계에 붙이는 편이 자연스럽습니다. 반대로 에이전트가 조직 사용자, 업무 문서, Microsoft 365 워크플로우와 깊게 연결된다면 Azure AI Foundry 쪽을 우선 검토할 만합니다.

중요한 것은 에이전트 플랫폼을 "AI 기능"으로만 보지 않는 것입니다. 운영자에게 Agentic AI는 새로운 실행 주체입니다. 그래서 모델보다 먼저 권한, 추적, 감사, 실패 대응 기준을 설계해야 합니다.

참고자료

• AWS Documentation: Automate tasks in your application using AI agents
  https://docs.aws.amazon.com/bedrock/latest/userguide/agents.html
• AWS Documentation: Track agent's step-by-step reasoning process using trace
  https://docs.aws.amazon.com/bedrock/latest/userguide/trace-events.html
• AWS Documentation: Understand observability for agentic resources in AgentCore
  https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/observability-telemetry.html
• AWS Machine Learning Blog: AgentOps with Amazon Bedrock AgentCore
  https://aws.amazon.com/blogs/machine-learning/agentops-operationalize-agentic-ai-at-scale-with-amazon-bedrock-agentcore/
• Microsoft Learn: What is Microsoft Foundry Agent Service?
  https://learn.microsoft.com/azure/foundry/agents/overview
• Microsoft Azure Blog: Introducing Microsoft Agent Framework
  https://azure.microsoft.com/en-us/blog/introducing-microsoft-agent-framework/
• Microsoft Official Blog: Microsoft Build 2025 and the age of AI agents
  https://blogs.microsoft.com/blog/2025/05/19/microsoft-build-2025-the-age-of-ai-agents-and-building-the-open-agentic-web/