Architecture and responsibilities
This runbook covers the managed installation in a dedicated customer AWS account.
Concept · Updated 2026-10-15 · Describes release 0.1.164
Evidence reviewed 8 October 2026; operating baseline 0.1.130 (the 16 October 2026 handover build; see the release notes).
This runbook covers the managed installation in a dedicated customer AWS account. The operating baseline is 0.1.130, the handover build; the procedures were verified on 0.1.108 and re-read against the 0.1.130 release notes. Use a later release only after its release record identifies the image and chart to deploy.
Who owns each part
| Part | Responsible team | Routine responsibility |
|---|---|---|
| Dedicated AWS account, organization policies, quotas and billing | Customer cloud team | Approve the account boundary and regional access; maintain payer-account budgets and cloud access |
| Bootstrap IAM role and cluster emergency access | Customer cloud team | Run the supplied bootstrap, retain an IAM principal able to administer EKS, review CloudTrail |
| Platform hostname and DNS | Owner of the DNS zone | Maintain the platform CNAME and ACM validation CNAME; keep records DNS-only |
| Release images, OCI chart and deployment pipeline | Vendor release team | Publish a release, maintain the customer branch and pipeline secret group, supply deployment evidence |
| Deployment approval | Named customer approver | Read every infrastructure plan and release a run in an agreed maintenance window |
| Platform administration | Customer platform administrators | Users, workspaces, model pricing, runner health, audit checks and incident response |
| Estate connections and signals | Customer workspace owners and monitoring teams | Grant read access, test connections, maintain ingest tokens and alert routing |
| Remediation decisions | Authorized customer operators and approvers | Review and release plans; maintain execution credentials separately from investigation access |
| Backups, recovery and security reviews | Customer cloud and security teams with the release team | Verify backups, retain encryption keys, rehearse recovery and archive audit evidence |
These are operating responsibilities, not response-time commitments. Agree named contacts using Support and escalation.
What runs where
| Component | Location and purpose | Data boundary |
|---|---|---|
| Control plane | One platform pod in the customer EKS cluster; portal, Ops console, APIs, intake, scheduler and coordination | Owns the PostgreSQL connection, tenant secret-store key, persistent records and audit trail |
| Workspace runner | A separate pod per workspace; claims durable work and executes investigations and discovery | Customer default is API mode: workspace-scoped token, no database credential or secret-store key; resolves that workspace's investigation credentials |
| Private-network agent | Customer-managed deployment where private estate endpoints are reachable | Connects back to the control plane with a scoped agent token; run it only with the estate read permissions it needs |
| PostgreSQL | Private RDS instance, Multi-AZ in the customer template | Incidents, investigations, settings, encrypted stored credentials and audit chains |
/data volume |
Single-zone EBS volume attached to the control plane | Derived skill and connection files; DuckDB lake data is re-collected after loss |
| Vendor pipeline | Azure Pipelines; assumes the customer deploy role for a run | Terraform state and release chart remain on the vendor side; they are not copied into the customer account |
In remote mode the control plane queues work and runners checkpoint each step through it. A failed runner resumes durable work after its lease expires, subject to the attempt limit. This is separate from platform availability: the control plane is one replica with a single-zone volume. Multi-AZ RDS does not make the portal or scheduler multi-AZ. See Availability and recovery.
Access and data decisions to retain
- Keep the account dedicated. The current deployer policy can effectively grant itself account administrator access; a permissions boundary is not delivered. Its trust restricts assumption to the vendor pipeline, with an ExternalId and operator SourceIdentity. Review that accepted risk before a production install.
- Store the onboarding secrets file in a vault. Losing the tenant secret-store key loses access to the credentials encrypted with it. A database backup alone does not replace that key.
- Keep estate permissions read-only at their source. Execution-only credentials are excluded from agent registries and are resolved by the approved execution path. A compromised runner can still read the credentials and evidence it legitimately needs for its own workspace.
- The customer template from 0.1.109 lets both control-plane and runner roles call
sts:AssumeRoleandsts:TagSessiononarn:aws:iam::*:role/aiops-*. Review every estate role that trusts those identities and its workspace External ID. The platform's own account uses a staff-prepared pair; a same-account trust naming the control plane must not bypass that account-selection restriction. - Confirm model region, endpoint and data-residency policy. Alert content, read-tool evidence and knowledge can enter model prompts. Configure the alert and tool-output PII controls according to that policy; storage scrubbing does not by itself prove every outbound prompt is scrubbed.
- The chart's runner NetworkPolicy needs network-plugin enforcement to be a boundary. Its presence alone proves no isolation. The metrics listener is unauthenticated and must stay inside the cluster.
Sources: Deployment runbook §0–1, Architecture, as-built design, Security review, accepted risks, and the /data decision.