How Eon built multi-cloud investigation with an MCP Gateway on Amazon Bedrock AgentCore

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Eon은 Amazon Bedrock AgentCore 기반 단일 MCP Gateway로 AWS·GCP·Azure의 조사 도구 접근을 통합하고, 사람과 에이전트의 권한을 분리하면서 신규 엔지니어의 도구 접근 준비 시간을 약 2일에서 약 2분으로 줄였다.

📌 핵심 요약

• Eon은 여러 클라우드와 수십 개 운영 시스템을 조사하는 과정에서 도구별 자격 증명, 개발자별 로컬 MCP 서버, 분산된 접근 권한, AWS 계정 간 네트워크 구성 부담을 해결해야 했다.
• Eon은 자체 인증을 갖춘 중앙 프록시와 Amazon Bedrock AgentCore Gateway라는 두 대안을 비교한 뒤, 자격 증명 통합뿐 아니라 신원 분리·계정 간 연결·정책 집행을 관리형 기능으로 제공하는 AgentCore를 선택했다.
• AgentCore Gateway·Runtime·Identity·Policy를 결합해 수십 개 MCP 대상의 수백 개 도구를 단일 URL로 제공한다. 개발자는 기업 SSO와 Amazon Cognito로 인증하고, Claude on Amazon Bedrock 기반 자율 SRE 에이전트는 별도 신원으로 같은 게이트웨이에 접근한다.
• Cedar 정책은 ENFORCE 모드에서 모든 tools/call 요청을 검사한다. 승인된 그룹만 읽기 접근을 얻으며, 쓰기는 명시적으로 허용된 특정 에이전트의 PR·티켓 댓글 같은 영향이 작은 협업 작업으로 제한된다. 프로덕션 접근은 읽기 전용이고, 사람의 접근에는 적시 승인과 감사가 적용된다.
• AWS 계정 간 Runtime 연결은 IAM 역할 위임으로 구성해 VPC 피어링·계정별 PrivateLink·보안 그룹 조율 부담을 없앴다. 개발자 100명 이상과 약 10,000개 세션 운영에서는 Cedar 정책 크기 한도 문제가 나타났고, 도구가 많은 대상에 DYNAMIC 목록 모드를 적용했다. 이 모드는 스키마 사전 색인에 따른 정책 크기 증가를 없애지만 의미 기반 도구 검색을 지원하지 않으며, 제공된 원문은 혼합 모드 구성 설명 도중 끝난다.

🧩 주요 포인트

1. 단일 MCP URL과 관리형 AgentCore 구성 → 도구별 인증·로컬 서버 관리 부담을 중앙화하고 사람과 에이전트의 조사 경로를 통합.
2. Cedar의 도구별 권한 검사와 IAM 역할 위임 → 공통 게이트웨이에서도 신원별 최소 권한과 AWS 계정 경계를 유지.
3. DYNAMIC 목록 모드의 정책 크기 절감과 의미 기반 도구 검색 미지원 → 대상별 도구 규모와 필요한 검색·인증 기능을 함께 고려할 필요.

🧠 상세 정리

1. 멀티클라우드 조사와 Eon의 배경

이 글은 Eon의 Roei Zavida와 공동 작성한 기고문으로, AI 제품을 만드는 독립 소프트웨어 공급업체가 여러 클라우드의 운영 도구를 사람과 에이전트에 연결할 때 겪는 복잡성을 다룬다. AWS·GCP·Azure마다 인증 방식, 네트워크 경계, 접근 정책이 달라 연결 대상이 늘수록 통합 부담도 커진다는 것이 출발점이다. 전직 AWS 엔지니어들이 설립한 Eon은 AWS에서 SaaS 인프라를 운영하며, 세 클라우드의 자원을 발견·분류하고 지속적인 중복 제거 백업을 제공한다. 저장 비용을 최대 50% 줄인다는 수치는 Eon의 내부 측정 결과이며, 플랫폼은 랜섬웨어와 비정상 에이전트의 손상 탐지 및 AI 에이전트를 위한 실시간 근거 맥락 제공도 지원한다고 설명한다. 이러한 기능은 단일 읽기 전용 IAM 역할을 기반으로 동작하며 데이터를 Apache Parquet와 Apache Iceberg 형식으로 저장한다.

2. 분산된 자격 증명과 로컬 MCP 운영의 한계

Eon 엔지니어는 프로덕션 장애 하나를 조사할 때도 여러 운영 시스템을 함께 확인해야 했다. 예를 들어 Kubernetes pod가 중단되면 같은 조사 세션에서 컨테이너 로그, Grafana 지표, 배포와 관련된 GitHub PR, 클라우드 제공자의 상태를 살펴봐야 한다. 도구가 추가될 때마다 자격 증명을 구성·보호·교체해야 했고, 개발자가 각자 여러 로컬 MCP 서버를 실행하는 방식은 표준화와 최신 상태 유지에 부담을 줬다. 시스템별 역할 권한은 있었지만 사람이나 에이전트가 어떤 도구를 호출할지 결정하는 단일 통제 지점은 없었으며, 여러 AWS 계정에 서버를 배치하려면 계정별 네트워크 연결 작업도 필요했다. 신규 엔지니어는 첫 장애 조사 전에 약 2일을 설정에 썼고, Claude on Amazon Bedrock으로 실행되는 자율 SRE 에이전트에도 사람과 같은 조사 도구를 서로 다른 권한으로 제공해야 했다.

3. 두 대안 비교와 AgentCore 선택

Eon이 검토한 대안은 자체 인증을 갖춘 중앙 프록시와 Amazon Bedrock AgentCore Gateway 두 가지였다. 중앙 프록시는 여러 도구를 모아 자격 증명을 통합할 수 있었지만 원격 MCP만 지원했고, 각 하네스에는 대상들을 포함한 자체 프록시 구성이 필요했다. 또한 도구 프로토콜 변환, 세션 관리, 인가 로직을 직접 구현하고 유지해야 하므로 개발과 운영 부담이 상당하다고 평가했다. AgentCore 쪽은 내장 신원 연동, Cedar 기반 인가 정책, 로컬 MCP 서버를 원격 HTTP 엔드포인트로 제공하는 Runtime 호스팅을 결합해 요구사항을 충족하는 대안이었다. Eon은 특히 신원 분리, AWS 계정 간 연결, 정책 집행을 자체 코드 대신 관리형 기능으로 확보할 수 있다는 이유로 두 번째 대안을 선택했다.

4. 단일 게이트웨이로 통합한 접근 구조

Eon은 AgentCore Gateway, Policy, Runtime, Identity를 함께 배포해 클라이언트부터 실제 도구 실행까지 연결했다. Claude Code·Cursor·OpenAI Codex를 사용하는 개발자는 단일 MCP URL에 접속하며, 자율 SRE 에이전트도 별도 신원으로 같은 게이트웨이를 사용한다. 사람의 인증에서는 Amazon API Gateway가 OAuth 진입점이자 MCP 세션 프록시 역할을 하고, 기업 SSO가 Amazon Cognito와 연동되어 게이트웨이에 전달할 JWT를 발급한다. 에이전트는 Cognito의 client_credentials 방식으로 게이트웨이에 직접 인증하며, 게이트웨이는 여러 AWS 계정의 Runtime에서 제공되는 수십 개 MCP 대상과 수백 개 도구를 연결한다. Runtime은 로컬 stdio 기반 MCP 서버를 Streamable HTTP 엔드포인트로 바꾸고, 개발자는 로컬 서버나 도구별 토큰을 따로 설정하지 않은 채 통합된 tools/list 응답으로 도구를 발견한다.

5. Cedar로 집행하는 사람과 에이전트의 권한 경계

보안 설계의 핵심은 게이트웨이에서 Cedar 정책으로 읽기와 쓰기의 경계를 집행하는 것이다. 모든 tools/call 요청은 대상에 전달되기 전에 ENFORCE 모드의 정책 평가를 거치며, 인증되었다는 이유만으로 모든 사용자가 읽기 권한을 얻지는 않는다. 승인된 그룹의 사람에게 읽기 접근을 제공하고 사람의 변경 도구 호출은 금지하며, 쓰기는 특정 에이전트 신원에 명시적으로 허용한 GitHub PR·티켓 댓글 같은 영향이 작은 협업 작업으로 제한한다. SSO 그룹은 직무 역할에 대응하고 엔지니어는 기본적으로 개발·테스트 환경에 접근하지만, 프로덕션 접근은 읽기 전용으로 적시 승인 절차와 감사를 따른다. 정책은 GitHub PR과 검토 의견을 통해 코드로 관리하므로 권한 변경의 버전과 감사 이력을 남기며, 에이전트 역시 자신의 신원에 허용된 도구만 호출한다.

6. IAM을 이용한 계정 간 연결과 대상 연결 방식

Eon은 환경이나 서비스 경계에 따라 Runtime을 여러 AWS 계정에 나누어 운영한다. AgentCore Gateway는 IAM의 계정 간 역할 위임으로 각 Runtime에 접근하며, 대상 계정의 Runtime은 표준 IAM 신뢰 정책으로 게이트웨이 실행 역할을 신뢰한다. 이 구성으로 계정 사이의 VPC 피어링과 라우팅 테이블 관리, 계정별 PrivateLink 엔드포인트 비용, 보안 그룹 조율을 제거했다고 설명한다. 신규 계정 연결도 며칠이 걸리던 설정 대신 몇 분 안에 배포할 수 있는 IAM 신뢰 정책 하나로 대체했다. 대상 연결은 주로 Grafana 쿼리나 Kubernetes API 호출처럼 IAM 자격 증명을 통한 클라우드 접근이 필요한 Runtime + IAM 방식을 쓰고, Linear처럼 도구 목록을 줄이거나 게이트웨이가 공급할 수 없는 자격 증명을 변환해야 하는 경우에만 원격 MCP를 Runtime으로 감싼다.

7. 인증에서 여러 도구의 결과 연결까지

프로덕션 장애 조사 예시에서는 개발자가 IDE에서 게이트웨이 URL에 연결하고 기업 SSO를 통한 OAuth 인증을 완료하면, Cognito가 사용자 신원과 그룹 정보를 담은 JWT를 발급한다. 게이트웨이는 연결된 수십 개 대상의 tools/list를 모아 수백 개 도구의 통합 목록을 IDE에 반환한다. 개발자가 최근 한 시간 동안 payments 서비스의 오류율 급증을 보여 달라고 요청하면 IDE의 에이전트는 Grafana 쿼리 도구를 선택하고, 게이트웨이는 해당 그룹의 호출 권한을 Cedar로 확인한다. 요청이 허용되면 다른 AWS 계정의 Runtime으로 전달되며, Runtime은 AgentCore Identity 저장소에 보관된 서비스 자격 증명으로 Grafana에 인증해 쿼리를 실행한다. 이후 에이전트는 서로 다른 Runtime을 통해 Kubernetes 배포 상태와 관련 GitHub PR을 확인하므로, 개발자는 도구를 전환하거나 다시 인증하지 않고 연결된 조사 결과를 볼 수 있다.

8. 운영 규모 확대와 도구 목록 모드의 절충

Eon은 단일 게이트웨이 도입으로 신규 엔지니어가 전체 조사 도구에 접근하기까지 걸리는 시간을 약 2일에서 약 2분으로 줄였다고 보고한다. 개발자 100명 이상과 약 10,000개 세션으로 운영 규모가 커지자, 게이트웨이가 사전 색인하는 각 도구 스키마가 Cedar 정책 크기에 기여해 정책이 크기 한도에 가까워지는 문제가 나타났다. Eon은 도구 수가 많은 대상에 DYNAMIC 목록 모드를 적용해, 스키마를 미리 색인하는 대신 요청 시 MCP 서버로 tools/list를 전달하도록 바꿨으며 이 방식은 정책 크기에 0바이트를 추가한다고 설명한다. 다만 DYNAMIC 대상에서는 의미 기반 도구 검색을 사용할 수 없다는 절충이 있다. 원문은 사용자별 OAuth가 필요한 대상에 DEFAULT 모드를 사용하는 혼합 구성을 설명하기 시작한 지점에서 잘려 있어, 나머지 선택 기준이나 후속 운영 교훈은 확인할 수 없다.

🧾 핵심 주장 / 시사점

• 접근 경로를 하나로 합쳐도 권한까지 동일하게 만들 필요는 없다. Eon은 공통 게이트웨이에 신원별 Cedar 정책을 결합해 사람과 자율 SRE 에이전트의 도구 범위를 구분했다.
• 온보딩 시간 단축은 단일 URL 제공과 함께 도구별 자격 증명 및 로컬 MCP 서버 설정을 중앙 구성으로 옮긴 결과로 제시된다.
• 도구 수가 늘면 연결뿐 아니라 스키마 색인이 정책 크기에 미치는 영향도 운영 제약이 된다. DYNAMIC 모드는 이 부담을 줄이지만 의미 기반 검색 기능과의 절충을 요구한다.

✅ 액션 아이템

• Amazon Bedrock AgentCore 기반 단일 MCP Gateway의 적용 가능성을 자격 증명 통합, 신원 분리, 계정 간 연결 요건에 비춰 평가한다.
• Cedar 정책으로 모든 tools/call 요청을 검사하고, 프로덕션 읽기 전용과 특정 에이전트에만 허용되는 쓰기 범위를 권한 설정에 반영한다.
• 도구가 많은 대상의 DYNAMIC 목록 모드 적용 여부는 Cedar 정책 크기 절감 효과와 의미 기반 도구 검색 미지원 제약을 함께 고려해 정한다.

❓ 열린 질문

• Eon이 약 2일에서 약 2분으로 줄인 신규 엔지니어의 도구 접근 준비 시간은 MCP 대상과 개발자 수가 더 늘어나도 유지되는가?
• Cedar 정책의 ENFORCE 모드에서 승인된 그룹과 특정 에이전트의 권한이 바뀔 때 tools/call의 최소 권한을 어떻게 유지하는가?
• DYNAMIC 목록 모드의 정책 크기 절감과 의미 기반 도구 검색 미지원 사이에서 대상별 도구 규모와 검색 필요를 어떤 기준으로 판단하는가?