A Pilot Light cluster is a small NC2 cluster that runs all the time in your AWS DR region. It hosts Prism Central and Multicloud Snapshot Technology (MST). Critical VMs replicate straight to it. Everything else replicates as snapshots to S3. At failover you expand the cluster and run your recovery plans. Day to day you run it like any other production cluster, but sizing, networking and testing need attention up front.
Source of truth: Nutanix Disaster Recovery Guide (pc.7.6), section “DR Using Multicloud Snapshot Technology.”
1. Decide the two protection tiers
| Tier | Target | Replication | RPO |
|---|---|---|---|
| Critical | Pilot Light NC2 cluster | NearSync or Async | 1 to 15 min, or 1 hour |
| Everything else | S3 bucket via MST | Async only | 1 hour minimum |
Recovering from S3 takes longer than recovering from the cluster, so put only the VMs that can tolerate the higher RTO on the MST tier.
2. Size the pilot cluster for what lives on it
The cluster carries Prism Central, MST and the critical-tier VMs, plus headroom for the first recovery wave.
| MST size | VMs | vCPU | RAM | Limits |
|---|---|---|---|---|
| 1-Node | 2 | 12 | 28 GiB | 1,000 entities, 100 TB live data |
| 3-Node | 4 | 32 | 76 GiB | 2,000 entities, 300 TB live data |
| 5-Node | 6 | 52 | 124 GiB | 10,000 entities, 1 PB live data |
All sizes keep 100 recovery points per entity.
Multiple MST instances per Prism Central are supported starting with PC 7.6, for example to separate tenants or sites. Each instance needs its own dedicated bucket and its own IP allocation. The combined limit is 10,000 entities per Prism Central, and instances don’t share data or deduplicate across each other.
3. Build the network
- MST subnet: a dedicated /27 AWS subnet that isn’t shared with the Prism Element or Prism Central networks. Reserve 3 static IPs outside the DHCP pool, plus DHCP addresses for the MST VMs (7 IPs total for a 3-Node instance).
- The MST subnet must route to Prism Central and Prism Element.
- On-prem to MST: Pilot Light needs on-prem to reach the MST subnet in AWS over Direct Connect, VPN or Transit Gateway. Open TCP 30990 (control service) and TCP 30900 (data service) in both directions between the on-prem Prism Element network and the MST network.
- MST outbound: TCP 443 and DNS (port 53) to the regional S3 endpoint.
4. Keep replication off the internet and off the NAT Gateway
This is where most of the avoidable cost is. MST runs in the NC2 VPC and writes to S3 continuously. If the MST subnet reaches S3 through a NAT Gateway, every replicated gigabyte is billed at NAT data-processing rates for as long as the cluster runs.
- Add an S3 Gateway VPC Endpoint and associate it with the MST subnet’s route table. S3 traffic then stays on the AWS network. Gateway endpoints have no hourly or per-GB charge.
- Put the bucket in the same region as the NC2 cluster. Cross-region adds transfer charges and latency.
- Add an endpoint policy that scopes the gateway endpoint to the MST bucket.
- Use Direct Connect for on-prem to AWS. Inbound data transfer into AWS is free. Failback traffic leaves AWS, and Direct Connect egress costs far less than internet or VPN egress (~$0.09/GB).
- Gateway endpoints only serve traffic that starts inside the VPC. If anything on-prem reads from or writes to S3 directly, such as a restore pulled back on-prem, use an S3 Interface Endpoint (PrivateLink) over Direct Connect, with on-prem DNS forwarding to a Route 53 Inbound Resolver. See Cutting the Cord: Cost Saving up to 65% on Nutanix MST Restores on AWS.
Example: 2 TB of changed data a day, or about 60 TB a month.
| MST to S3 path | Rate (us-east-1 list) | Monthly | Annual |
|---|---|---|---|
| Through NAT Gateway | $0.045 / GB processed | ~$2,765 | ~$33,000 |
| S3 Gateway Endpoint | No charge | $0 | $0 |
5. Prepare the S3 bucket
- One bucket per MST instance, used only by MST. Sharing it risks data loss or corruption.
- Object Lock disabled. MST doesn’t support Object Lock on its snapshot bucket.
- IAM user or role with read and write access to the bucket. Add
kms:GenerateDataKeyif the bucket uses SSE-KMS. - If you filter egress, allow both the virtual-hosted and path-style S3 hostnames for the region. MST uses path style by default.
6. Configure protection and recovery
- Deploy the NC2 cluster, deploy Prism Central and register the cluster with it.
- Deploy MST from the Prism Central Marketplace onto the NC2 cluster.
- Create protection policies. For the MST tier, choose the S3 bucket as the target. Each policy can have only one on-prem source cluster, and “All clusters” isn’t supported.
- Use a composite protection rule so MST-protected VMs get reverse protection after failover.
- Build recovery plans with boot order, inter-stage delays, network mapping, IP mapping and in-guest scripts.
7. Prove it before you need it
- Run test failovers on a schedule. Pilot Light supports test, planned and unplanned failover from on-prem to AWS.
- Time a real cluster expansion and use that number as your RTO. Confirm bare-metal capacity for the expanded node count in the DR region, and use an EC2 Capacity Reservation if the RTO can’t absorb a capacity shortage.
- Plan the failback. Returning from AWS to on-prem is a planned failover only.
Limits to know
- Only AHV VMs are protected through MST. ESXi VMs aren’t supported.
- Cluster Protect can’t be used on a cluster running MST DR. You choose one or the other.
- Synchronous replication from on-prem to NC2 isn’t supported.
- Protection Summary doesn’t show bandwidth statistics when the target is a bucket.