Operate — CHT on AWS
3 min read
This page covers day-two operations for a live client-hosted tenant: what availability to expect, how the platform is monitored and how logs reach the client, and how access, break-glass and guardrail drift are handled.
It assumes the tenant is deployed and verified — see Prepare & deploy. For the components referenced here, see Reference architecture.
Availability & resilience
The platform is designed to run continuously with a high-availability target. Resilience is built in at several layers:
Multi-AZ — workloads and data services are spread across three Availability Zones, so the loss of a single zone does not take the tenant down.
Zero-downtime maintenance — platform and cluster upgrades roll through nodes and pods without a service outage, using rolling replacement and health-gated cutover.
Elastic scaling — a pod autoscaler reacts to load and a node provisioner adds capacity when pods cannot be scheduled, across a steady pool for baseline load and a rapid pool for bursts.
What availability depends on the client. This target covers the platform Unique operates. Client-owned foundations — the network hub, Direct Connect, identity provider and guardrails — sit outside that boundary; their availability contributes to the end-to-end experience and is the client's responsibility.
Monitoring & observability
The platform ships with a full observability stack so both Unique and the client have visibility into health and behaviour.
Signal | How it is collected | Where it goes |
|---|---|---|
Metrics | In-cluster monitoring stack (Prometheus-based), plus AWS Managed Prometheus / Grafana | Dashboards and alerts; retained for trend analysis |
Container & platform logs | Cluster log collection | CloudWatch in the client's account; drained to the client's SIEM as required |
AWS service & API activity | Configuration recording and API audit trail | Client's account; available to the client's audit tooling |
Health & alerting | Alerting rules on the metrics stack | Notifies the operating team on threshold breaches |
Log drain to the client
Because the tenant runs in the client's own account, all logs and audit records are generated and stored there. Platform and container logs land in CloudWatch; AWS activity is captured by the account's configuration recorder and API audit trail. From there the client can drain them into their own SIEM or log platform for retention and correlation with the rest of their estate. Unique does not need to hold a copy for the tenant to be observable.
Access & break-glass
Operational access follows least privilege and leaves an audit trail.
Federated, role-based access — human access is via IAM Identity Center permission sets, not long-lived IAM users. Access is scoped to what the role needs.
Workload identity — platform components authenticate to AWS services through EKS Pod Identity associations scoped per component, so each workload gets only the permissions it requires.
No standing bastion hosts — administrative access to nodes is via session management (SSM Session Manager), which is audited, rather than SSH over the network.
Break-glass — elevated, time-boxed access for incident response is granted through a defined break-glass procedure and is fully logged, so emergency access never means unaudited access.
Unique never accesses client data. The operational access above is scoped to running the platform. The client owns the account, the keys and the data; the CHT model means Unique operates the application layer without access to the client's content.
Guardrail & configuration drift
The service control policies and configuration rules agreed at deployment are not "set and forget". Over time, changes on either side can cause drift:
Detection — configuration recording continuously evaluates account state against the agreed rules and flags non-compliant resources.
Guardrail changes — if the client tightens or alters a guardrail after go-live, it can block actions the platform relies on. Coordinate guardrail changes with Unique so the platform's required actions stay permitted while controls remain enforced.
Remediation — drift is reviewed jointly; platform-side drift is corrected by the GitOps reconciliation loop, while account-side drift (network, keys, guardrails) is remediated by the client.
GitOps keeps the platform in its declared state. Platform configuration is reconciled continuously from source control, so unintended in-cluster changes are automatically corrected back to the declared state — reducing drift on the components Unique operates.
Upgrades & lifecycle
Unique maintains the platform: application, AI and platform-service upgrades are delivered through the GitOps pipeline with health-gated rollout, and cluster/node upgrades follow the zero-downtime maintenance model above. Client-owned foundations (account, network, identity, keys) are upgraded and patched by the client, coordinated with Unique where a change affects the platform.
Where to go next
Return to the documentation home, or revisit Plan your deployment to revisit a design choice.