View a markdown version of this page

에이전트에 대해 격리된 세션 사용 - Amazon Bedrock AgentCore

에이전트에 대해 격리된 세션 사용

Amazon Bedrock AgentCore 런타임을 사용하면 각 사용자 세션을 격리하고 사용자 세션의 여러 간접 호출에서 컨텍스트를 안전하게 재사용할 수 있습니다. 세션 격리는 고유한 운영 특성으로 인해 AI 에이전트 워크로드에 매우 중요합니다.

  • 전체 실행 환경 분리: AgentCore 런타임의 각 사용자 세션은 격리된 컴퓨팅, 메모리 및 파일 시스템 리소스가 있는 자체 전용 microVM을 받습니다. 이렇게 하면 한 사용자의 에이전트가 다른 사용자의 데이터에 액세스하지 못합니다. 세션이 완료되면 전체 microVM이 종료되고 메모리가 삭제되어 모든 세션 데이터가 제거되므로 세션 간 오염 위험이 없습니다.

  • 상태 저장 추론 프로세스: 상태 비저장 함수와 달리 AI 에이전트는 멀티턴 대화에 대한 간단한 메시지 기록 외에도 실행 주기 전반에 걸쳐 복잡한 컨텍스트 상태를 유지합니다. AgentCore 런타임은 세션 내에서이 상태를 안전하게 유지하면서 서로 다른 사용자 간의 완전한 격리를 보장하여 데이터 경계를 손상시키지 않으면서 개인화된 에이전트 경험을 가능하게 합니다.

  • 권한 있는 도구 작업: AI 에이전트는 다양한 리소스에 액세스하는 통합 도구를 통해 사용자를 대신하여 권한 있는 작업을 수행합니다. AgentCore 런타임의 격리 모델은 이러한 도구 작업이 적절한 보안 컨텍스트를 유지하고 서로 다른 사용자 세션 간의 자격 증명 공유 또는 권한 에스컬레이션을 방지하도록 합니다.

  • 비결정적 프로세스에 대한 결정적 보안: AI 에이전트 동작은 파운데이션 모델의 확률적 특성으로 인해 비결정적일 수 있습니다. AgentCore 런타임은 에이전트 실행 패턴과 관계없이 일관되고 결정적인 격리 경계를 제공하여 엔터프라이즈 배포에 필요한 예측 가능한 보안 속성을 제공합니다.

참고

AgentCore는 session-to-user 매핑을 적용하지 않습니다. 클라이언트 백엔드는 사용자와 세션 IDs 간의 관계를 유지해야 합니다. 또한 클라이언트 백엔드는 사용자당 최대 세션 수와 같은 사용자-세션 수명 주기 관리를 위한 로직을 구현해야 합니다. 전체 세션 격리 지침은 AgentCore 런타임의 보안 모범 사례를 참조하세요.

임시 컨텍스트 이해

기본적으로 세션과 연결된 컴퓨팅(microVM)은 임시적입니다. 메모리에 저장되거나 디스크에 기록된 모든 데이터는 컴퓨팅 수명 주기 동안만 유지됩니다. 여기에는 대화 기록, 사용자 기본 설정, 중간 계산 결과 및 에이전트가 유지 관리하는 기타 상태 정보가 포함됩니다.

세션 중지/재개 주기 전반에 걸쳐 파일 시스템 데이터를 유지하려면 컴퓨팅 종료 후에도 지속되는 영구 디렉터리인 세션 스토리지를 구성합니다. AgentCore 런타임에 대한 파일 시스템 구성을 참조하세요.

세션 수명을 초과하여 보존해야 하는 구조화된 데이터(예: 사용자 대화 기록, 학습된 기본 설정 또는 중요한 인사이트)의 경우 AgentCore 메모리를 사용합니다. 이 서비스는 단기 및 장기 메모리 기능을 모두 갖춘 에이전트 워크로드용으로 특별히 설계된 목적별 영구 스토리지를 제공합니다.

확장된 대화 및 다단계 워크플로

각 요청 후 종료되는 기존 서버리스 함수와 달리 AgentCore는 수명 주기당 최대 8시간 동안 지속되는 임시 컴퓨팅을 기반으로 하는 격리된 세션을 지원합니다. 이렇게 하면 동일한 환경을 여러 번 호출할 수 있으므로 다단계 에이전트 워크플로 구축이 간소화되며, 각 호출은 이전 상호 작용에서 설정한 컨텍스트를 기반으로 구축됩니다. 동일한 세션 내에서 InvokeAgentRuntime 에이전트 추론과 결정적 셸 명령 실행 InvokeAgentRuntimeCommand 모두에를 사용할 수 있습니다.

AgentCore 런타임 세션 수명 주기

세션 생성

애플리케이션에서 제공하는 고유한 runtimeSessionId를 사용하여 첫 번째 호출 시 새 세션이 생성됩니다. AgentCore 런타임은 각 세션에 대해 전용 실행 환경(microVM)을 프로비저닝합니다. 컨텍스트는 동일한 세션에 대한 호출 사이에 보존됩니다. InvokeAgentRuntime 및 모두 동일한 세션에서 InvokeAgentRuntimeCommand 작동합니다. 명령은 에이전트와 동일한 컨테이너, 파일 시스템 및 환경을 확인합니다.

세션 상태

세션 상태는 컴퓨팅 수명 주기에 따라 결정되며 다음 중 하나일 수 있습니다.

  • 활성: 동기화 요청을 처리하거나, 명령을 실행하거나, 백그라운드 작업을 수행합니다. 동기화 호출 및 명령 실행 활동은 런타임 세션에 대한 호출을 기반으로 자동으로 추적됩니다. 백그라운드 작업은 pings에서 "HealthyBusy" 상태로 응답하여 에이전트 코드에 의해 전달됩니다.

  • 유휴 : 요청 또는 백그라운드 작업을 처리하지 않는 경우. 세션이 처리를 완료했지만 향후 호출에 계속 사용할 수 있습니다.

  • 중지됨: 세션에 프로비저닝된 컴퓨팅(microVM)이 종료되고 세션이 중지되었습니다. 이는 비활성(기본값 15분), 최대 컴퓨팅 수명(기본값 8시간) 도달, StopRuntimeSession API 호출로 인한 명시적 중지 또는 상태 확인을 기반으로 컴퓨팅이 비정상으로 간주되는 경우 발생할 수 있습니다. 세션은 다음 간접 호출 시 다시 활성으로 전환되고 새 컴퓨팅이 동일한 수명 주기 구성(즉, idleRuntimeSessionTimeout 및 최대 추가 8시간일 수 있는 maxLifetime)으로 프로비저닝됩니다. 세션 자체는 AgentCore 런타임 ARN이 삭제될 때까지 유효합니다. 런타임이 세션 스토리지로 구성된 경우 구성된 탑재 경로의 파일 시스템 데이터는 중지/재개 주기 동안 유지됩니다. AgentCore 런타임에 대한 파일 시스템 구성을 참조하세요.

세션 사용 방법

세션을 효과적으로 사용하려면:

  • 각 사용자 또는 대화에 대해 33자 이상의 고유한 세션 ID 생성

  • 모든 관련 호출에 대해 동일한 세션 ID 전달

  • 사용자 또는 대화마다 다른 세션 IDs 사용

대화에 세션 사용 예제

# First message in a conversation response1 = agent_core_client.InvokeAgentRuntime( agentRuntimeArn=agent_arn, runtimeSessionId="user-123456-conversation-12345678", # or uuid.uuid4() payload=json.dumps({"prompt": "Tell me about AWS"}).encode() ) # Follow-up message in the same conversation reuses the runtimeSessionId. response2 = agent_core_client.InvokeAgentRuntime( agentRuntimeArn=agent_arn, runtimeSessionId="user-123456-conversation-12345678", # or uuid.uuid4() payload=json.dumps({"prompt": "How does it compare to other cloud providers"}).encode() )

관련 호출에 동일한 runtimeSessionId를 사용하면 대화 전반에 걸쳐 컨텍스트가 유지되도록 하여 에이전트가 이전 상호 작용을 기반으로 하는 일관된 응답을 제공할 수 있습니다.

프로토콜별 세션 헤더

에이전트를 호출할 때 요청이 동일한 microVM으로 라우팅되도록 적절한 세션 헤더를 포함합니다. 헤더는 에이전트의 구성된 프로토콜에 따라 다릅니다.

프로토콜 세션 헤더

MCP

Mcp-Session-Id

HTTP

X-Amzn-Bedrock-AgentCore-Runtime-Session-Id

A2A

X-Amzn-Bedrock-AgentCore-Runtime-Session-Id

AG-UI

X-Amzn-Bedrock-AgentCore-Runtime-Session-Id

MicroVM 고정성: Amazon Bedrock AgentCore는 세션 헤더를 사용하여 요청을 동일한 microVM 인스턴스로 라우팅합니다. 클라이언트는 응답에 반환된 세션 ID를 캡처하고 세션 선호도를 보장하기 위해 모든 후속 요청에 포함해야 합니다. 일관된 세션 ID가 없으면 각 요청이 새 microVM으로 라우팅되어 콜드 스타트로 인한 추가 지연 시간이 발생할 수 있습니다.

상태 비저장 및 상태 저장 모드를 포함한 MCP 프로토콜 세부 정보는 MCP 세션 관리 및 microVM 고정을 참조하세요.