Load Balancers

Fugoku Load Balancers distribute traffic across multiple servers with high availability, health checks, and SSL termination. Attach load balancers to any private network or assign an Elastic IP for public ingress.

Features

• Layer 4 (TCP) — Fast, protocol-agnostic forwarding for databases, game servers, and any TCP/UDP service
• Layer 7 (HTTP/HTTPS) — Host, path, and header-based routing with TLS termination
• Health checks — TCP, HTTP, or HTTPS probes remove failed backends automatically
• Sticky sessions — Cookie-based session affinity (L7) and source-IP affinity (L4)
• SSL termination — Terminate TLS at the load balancer or pass-through to backends
• Elastic IP integration — Reserve a static anycast IP and assign it to your load balancer
• Private network attachment — Front private-only services with internal load balancers
• Zero egress — All load balancer traffic included

Pricing

Pricing is per load balancer instance — there is no per-rule, per-backend, or per-connection fee. Backends may be servers, virtual machines, or any IP reachable via a private network.

Layer 4 vs Layer 7

Creating a Load Balancer

Console

1. Navigate to Load Balancers in the console
2. Click Create Load Balancer
3. Name: web-lb
4. Type: Choose Layer 7 (HTTP/HTTPS) or Layer 4 (TCP)
5. Region: ashburn-1 (must match backend region)
6. Network: Attach a Private Network (optional, for internal-only LBs)
7. Listeners: Add listeners (port + protocol)
8. Click Create

CLI

Load balancers are created and configured in the console, then attached to private networks and Elastic IPs via the CLI:

# Reserve a static Elastic IP
fugoku eips reserve --region ashburn-1 --ipv4
# → 203.0.113.50

# Assign the Elastic IP to your load balancer
fugoku eips assign 203.0.113.50 --load-balancer web-lb

# Attach the load balancer to a private network for internal backends
fugoku networks attach backend-net --load-balancer web-lb

Load balancer creation, listener configuration, and backend pool management are available via the console. API endpoints for full programmatic management are coming soon — see API Reference for the planned surface.

Adding Backends

Backends (server pools) are configured in the console during load balancer setup. You can register servers by ID, instance ID, or private IP. Load balancing algorithms are selectable from the console:

Health Checks

Health checks automatically remove failed backends and re-add them when they recover.

Configuration

Health check parameters (protocol, path, interval, timeout, thresholds, expected status) are configured in the console's Health Checks panel for each backend pool.

Recommended Application Health Endpoints

A good health endpoint is lightweight, unauthenticated, and indicates true readiness:

# Flask
@app.route("/health")
def health():
    return {"status": "ok"}, 200

// Express
app.get("/health", (req, res) => res.status(200).json({ status: "ok" }));

Avoid including database or external dependency checks in your load balancer health endpoint — they cause cascading failures. Use a separate /ready endpoint for deep checks.

Sticky Sessions

Sticky sessions route the same client to the same backend, useful for shopping carts, sessions, and WebSocket affinity.

Layer 7 (Cookie)

Sticky sessions are configured during backend pool creation in the console. Enable Cookie stickiness and set the cookie name and TTL.

Cookie attributes:

• HttpOnly — Always set
• SameSite=Lax — Default; configurable
• Secure — Always set when listener uses HTTPS

Layer 4 (Source IP)

Source-IP stickiness uses a consistent hash on the client IP — it works for any protocol but is less precise than cookies.

SSL Termination

SSL termination decrypts TLS at the load balancer so backends speak plain HTTP. This offloads CPU-intensive TLS work from your servers.

Options

Bring Your Own Certificate

Upload a certificate and key via the console's Certificates tab, then attach it to an HTTPS listener during LB configuration.

TLS Passthrough (L4)

For end-to-end encryption (e.g., mutual TLS), use a Layer 4 TCP listener configured in the console. Select Layer 4 (TCP), port 443, and the load balancer forwards bytes without decrypting.

For free, automated certificates via Let's Encrypt, see Domains & SSL.

Attaching to Private Networks

Load balancers can be attached to a private network to front internal-only services or to isolate backend traffic.

CLI

# Attach an existing LB to a private network
fugoku networks attach backend-net --load-balancer internal-lb

Internal-only load balancers have no public IP and are reachable only from the attached private network — ideal for database frontends, internal microservices, and east-west load balancing.

Assigning an Elastic IP

Reserve an Elastic IP and assign it to your load balancer for a stable anycast public endpoint.

# Reserve Elastic IP
fugoku eips reserve --region ashburn-1 --ipv4

# Assign to load balancer
fugoku eips assign 203.0.113.50 --load-balancer web-lb

# Move IP to a different LB (no downtime)
fugoku eips move 203.0.113.50 --load-balancer web-lb-v2

DNS Records

Once you have a public IP (from the LB directly or an attached Elastic IP), point your DNS A record to it.

app.example.com.    A    203.0.113.50

For instructions on configuring Let's Encrypt with certbot, see Domains & SSL.

Monitoring

Metrics

Metrics are available in the console's Monitoring → Load Balancers tab.

Alerts

Set up alerts in the console's Monitoring → Alerts tab to trigger when backend health degrades or 5xx rates spike.

Full API reference for load balancers is coming soon. For immediate programmatic needs, use the console or the existing Instances API and Networks endpoints.

Best Practices

1. Use health checks — Every backend pool needs a health check or a failed server will keep receiving traffic
2. Shallow health endpoints — /health should return 200 when the process is alive, not when downstream dependencies are healthy
3. Sticky sessions for stateful apps — Use cookie stickiness for shopping carts, JWT validation, WebSockets
4. Centralize TLS at the LB — Offload TLS for easier cert rotation and CPU savings
5. Pin backends to a private network — Front backends on a private network and never expose them publicly
6. Use the right algorithm — round-robin for homogeneous servers, least-connections for long-lived connections, weighted for mixed capacity
7. Reserve an Elastic IP — For stable public endpoints and anycast DDoS protection
8. Monitor backend health — Alert on unhealthy backends before users notice
9. Scale by adding backends — Add more servers to a pool rather than resizing existing ones
10. Test failover — Stop a backend and confirm traffic reroutes within seconds

Troubleshooting

Getting Help

• Documentation: docs.fugoku.com/load-balancers
• Support: support@fugoku.com
• Networking: network@fugoku.com
• Status: status.fugoku.com

Next Steps:

• Set Up SSL with Let's Encrypt
• Configure a Private Network
• Reserve an Elastic IP
• Attach to Instances