Skip to main content
B BeY | Data Platform

Solution architecture

Six application layers, four cross-cutting layers, zero servers.

BeY is built exclusively on AWS managed services. There is no virtual machine, no application container and no orchestrator to administer: every layer is a service whose availability AWS operates, and billing follows actual use.

100% serverless Amazon Bedrock · Claude Haiku 4.5 Aurora Serverless v2 · PostgreSQL 16 Lambda python 3.12 API Gateway HTTP v2 Cognito · OAuth 2.0 + PKCE Terraform
Layered diagram of the BeY architecture: sources and consumers on the left; six application layers in the centre — ingestion and connectivity, storage, processing and engines, AI and assistance on Amazon Bedrock, API and identity, consumption and distribution; four cross-cutting layers on the right — security, governance, responsible AI, operations; and a DevSecOps delivery band underneath. Dashed items marked planned are on the roadmap.
Read it top to bottom: data enters at 1, is stored at 2, checked at 3, explained by the AI at 4, guarded at 5 and published at 6. The four blocks on the right apply to every layer; the band underneath is how it all ships. Dashed and marked “planned” means roadmap, not production.

The layers

What each layer does, and why it is separate.

Layer 1

Ingestion & connectivity

Two front doors: connectors, which reach into the customer's information system, and the file drop. Connectors run inside a VPC and egress through a NAT gateway — the only persistent network resource in the architecture. Credentials never pass through application code: a dedicated function reads them from Secrets Manager.

Whatever breaks the inbound contract goes to quarantine with its cause and is resubmitted once fixed. The silver layer normalizes and types what was accepted.

Layer 2

Storage

Aurora Serverless v2 (PostgreSQL 16) holds the model and the data, accessed through the RDS Data API over HTTPS — which keeps application functions out of a VPC. S3 holds datasets and exports, Secrets Manager the connection credentials, KMS the encryption keys at rest.

Why one schema for every tenant rather than one per customer: the second is easier to explain and far more expensive to run. Drift is inevitable, and every migration multiplies by the customer count.

Layer 3

Processing & engines

128 service modules, packaged as python3.12 Lambda functions in zip format. This is where the engines that make the product live: deterministic and probabilistic matching, reversible survivorship, the quality rule engine, the profiler, the lineage engine and drift detection.

Long-running work goes through an asynchronous queue and a dedicated worker: the HTTP call returns immediately with a job identifier.

Layer 4 · AI

AI & assistance

An assistant built on Amazon Bedrock (Claude Haiku 4.5) that does three things: it explains what is on screen, it helps decide by ranking what to fix next, and it automates the repetitive part of stewardship — synthesising quality rules from real profiles, inferring semantic types and PII, and proposing mass corrections.

Retrieval is real: catalogue assets are embedded with Titan Text Embeddings v2, so “find me something like this table” is a vector search, not a keyword match. A document knowledge base is the next step and is marked planned on the diagram.

The discipline is in the contract between tool and model. A tool returns a measure, never a sentence, so the assistant cites a figure instead of paraphrasing one. And it proposes in a closed vocabulary, carrying the identifiers it saw — so a person confirms exactly that list, not a vague “yes”.

Layer 5

API & identity

API Gateway HTTP v2, behind a dedicated domain and an ACM certificate, delegates to a JWT authorizer that validates the token signature against the Cognito public keys. Identity comes from Cognito (Hosted UI, OAuth 2.0 Authorization Code + PKCE).

The tenant_id and roles are read from the token claims, never from a request parameter. That is what makes multi-tenant isolation impossible to bypass from the client.

Layer 6

Consumption & distribution

The React console is served as static files from a private S3 bucket, exposed only through CloudFront via an Origin Access Control, with an SPA fallback for client-side routes. Other consumers go through the Pull API, webhooks or the data product marketplace.

Masking, filtering and message contracts apply on the way out: the policy follows the requester, not the dataset.

Cross-cutting

Security, governance, responsible AI, operations

Four concerns that cannot live inside one layer: encryption and isolation apply everywhere; policies and contracts are evaluated on ingestion as well as on output; every AI system is registered with its risk tier, its model card and its incidents, as the EU AI Act requires; and observability and FinOps measure the whole.

Underneath

Secure delivery — DevSecOps

Every layer above is built and shipped through one pipeline. Today it gates on a pinned static analyser for Python, a strict TypeScript type-check, deployment guards that fail the build, and a Terraform plan read with -detailed-exitcode so “code waiting to be applied” is reported rather than confused with a failure.

Security by design is the next stage, and it is not in place yet. The tools that get it there — static analysis, dependency and IaC scanning, secret detection, runtime protection, an SBOM, threat modelling — are named in the delivery section below, drawn dashed on the diagram and marked planned. A security posture you have not built yet is a plan, not a fact.

Delivery pipeline

Infrastructure is code — including this site's.

Four pieces are in the pipeline today. The security tooling that turns it into a DevSecOps pipeline is on the roadmap, and is named as such below rather than implied.

Terraform

Reusable modules — network, data, compute, API, identity, frontend, naming, tagging — and one environment per variable set.

CodeBuild

Frontend build, Lambda packaging, migration application, publication to S3 and CloudFront invalidation.

Migrations

The schema evolves through versioned migrations, applied once for every tenant. No manual fixes in the database.

Naming & tagging

A dedicated module enforces the naming convention and cost tags on every resource — which is what makes FinOps attribution possible.

Planned

SonarQube

Quality gate and static application security testing on every merge request, blocking on new issues rather than on the existing backlog.

Planned

Snyk

Software composition analysis across npm and Python dependencies and the Terraform modules — today the build runs npm ci --no-audit, which checks nothing.

Planned

Secrets & IaC scanning

Secret detection before commit and in CI, plus Checkov / tfsec policy checks on the Terraform plan.

Planned

Security by design

Threat-modelling reviews on new surfaces, an SBOM per release, and runtime protection: AWS WAF in front, GuardDuty and Inspector behind.

Questions about how this would fit your estate?

Every architecture meets a different one. Tell us what you run — sources, volumes, regulators — and we will tell you plainly what fits, what needs a pack, and what does not exist yet.