Naming is applied at deployment time following the CAF pattern ng-{workload}-{env}-{region}-{index} for the NAT Gateway and pip-{workload}-{env}-{region}-{index} for the associated Public IP — the portal form provides these conventions as guidance. The deployment targets an existing VNet and is designed for hub-spoke landing zone architectures where the hub VNet is centrally managed in a separate resource group. Governance items address resource tagging (Workload, Environment, CostCenter, createdBy), CanNotDelete resource locks on production resources, and Azure Policy compliance for public IP exposure in private subnets.

Reliability: Standard SKU Public IP is zone-aware, and NAT Gateway itself is a fully managed, zone-resilient service — no VM-level public IPs or SNAT port exhaustion from overloaded load balancers. Security: outbound-only design means no inbound attack surface exposed; NSGs on associated subnets provide east-west micro-segmentation. Performance Efficiency: SNAT port capacity planning (64,512 ports per public IP) prevents port exhaustion for AKS, VMSS, and high-concurrency workloads. Cost Optimization: NAT Gateway eliminates the need for per-VM public IPs and outbound load balancer rules, with billing based on gateway hours plus data-processing charges. Operational Excellence: ARM template with UI definition enables repeatable portal deployments, and diagnostic settings capture SNAT metrics for capacity planning.

Verify explicitly: NAT Gateway provides no inbound internet access — resources remain private with no public IP exposure. Outbound traffic flows through a controlled, single-egress point whose IP range can be allowlisted at external destinations. Least privilege: the deployment identity requires Contributor on the NAT Gateway resource group and Network Contributor on the VNet resource group — not Owner; post-deployment operations use scoped RBAC roles with no standing access. Assume breach: removing VM-level public IPs from workload subnets eliminates direct instance-level internet exposure; NSGs on all associated subnets must still enforce east-west traffic controls — NAT Gateway only handles north-south outbound egress and provides no lateral-movement protection within the VNet.