Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Azure Container Apps dynamic sessions provide fast access to secure sandboxed environments that are ideal for running code or applications that require strong isolation from other workloads.
Sessions operate within the context of a session pool which mitigates cold start to ensure immediate availability of a session.
With sessions, you get:
Strong isolation: Sessions are isolated from each other and from the host environment. Each session runs in its own Hyper-V sandbox, providing enterprise-grade security and isolation. Optionally, you can enable network isolation to further enhance security.
Simple access: Sessions are accessed through a REST API. A unique identifier marks each session. If a session with a given identifier doesn't exist, a new session is automatically allocated.
Fully managed: Container Apps fully manages a session's lifecycle. Sessions are automatically cleaned up when no longer in use.
Fast startup: New sessions are allocated in milliseconds. Rapid start-ups are achieved by automatically maintaining a pool of ready but unallocated sessions.
Scalable: Sessions can run at a high scale. You can run hundreds or thousands of sessions concurrently.
API access: Sessions are exposed to your application via a single HTTP endpoint.
Session
A session is a sandboxed environment that runs untrusted code or your application.
Each session is isolated from all other sessions and from the host environment with a Hyper-V sandbox. Hyper-V technology is at the foundation for session isolation, ensuring that different sessions operate independently with the necessary security boundaries in place. For enhanced network security, you can enable session network isolation on your session.
There are two different types of sessions.
Session types
Azure Container Apps supports two types of sessions:
| Type | Description | Billing model |
|---|---|---|
| Code interpreter sessions | Fully managed code interpreter which allows you to run code in a sandbox preinstalled with popular libraries. Ideal for running untrusted code, such as code provided by users of your application or code generated by a large language model (LLM). You can use the session out-of-the-box or with a language model framework. |
Per session (consumption) |
| Custom container sessions | Bring-your-own-container option where you run your own container images in secure, isolated sandboxes. This approach is a good option if you want to run a custom code interpreter for a language that isn't supported out of the box, or workloads that require strong isolation. |
Container Apps Dedicated Plan |
Each session, regardless of type, runs in the context of a session pool.
Session pools
To provide subsecond session allocation times, Azure Container Apps maintains a pool of ready but unallocated sessions. When your application makes a request for a session that hasn't been used before, the pool automatically assigns a new session for you. As sessions are allocated, the pool is automatically replenished to maintain a constant number of ready sessions.
Each session pool is available to your app through a unique pool management endpoint location.
Session lifecycle
The Container Apps runtime automatically manages the lifecycle for each session in a pool. A session's life begins as the session starts and continues while the session is in use. After there are no requests to the session after the cool down time has elapsed, the session is destroyed.
The following states define this lifecycle:
Pending: When a session is starting up, it's in the pending state. The amount of time a session spends in this state depends on the container image and settings specified for the session pool. A session in this state isn't added to the pool of ready sessions.
Unallocated: Once a session is done starting up, it's added to the pool and becomes available for allocation. For custom container sessions, you can specify how many ready sessions to maintain in the pool. This number should be increased if sessions are allocated faster than they're replenished.
Allocated: When you send a request to a nonrunning session, the pool provides a new session and places it in an allocated state. Subsequent requests with the same session identifier are routed to the same session, allowing for efficient reuse without cold starts. Each allocated session is associated with a session identifier.
Destroyed: If a session doesn't receive requests for a duration defined by the
cooldownPeriodInSecondssetting, the session and its Hyper-V sandbox are securely deleted. This automatic cleanup setup enhances resource management and security.
The Container Apps runtime automatically manages the lifecycle for each session in a session pool.
Region availability
Dynamic sessions are available in the following regions:
| Region | Code interpreter | Custom container |
|---|---|---|
| Australia East | ✔ | ✔ |
| Central US EUAP | ✔ | ✔ |
| East US 2 EUAP | ✔ | ✔ |
| East US | ✔ | ✔ |
| East Asia | ✔ | ✔ |
| Germany West Central | ✔ | ✔ |
| Italy North | ✔ | ✔ |
| North Central US | ✔ | - |
| Poland Central | ✔ | ✔ |
| Switzerland North | ✔ | ✔ |
| West Central US | ✔ | ✔ |
| West US 2 | ✔ | ✔ |
Billing
Custom container sessions are billed based on the resources consumed by the session pool. For more information, see Azure Container Apps billing.
Security
Use the following methods to help harden the security of your dynamic sessions.
Secure identifiers: Use secure session identifiers at all times. Generate session identifiers using cryptographic methods to ensure unique and unpredictable values. Avoid using sequential IDs that could be guessed by an attacker.
Use HTTPS: Always use HTTPS to encrypt data in transit. This protects session identifiers and any sensitive data exchanged between the client and server from being intercepted.
Limit session lifetime: Implement timeouts for sessions. For instance, allow a maximum of 15 minutes of inactivity before the session is automatically terminated. This helps mitigate risks due to a lost or unattended device.
Regular audits and monitoring: Periodically review session management practices and logs. Implement monitoring tools to alert suspicious activities, such as repeated failed login attempts or abnormal session lengths.