AWS-Client Hosted Tenant on AWS — Documentation
2 min read
Public-facing documentation for deploying Unique AI as a Client Hosted Tenant (CHT) on AWS. Written for the client's cloud, security and platform architects. All references are generic ("the client") and the technical content follows Unique's AWS Reference Architecture.
What is a Client Hosted Tenant?
In a CHT deployment the client owns the AWS account(s) and the underlying cloud environment. Unique deploys and operates the application layer (EKS workloads, GitOps, application and AI services) on top of that environment but cannot access the client's underlying data. The result: the client keeps full data sovereignty and control of the cloud perimeter, while Unique owns the application lifecycle.
Why choose CHT?
Data residency & sovereignty — all data stays inside the client's own AWS account and region.
Regulatory / compliance — the client's guardrails (SCPs, AWS Config) and audit tooling apply to the whole estate.
Separation of duties — Unique operates the app layer without access to underlying data.
Landing-zone conformance — the workload conforms to the client's existing AWS Organization / landing zone.
Shared responsibility
Area | The client owns | Unique operates |
|---|---|---|
AWS accounts & Organization | Account ownership, OU placement, SCP guardrails, AWS Config | — |
Network perimeter | VPC/CIDR design, connectivity (Direct Connect / TGW), egress policy, DNS delegation | In-cluster ingress (ALB + Kong), VPC-endpoint requirements |
Identity | IAM Identity Center, human SSO, break-glass policy | Workload identity (EKS Pod Identity), app IdP (Zitadel) |
Data | Data at rest in the account; KMS CMK ownership | Application data lifecycle; no access to underlying data stores |
Application layer | — | EKS workloads, GitOps (ArgoCD), releases, app-layer SLAs |
Observability | Destination sinks / log drain targets | App metrics, logs, dashboards, alerting |
How this documentation is organized
The docs follow reader intent, from orientation through to day-2 operations:
Section | Read it to… |
|---|---|
Reference architecture | Understand the target design, layer by layer (accounts, network, compute, data, identity, observability). |
Plan your deployment | Make the three core choices — topology, network access model, data hosting model — and decide DEV/PRD segregation. |
Prepare & deploy | See prerequisites, responsibilities, the kick-off checklist, migration and timeline. |
Operate | Run the tenant: SLAs, monitoring & log drain, access and guardrail-drift handling. |
The three choices you will make
Most of the planning reduces to three independent axes (covered in Plan your deployment):
Account topology — standalone, hub-and-spoke, or hub-and-spoke with shared services.
Network access model — internal (Direct Connect + Transit Gateway), CloudFront (public), or dual.
Data hosting model — PaaS (managed) or cloud-native (in-cluster), chosen per service.