An Azure Virtual Network (VNet) is an isolated network environment within Azure.

Azure VNet provides complete control over networking configuration, including:

  • IP address ranges
  • Subnets
  • Routing tables
  • Network gateways

For SystemLink Enterprise deployments, a properly configured VNet is essential for security, scalability, and network isolation.

Configure your VNet to isolate compute and storage infrastructure on private subnets, separate from internet-facing gateways and load balancers. This configuration follows cloud security best practices and ensures that sensitive workloads are not directly accessible from the internet.

For a general reference of the architecture, refer to the Azure SystemLink Enterprise Kubernetes Architecture Diagram.

Subnet Architecture

Configure your VNet with both public and private subnets to separate internet-facing components from internal infrastructure.

Deploy the following components in private subnets with no direct internet access:

  • AKS cluster nodes: Worker nodes hosting SystemLink Enterprise pods, including web services, web applications, and supporting infrastructure.
  • Databases: Azure Database for PostgreSQL, or self-managed database instances.
  • Private Endpoints for Azure Storage: Configure private endpoints to access Azure Blob Storage from private subnets without using the public internet.

Deploy the following components in public subnets with internet access:

  • Application Gateway: Internet-facing application load balancer for HTTPS traffic to the SystemLink web application and API.
  • Azure Load Balancer: TCP load balancer for Salt Master traffic (ports 4505 and 4506).
  • NAT Gateway: Enable outbound internet access for resources in private subnets.

Addres Space Planning

Plan your VNet address space to ensure sufficient IP addresses for SystemLink Enterprise and future growth.

  • Recommended VNet size: /16 CIDR block (65,536 IP addresses) provides flexibility for scaling
  • Minimum VNet size: /20 CIDR block (4,096 IP addresses) for smaller to medium size deployments

Allocate subnets based on the following considerations:

  • Private subnets for AKS nodes: Size based on maximum expected node count. Each AKS node requires one IP address from the subnet address space.
  • Private subnets for pods: If using Azure CNI networking, allocate additional address space for pod IP addresses. Each pod requires its own IP address.
    • Start with kubenet networking (default) where pods use a separate address space unless you have specific requirements for pod-level network integration.
    • Monitor IP utilization carefully with Azure CNI. Each node can consume 10-100+ IP addresses depending on the VM size and max pods per node configuration.
    • Plan for growth. Ensure subnet sizing can support significant scaling of your workload.
  • Public subnets: Smaller allocation, such as /24 is sufficient for load balancers and NAT gateways.
  • Multi-zone deployment: Create subnet pairs (public/private) distributed across availability zones for high availability.
Table 61. Example Address Allocation (VNet using 10.0.0.0/16)
Subnet Type Availability Zone Address Range Available IPs
Private (AKS nodes) Zone 1 10.0.0.0/19 8,192
Private (AKS nodes) Zone 2 10.0.32.0/19 8,192
Private (Databases) Zone 1 10.0.64.0/24 256
Private (Databases) Zone 2 10.0.65.0/24 256
Public Zone 1 10.0.128.0/24 256
Public Zone 2 10.0.129.0/24 256
Note Azure reserves the first four addresses and the last address IP addresses per subnet. Plan accordingly when calculating available addresses.

Security Best Practices

Observe the following security best practices when configuring your VNet for SystemLink Enterprise:

  • No direct internet access for compute and storage: All AKS nodes, databases, and internal services must reside in private subnets with no internet gateway route.
  • Traffic flow isolation: Internet traffic flows through the Internet, the public Application Gateway/Load Balancer, the private Ingress Controller, and then the private SystemLink services.
  • Outbound internet via NAT: Use NAT Gateway in public subnets to provide outbound internet access for private subnet resources. Deploy NAT Gateway with zone redundancy for high availability.
  • Private endpoints: Use private endpoints for Azure services (Blob Storage, Container Registry) to avoid internet routing and reduce data transfer costs.
  • Network security groups (NSGs): Configure NSGs to allow only necessary traffic between components. Use the principle of least privilege.

Availability Zone Considerations

Deploy SystemLink Enterprise across multiple availability zones for high availability and fault tolerance:

  • Minimum deployment: Use at least two availability zones with subnet distribution across zones.
  • AKS node pools: Distribute worker nodes across availability zones using zone-redundant node pools.
  • Database zone redundancy: Enable zone-redundant deployments for Azure Database for PostgreSQL.
  • Load balancer distribution: Configure Application Gateway and Load Balancer with zone redundancy to distribute traffic across availability zones.