Nutanix NCP-CI-AWS cheat sheet

NC2 runs the Nutanix AHV hypervisor on AWS bare-metal EC2 instances (i3.metal/i3en.metal families); the Prism Central VM is deployed as a separate EC2 instance in the same VPC.

A cluster requires a minimum of 3 nodes for resiliency; RF2 tolerates one node failure, RF3 tolerates two - node count and replication factor are chosen at cluster creation and RF cannot be lowered below the number of tolerated failures.

Each NC2 node maps one-to-one to a bare-metal EC2 instance; the cluster's storage is local NVMe instance store, so instance stop/terminate destroys data unless protected by snapshots or replication.

Deployment prerequisites: an AWS account with a service-linked role, a VPC with subnets in the target AZ, an internet gateway or NAT for Prism Central registration, and a key pair for SSH access.

NC2 cluster creation is orchestrated through the NC2 console (or API), which provisions CloudFormation stacks, IAM roles, and EC2 resources in the customer's account.

The NC2 console is hosted by Nutanix; cluster metadata and licensing are managed there, while the data plane stays entirely inside the customer's AWS account and VPC.

AHV on NC2 supports Nutanix AOS features including Prism Element/Prism Central, Flow networking, and Nutanix Files, subject to the NC2-AWS feature compatibility matrix.

Cluster registration to Prism Central is required for centralized management; a single Prism Central can manage multiple NC2 clusters across regions and accounts.

Deployment sizing: validate EC2 bare-metal quota per region/AZ before deployment; insufficient quota is the most common cause of failed cluster builds.

NC2 requires a dedicated VPC (or dedicated subnets) per cluster; the cluster subnet must have enough free IPs for nodes, Prism Central, and the IP address management (IPAM) pool used by guest VMs.

Guest VM traffic is NATed by AHV and exits through the EC2 instance's elastic network interface; AWS security groups and NACLs therefore apply to all VM traffic.

Two connectivity models exist: the default overlay/VPC-routed model, and Flow Network Security for microsegmentation; AWS-native security groups still filter at the ENI level.

For on-premises connectivity use AWS Site-to-Site VPN or Direct Connect to a transit gateway or virtual private gateway; NC2 does not create these attachments automatically.

Cross-VPC and cross-account access is achieved with VPC peering or AWS Transit Gateway; NC2 clusters cannot span AZs - one cluster lives in one AZ, so cross-AZ resilience requires a second cluster plus replication.

DNS: Prism Central and cluster VIPs need resolvable names; configure DHCP option sets or static entries so guest VMs and Prism can resolve each other.

Egress to the internet (or a proxy) is needed for licensing, Prism Central registration, and AOS updates; use NAT gateway with a stable elastic IP for allowlisting.

AWS Elastic Load Balancing can front workloads, but the cluster virtual IP is managed by AHV and must not be placed in the AWS subnet range reserved by AWS (first four and last IP of each subnet).

Prism Central authentication supports local users, Active Directory/LDAP directory services, and SAML 2.0 identity providers; role-based access control (RBAC) assigns roles to users or AD groups.

Built-in roles include Prism Admin, Prism Viewer, and project-scoped roles; custom roles are composed of permission sets over object types such as VMs, clusters, and categories.

Projects combine a set of VMs, users, and roles to provide multi-tenant isolation; a user only sees resources within assigned projects.

AWS-side security: NC2 uses IAM roles and instance profiles created during deployment; rotating or deleting those roles breaks cluster operations such as snapshots and CloudFormation updates.

Data at rest is encrypted with AWS EBS/NVMe encryption where configured; in-flight encryption uses TLS for Prism and IPsec for replication traffic between clusters.

Flow Network Security provides distributed firewall policy per VM, with policy categories applied by VM name, category, or subnet; policy is enforced in AHV, not by AWS security groups.

Enable cluster lockdown / Prism access restrictions and use the principle of least privilege on the NC2 console accounts, which can manage multiple AWS accounts.

Audit trails: Prism Central records task and user activity; AWS CloudTrail records API calls made by NC2 service roles in the customer account.

AOS, AHV, and Prism upgrades on NC2 are performed through LCM (Lifecycle Manager) in Prism Central; upgrades require healthy cluster status and sufficient free capacity for rolling node reboots.

LCM inventory compares installed versions against the Nutanix compatibility matrix; NC2 has its own validated version sets, so only versions listed for NC2 on AWS should be applied.

Prism Central monitors alerts, health checks, and performance metrics; NC2 clusters also surface AWS-level events (instance status checks, EBS events) that must be monitored separately.

Nutanix Cluster Check (NCC) runs health checks; schedule regular NCC runs and resolve failures before upgrades or DR tests.

Scaling: add nodes by expanding the cluster in the NC2 console, which provisions additional bare-metal instances; scale-down requires the cluster to remain above minimum node count and RF requirements.

Capacity planning uses Prism capacity dashboards plus AWS Cost Explorer; bare-metal instances are billed hourly whether or not VMs are running, so idle clusters are expensive.

Cluster stop/start: stopping an NC2 cluster decommissions or powers off instances depending on the chosen action; preserve snapshots before stopping because instance store data is ephemeral.

Monitoring integrations: Prism REST API and syslog/SNMP forwarding to external tools; AWS CloudWatch covers the underlying EC2 layer.

Protection domains group VMs for consistent snapshots; local snapshots on NC2 reside on the same cluster and do not protect against cluster or AZ loss.

Async replication (Protection Policies with remote sites) sends snapshots to a second NC2 cluster, typically in another AZ or region; RPO equals the replication schedule interval.

Nutanix Leap provides orchestrated DR with recovery plans that define boot order, IP re-mapping, and one-click failover to the recovery cluster.

NearSync replication offers RPO measured in seconds but requires low-latency links and specific AOS licensing; standard async replication is the norm for cross-region NC2.

Migration to NC2: Nutanix Move migrates VMs from VMware, Hyper-V, and AWS EC2 into AHV on NC2; Move requires network reachability and sufficient target capacity.

Nutanix Xi Leap / cloud DR options differ from NC2-native replication - on NC2 the recovery site is another NC2 cluster you own, so cost includes the standby cluster's bare-metal instances.

Snapshots on NC2 can be exported to AWS S3 via Files or third-party tooling; native Nutanix snapshots stay within the Nutanix storage layer.

DR testing: use Leap test failover to validate recovery plans without disrupting production; test failover clones VMs in an isolated network.

Cluster creation failures most often trace to AWS quota limits for bare-metal instances, IAM role/permission errors, or subnet IP exhaustion - check the NC2 console task log and CloudFormation stack events first.

If Prism Central cannot register a cluster, verify outbound connectivity (NAT/proxy), DNS resolution, and that the cluster VIP and Prism Central IP are routable.

Node down or CVM unreachable: check EC2 instance status checks in the AWS console; a failed instance status check indicates host-level AWS failure requiring instance replacement.

Performance issues: check AHV host CPU/memory contention in Prism, then AWS-level throttling such as EBS or network limits; instance store NVMe performance is fixed per instance type.

Upgrade failures: run NCC, verify LCM pre-checks, and confirm no pending tasks or alerts; failed upgrades can often be resumed from the LCM task.

Log collection: use NCC logbay / Prism log collection and attach the bundle to a Nutanix support case; include the NC2 cluster ID and AWS region.

Support boundaries: Nutanix supports the NC2 software stack; AWS supports the underlying infrastructure - cases may require joint handling, so gather both CloudTrail and Prism logs.

Common networking fault: security group or NACL blocking ports 9440 (Prism), 22 (SSH), or replication ports between clusters; verify with VPC Reachability Analyzer.