Chapter 13: Helios SaaS, Marketplace Apps, and Automation

CCAE Exam Preparation — Interactive Study Guide

If Chapters 1 through 12 taught you how to design, deploy, secure, and protect data on individual Cohesity clusters, this chapter zooms out to the operating model an architect actually inherits in production: a fleet. Real CCAE-scale customers run anywhere from three or four clusters to several hundred, and they cannot afford for the same Gold protection policy to mean three different things in three different regions. The architectural answer is the Helios SaaS control plane plus the Marketplace and the automation stack.

Think of it this way: a single Cohesity cluster is a server. Helios is the cloud console for the whole fleet, and the automation tools are the deployment pipelines that keep that fleet in compliance with whatever the architecture document says it should be.

Section 1: Helios SaaS Control Plane

Helios Architecture and Tenancy Model

Cohesity Helios is delivered as a SaaS service that aggregates and centralizes management of every Cohesity cluster a customer owns, regardless of whether those clusters live on-premises, in a public cloud, or in a hybrid topology. From an architect's standpoint, Helios is the single pane of glass that turns a fleet of independent clusters into one logical, policy-governed estate.

Architecturally, Helios is a multi-tenant cloud service hosted by Cohesity. Each customer gets a Helios account (a tenant), and clusters are bound to that account during onboarding. Connectivity from cluster to Helios is outbound HTTPS over TCP/443 — Cohesity does not require any inbound openings on customer firewalls, which is exactly what enterprise security architects want to hear. The cluster establishes a long-lived TLS session to Helios, sends telemetry, accepts pushed configuration, and exposes a relay channel for "Launch Cluster UI" proxying.

Onboarding, Dashboards, and Federated Capabilities

Onboarding is intentionally trivial: in the cluster UI under Settings → Helios Registration, the admin enters Helios credentials, Helios issues a registration token, and the cluster establishes the outbound tunnel. For dark sites or air-gapped environments where outbound HTTPS is forbidden, Cohesity offers Helios Self-Managed, a customer-hosted variant of the Helios services that runs on customer infrastructure and provides equivalent fleet management without depending on Cohesity's SaaS — the standard answer for federal classified environments and certain regulated banks.

Helios presents a unified, real-time view that aggregates health, capacity, protection status, SLA compliance, and performance metrics from every managed cluster. Federated global search lets an admin search for a VM, file, mailbox object, or database backup by name across the entire fleet. Federated RBAC layers on top: granular roles can be scoped to specific clusters, regions, organizations, or object types, sourced from Okta, Azure AD/Entra ID, AD, or any SAML 2.0 IdP.

Helios-Only Features

• DataHawk — ML-based ransomware detection, threat intelligence (YARA), and data classification, scoring backup ingest patterns across the fleet.
• FortKnox — managed cyber vault that air-gaps an immutable copy of backups in a Cohesity-operated cloud tenant.
• Cross-cluster anomaly detection — sudden change-rate spikes correlated across the fleet, only computable globally.

Figure 13.1 — Helios SaaS topology (mermaid)

Key Takeaway: Helios converts N independent Cohesity clusters into one managed estate over outbound-HTTPS only. Backup data stays put; metadata flows up; and Self-Managed Helios covers the dark-site case.

Section 2: Helios as a Service (HaaS) and DMaaS

Helios is not just a console; it is also the entry point and management surface for Cohesity's Data Management as a Service offerings. DMaaS shifts the operating model from "I run the cluster" to "I subscribe to backup outcomes" — Cohesity operates the underlying clusters in the cloud, and the customer consumes them through Helios.

DataProtect Delivered as a Service

DMaaS bundles DataProtect, replication, archive, and recovery as a fully managed SaaS service. The customer points sources (VMs, M365 tenants, databases, NAS) at the DMaaS endpoint; Cohesity provisions the underlying SpanFS capacity, runs the backup jobs, manages upgrades, and meters consumption. There is no cluster to bootstrap, no node to replace, and no version to upgrade — the SLA covers the platform.

Region Selection and Data Residency

DMaaS is provisioned into specific cloud regions (AWS or Azure, depending on offering). The architect's job is to map regulatory boundaries — GDPR for EU data, sovereignty laws in countries like Germany, Switzerland, India, Australia, Canada — to a region selection. Backup data carries the same residency obligations as primary data; picking a US region for an EU tenant's M365 backups is not an option you can quietly hand-wave past an auditor. Helios surfaces region choice during DMaaS subscription and pins data residency for the lifetime of the tenant.

Subscription and Licensing Implications

DMaaS is sold on a subscription basis (typically per FETB-month or per workload tier), versus the perpetual or term license model common to self-managed DataProtect. This shifts the economics from CapEx + ongoing maintenance to pure OpEx. Architects sizing DMaaS apply the same FETB and change-rate inputs from Chapter 3 but must additionally model:

• Egress — recall traffic leaving the cloud, billed by the cloud provider through Cohesity's pass-through.
• Long-term retention — DMaaS includes integration with cloud archive tiers (S3 Glacier, Azure Archive).
• Replication scope — replication between DMaaS regions or between DMaaS and self-managed clusters is supported and factored into subscription tiers.

On-Prem vs. SaaS — Comparison

Key Takeaway: DMaaS is DataProtect-as-a-managed-SaaS. Architects pick a region for residency, subscribe by FETB/workload, and consume backup as an outcome rather than an appliance.

Section 3: Marketplace Apps

The Cohesity Marketplace is the storefront and delivery mechanism for first- and third-party applications that run directly on the Cohesity DataPlatform. The architectural value proposition is compute at data: instead of egressing backup data to a separate analytics, AV, or compliance system, applications run in containers next to SpanFS where the data already lives.

App Framework, Apollo, and Isolation

Apps are packaged as Docker images plus a Cohesity AppSpec — a Kubernetes-style YAML descriptor extended with Cohesity-specific fields. The cluster's container runtime, Apollo (introduced in the Pegasus 6.3 release line), executes the image. The AppSpec declares resources, view mounts, network requirements, and lifecycle hooks.

apiVersion: cohesity.com/v1
kind: App
metadata:
  name: clamav-scanner
  version: 1.4.0
spec:
  image: cohesity-marketplace/clamav:1.4.0
  resources:
    cpu: "2"
    memory: "4Gi"
  views:
    - name: vm-backups
      mountPath: /mnt/backups
      mode: ReadOnly
  network:
    egress: false
  lifecycle:
    onStart: /opt/clamav/scan.sh

Three security properties matter:

1. views — the only sanctioned data path. The app sees backup data through view mounts (NFS/SMB-backed), restricted to admin-authorized views. There is no direct SpanFS access.
2. network.egress: false — apps can be locked into air-gapped operation, supporting dark-site and high-security deployments.
3. resources — Apollo enforces CPU/memory quotas, so a misbehaving app cannot starve the cluster.

Marketplace Access and Vetted Apps

Custom App Development

Cohesity ships two SDKs: the App SDK (primitives like cohesity_mount for view mounting) and the Management SDK (REST API surface from inside the container). The publish flow is build → AppSpec validate (appspecvalidator) → Cohesity vetting (developer@cohesity.com) → list. Vetting + isolation + view scoping form a defense-in-depth posture that makes "third-party code on my backup cluster" an acceptable architectural decision.

Key Takeaway: Marketplace turns a Cohesity cluster into a compute-at-data platform — Docker containers isolated by Apollo, scoped to admin-authorized views, with optional internet air-gap.

Section 4: Automation Stack

Helios and Marketplace solve the interactive operating model. The programmatic operating model is REST API v2 plus the language-specific wrappers — Terraform, Ansible, and PowerShell. At CCAE scale, automating policy and protection-group management is the only scalable path; manually clicking through hundreds of policies across dozens of clusters is both error-prone and untraceable.

REST API v2 — the bedrock

All higher-level tools sit on top of the cluster's REST API v2 (cluster 6.3.1+). It covers protection groups, policies, sources, storage domains, views, alerts, recoveries, and tenants. Direct REST is the right choice when no higher-level wrapper exists, or for purpose-built integrations with ITSM (ServiceNow), SIEM (Splunk, Sentinel), or custom self-service portals.

TOKEN=$(curl -sk -X POST https://cluster.example.com/v2/mcm/access-tokens \
  -H 'Content-Type: application/json' \
  -d '{"username":"admin","password":"'"$PWD"'","domain":"LOCAL"}' \
  | jq -r .accessToken)

curl -sk -H "Authorization: Bearer $TOKEN" \
  https://cluster.example.com/v2/data-protect/protection-groups

Tool Selection — Comparison

Architect rule of thumb: Terraform for cluster-side IaC, Ansible for source-side push, PowerShell for Windows-native ops, REST when nothing else fits. All four are thin layers over REST API v2 — pick the right ergonomics for the job.

Figure 13.4 — Tool selection decision tree (mermaid)

Worked Example: Terraform Module — Gold Policy + Protection Group

The architectural payoff: every Cohesity cluster in the fleet has a Gold-1h-30d-1y policy that means exactly the same thing — 1-hour incremental, 30-day local retention, 1-year archive, app-consistent VMware snapshots, indexed for search, weekly archive cadence. A change request to extend retention to 45 days is a one-line PR that cascades to every cluster on merge.

resource "cohesity_protection_policy" "gold" {
  name        = "Gold-1h-30d-1y"
  description = "Tier 1: 1h RPO, 30d local retention, 1y archive"

  backup_policy {
    regular {
      incremental {
        schedule { unit = "Hours" hour_schedule { frequency = 1 } }
      }
      retention { unit = "Days" duration = 30 }
    }
  }
  remote_target_policy {
    archival_targets {
      target_id = var.archive_target_id
      schedule  { unit = "Weeks" frequency = 1 }
      retention { unit = "Years" duration = 1 }
    }
  }
}

resource "cohesity_protection_group" "tier1_vms" {
  name        = "Tier1-VMware-Gold"
  policy_id   = cohesity_protection_policy.gold.id
  environment = "kVMware"
  vmware_params {
    source_id  = var.vcenter_source_id
    object_ids = var.vm_object_ids
    app_consistent_snapshot = true
    indexing_policy { enable_indexing = true }
  }
}

Key Takeaway: Treat backup configuration as code. Pair Terraform (cluster-side) with Ansible (source-side), use PowerShell for Windows ops, and call REST when nothing else fits. Every cluster in the fleet gets the same Gold policy from the same Git PR.

Chapter Summary

Helios is the architectural answer to fleet sprawl — a SaaS control plane with outbound-HTTPS-only connectivity that converts any number of independent Cohesity clusters into one managed estate, with shared dashboards, federated RBAC, global search, anomaly detection, and centralized policy authoring. Helios Self-Managed delivers the same model on customer infrastructure for dark sites. DMaaS extends Helios into a fully managed subscription where Cohesity operates the cluster — region selection pins residency.

The Marketplace brings third-party compute to where the data already lives: Apollo (Docker runtime) executes apps declared by AppSpec YAML, isolated by container boundaries, scoped to admin-authorized view mounts, optionally air-gapped. The automation stack — REST API v2 plus Terraform, Ansible, and PowerShell — is the programmatic counterpart, with Git, CI/CD, and policy review keeping the fleet honest.