> ## Documentation Index
> Fetch the complete documentation index at: https://docs.uselayerup.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Infrastructure & Compute Runtimes
> Container image delivery, private registry integration, pre-deployment security scanning, execution environment options, and the compute scaling model for Layerup AI Agents.
# 2 — Infrastructure provisioning & compute runtimes — container delivery, security scanning & execution environments.
This section details the specific compute components required to run Layerup AI Agents at scale, and the compatibility of those components with your existing cloud-native infrastructure standards. It is addressed to Platform Engineering and Cloud Architecture teams.
***
## 2.1 Container image delivery and private registry integration
Layerup AI Agents are packaged as a standard Open Container Initiative (OCI)-compliant Docker container image. This is an industry-standard artifact format — compatible with any enterprise container registry and runtime your organization already operates.
### 2.1.1 AWS: Amazon Elastic Container Registry (ECR)
The delivery sequence for AWS environments:
1. Your AWS Marketplace subscription triggers delivery of the signed Layerup container image to a designated ECR repository within your own AWS account.
2. The image is tagged with a semantic version (e.g., `layerup-ai-agent:1.4.2`) for full traceability across environments.
3. ECR repository policies are configured by your team to allow access only from IAM roles within your account. Layerup retains zero access to the repository after image delivery.
4. Amazon ECR automatically replicates the image across your chosen AWS regions for high availability and disaster recovery compliance.
### 2.1.2 Azure: Azure Container Registry (ACR)
The equivalent delivery sequence for Azure environments:
1. The Azure Marketplace offer delivers the signed image to your private Azure Container Registry (ACR) instance.
2. Azure Defender for Containers continuously scans all images in ACR for known CVEs from the moment of delivery.
3. Images are stored with geo-replication enabled across your designated Azure regions, maintaining data residency requirements at the registry layer.
4. ACR Access Tokens restrict pull access to specific managed identities assigned to your agent compute instances — no external principal can pull the image.
***
## 2.2 Pre-deployment security scanning — no image enters production unscanned
Before any container image version is promoted to your production compute environment, it must pass your existing automated vulnerability scanning pipeline:
| cloud | scanning tool | behavior |
| ---------------------- | --------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **AWS** | Amazon Inspector | Automatically initiates a vulnerability assessment when a new image version lands in ECR. Evaluates against known CVE databases, checking all OS packages and application dependencies. Images failing defined severity thresholds are quarantined and cannot be deployed to production without a documented exception approval. |
| **Azure** | Microsoft Defender for Cloud | Continuously monitors images in ACR and running containers in AKS or Container Apps for emerging vulnerabilities. Surfaces findings directly in your Microsoft Defender portal. |
| **Custom CI/CD Gates** | Jenkins · Azure DevOps · GitHub Actions | Your internal CI/CD pipelines can impose additional quality gates before a Layerup image version is approved for production deployment. These gates may include SAST/DAST scans, SBOM validation, and sign-off approvals from your security team. |
Layerup also provides a signed SBOM in CycloneDX or SPDX format for every
released image version. Your security team can validate the SBOM against the
image digest before it enters your registry. See 4 for full supply chain
security documentation.
***
## 2.3 Agent execution environments
Your Platform Engineering team selects the execution environment that best fits your existing infrastructure standards. Three options are supported.
### 2.3.1 AWS Option A: Amazon Bedrock AgentCore Runtime (recommended)
Amazon Bedrock AgentCore Runtime (released early 2026) is AWS's native, purpose-built execution environment for AI agents. It is the recommended runtime for Layerup AI Agents on AWS for the following reasons:
AgentCore Runtime launches a lightweight, isolated microVM for each agent session. Each application case processed by the agent runs in its own isolated execution environment. Memory, context, and intermediate reasoning states cannot be accessed across sessions — critical for ensuring that the context of Applicant A's case does not contaminate the reasoning for Applicant B's case.
AgentCore Runtime is framework-agnostic. The Layerup agent deploys without
requiring any AWS-specific SDK rewrites. The container simply executes within
the runtime — your existing container operational model applies.
AgentCore Runtime automatically provisions and deprovisions microVMs in
response to workload. During high-volume intake periods, the runtime scales
horizontally without your team needing to pre-provision capacity or manage EC2
instance fleets.
The runtime natively integrates with Amazon Bedrock Guardrails, applying your configured compliance policies at the model inference layer before the agent can take any action. There is no additional integration work required to enable this layer.
#### Agent deployment modality: container image vs. Python via S3
AgentCore Runtime supports two ways to deliver the agent code into a microVM session. Layerup ships as a container image by default. Understanding the tradeoffs is important for customers whose internal delivery pipelines were built for one modality or the other.
| dimension | Container image (OCI / Docker) | Python code via S3 |
| --------------------------------- | ------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------ |
| **Layerup default** | Yes — all agent releases ship as signed OCI images | Under evaluation — not yet available in all regions |
| **Runtime language** | Any — Node.js, Python, Java, Go, or multi-language | Python only — AWS controls the managed runtime version |
| **System dependencies** | Full OS-level control; any library or binary can be included | Pip-installable pure-Python packages only |
| **Source code visibility** | Code is bundled inside image layers; not directly readable by registry holders | Python source files (.py) are stored as plain text in an S3 bucket accessible to your AWS account team |
| **IP protection** | Image layers can contain compiled bytecode; Cosign signing provides provenance chain | Source is readable by anyone with S3 read access to the delivery bucket |
| **Delivery pipeline requirement** | Container-capable CI/CD pipeline with ECR pull access | Standard S3 write access; no container runtime required |
| **Signing and SBOM** | Cosign-signed; CycloneDX SBOM included | Not applicable |
AgentCore Runtime is itself just one of four services in the full Agent Core
suite. For a complete breakdown of which Agent Core services a Layerup
deployment activates, which are optional, and what each requires from your
cloud governance team, see [Agent Core Service
Suite](/agents/deployment/agent-core-services).
### 2.3.2 AWS Option B: Amazon ECS with Fargate
For teams with existing ECS-based container orchestration, the Layerup agent can alternatively be deployed to Amazon ECS using the Fargate serverless compute engine:
* **No EC2 Instance Management:** Fargate eliminates the need to provision or patch underlying EC2 instances. Your team defines the CPU and memory requirements for each agent task; Fargate provisions the compute dynamically.
* **Task Isolation:** Each ECS Task definition for the Layerup agent runs in its own isolated compute environment with a separate network interface and IAM task role.
* **ECS Service Auto Scaling:** Application Auto Scaling policies on the ECS service allow you to scale concurrent agent tasks horizontally based on SQS queue depth (i.e., the number of pending application packets awaiting processing).
* **Existing ECS Integration:** If your existing AI platform team already manages workloads on ECS, the Layerup agent slots into that operational model without introducing new tooling or operational overhead.
### 2.3.3 Azure Option: AKS or Azure Container Apps
On Azure, your team deploys the Layerup agent container using either of the following orchestration layers, depending on your existing platform standards:
* **Azure Container Apps (ACA):** The lower-operational-overhead option. ACA provides a fully managed serverless container platform that handles scaling, load balancing, and service discovery automatically. Recommended for teams that prefer a managed abstraction over raw Kubernetes. KEDA (Kubernetes Event-Driven Autoscaling) on Container Apps scales agent instances directly off Azure Service Bus queue depth.
* **Azure Kubernetes Service (AKS):** For teams that already operate AKS clusters, the Layerup agent is deployed as a Kubernetes `Deployment` resource with a corresponding `HorizontalPodAutoscaler`. Your existing Kubernetes RBAC, NetworkPolicies, OPA/Gatekeeper policies, and namespace isolation apply natively to the agent pods.
* In both cases, inference calls are routed to your securely managed Azure OpenAI endpoints within your Azure AI Foundry hub, governed by Azure AI Content Safety filters configured by your team.
```mermaid theme={null}
flowchart LR
IMG[OCI Container Image\nLayerup AI Agent]
IMG -->|delivered to ECR| AGC
IMG -->|delivered to ECR| ECS
IMG -->|delivered to ACR| ACA
IMG -->|delivered to ACR| AKS
AGC[Bedrock AgentCore Runtime\nRecommended — session-isolated microVMs]
ECS[Amazon ECS + Fargate\nServerless task execution]
ACA[Azure Container Apps\nKEDA autoscaling]
AKS[Azure Kubernetes Service\nHPA + namespace isolation]
```
*Fig. A2.1 — Execution environment options by cloud provider. All options share the same network isolation model, IAM boundary, and guardrails integration.*
***
## 2.4 Compute scaling and session concurrency
Layerup AI Agents process each application case asynchronously. A typical case requires between 7 and 55 minutes of reasoning time, depending on document volume and complexity. The following scaling model ensures intake volumes are handled efficiently regardless of concurrent load.
| scenario | performance characteristic |
| ---------------------------------------------------- | ----------------------------------------------------------------------------------- |
| Simple case (\<10 documents) | 7–12 minutes of processing time |
| Standard case (10–50 documents) | 12–20 minutes of processing time |
| Complex case (50+ documents, large MIB / Rx history) | 20–55 minutes of processing time |
| Maximum observed processing time | \~55 minutes (hundreds of MB of documents across all channels) |
| Concurrency | Unlimited parallel cases — each case runs in an independent isolated session |
| AWS scaling trigger | SQS queue depth — target: fewer than 5 pending tasks per active agent instance |
| Azure scaling trigger | Azure Service Bus queue depth — KEDA scaling rule on the Container Apps environment |
Auto-scaling is configured to maintain a target SQS / Service Bus queue depth of fewer than 5 pending tasks per active agent instance, ensuring consistent processing latency regardless of intake volume spikes — including post-event surge scenarios.
The asynchronous, queue-driven processing model means that peak intake events
do not degrade processing quality. New agent instances are provisioned within
seconds of queue depth rising above threshold. When the queue drains,
instances are de-provisioned automatically — you pay only for compute consumed
during active processing.