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 organization. No compute, storage, queuing, networking, encryption keys, or model deployments are shared with any other Layerup customer.

infrastructure component	what is provisioned for your organization
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 organization’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.uselayerup.com). This is the simplest path and is appropriate for most organizations. 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 *.uselayerup.com (or the specific IP range provided by your Layerup implementation engineer)

Option B: AWS PrivateLink (private network path)

For organizations 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.uselayerup.com/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.uselayerup.com/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 organization. The following summarizes 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 organization 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

Foundations

Deployment Architecture

Security & Governance

Data & Integration

Observability & Resilience

Configuration & Lifecycle

Confidence & Scoring

Reference

Layerup's Cloud

Layerup’s Cloud — integration mechanism, network connectivity & dedicated cluster.

What “dedicated cluster” means in concrete infrastructure terms

Network connectivity — two options

Option A: HTTPS over internet (default)

Option B: AWS PrivateLink (private network path)

API integration mechanism

Submitting a case

Receiving output

Case status

Authentication — API and dashboard

Data residency under Option 3

SaaS vs private cloud — key differences at a glance

​Layerup’s Cloud — integration mechanism, network connectivity & dedicated cluster.

​What “dedicated cluster” means in concrete infrastructure terms

​Network connectivity — two options

​Option A: HTTPS over internet (default)

​Option B: AWS PrivateLink (private network path)

​API integration mechanism

​Submitting a case

​Receiving output

​Case status

​Authentication — API and dashboard

​Data residency under Option 3

​SaaS vs private cloud — key differences at a glance

Layerup’s Cloud — integration mechanism, network connectivity & dedicated cluster.

What “dedicated cluster” means in concrete infrastructure terms

Network connectivity — two options

Option A: HTTPS over internet (default)

Option B: AWS PrivateLink (private network path)

API integration mechanism

Submitting a case

Receiving output

Case status

Authentication — API and dashboard

Data residency under Option 3

SaaS vs private cloud — key differences at a glance