Load Balancing with VPC

Each NetActuate VPC includes built-in network (L4) and HTTP (L7) load balancers. This guide shows how to distribute traffic across backend VMs using both load balancer types, configure health checks, and terminate SSL at the load balancer.

Network Load Balancer (L4)

The network load balancer operates at the transport layer, forwarding TCP and UDP connections to backend servers. It does not inspect HTTP headers or modify traffic: it simply distributes connections based on the configured algorithm and monitors backend health.

Configuration

Define a network load balancer group with health checks, forwarding rules, and backends:

variable "network_loadbalancer_id" {
  type = number
}

variable "http_loadbalancer_id" {
  type = number
}

variable "vpc_id" {
  type = number
}

variable "load_balancer_ip" {
  type = string
}

variable "web_1_private_ip" {
  type = string
}

variable "web_2_private_ip" {
  type = string
}

variable "web_3_private_ip" {
  type = string
}

resource "netactuate_network_loadbalancer_group" "tcp_lb" {
  name                    = "web-tcp-lb"
  network_loadbalancer_id = var.network_loadbalancer_id
  algorithm               = "round_robin"
  ip_version              = 4
  match_address           = var.load_balancer_ip

  health_check {
    enabled  = true
    method   = "tcp"
    interval = 10
    delay    = 10
    retries  = 3
    timeout  = 5
  }

  rule {
    protocol      = "TCP"
    port_match    = 80
    port_internal = 80
  }

  rule {
    protocol      = "TCP"
    port_match    = 443
    port_internal = 443
  }

  backend {
    name             = "web-1"
    internal_address = var.web_1_private_ip
  }

  backend {
    name             = "web-2"
    internal_address = var.web_2_private_ip
  }

  backend {
    name             = "web-3"
    internal_address = var.web_3_private_ip
  }
}

Health Check Methods

Method	Behavior
Ping	Sends ICMP echo requests to the backend IP. Checks network reachability only.
TCP Connect	Opens a TCP connection to the backend on the rule port. Confirms the service is accepting connections.

Set interval to control how often checks run (in seconds) and retries to control how many consecutive failures remove a backend from rotation.

Algorithms

Algorithm	Behavior
round-robin	Distributes connections evenly across all healthy backends in order
least-connections	Sends new connections to the backend with the fewest active connections

Use round-robin for stateless workloads where all backends are equivalent. Use least-connections when backends have varying capacity or when connections have different durations.

Backend Weights

Each backend has a weight value. Higher weights receive proportionally more traffic. For example, a backend with weight = 200 receives twice as many connections as one with weight = 100.

HTTP Load Balancer (L7)

The HTTP load balancer operates at the application layer. It inspects HTTP headers, terminates SSL/TLS, matches requests by domain and path, and supports sticky sessions. Use it when you need routing decisions based on the request content.

SSL Certificate

Upload your certificate and private key before creating the load balancer:

resource "netactuate_ssl_certificate" "web_cert" {
  name        = "web-example-com"
  certificate = file("certs/fullchain.pem")
  private_key = file("certs/privkey.pem")
}

The certificate resource accepts PEM-encoded files. Include the full chain (server certificate plus intermediates) in the certificate file.

Configuration

Define an HTTP load balancer group with domain matching, SSL termination, health checks, and backends:

resource "netactuate_http_loadbalancer_group" "web_lb" {
  name                 = "web-http-lb"
  http_loadbalancer_id = var.http_loadbalancer_id
  algorithm            = "round_robin"
  internal_port        = 8080
  match_address        = var.load_balancer_ip
  match_ports          = "80+443"

  rule {
    match_domain       = "example.com"
    match_path         = "/"
    ssl_enabled        = true
    ssl_certificate_id = netactuate_ssl_certificate.web_cert.ssl_certificate_id
  }

  rule {
    match_domain       = "www.example.com"
    match_path         = "/"
    ssl_enabled        = true
    ssl_certificate_id = netactuate_ssl_certificate.web_cert.ssl_certificate_id
  }

  health_check_active_enabled  = true
  health_check_active_path     = "/health"
  health_check_active_interval = 15
  health_check_active_retries  = 3

  backend {
    name             = "web-1"
    internal_address = var.web_1_private_ip
  }

  backend {
    name             = "web-2"
    internal_address = var.web_2_private_ip
  }
}

SSL Termination

The load balancer handles TLS decryption. Traffic between the load balancer and your backends travels over the private VPC network unencrypted (on port 8080 in the example above). This offloads CPU-intensive TLS processing from your application servers.

Each ssl_rule binds a domain name to a certificate. The load balancer uses SNI (Server Name Indication) to select the correct certificate when clients connect.

Domain and Path Matching

Routing rules control which requests reach the backend pool:

• domain: matches the HTTP Host header
• path: matches the request URI prefix

You can create multiple routing rules to direct different domains or paths to separate backend pools by defining multiple load balancer groups.

Health Checks

The HTTP load balancer supports two health check modes:

• Active: the load balancer sends periodic HTTP requests to the specified path on each backend. If a backend returns a non-2xx status code for the configured number of retries, it is removed from rotation.
• Passive: the load balancer monitors real client traffic. If a backend produces repeated errors during normal operation, it is temporarily removed.

Using both active and passive health checks together provides the fastest detection of backend failures.

Sticky Sessions

When sticky sessions are enabled, the load balancer routes all requests from the same client to the same backend. This is useful for applications that store session state locally rather than in a shared store.

Backend Templates

For VPCs with many load balancer groups sharing the same backends, use a backend template to define the pool once:

resource "netactuate_vpc_backend_template" "web_pool" {
  vpc_id = var.vpc_id
  name   = "web-backend-pool"

  backend_host {
    name    = "web-1"
    address = var.web_1_private_ip
  }

  backend_host {
    name    = "web-2"
    address = var.web_2_private_ip
  }

  backend_host {
    name    = "web-3"
    address = var.web_3_private_ip
  }
}

Reference the template in your load balancer groups instead of repeating backend blocks. When you add or remove servers, update the template in one place.

When to Use Which

Criteria	Network LB (L4)	HTTP LB (L7)
Protocol	Any TCP/UDP	HTTP/HTTPS only
SSL termination	No (passthrough)	Yes
Domain-based routing	No	Yes
Path-based routing	No	Yes
Sticky sessions	No	Yes
Health checks	Ping, TCP Connect	HTTP path, passive monitoring
Performance	Higher throughput, lower latency	Slight overhead from HTTP parsing
Use case	Databases, mail, game servers, generic TCP	Web applications, APIs, microservices

Use the network load balancer when you need raw TCP/UDP forwarding without HTTP inspection. Use the HTTP load balancer when you need SSL termination, domain routing, or application-layer health checks.

Reference

• Repository: netactuate-terraform-vpc: advanced examples including load balancer configurations
• Provider docs: VPC Load Balancers Reference

Related Guides

• Private Cloud Networking with VPC
• ECMP Load Balancing

---

Need Help?

Contact support@netactuate.com or open a support ticket from the portal.