Layerup’s Cloud — integration mechanism, network connectivity & dedicated cluster.
This page covers the technical architecture of Option 3 — Layerup’s Cloud — in the same depth that Native VPC Deployment Paradigm covers Option 2. It is addressed to security architects and integration engineers evaluating whether the SaaS model satisfies your network, data residency, and integration requirements.
Everything on this page applies only to Option 3. For Option 2 (your private cloud), see Native VPC Deployment Paradigm. The core agent logic, AOP governance, and output schema are identical across all deployment models.
What “dedicated cluster” means in concrete infrastructure terms
Option 3 is not a shared multi-tenant SaaS product. Layerup provisions a fully isolated set of infrastructure in Layerup’s AWS account, dedicated exclusively to your organisation. No compute, storage, queuing, networking, encryption keys, or model deployments are shared with any other Layerup customer.
| infrastructure component | what is provisioned for your organisation |
|---|
| VPC | A dedicated Virtual Private Cloud in Layerup’s AWS account, used by no other customer |
| ECR repository | A private container registry holding only your organisation’s agent image version |
| S3 buckets | Dedicated input and output buckets, encrypted with a customer-specific KMS key |
| SQS queues | Dedicated intake and completion queues for your case workflow |
| Amazon Bedrock model | A dedicated model deployment within Layerup’s Bedrock account, not shared across customers |
| CloudWatch Log Group | Dedicated audit log stream — no logs from other customers appear in your group |
| KMS key | A customer-specific AWS KMS key for all data encryption at rest |
| IAM roles | Execution roles scoped exclusively to your cluster’s resources |
Layerup’s own operational tooling accesses your cluster through a separate, time-limited, audited cross-account role used only for deployment, monitoring, and incident response. This role is not used for any customer’s data access and is subject to the same BAA controls as the customer-facing infrastructure.
Network connectivity — two options
Option A: HTTPS over internet (default)
The default connectivity model uses HTTPS (TLS 1.3) over the public internet between your systems and Layerup’s cluster API endpoint. All data is encrypted in transit. Your systems make API calls to a dedicated HTTPS endpoint assigned to your cluster (<your-org>.api.layerup.ai).
This is the simplest path and is appropriate for most organisations. The dedicated endpoint is authenticated — unauthenticated requests are rejected before any data is processed.
Fig. S1.1 — HTTPS connectivity (default). Data is encrypted end-to-end via TLS 1.3. The ALB and all cluster resources are in Layerup’s dedicated VPC — no shared infrastructure.
Firewall rule required on your side:
- Outbound TCP port 443 to
*.layerup.ai (or the specific IP range provided by your Layerup implementation engineer)
Option B: AWS PrivateLink (private network path)
For organisations whose security policy prohibits internet-egress to third-party HTTPS endpoints — or who prefer a fully private network path for all data traffic — Layerup supports connectivity via AWS PrivateLink.
With PrivateLink, traffic between your VPC and Layerup’s dedicated cluster travels entirely over AWS’s private backbone network. No data traverses the public internet at any point.
Fig. S1.2 — PrivateLink connectivity. All traffic stays on AWS’s internal network. Your VPC creates an Interface VPC Endpoint pointing to Layerup’s PrivateLink service. No internet gateway or NAT gateway route is required.
What your AWS team needs to provision for PrivateLink:
- An Interface VPC Endpoint in your AWS account, using the PrivateLink service name provided by Layerup
- A security group on the endpoint allowing outbound from your integration workloads
- No internet gateway route changes are required — PrivateLink traffic does not use the internet path
Availability: PrivateLink is available for all Option 3 deployments in supported AWS regions. Confirm regional availability with your Layerup implementation engineer.
API integration mechanism
Your systems interact with the Layerup dedicated cluster through a REST API. The integration pattern mirrors Option 2 (S3/SQS-based staging) but operates against Layerup-managed endpoints rather than resources in your own AWS account.
Submitting a case
POST https://your-org.api.layerup.ai/v1/cases
Authorization: Bearer <access_token>
Content-Type: application/json
{
"workflow": "idi-underwriting",
"documents": [
{ "type": "application_form", "upload_url": "<presigned_S3_put_url>" },
{ "type": "aps", "upload_url": "<presigned_S3_put_url>" },
{ "type": "rx_history", "upload_url": "<presigned_S3_put_url>" }
],
"metadata": {
"case_reference": "UW-2026-110482",
"line_of_business": "idi",
"aop_version": "v2.4.1"
},
"webhook_url": "https://your-system.example.com/agent-callback"
}
The API response returns a case_id and pre-signed S3 upload URLs for each document. Your system uploads the documents directly to Layerup’s S3 input bucket using the pre-signed URLs (TLS-encrypted; URLs expire after 15 minutes).
Receiving output
Two consumption patterns are supported:
| pattern | how it works | when to use |
|---|
| Webhook (push) | When the agent completes the case, Layerup POSTs the structured output JSON to your configured webhook_url. Your system must expose an HTTPS endpoint to receive it. | Recommended for real-time downstream integration |
| Polling (pull) | Your system polls GET /v1/cases/{case_id}/output until status is complete, then retrieves the output payload. | Simpler to implement; suitable for lower-volume workflows or when webhook infrastructure is not available |
Case status
GET https://your-org.api.layerup.ai/v1/cases/{case_id}
Authorization: Bearer <access_token>
Response:
{
"case_id": "IDI-2026-110482",
"status": "processing", // pending | processing | complete | failed
"submitted_at": "2026-06-17T18:22:00Z",
"estimated_completion": "2026-06-17T18:35:00Z"
}
Authentication — API and dashboard
See SSO & API Authentication for the full authentication reference. In summary:
| access type | mechanism |
|---|
| System-to-system (API calls) | OAuth 2.0 client credentials — client ID + secret → access token (1-hour TTL) |
| Human users (dashboard) | SAML 2.0 or OIDC federated to your corporate identity provider (Okta, Azure AD, PingFederate, etc.) |
Data residency under Option 3
All data processed by the agent remains within Layerup’s dedicated cluster for your organisation. The following summarises where data lives and how it is protected:
| data type | location | encryption | retention |
|---|
| Submitted documents (S3 input) | Layerup’s dedicated S3 bucket — your org only | AES-256, customer-specific KMS key | Deleted 7 days after case completion (configurable) |
| Structured output JSON (S3 output) | Layerup’s dedicated S3 bucket — your org only | AES-256, customer-specific KMS key | Retained per your configured retention policy |
| Audit logs (CloudWatch) | Layerup’s dedicated CloudWatch Log Group — your org only | Encrypted at rest | 7-year minimum retention (HIPAA requirement) |
| LLM inference prompts and responses | Processed transiently within Bedrock model deployment — never persisted by Bedrock | Not stored | Never retained by Bedrock (confirmed by AWS DPA) |
| Agent working memory (session) | Session-isolated microVM memory — cleared on session termination | In-memory only | Cleared at end of each case session |
Your organisation has audit access to the CloudWatch Log Group for your dedicated cluster. Layerup provides read-only IAM access credentials for your compliance team, allowing independent verification of the audit trail without requiring Layerup involvement. This access is governed by the BAA.
SaaS vs private cloud — key differences at a glance
| dimension | Option 2: Your Private Cloud | Option 3: Layerup’s Cloud |
|---|
| Infrastructure account | Your AWS account | Layerup’s AWS account |
| Network boundary | Your VPC | Layerup’s dedicated VPC |
| Integration model | Direct S3/SQS in your account | REST API → Layerup-managed S3/SQS |
| Connectivity path | Internal (no internet egress) | HTTPS or PrivateLink |
| Update control | Your CI/CD pipeline | Layerup — with advance notice and freeze option (see Agent Update Lifecycle) |
| IT provisioning | Your cloud team | Layerup |
| Audit log access | Your CloudWatch | Read-only access to Layerup-managed CloudWatch |
| KMS key | Your KMS (CMK) | Layerup-managed customer-specific KMS key |
| Time to go live | Moderate | Fastest |