Amazon Bedrock AgentCore에 추가된 runtime instances: 장기 실행 AI 에이전트를 위한 상시 컴퓨트

Amazon Bedrock AgentCore Runtime에 runtime instances라는 컴퓨팅 옵션이 추가됐습니다. AWS가 관리하는 EC2 위에서 에이전트를 실행하고, 하나의 런타임에 여러 에이전트를 함께 배포합니다. 이전에는 에이전트를 며칠 동안 돌리거나 GPU에 접근하거나 여러 에이전트를 한 호스트에서 협업시키려면 EC2를 직접 프로비저닝하고 네트워크와 세션 관리, 스케일링, 모니터링을 손수 엮어야 했습니다. runtime instances는 그 작업을 AWS가 맡고, 기존 AgentCore Runtime microVM과 같은 API, 자격 증명, 관측 기능을 그대로 씁니다.

에이전트 워크로드가 이미 운영에 올라가 있고, 그 실행이 몇 시간을 넘어 며칠 이어지거나 GPU가 필요하다면 이 옵션이 직접 닿는 지점입니다. 상태를 세션 안에 유지하면서 여러 에이전트가 같은 호스트에서 파일을 공유하기 때문입니다.

microVM과 runtime instances의 차이

기존 microVM은 한 번의 호출이 최대 8시간 실행되고, 관리형 세션 스토리지로 상태를 유지합니다. runtime instances의 세션은 최대 14일 지속됩니다. 에이전트가 여러 날 계속 돌아야 하거나, GPU와 하위 OS에 접근해야 하거나, 여러 협업 에이전트를 한 호스트에서 실행할 때 쓰는 옵션입니다. 월요일 밤에 세션을 중단(hibernate)했다가 수요일 아침에 상태를 그대로 두고 다시 시작할 수 있습니다.

두 옵션은 같은 AgentCore Runtime API를 공유하며 따로 쓰거나 함께 쓸 수 있습니다. microVM에 가벼운 오케스트레이터 에이전트를 두어 API 호출과 작업 분배, 결과 취합을 맡기고, 코드 컴파일이나 보안 스캔, GUI 자동화처럼 상시 상태와 직접 OS 접근이 필요한 무거운 작업은 instances 위의 워커 에이전트가 처리하는 구성이 가능합니다.

에이전트 간 협업 방식

같은 세션 안에서 에이전트들이 서로를 도구처럼 호출하며 작업이 끝날 때까지 자율적으로 반복합니다. 프레임워크는 CrewAI, LangGraph, LlamaIndex, Strands 등 원하는 것을 쓰고, 모델도 자유롭게 고릅니다. 패키징은 @app.entrypoint 데코레이터를 붙인 코드와 zip 파일 또는 컨테이너 이미지면 됩니다.

공개된 데모는 작성 에이전트와 리뷰 에이전트 두 개가 같은 세션 디렉터리를 공유합니다. 작성 에이전트가 생성한 코드를 세션 디렉터리에 파일로 쓰고, 리뷰 에이전트가 같은 세션 ID로 그 파일을 읽어 검토합니다. 두 에이전트는 메시지를 주고받거나 서로의 API를 부르지 않고, 세션이 제공하는 공유 파일 시스템만으로 협업합니다. 여기에 테스트 에이전트나 문서 생성 에이전트를 같은 디렉터리에 붙여 확장할 수 있습니다.

배포는 먼저 capacity provider를 만들어 EC2 인프라(OS, 인스턴스 타입, VPC, 스토리지)를 정의하고, 그 위에 런타임을 생성해 에이전트를 배포합니다. 데모에서는 8 vCPU에 16 GiB 메모리인 c7g.2xlarge를 골라 두 에이전트를 나란히 돌렸습니다. capacity provider는 생성 후 설명만 수정할 수 있으므로, 만들기 전에 설정을 확인해야 합니다.

세션이 끝난 뒤에도 남겨야 하는 지식은 Amazon EBS와 AgentCore Memory와 함께 씁니다. 이렇게 하면 세션과 환경을 넘어 장기 기억을 유지합니다.

지원 범위

출시 시점 기준으로 Linux ARM64와 x86_64를 지원하고, Python 3.11부터 3.14까지 네이티브 코드 실행과 컨테이너 이미지를 지원합니다. GPU 가속 인스턴스 타입도 쓸 수 있습니다. 요금은 표준 EC2 요금에 AgentCore 오케스트레이션 관리 요금이 더해집니다. 제공 리전은 미국 동부(오하이오, 버지니아 북부), 미국 서부(오리건), 아시아 태평양(뭄바이, 싱가포르, 시드니, 도쿄), 유럽(프랑크푸르트, 아일랜드)입니다. 서울 리전은 목록에 없습니다.

도입 검토 의견

원문 발표가 아닌 솔트웨어의 의견입니다

세션을 상시로 켜 둘지 stop/restart로 끊을지가 EC2 청구액을 좌우합니다. runtime instances는 관리형이라도 그 아래는 실제 EC2 인스턴스이고, 세션이 14일까지 지속되는 동안 인스턴스가 계속 살아 있으면 표준 EC2 요금에 관리 요금까지 붙어 쌓입니다. 유휴 구간에 세션을 중단했다가 재개하는 패턴을 처음부터 설계에 넣으세요. 서울 리전이 아직 없으므로, 국내 사용자 대상 지연이 중요한 서비스라면 도쿄나 싱가포르를 놓고 지연을 재본 뒤 판단하는 편이 안전합니다.

지금 손댈 만한 팀은 에이전트가 이미 운영에 올라가 있고 실행이 8시간을 넘거나 며칠 이어지는 경우, 또는 GPU가 필요하거나 여러 에이전트를 한 호스트에서 협업시켜야 하는 경우입니다. 여기에 해당하지 않고 호출이 짧게 끝나는 워크로드라면 기존 microVM으로 충분하니 이번에는 넘어가도 됩니다. 프레임워크와 모델을 바꾸지 않고 패키징만 zip이나 컨테이너로 맞추면 되므로, 데모 수준의 두 에이전트 협업을 한 리전에서 세워 보는 데는 반나절이면 됩니다. 여기서 세션 유지 비용과 stop/restart 동작을 실제 청구서로 확인한 다음, 상시 워크로드로 넓힐지 결정하는 순서를 권합니다. 요금 세부는 Amazon Bedrock AgentCore 문서와 EC2 요금표에서 지금 쓰는 인스턴스 타입 단가와 대조하세요.

원문: Runtime instances: persistent compute for production AI agents on Amazon Bedrock AgentCore · 발행일 2026-08-06