AWS Deployment Patterns

Instance topologies for the Purple8 AML Platform on AWS. These patterns apply to the Customer VPC and Managed Service models, and to Self-Hosted deployments on AWS. All three patterns are built from the same instance definition and compose with one another.

Instance definition

An instance is the unit of deployment. One instance holds one Purple8 Graph data set and is confined to one AWS region.

 Instance  (one AWS region, two availability zones)
 ┌─────────────────────────────────────────────────────────────────────┐
 │  Presentation   CloudFront + S3 (Investigator UI)                    │
 │                 LCNC admin console served by Purple8 Graph at /lcnc  │
 │                                                                     │
 │  Edge           Route 53 · AWS WAF · Application Load Balancer (ACM) │
 │                                                                     │
 │  Core           Purple8 Graph primary   EC2 + EBS   AZ-a  (writer)   │
 │                 Purple8 Graph follower  EC2 + EBS   AZ-b  (WAL SYNC) │
 │                                                                     │
 │  Processing     Purple8 DocIntel        ECS Fargate  AZ-a, AZ-b      │
 │                 ElastiCache for Valkey  (DocIntel job store)         │
 │                                                                     │
 │  Inference      Amazon Bedrock (VPC endpoint)  |  Ollama on EC2/ECS  │
 │                 |  external provider via NAT — customer choice       │
 │                                                                     │
 │  Platform       AWS KMS · Secrets Manager · S3 backups · CloudWatch  │
 │                 VPC endpoints for all AWS service traffic            │
 │                                                                     │
 │  Identity       Customer IdP via OIDC or SAML                        │
 │  Integration    REST ingest · inbound webhooks · REST polling        │
 │                 egress webhooks · Prometheus · OpenTelemetry         │
 └─────────────────────────────────────────────────────────────────────┘

Properties that hold for every instance:

Property	Value
Writers	Exactly one Purple8 Graph process accepts writes
Region	One. Storage, keys, logs, backups and Bedrock inference are regional.
Availability zones	Two minimum. Primary and follower in different AZs. DocIntel tasks spread across AZs.
Durability	WAL fsync'd before mutation. `SYNC` replication to follower before write returns (RPO ≈ 0).
Failover	Replica watchdog promotes itself after consecutive probe failures and swaps the ALB write target group (`elbv2` hook).
Encryption	AES-256-GCM envelope encryption with a customer-managed KMS key. TLS at ALB and on the replication link.
Backup	Incremental to a versioned S3 bucket in the same region.
Tenancy within instance	Optional. Line-of-business or team separation via `tenant_id` (shared-key prefix) or dedicated data path.

Compute for Purple8 Graph: EC2 + EBS is the reference. ECS Fargate + EFS is a supported alternative; see the comparison.

Application layer

The application layer is the same in every pattern. Only the number of instances and the number of front-ends change.

Investigator UI

React single-page application. Static assets in S3, served through CloudFront.
Calls the Purple8 Graph REST API and MCP endpoint directly. No intermediate application server.
Configured per deployment with API base URL, IdP client settings and branding.
One UI build can serve one instance, or several UI builds can serve the same instance (Many-to-One).
Private access: replace CloudFront with an internal ALB and restrict by VPN or AWS Client VPN.

Purple8 Hyper Graph

Graph, vector, document and full-text store (BrickCoreStorage + BrickWAL + CortexAutoConfig); REST API (port 8080 in the commercial image); MCP server (125 MCP tools across 16 namespaces) for AI agents.
Journey Engine: case lifecycle, stage definitions, SLA policies, HITL gates, immutable audit trail.
AML detection functions: community and ring detection, centrality, shortest path, link prediction, evolutionary threshold tuning.
LCNC console at /lcnc/ for tenants, users, API keys, storage and settings.
Envelope encryption via AwsKmsProvider. Secrets from Secrets Manager. Backups via IncrementalBackupManager to S3, plus online non-destructive integrity verification via POST /admin/storage/scrub.

Purple8 DocIntel

Stateless. Parses, classifies, chunks and extracts entities and relationships from 70 document formats; emits to the Purple8 Graph ingest API (/ingest/preview, /ingest/commit).
ECS Fargate service, autoscaled. Job store on ElastiCache for Valkey when running more than one task.
Uses the same inference provider configuration as Purple8 Graph.
May be dedicated per instance (default) or pooled across instances of one customer where residency permits.

Inference

Option	Data path	Use
Amazon Bedrock	Stays in account and region via VPC endpoint	Default for AWS deployments
Ollama / SentenceTransformers / Hugging Face	Stays inside the VPC	No external egress; GPU or CPU EC2
OpenAI, Anthropic, Google, Azure OpenAI, Vertex AI, Mistral, Cohere	Leaves the VPC via NAT	Where customer policy permits

Provider is selected by configuration and may differ per instance.

Identity

Customer IdP federated via OIDC (with PKCE and JWKS validation) or SAML 2.0.
Users mapped to Purple8 roles (viewer, editor, admin, super_admin) and, where used, to a tenant_id.
API keys for service-to-service calls (DocIntel → Graph, downstream consumers → Graph).

Integration

Direction	Mechanism
Inbound (transactions, customers, accounts, alerts)	REST API (`/nodes`, `/edges`, `/ingest/*`); `WebhookReceiver` for push from source systems; `RESTPoller` for pull from source APIs; file drop to DocIntel
Inbound (documents)	DocIntel `/process`, `/process/url`; Confluence, SharePoint and S3 connectors
Outbound (case events, alerts)	Egress sinks: HMAC-signed webhooks to SIEM, case management or data warehouse
Operational	Prometheus `/metrics`; OpenTelemetry traces; alerts to PagerDuty, OpsGenie, Slack or webhook; CloudWatch Logs
Audit	`GET /admin/audit`; graph-stored audit edges; export to S3

Streaming platforms (Kafka, Kinesis) are integrated through a customer-side consumer that calls the REST ingest API. There is no native broker consumer in the platform.

One-to-One

One customer, one instance. Complete physical and logical isolation.

 Customer account or dedicated VPC — region chosen by customer
 ┌───────────────────────────────────────────────────────────┐
 │  Investigator UI ─► ALB ─► Purple8 Graph (primary, follower) │
 │  DocIntel ─► Purple8 Graph                                  │
 │  Dedicated: KMS key · S3 bucket · Secrets · IAM · logs      │
 └───────────────────────────────────────────────────────────┘

Aspect	Value
Instances	1
Region	1, customer-nominated
AZs	2
Isolation	Account or VPC; dedicated volumes, keys, buckets, IAM roles, log groups
Customization	Unrestricted: detection configuration, ontologies, journey templates, UI branding, inference provider, release schedule
Internal segregation	Optional `tenant_id` per line of business within the instance
Cross-region	Optional ASYNC follower or replicated backups in a second region for disaster recovery

Use when the customer requires isolation that can be demonstrated to a regulator or auditor at the account boundary, or when customization would be constrained by any sharing.

One-to-Many

One customer, one instance per market or jurisdiction. Data stays in its region. Platform version and operating model are common.

                    Customer or operator control plane
                    (IaC pipeline · release line · aggregated telemetry)
                                    │
          ┌─────────────────────────┼─────────────────────────┐
          ▼                         ▼                         ▼
  Instance: US               Instance: EU               Instance: APAC
  us-east-1                  eu-west-1                  ap-southeast-1
  Graph primary + follower   Graph primary + follower   Graph primary + follower
  DocIntel · KMS · S3        DocIntel · KMS · S3        DocIntel · KMS · S3
  Bedrock (us-east-1)        Bedrock (eu-west-1)        Bedrock (ap-southeast-1)
          ▲                         ▲                         ▲
          └── Investigator UI per market, or one UI with market selector ──┘

Aspect	Value
Instances	One per market or jurisdiction
Region	One per instance; no data crosses a regional boundary
AZs	2 per instance
Data model	Each instance holds only its market's data. Purple8 Graph has one primary per logical database; it cannot span regions. Residency is structural, not a configuration flag.
Common elements	Container image, infrastructure template, detection baseline, journey templates, release calendar
Divergent elements	Detection thresholds, local typologies, inference provider and model, retention, UI language and branding — per instance
Cross-market reporting	Aggregation layer above the instances reads each instance's REST API. No cross-region data replication.
Adding a market	Apply the same stack in the new region with new parameters

Use when regulatory or residency requirements differ by jurisdiction but the institution wants one product, one release line and one operating model.

Inference: Amazon Bedrock model availability varies by region. Confirm the required models exist in each target region or select a local provider.

Many-to-One

Many front-end applications, one instance. Different branding, workflows and role sets over a common data set and detection engine.

  Wealth investigations UI    Fraud operations UI    Executive dashboard    Partner portal
  (CloudFront + S3)           (CloudFront + S3)      (CloudFront + S3)      (CloudFront + S3)
         │                          │                       │                     │
         │  API key / OIDC client   │  API key / OIDC client │  read-only role     │  scoped tenant
         └──────────────────────────┴───────────┬───────────┴─────────────────────┘
                                                ▼
                                     ALB ─► Purple8 Graph instance
                                             (primary + follower)

Aspect	Value
Instances	1
Front-ends	Any number. Each is an independent static deployment with its own CloudFront distribution, domain, branding and build configuration.
Authentication	Each front-end registered as its own OIDC client at the customer IdP, or issued its own API key
Authorization	RBAC roles, field-level and row-level policies, and optional `tenant_id` scoping determine what each front-end's users can see and do
Data	One data set. All front-ends see the same graph subject to their permissions.
Capacity	Aggregate write load across all front-ends is served by one writer. Size the instance for the sum.
Promotion	If one front-end's workload or isolation requirement outgrows the shared instance, move it to its own instance (One-to-One). No change to the remaining front-ends.

Use when several teams or business lines need distinct user experiences over the same cases, entities and detections, and separate data sets would fragment investigations.

Composition

 Customer
 ├── Instance: US  (One-to-Many member)
 │     ├── Wealth UI        ┐
 │     ├── Fraud Ops UI     ├ Many-to-One over the US instance
 │     └── Exec dashboard   ┘
 ├── Instance: EU  (One-to-Many member)
 │     ├── Wealth UI (EU)   ┐
 │     └── Compliance UI    ┘ Many-to-One over the EU instance
 └── Instance: Private banking  (One-to-One; separate account, own release schedule)
       └── Private banking UI

One-to-Many determines how many instances exist and where.
Many-to-One determines how many front-ends attach to each instance.
One-to-One is the degenerate case of both: one instance, typically one front-end, with the strongest isolation.

Region and zone summary

Pattern	Regions	AZs per instance	Cross-region data movement
One-to-One	1 (plus optional DR region)	2	None by default; optional DR replication
One-to-Many	1 per market	2	None. Aggregation reads APIs; no replication.
Many-to-One	1	2	None

Active-active multi-region writers are not supported in any pattern. A region hosts exactly one writer per instance.

Resiliency summary

Event	One-to-One	One-to-Many	Many-to-One
AZ loss	Follower promoted	Follower promoted in affected market; other markets unaffected	Follower promoted; all front-ends reconnect to the same ALB
Instance data loss	Restore from S3	Restore affected market from its regional S3	Restore from S3
Region loss	Optional DR follower or cold restore	Affected market only; optional DR per market	Optional DR follower or cold restore
Front-end failure	Redeploy static assets	Redeploy static assets	Affected front-end only; instance and other front-ends unaffected

Recovery point and recovery time depend on replication mode, instance size and backup frequency. Measure them during acceptance testing.

Selecting a pattern

Requirement	Pattern
Single jurisdiction, single business line	One-to-One
Multiple jurisdictions with residency constraints	One-to-Many
Multiple business lines or roles over shared cases	Many-to-One
Multiple jurisdictions, each with multiple business lines	One-to-Many, with Many-to-One per instance
A business line requiring auditor-demonstrable isolation from the rest	One-to-One for that line; other patterns for the rest

AWS Deployment Patterns ​

Instance definition ​

Application layer ​

Investigator UI ​

Purple8 Hyper Graph ​

Purple8 DocIntel ​

Inference ​

Identity ​

Integration ​

One-to-One ​

One-to-Many ​

Many-to-One ​

Composition ​

Region and zone summary ​

Resiliency summary ​

Selecting a pattern ​