Cloud Deployment Architectures
The Ozone Orchestrator runs today on Google Cloud, but nothing above the infrastructure line is tied to it. The microservices, the event bus, the relational databases, Keycloak, and the telemetry stores are all standard containers, so a move to AWS or Azure is a swap of managed services, not a rewrite. This page records the current GCP footprint and gives an enterprise-grade reference architecture for AWS and Azure next to it, with a portability matrix, so when the team decides to migrate, the target is already drawn.
The GCP deployment described in Section 1 is what runs today. The AWS (Section 4) and Azure (Section 5) blueprints are target-state reference designs, not yet deployed. They describe the enterprise-grade managed footprint the platform would adopt on either cloud. The application layer (Section 6) is identical across all three.
The single customer entry point is ozone.techforcz.com on every cloud. The domain does not change with the infrastructure, so a migration re-points DNS at the new ingress and keeps the same URL.
1. Current deployment (GCP)
Production runs as a single cost-optimised node, not a Kubernetes fleet. This is deliberate: it keeps the running cost low while the platform matures, and the same Compose stack is what developers run locally.
| Concern | What runs today |
|---|---|
| Compute | A cloud VM in your region running the full Compose stack |
| Ingress / TLS | Cloudflare Tunnel (cloudflared on the VM); TLS terminates at the Cloudflare edge, no inbound ports on the VM |
| Relational DB | managed PostgreSQL (Cloud SQL), reached through a proxy sidecar with IAM auth, no key files |
| Cache, TSDB, OLAP, bus | Redis, VictoriaMetrics, ClickHouse, NATS JetStream, all as containers on the VM |
| Identity | Keycloak as a container |
| Deploy | Pull-based: the VM re-deploys when the release branch advances |
The end-to-end platform topology is in Platform Architecture.
2. Platform services (cloud-agnostic)
These services are the same on every cloud. Only where they store data and how they are fronted changes.
| Service | Responsibility |
|---|---|
| api-gateway | Single ingress: verifies the user JWT, per-user rate limit, the collector ingest receiver with per-tenant ingest rate limiting, batch decode/decrypt and fan-out to tenant-scoped subjects, reverse-proxy, serves the SPA, hosts the billing router |
| auth-service | Signup and login, user JWTs plus offline-verifiable edge tokens, environments (tenants), Keycloak OIDC |
| tenant-service | Tenant and account lifecycle, quotas |
| collector-registry | Collector registration, one-time tokens, long-lived collector JWTs, heartbeats, and the authoritative fleet-wide collector state, lifecycle, and group operations |
| correlation-engine | Graph correlation, event linking |
| ai-engine | Anomaly detection, forecasting, RCA, the context builder |
| alerting-engine | Dedup, suppression, escalation, routing |
| licensing-service | Signed tier licences, feature gating |
| billing-service | Subscriptions and checkout |
| inventory-service | CMDB device catalog |
| notification-service | Internal dispatcher for alert and escalation events (consumes NATS alert/insight subjects); it has no customer-facing connector UI. Customer-facing operational integrations are configured and delivered on-prem by the collector (see Integrations) |
| audit-service | Immutable audit trail |
| ai-triage | The LLM triage brain (agent, read-only tools, retrieval-augmented context) |
| frontend | React SPA, served single-origin through the gateway |
Network topology, per-service SLO and error-budget tracking, and capacity forecasting are delivered at the on-prem collector tier rather than as cloud services. The full AI internals are in AI Intelligence.
3. Cloud portability matrix
This is the migration cheat-sheet. Each row is a capability the platform needs, and the managed service that provides it on each cloud. Anything marked "self-managed" runs as a container on the cluster and does not change between clouds.
| Capability | GCP (current) | AWS (target) | Azure (target) |
|---|---|---|---|
| Container orchestration | GCE VM + Docker Compose | Amazon EKS (Kubernetes) | Azure AKS (Kubernetes) |
| Relational database | managed PostgreSQL (Cloud SQL) | Amazon RDS for PostgreSQL (or Aurora PostgreSQL) | Azure Database for PostgreSQL Flexible Server |
| Database auth | cloud-sql-proxy + IAM (ADC) | RDS IAM auth + Secrets Manager | Entra ID auth + Key Vault |
| Object storage | not deployed | Amazon S3 | Azure Blob Storage |
| Cache and rate-limit | Redis (self-managed) | Amazon ElastiCache for Redis | Azure Cache for Redis |
| Time-series metrics | VictoriaMetrics (self-managed) | VictoriaMetrics on EKS (or Amazon Managed Service for Prometheus) | VictoriaMetrics on AKS (or Azure Monitor managed Prometheus) |
| Log and event OLAP | ClickHouse (self-managed) | ClickHouse on EKS (or ClickHouse Cloud) | ClickHouse on AKS (or ClickHouse Cloud) |
| Event bus | NATS JetStream (self-managed) | NATS JetStream on EKS | NATS JetStream on AKS |
| Ingress and TLS | Cloudflare Tunnel | AWS ALB + ACM certificate | Azure Application Gateway (WAF) |
| CDN and edge WAF | Cloudflare | Amazon CloudFront + AWS WAF | Azure Front Door (WAF) |
| DNS | Cloudflare DNS | Amazon Route 53 | Azure DNS |
| Secrets | .env injected at runtime | AWS Secrets Manager | Azure Key Vault |
| Workload identity | GCE service account + ADC | IAM Roles for Service Accounts (IRSA) | AKS Workload Identity (Entra) |
| Identity provider (SSO) | Keycloak (self-managed) | Keycloak on EKS (Amazon Cognito optional) | Keycloak on AKS (Entra ID optional) |
| Container registry and CI/CD | Artifact Registry + pull-based CD | Amazon ECR + EKS + Helm | Azure ACR + AKS + Helm |
Reading the matrix by column gives a full deployment for that cloud. The two right-hand columns are drawn out below.
4. AWS reference deployment (target)
An enterprise-grade AWS footprint runs the platform on EKS, with the stateful services split between managed AWS services (Postgres, Redis, object storage) and self-managed containers on the cluster (NATS, VictoriaMetrics, ClickHouse, Keycloak).
Topology and services
| Layer | AWS service | Notes |
|---|---|---|
| Edge | Route 53 + CloudFront + AWS WAF | ozone.techforcz.com resolves to CloudFront; WAF at the edge |
| Ingress | Application Load Balancer + ACM | TLS terminated with an ACM certificate; forwards to the EKS ingress |
| Compute | EKS with three node groups | system (t3.medium x2), compute (t3.large x3 for AI and correlation), data (r5.large x2 for ClickHouse and VictoriaMetrics) |
| Relational | RDS for PostgreSQL (Multi-AZ), or Aurora PostgreSQL | The platform's relational databases, including the AI/RAG store; automated backups and PITR |
| Cache | ElastiCache for Redis | Cache, rate-limit buckets, LLM budget counters |
| Object | Amazon S3 | ML model artifacts, plugin bundles, OVA images; the app's S3 client points straight at S3 |
| Secrets | AWS Secrets Manager | Database DSNs become RDS secrets; injected via the External Secrets Operator |
| Identity | IRSA (IAM Roles for Service Accounts) | Each service account maps to a least-privilege IAM role, replacing the GCE service account |
Region: us-east-1 (primary) + us-west-2 (DR)
VPC 10.0.0.0/16
Public subnets 10.0.1.0/24, 10.0.2.0/24, 10.0.3.0/24 (ALB, NAT)
Private subnets 10.0.11.0/24, 10.0.12.0/24, 10.0.13.0/24 (EKS nodes)
DB subnets 10.0.21.0/24, 10.0.22.0/24, 10.0.23.0/24 (RDS, ElastiCache)
DNS
ozone.techforcz.com -> CloudFront -> ALB -> EKS ingress (frontend + api-gateway)
5. Azure reference deployment (target)
The Azure footprint is the direct equivalent on AKS, using Azure's managed data services and Entra ID for workload identity.
Topology and services
| Layer | Azure service | Notes |
|---|---|---|
| Edge | Azure DNS + Azure Front Door (WAF) | ozone.techforcz.com fronted by Front Door with edge WAF |
| Ingress | Application Gateway | TLS termination and routing into the AKS ingress |
| Compute | AKS with three node pools | system (Standard_D2s_v5 x2), compute (Standard_D4s_v5 x3), data (Standard_E4s_v5 x2 for ClickHouse and VictoriaMetrics) |
| Relational | Azure Database for PostgreSQL Flexible Server | The platform's relational databases, including the AI/RAG store; zone-redundant HA, automated backups |
| Cache | Azure Cache for Redis | Cache, rate-limit buckets, LLM budget counters |
| Object | Azure Blob Storage | ML models, plugins, OVA; front Blob with an S3-compatible gateway if a native S3 API is required |
| Secrets | Azure Key Vault | DSNs and provider keys; injected via the Key Vault CSI driver |
| Identity | AKS Workload Identity (Entra) | Federated pod identity replaces the GCE service account; Entra ID is an optional external IdP alongside Keycloak |
Region: Central India (primary) + South India (DR)
VNet 10.10.0.0/16
AKS subnet 10.10.1.0/24
Data subnet 10.10.2.0/24 (PostgreSQL Flexible Server, Cache for Redis via private endpoints)
DNS
ozone.techforcz.com -> Front Door -> Application Gateway -> AKS ingress (frontend + api-gateway)
6. What stays the same across every cloud
The application layer does not know which cloud it is on. Migrating swaps the managed-service endpoints in configuration and leaves the rest untouched.
Event bus (NATS JetStream) streams and subjects:
| Stream | Subjects | Consumers |
|---|---|---|
| TELEMETRY | telemetry.metrics.>, telemetry.logs.>, telemetry.events.> | correlation-engine, ai-engine, alerting-engine, inventory-service |
| FLEET | fleet.heartbeat.>, fleet.registration.>, fleet.config.> | collector-registry |
| ALERTS | alerts.raw.>, alerts.correlated.> | alerting-engine, notification-service |
| INSIGHTS | insights.anomaly.>, insights.rca.> | alerting-engine, notification-service |
| AUDIT | audit.> | audit-service |
| LICENSING | licensing.validate.> | licensing-service |
Data stores: the platform's relational databases, including the AI/RAG store, keep the same roles; VictoriaMetrics (90-day retention), ClickHouse, and Redis keep the same roles too. Only the managed backend behind each changes. The AWS and Azure target designs add a managed object store (S3 or Blob) for model, plugin, and OVA artifacts; the current GCP deployment does not run one.
Identity and access: Keycloak (realm techforcz) provides SSO on every cloud. The RBAC model is five roles: SuperAdmin, TenantAdmin, Engineer, ReadOnly, Auditor. User JWTs are HS256, collector JWTs are 365-day HS256, and the edge token is RS256/JWKS for offline verification. These are described in Security & Compliance.
Security posture (target on any cloud): TLS in transit, signed container images and SBOM generation in CI, secrets from the cloud secret manager, private subnets for data services, and edge WAF. Service-to-service mTLS is a hardening target, not yet shipped; the collector-to-SaaS channel is bearer JWT plus ingest token over TLS today (see Security & Compliance).
7. Migration approach
Because the app layer is portable, a GCP-to-AWS or GCP-to-Azure move is a staged cutover rather than a rebuild:
- Stand up the target cluster (EKS or AKS) and deploy the platform Helm charts, with NATS, VictoriaMetrics, ClickHouse, and Keycloak as self-managed workloads.
- Provision the managed data services for that cloud from the matrix in Section 3 (Postgres, Redis, object storage), and wire each service's
DATABASE_URL, Redis, and object-store endpoints through the cloud secret manager. - Migrate data:
pg_dumpand restore the logical databases into the target Postgres, copy any object artifacts into S3 or Blob, and let VictoriaMetrics and ClickHouse rebuild from the collector store-and-forward stream or from a snapshot. - Re-point DNS: move
ozone.techforcz.comto the new edge (CloudFront/ALB or Front Door/Application Gateway). Because the domain does not change, collectors and users keep the same URL. - Cut over collectors: no collector change is needed. They dial out to
ozone.techforcz.comover TLS, so the DNS switch moves the fleet with no on-site work.
| Related | Link |
|---|---|
| The end-to-end platform topology | Platform Architecture |
| Identity, RBAC, and the security boundary | Security & Compliance |
| Tenant onboarding and day-2 operations | SaaS Workflows |