Bursting to NC2 on AWS While Keeping Data Gravity On-Premises
A company runs NKP on-premises on AHV with eight workers and a stateful order service using Nutanix Volumes PVCs. It plans a three-week marketing campaign that needs roughly triple the current web-tier capacity. The team is evaluating Nutanix Cloud Clusters (NC2) on AWS for burst capacity. The on-premises site has about 18 ms round-trip latency to the chosen AWS region, and the primary PostgreSQL database must remain on-premises for regulatory reasons. The DR plan targets an RPO of 15 minutes and an RTO of four hours. Marketing wants a single global hostname, and security wants consistent policy and observability across both environments.
1. Decide which workloads should run in NC2 on AWS and which must remain on-premises. Justify the placement with the latency, data-gravity, and regulatory constraints.
Read the worked answer
The web tier and stateless API workers are the best candidates for NC2. They scale horizontally, tolerate 18 ms latency to the database for many request patterns, and can be placed behind a global entry point. Put them in an NC2 cluster in the AWS region, close to the users or at least with predictable egress, and keep the database on-premises.
The order service is stateful and its PVCs live on Nutanix Volumes on-premises. Moving the whole service would create cross-site storage latency and split the transaction boundary. Keep the write path and the primary database on-premises. If read scaling is needed, run a read replica or cache in AWS only after validating consistency and regulatory approval. Do not stretch a block volume across sites or run a database with synchronous replication over 18 ms.
The regulatory constraint is decisive for the database. The design should document that no regulated data is stored in NC2, or that only approved derived data is cached there. The global hostname should route to the web tier, not directly to the database.
2. Design the networking and failover architecture for a single global hostname, 15-minute RPO, and four-hour RTO.
Read the worked answer
Use global DNS or a global load balancer with health checks to direct users to the on-premises or NC2 ingress endpoint. Keep the hostname stable and use short TTLs or a managed global traffic manager. The NC2 cluster needs its own ingress controller and a load-balancer VIP, with network connectivity back to on-premises for API calls to the order service. Restrict that path with firewall rules and mutual authentication; do not expose the database directly.
For DR, replicate backups and database logs to an independent location. The 15-minute RPO must come from continuous WAL shipping or storage replication, not nightly backups. Test restore into a clean environment and measure the time to provision the NC2 cluster, restore data, update DNS, and validate transactions against the four-hour RTO. A standby NC2 cluster can reduce RTO but adds cost; if used, keep it scaled down and document the scale-up procedure. Failover must include DNS, secrets, certificates, and network policy, not only compute.
3. What observability and security controls must be in place before the burst environment is allowed to handle production traffic?
Read the worked answer
Observability must span both environments with common dashboards and alert routing. Collect metrics, logs, and traces from the on-premises NKP cluster and the NC2 cluster into one backend, tag by environment and cluster, and alert on golden signals for the web tier plus the cross-site dependency on the order service. Include synthetic checks through the global hostname and track DNS failover time. Without cross-site visibility, the team cannot tell whether latency is caused by the 18 ms link, the database, or the NC2 ingress.
Security must be consistent: the same image policy, pod security, network policies, secrets management, and identity provider across both clusters. Restrict NC2 egress to approved destinations, encrypt the cross-site path, and use least-privilege service identities. Scan the burst cluster with the same admission controls as on-premises, and log audit events centrally. Before cutover, test that a compromised NC2 web pod cannot reach the database directly and that production secrets are not copied into the burst environment. Require a documented rollback that drains NC2 traffic and returns the hostname to on-premises.