AWS bedrock-agentcore documentation change
Summary
Updated documentation to clarify session lifecycle and persistence mechanisms, introducing session storage for filesystem data persistence across stop/resume cycles and refining terminology around compute (microVM) ephemerality.
Security assessment
The changes are primarily clarifications about data persistence and session lifecycle management. There is no mention of security vulnerabilities, patches, or incident responses. The updates focus on feature documentation (session storage) and terminology refinement (changing 'Terminated' to 'Stopped' state). While data persistence and isolation are security-adjacent topics, these changes don't address specific security issues or introduce new security features.
Diff
diff --git a/bedrock-agentcore/latest/devguide/runtime-sessions.md b/bedrock-agentcore/latest/devguide/runtime-sessions.md index 00745cdeb..85cd01a82 100644 --- a//bedrock-agentcore/latest/devguide/runtime-sessions.md +++ b//bedrock-agentcore/latest/devguide/runtime-sessions.md @@ -28 +28 @@ AgentCore does not enforce session-to-user mappings - your client backend should -While AgentCore provides strong session isolation, these sessions are ephemeral in nature. Any data stored in memory or written to disk persists only for the session duration. This includes conversation history, user preferences, intermediate calculation results, and any other state information your agent maintains. +By default, the compute (microVM) associated with a session is ephemeral. Any data stored in memory or written to disk persists only for the compute lifecycle. This includes conversation history, user preferences, intermediate calculation results, and any other state information your agent maintains. @@ -30 +30,3 @@ While AgentCore provides strong session isolation, these sessions are ephemeral -For data that needs to be retained beyond the session lifetime (such as user conversation history, learned preferences, or important insights), you should use AgentCore Memory. This service provides purpose-built persistent storage designed specifically for agent workloads, with both short-term and long-term memory capabilities. +To persist filesystem data across session stop/resume cycles, configure **session storage** — a persistent directory that survives compute termination. See [Persist session state across stop/resume with a filesystem configuration (Preview)](./runtime-persistent-filesystems.html). + +For structured data that needs to be retained beyond the session lifetime (such as user conversation history, learned preferences, or important insights), use AgentCore Memory. This service provides purpose-built persistent storage designed specifically for agent workloads, with both short-term and long-term memory capabilities. @@ -34 +36 @@ For data that needs to be retained beyond the session lifetime (such as user con -Unlike traditional serverless functions that terminate after each request, AgentCore supports ephemeral, isolated compute sessions lasting up to 8 hours. This simplifies building multi-step agentic workflows as you can make multiple calls to the same environment, with each invocation building upon the context established by previous interactions. You can use both `InvokeAgentRuntime` for agent reasoning and `InvokeAgentRuntimeCommand` for deterministic shell command execution within the same session. +Unlike traditional serverless functions that terminate after each request, AgentCore supports isolated sessions backed by ephemeral computes lasting up to 8 hours per lifecycle. This simplifies building multi-step agentic workflows as you can make multiple calls to the same environment, with each invocation building upon the context established by previous interactions. You can use both `InvokeAgentRuntime` for agent reasoning and `InvokeAgentRuntimeCommand` for deterministic shell command execution within the same session. @@ -44 +46 @@ A new session is created on the first invoke with a unique runtimeSessionId prov -Sessions can be in one of the following states: +Session state is determined by the compute lifecycle and can be one of the following: @@ -50 +52 @@ Sessions can be in one of the following states: - * **Terminated** : Execution environment provisioned for the session is terminated. This can be due to inactivity (of 15 minutes), reaching max duration (8 hours) or if it's deemed unhealthy based on health checks. Subsequent invokes to a terminated runtimeSessionId will provision a new execution environment. + * **Stopped** : The compute (microVM) provisioned for the session has been terminated and the session is stopped. This can occur due to inactivity (default 15 minutes), reaching max compute lifetime (default 8 hours), an explicit stop by invoking the [StopRuntimeSession](https://docs.aws.amazon.com/bedrock-agentcore/latest/APIReference/API_StopRuntimeSession.html) API, or if the compute is deemed unhealthy based on health checks. The session transitions back to Active on the next invocation and a new compute is provisioned, with the same lifecycle configuration (i.e. idleRuntimeSessionTimeout and maxLifetime that can be up to another 8 hours). The session itself remains valid until the AgentCore Runtime ARN is deleted. If the runtime is configured with session storage, filesystem data at the configured mount path persists across stop/resume cycles. See [Persist session state across stop/resume with a filesystem configuration (Preview)](./runtime-persistent-filesystems.html).