Chapter 10 — Cloud Integration: Archive, Tier, Replicate, and Spin

10.1.1 Long-Term Retention to Object Storage

CloudArchive is a copy-out mechanism. The cluster keeps a complete local snapshot — chunk files, blob files, and metadata — and additionally writes a deduplicated, compressed copy to a registered external target. The local cluster remains authoritative for indices and metadata so that catalog operations (browse, search, restore) can be answered without rehydrating cloud objects unnecessarily.

CloudArchive is driven by Protection Policies: each policy may attach one or more Archival actions, each referencing an External Target with its own retention horizon. A typical pattern: daily incrementals retained 30 days on cluster, weekly fulls 90 days on cluster, and monthly fulls retained 7 years in S3 Glacier Deep Archive via CloudArchive. Only the third tier leaves the cluster.

10.1.2 Encryption and Immutability Options

CloudArchive honors the cluster's encryption posture end-to-end. Data leaves the cluster over TLS 1.2+ and is written at rest as AES-256. When the target is AWS S3, Cohesity can also use SSE-S3 or SSE-KMS server-side encryption, the latter requiring kms:Encrypt, kms:Decrypt, and kms:GenerateDataKey permissions on the customer-managed key.

Immutability for ransomware-resistant archives uses S3 Object Lock (AWS) or the equivalent Immutable Blob Storage (Azure). Cohesity sets per-object retention via the s3:PutObjectRetention API as objects are written. Object Lock must be enabled at bucket creation — it cannot be retrofitted without contacting AWS Support.

10.1.3 Indexing for Cloud-Archived Snapshots

The Cohesity index (Yoda) stays on the cluster. Two consequences:

1. You can browse and search archived snapshots without paying retrieval fees. The metadata is local; only the actual chunk data lives in Glacier.
2. If the originating cluster is destroyed, you must rebuild the index from cloud-resident metadata before recovery is fast. This is one of the principal differences between CloudArchive (cluster-authoritative) and FortKnox cyber vaulting (Cohesity-managed).

10.1.4 Direct Archive vs. Archive on Policy

• CloudArchive (standard) — default; archive copy is created via a Protection Policy.
• CloudArchive Direct — streaming variant: data flows through the cluster but is not retained as a full local copy — only metadata and index live on cluster, while bulk data is streamed directly to the external target. Appropriate for decommissioned apps retained only for compliance.

10.2.1 Capacity Tiering for Cold Blocks

CloudTier is a move operation, not a copy. The cluster's tiering engine continuously profiles block heat: blocks not accessed for the configured threshold are migrated out to cloud object storage, freeing local capacity. The cluster retains a pointer (a stub) so the namespace appears unchanged — when the data is needed, it is rehydrated transparently.

Because tiering moves data, CloudTier is irreversible without a recall operation. If you tier 500 TB out to S3 Standard-IA, you cannot simply "untier" by toggling a setting — you must recall the data, which counts as a full read against the object store and incurs egress and request charges.

10.2.2 Tiering Thresholds and Recall Behavior

• Age-based: "tier any block not read in 90 days."
• Capacity-based: "begin tiering when the View Box exceeds 80% utilization."
• Hybrid: tier opportunistically by age, urgently by capacity pressure.

10.2.3 Performance Impact Considerations

• Aggressive thresholds (e.g., "tier anything older than 7 days") tier blocks that will be read by month-end backups, causing recall storms.
• Disaster recall storms — rehydrating 100 TB of tiered data through WAN bandwidth and cloud egress quotas can dominate RTO. Plan this scenario explicitly.
• Cluster cache effect — recalled blocks repopulate the local tier, so recurring workloads stop hitting the cloud after the first recall.

10.2.4 Tier vs. Archive Trade-offs

The two patterns are complementary, not mutually exclusive. A common enterprise design tiers cold backup blocks to S3 Standard-IA (CloudTier) and copies monthly fulls to Glacier Deep Archive (CloudArchive).

10.3.1 CloudReplicate to a Cohesity Cloud Edition

CloudReplicate is conceptually identical to cluster-to-cluster replication, except the destination cluster is a Cohesity Cloud Edition running inside AWS, Azure, or GCP. The replicated data lands on a fully-functional Cohesity cluster, so all DataPlatform features (instant mass restore, indexing, granular search) are available on the cloud side.

CloudReplicate is the right answer when:

• The DR strategy requires a functioning Cohesity control plane in the cloud.
• RTO requirements exclude a slow rehydration from object storage.
• Compliance permits the cluster's normal feature set in the cloud (DataLock, indexing).

The cost profile is meaningfully higher than CloudArchive — you are paying for cluster compute (EC2 or Azure VMs running Cohesity), local SSD/EBS, and replication network — but the recovery posture is dramatically better.

10.3.2 Converting Backups to Native Cloud VMs (CloudSpin)

CloudSpin converts an on-prem VM backup into a native cloud VM — EC2, Azure VM, or GCE instance — without requiring a Cohesity cluster on the destination side. The flow:

1. Reads the VM backup from local cluster (or recalls from CloudArchive if needed).
2. Converts the disk format (VMDK or VHDX → AMI for AWS, managed disk for Azure).
3. Boots the VM into the target VPC/VNet with the chosen instance shape.

CloudSpin use cases:

• Test/dev cloud bursting — spin a copy of a production VM in the cloud for a stress test, then destroy it.
• Forensic investigation — boot a known-clean snapshot in an isolated VPC for malware analysis.
• Cloud migration trial runs — validate a workload runs in EC2 before lift-and-shift.

CloudSpin is not a continuous DR replication mechanism — each spin is a discrete conversion job.

10.3.3 Network and IAM Prerequisites

• Outbound HTTPS (port 443) to the cloud control plane endpoints.
• IAM credentials with permission to create EC2/Azure VM resources, manage EBS/managed disks, and configure VPC/VNet network interfaces.
• VPC/VNet design with appropriate subnets, security groups, and route tables.
• For CloudReplicate: a registered Cloud Edition cluster as the destination.

The IAM minimums for CloudSpin in AWS include ec2:RunInstances, ec2:CreateVolume, ec2:AttachVolume, ec2:CreateImage, ec2:RegisterImage, iam:PassRole, plus S3 actions if the backup is in object storage.

10.3.4 Test Recovery and Clean-Up

SiteContinuity wraps CloudSpin and CloudReplicate in runbooks supporting test failover, planned failover, and failback. Always include a destroy step in the runbook — spun cloud VMs accrue compute charges as long as they run.

The single most exam-relevant artifact in this chapter is the decision matrix below. Memorize it.

Exam tip: "Cluster at 85% capacity, customer wants cold backups online 90 more days, budget tight" → CloudTier. "7-year compliance, ransomware-resistant copies off-cluster" → CloudArchive with Object Lock. "Quarterly DR test in AWS without standing up another Cohesity cluster" → CloudSpin.

Figure 10.1: Cloud option decision tree (Mermaid)

The AWS Glacier flow is the most exam-tested external target configuration. Cohesity documents a five-step pattern.

Five-step workflow

10.5.1 Step 1 — Register the External Target

Navigate to Inventory > External Targets > Register External Target. Configure name, Purpose: Archival (not Tiering — this one-character mistake defines the target's whole behavior), Provider (AWS > S3), bucket, region, access key, secret key, and storage class.

10.5.2 Step 2 — IAM via the Cohesity CloudFormation Template

The CFT provisions a least-privilege IAM role. Required actions:

s3:PutObject
s3:GetObject
s3:DeleteObjectVersion
s3:RestoreObject              ← required to recall from Glacier
s3:PutLifecycleConfiguration
s3:GetLifecycleConfiguration
s3:GetBucketObjectLockConfiguration
s3:PutObjectRetention         ← required for Object Lock / WORM
iam:SimulatePrincipalPolicy
kms:Encrypt
kms:Decrypt
kms:GenerateDataKey           ← required for SSE-KMS

The CFT-generated role is the right answer on the exam — never grant s3:* or ec2:*.

10.5.3 Step 3 — Bucket Policy

Authorize the Cohesity role explicitly:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"AWS": "arn:aws:iam::<ACC>:role/<COHESITY-ROLE>"},
    "Action": ["s3:PutObject","s3:GetObject","s3:RestoreObject","s3:PutObjectRetention"],
    "Resource": "arn:aws:s3:::your-bucket/*"
  }]
}

10.5.4 Step 4 — S3 Lifecycle Rule

The lifecycle rule lives on the bucket, not in Cohesity. Cohesity manages retention; the bucket lifecycle manages storage class.

Respect the minimum storage durations: Standard-IA 30 days, Glacier 90 days, Deep Archive 180 days. Early deletion triggers a charge equal to the remaining minimum days.

10.5.5 Step 5 — Bind to a Protection Policy

Edit a Protection Policy, add an Archival action targeting the new external target, define retention, attach to a Protection Group, validate, and run.

10.5.6 Glacier Pricing and Minimum Retention

10.6.1 The Minimum Role — Storage Blob Data Contributor

The single role a CCAE candidate must remember is Storage Blob Data Contributor. It grants:

• Read, write, and delete on blobs.
• The setBlobTier/action data action — required for tier transitions to Archive.
• Sufficient for backup, archive, list, and restore against the target container.

What it does not grant: control-plane operations like creating storage accounts. That is Storage Account Contributor — a control-plane role that does NOT grant data-plane access. Assigning Reader or Storage Account Contributor alone causes confusing 403 errors when the cluster tries to write objects.

10.6.2 Authentication Model — Entra ID Service Principals Preferred

1. Microsoft Entra ID service principal with RBAC — the recommended pattern. Use a managed identity if the cluster runs in Azure.
2. Shared Access Signature (SAS) — time-limited tokens; rotation risk. Avoid in production.
3. Storage Account Access Keys — easiest, full account access, hardest to revoke.

10.6.3 setBlobTier and the Azure Archive Tier

To move a blob to Azure's Archive tier, the principal must have:

Microsoft.Storage/storageAccounts/blobServices/containers/blobs/setBlobTier/action

Included in Storage Blob Data Contributor. Rehydration: up to 15h Standard or up to 1h High priority.

10.6.4 Private Endpoints — Production Networking

1. Provision an Azure Private Endpoint on the storage account's blob sub-resource.
2. Approve the connection in Networking > Private endpoint connections.
3. Ensure the cluster VNet resolves privatelink.blob.core.windows.net via Azure Private DNS.
4. Lock the storage account firewall to Cohesity public IPs / VNet / service tags if any public access is permitted.

Common pitfall: private endpoint configured but DNS pointed at the public Blob endpoint — traffic falls back, gets blocked, archives fail.

10.7.1 S3 and Azure Class Mapping

10.7.2 The Three Cost Components

1. Storage — $/GB-month at rest.
2. Requests — per-API-call PUT, GET, RESTORE. Glacier and Archive request fees can dominate when many small objects are archived.
3. Egress — outbound data transfer. AWS charges roughly $0.09/GB egress to Internet. Cross-region ~$0.02/GB. Within-region to AWS services typically free.

10.7.3 Worked Example — 100 TB Disaster Recall

Scenario: 500 TB archived to Glacier Deep Archive over 4 years. Ransomware destroys the production environment. Customer must recall 100 TB to a new on-prem cluster.

Architectural lessons:

• Egress dominates the recall event. Recalling within AWS makes egress effectively free.
• Storage is cheap; recall is not. Design recall destinations to keep traffic in-region.
• Bandwidth may be the real constraint. 100 TB over 1 Gbps WAN ≈ 9 days; AWS Snowball Edge ships 80 TB devices for offline recall.

10.7.4 Lifecycle and Retention Best Practices

• Match Cohesity retention to bucket lifecycle expiration, with a small safety margin so orphans get cleaned but Cohesity-managed objects are never prematurely deleted.
• Stage transitions: Standard → IA at 30d → Glacier at 90d → Deep Archive at 180d. Avoids early-deletion charges.
• Test rehydration windows quarterly. A 12h rehydration on a 50 TB recall is real RTO cost — put it in the runbook.