Automating AWS Agent Registry updates with push-based architecture

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

AWS Agent Registry의 MCP 서버 메타데이터를 최신으로 유지하기 위해 AWS CloudTrail, Amazon EventBridge, AWS Lambda와 AgentCore Identity를 연결하고, 런타임 변경 이벤트를 계기로 기존 레코드의 도구·스키마를 동기화하는 아키텍처를 제시한다.

📌 핵심 요약

• MCP 서버의 도구나 스키마가 변경되어도 AWS Agent Registry가 갱신되지 않으면 새 기능을 발견하지 못하거나 오래된 스키마로 호출해 예상하지 못한 실행 결과와 드러나지 않는 워크플로 이탈이 발생할 수 있다.
• AWS CloudTrail이 UpdateAgentRuntime 호출을 관리 이벤트로 기록하면 Amazon EventBridge가 AWS Lambda를 호출한다. 다중 계정에서는 MCP 서버가 있는 Account B에서 레지스트리가 있는 Account A로 이벤트를 전달하며, CloudTrail 전달 지연은 약 5~15분이다.
• AWS Lambda는 이벤트의 런타임 ARN으로 MCP 호출 URL을 구성하고, AgentCore Identity에서 워크로드 토큰과 OAuth bearer token을 차례로 얻은 뒤 initialize와 tools/list를 호출해 현재 도구·스키마를 조회한다.
• AWS Lambda는 조회한 도구·스키마를 기존 레지스트리 정보와 비교하고 변경된 경우 갱신한다. 이 샘플은 초기 온보딩에서 사전 등록한 기존 레코드만 갱신하며, 새 레코드를 생성하지 않고 APPROVED 레코드에서 일치 항목을 찾는다.
• 단일 계정에서는 교차 계정 전달을 생략할 수 있다. 다중 계정에서는 계정별 자격 증명 공급자를 사용해 하나의 AWS Lambda가 여러 계정의 MCP 서버에 인증하며, OAuth 클라이언트 비밀을 Lambda 환경 변수에 저장할 필요가 없다.

🧩 주요 포인트

1. UpdateAgentRuntime을 변경 신호로 사용 → 레지스트리 갱신을 배포 흐름에 연결하지만, 약 5~15분의 CloudTrail 전달 지연을 고려해야 한다.
2. 런타임 ARN을 호출 대상 구성과 레코드 검색에 활용 → 여러 계정의 MCP 서버를 중앙에서 처리할 수 있으며, 사전 등록과 APPROVED 상태가 동기화의 전제가 된다.
3. AgentCore Identity의 토큰 교환과 계정별 자격 증명 공급자 사용 → 하나의 AWS Lambda로 여러 계정에 인증하면서 OAuth 클라이언트 비밀의 직접 보관을 줄인다.

🧠 상세 정리

1. 메타데이터 노후화가 레지스트리 신뢰를 떨어뜨리는 이유

Amazon Bedrock AgentCore의 기능인 AWS Agent Registry에 등록된 MCP 서버가 새 도구를 추가하거나 스키마를 바꾸면, 해당 레지스트리 레코드도 함께 갱신되어야 한다. 원문은 월요일에 새 도구를 배포했는데 카탈로그에는 지난주의 스키마가 남아 있는 상황을 예로 들며, 카탈로그의 가치는 정보의 최신성에 달려 있다고 설명한다. 갱신을 놓치면 사용자는 새 기능 자체를 발견하지 못하거나, 오래된 스키마로 도구를 호출해 예상하지 못한 실행 동작과 드러나지 않는 워크플로 이탈을 겪을 수 있다. 이런 문제가 여러 팀에 누적되면 부정확한 정보에 대한 의존이 생기고, 조직은 하드코딩된 엔드포인트나 비공식 지식 공유, 오래된 문서에 다시 의존하게 된다는 것이 자동화의 출발점이다.

2. 단일 계정과 다중 계정을 지원하는 중앙 동기화 구조

제안된 아키텍처는 AWS CloudTrail, Amazon EventBridge, AWS Lambda를 연결해 런타임 변경을 감지하고 AWS Agent Registry에 반영하는 이벤트 기반 파이프라인이다. 다중 계정 예제에서 Account A는 레지스트리, EventBridge 규칙, 동기화 Lambda와 CloudTrail 로그를 소유하고, Account B는 MCP 서버 런타임과 인증에 사용하는 Amazon Cognito OAuth 공급자를 호스팅한다. Account B에서 발생한 변경 이벤트는 Account A로 전달되며, 중앙의 Lambda가 해당 MCP 서버를 조회하고 대응하는 레지스트리 레코드를 갱신한다. 예제는 두 계정을 사용하지만 Account A를 중앙 레지스트리 계정으로 두고 여러 Account B 형태의 계정을 연결할 수 있으며, 모든 구성 요소가 한 계정에 있으면 교차 계정 전달 설정을 생략한다.

3. 변경 감지부터 기존 레코드 갱신까지의 처리 흐름

개발자가 Account B의 MCP 서버를 갱신해 UpdateAgentRuntime API가 호출되면 CloudTrail이 이를 포착하고, EventBridge가 이벤트를 Account A의 중앙 이벤트 버스로 전달한다. 동기화 Lambda는 이벤트에서 런타임 ARN을 추출해 호출 URL을 구성한 다음, AgentCore Identity를 통해 OAuth bearer token을 얻어 서버에 인증한다. 이어 initialize와 tools/list를 호출해 최신 도구 정보를 가져오고, ARN으로 대응하는 레지스트리 레코드를 찾아 차이를 평가한 뒤 스키마가 달라졌으면 갱신한다. 이 흐름은 초기 온보딩 과정에서 MCP 서버 레코드가 이미 등록되어 있다는 전제에 의존하며, 샘플 Lambda는 새 레코드를 만들지 않고 기존 레코드만 수정한다. 각 서버의 UpdateAgentRuntime 이벤트는 독립적으로 처리되며, Lambda는 한 번에 하나의 이벤트를 다루고 EventBridge 호출 모델에 따라 확장된다.

4. CloudTrail 이벤트 포착과 EventBridge 라우팅

MCP 서버를 배포하거나 갱신할 때 AgentCore CLI의 agentcore deploy 또는 직접적인 API 호출을 통해 UpdateAgentRuntime이 실행된다. CloudTrail은 이를 Account B의 관리 이벤트로 기록하며, 원문이 제시한 전달 지연은 약 5~15분이므로 변경 직후 레지스트리가 즉시 갱신되는 흐름으로 해석해서는 안 된다. 교차 계정 구성에서는 Account B의 EventBridge 규칙이 조건에 맞는 이벤트를 Account A의 기본 이벤트 버스로 전달하고, Account A의 규칙 대상이 전체 CloudTrail 이벤트 JSON을 입력으로 Lambda를 호출한다. 제시된 이벤트 패턴은 source가 aws.bedrock-agentcore이고 detail-type이 API Call via AWS CloudTrail이며, detail의 eventName이 UpdateAgentRuntime인 이벤트를 선택한다. 단일 계정 구성에서는 같은 계정의 EventBridge 버스 안에서 이 전달이 이루어진다.

5. 런타임 ARN으로 MCP 호출 URL 구성

Lambda는 이벤트의 detail.responseElements.agentRuntimeArn에서 런타임 ARN을 읽어 어떤 MCP 서버를 조회할지 결정한다. 코드 예제는 ARN의 콜론 구분 요소 중 다섯 번째 값에서 호스팅 계정 ID를 추출하고, 이벤트의 awsRegion을 사용하되 값이 없으면 us-west-2를 기본값으로 사용한다. 이어 ARN의 콜론과 슬래시를 각각 URL 인코딩하고, 해당 리전의 bedrock-agentcore 엔드포인트 아래 runtimes 경로와 invocations 경로를 조합하며 qualifier=DEFAULT를 붙인다. 이 방식은 이벤트에 포함된 런타임 식별자로 호출 대상을 동적으로 구성해 계정이 다른 서버도 같은 처리 흐름으로 조회하게 한다. ARN이 없으면 예제 함수는 URL과 계정 ID를 모두 None으로 반환하지만, 이후 상위 호출부에서 이를 어떻게 처리하는지는 제공된 본문에 나타나지 않는다.

6. AgentCore Identity를 통한 두 단계 인증

인증은 Lambda의 실행 신원을 임시 워크로드 토큰으로 교환한 뒤, 그 토큰을 사용해 자격 증명 공급자에서 범위가 지정된 OAuth bearer token을 받는 두 단계로 이루어진다. 예제는 get_workload_access_token으로 워크로드 접근 토큰을 얻고, 이를 get_resource_oauth2_token에 전달하면서 oauth2Flow를 M2M으로 지정한다. 공급자와 인증 범위는 CREDENTIAL_PROVIDER_{ACCT_ID} 및 CREDENTIAL_SCOPE_{ACCT_ID} 같은 계정별 환경 변수에서 우선 찾고, 없으면 공통 설정으로 대체하며 WORKLOAD_IDENTITY_NAME도 필요하다. Cognito와 OAuth 설정은 AgentCore Identity의 자격 증명 공급자에 안전하게 저장되므로 Lambda 환경 변수에 클라이언트 비밀을 둘 필요가 없다는 설명이다. 계정별 공급자를 선택하는 구조를 통해 하나의 Lambda가 여러 계정의 MCP 서버에 인증할 수 있다.

7. MCP 세션 초기화와 최신 도구 조회

Lambda는 표준 MCP streamable-HTTP 방식에 따라 먼저 initialize 요청으로 세션을 초기화하고, 이어 tools/list를 호출해 현재 노출된 도구와 스키마를 가져온다. 예제의 initialize 요청은 protocolVersion을 2025-03-26으로 지정하고, 클라이언트 이름을 tool-sync-lambda, 버전을 1.0.0으로 전달한다. 서버가 세션을 사용하는 경우 초기화 응답의 Mcp-Session-Id를 다음 tools/list 요청 헤더에 포함하므로, 초기화와 조회가 같은 세션으로 연결된다. 코드에는 호출 URL이 https://로 시작하는지 검증하는 조건과 각 POST 요청의 30초 제한 시간이 있으며, HTTP 오류를 확인한 뒤 응답 본문을 파싱한다. 이 단계에서 얻은 현재 도구 정보가 레지스트리에 저장된 정보와의 차이를 판단하는 입력이 된다.

8. 승인된 레코드 검색과 제공된 본문의 범위

최신 도구 정보를 조회한 뒤 Lambda는 중앙 Agent Registry의 APPROVED 레코드 중 해당 MCP 서버와 대응하는 항목을 찾는다. 원문은 레코드 생성 시 mcpServer.data에 포함한 런타임 ARN을 검색에 사용한다고 설명하며, 함수 설명에는 디코딩된 ARN, URL 인코딩된 ARN, 전체 MCP URL이라는 세 가지 일치 전략이 제시된다. 검색 함수는 일치 항목이 있으면 레코드 ID와 전체 레코드를 반환하고, 없으면 두 값 모두 None을 반환하도록 설명되어 있다. 따라서 초기 등록 때 저장한 서버 식별 정보가 이후 이벤트에서 도출한 호출 대상과 연결될 수 있어야 하며, 승인된 기존 레코드가 자동 갱신의 대상이라는 제약이 유지된다. 다만 제공된 source_body는 URL을 디코딩하는 코드 중간에서 끝나므로, 이후 검색 구현과 상세 비교·갱신 로직까지 확인할 수는 없다.

🧾 핵심 주장 / 시사점

• 이 아키텍처의 푸시 기반 동기화는 런타임 변경 이벤트가 처리를 시작하고 Lambda가 MCP 서버의 현재 정보를 조회하는 결합 구조다.
• 자동 갱신은 초기 온보딩을 대체하지 않는다. 사전 등록된 APPROVED 레코드를 찾는 흐름이므로 기존 등록·승인 절차와 연결되어야 한다.
• 이벤트 기반 자동화로 수동 갱신 누락을 줄일 수 있지만, 약 5~15분의 CloudTrail 전달 지연 때문에 배포와 레지스트리 반영 사이의 시간차는 남는다.

✅ 액션 아이템

• UpdateAgentRuntime 이후 약 5~15분의 CloudTrail 전달 지연을 레지스트리 최신성 기대에 반영.
• 자동 갱신 대상 MCP 서버의 사전 등록과 APPROVED 상태, 런타임 ARN 기반 레코드 연결 확인.
• 다중 계정 구성에 맞춰 AgentCore Identity의 계정별 자격 증명 공급자와 OAuth 인증 범위 설정.

❓ 열린 질문

• 약 5~15분의 CloudTrail 전달 지연이 있는 동안 오래된 스키마를 사용하는 애플리케이션에는 어떤 영향이 있는가?
• MCP 서버에 대응하는 사전 등록된 APPROVED 레코드를 찾지 못하면 동기화는 어떻게 처리되는가?
• 하나의 AWS Lambda가 여러 계정의 MCP 서버에 인증할 때 계정별 자격 증명 공급자와 OAuth 인증 범위는 어떻게 구분되는가?