Skip to content

Network Access Resources#

Every Ametnes service is reachable through an FQDN endpoint. Behind the scenes each service attaches to a network access resource - typically a load balancer - that publishes the endpoint and routes traffic to the service.

Network access is an independent platform resource, not a property of an individual service. Ametnes allocates and reuses network access resources independently of application deployment, so a load balancer can outlive any single service and be reused by others.

This matters most in private and on-premise Kubernetes environments, where external IP addresses are limited or expensive. Multiple services can share one external IP when they use different ports, and HTTP/HTTPS services share an IP through Ingress routing.

Intelligent network resource management#

Ametnes optimises network resource allocation across deployed services, allowing multiple applications to share external network infrastructure where appropriate.

The platform supports both Layer 4 TCP routing and Layer 7 HTTP/HTTPS ingress, adapting network allocation to the requirements of individual services.

Through intelligent LoadBalancer allocation and reuse, Ametnes reduces unnecessary consumption of external IP addresses while maintaining independent network access for deployed applications.

For HTTP/HTTPS services, operators can configure LoadBalancer sharing limits directly through the Ametnes console, providing control over network resource utilisation.

This approach is particularly valuable in private and on-premise environments, where external IP addresses and network infrastructure capacity may be limited.

The capability has three layers:

Capability What Ametnes provides
Network abstraction Separates network access from application services, so a load balancer can outlive any single service
Intelligent allocation Manages when to provision a new load balancer and when to reuse an existing one
Resource optimisation Shares external IPs through Layer 4 port allocation and Layer 7 Ingress routing

The result is fewer load balancers, more efficient use of a limited external IP pool, and independent service access for every application.

Layer 4: TCP network access#

TCP services such as RabbitMQ, MySQL, PostgreSQL and Redis are exposed through NGINX Layer 4 (TCP) routing. A load balancer publishes one external IP address, and NGINX forwards each connection on an allocated port to the matching backend service.

Multiple services share a load balancer when they use different ports. A port can be bound only once per load balancer, so two services that both require the same port cannot share the same IP-and-port endpoint.

Ametnes manages placement automatically. It gives a service its standard port where possible, and when you attach a service to a network resource yourself it allocates an available port on that load balancer.

flowchart LR
    C1["RabbitMQ client<br/>port 5671"] --> LB_A["Load balancer A<br/>external IP"]
    C2["MySQL client<br/>port 3306"] --> LB_A
    C3["PostgreSQL client<br/>port 5432"] --> LB_A

    LB_A --> NGX_A["NGINX Layer 4"]

    NGX_A -->|"5671"| R1["RabbitMQ"]
    NGX_A -->|"3306"| M1["MySQL"]
    NGX_A -->|"5432"| P1["PostgreSQL"]

Three services share one external IP. The endpoint connection details always show the port to use; connect on the port shown rather than assuming the service's default port.

Layer 7: HTTP/HTTPS network access#

HTTP/HTTPS services are exposed through Kubernetes Ingress. The NGINX ingress controller listens on the standard ports (80 and 443) and routes each request to the correct backend by hostname or path.

Because every HTTP/HTTPS service uses the same listener ports, port 443 does not by itself consume a load balancer address or trigger another load balancer. Many services can share one external IP through Ingress routing.

flowchart LR
    U1["app.example.com"] --> LB["Load balancer<br/>HTTPS :443"]
    U2["api.example.com"] --> LB
    U3["app.example.com/admin"] --> LB

    LB --> ING["NGINX Ingress"]
    ING -->|"host app.example.com"| A["Application A"]
    ING -->|"host api.example.com"| B["Application B"]
    ING -->|"path /admin"| C["Admin UI"]

For platform-managed placement, Ametnes applies a configurable service-sharing threshold that spreads services across load balancers instead of concentrating them on a single shared endpoint. The threshold is a target, not a hard maximum: when additional infrastructure is not available, services continue to be placed on compatible existing load balancers and the deployment does not fail.

A service attached to a network resource you created stays on that load balancer; the sharing threshold applies to platform-managed placement.

The default is 5 services per load balancer. Set it on the load balancer network resource at the location:

  1. Navigate to the Network Access left menu.
  2. Click New Network (or open the existing load balancer resource).
  3. In the config section, set Services Per Load Balancer.
  4. Click Create Network (or save the resource).
network.tf
1
2
3
4
5
6
7
8
resource "ametnes_network" "network" {
  name     = "NETWORK-USE2"
  project  = ametnes_project.project.id
  location = data.ametnes_location.location.id
  config = {
    "services_per_lb" = "5"
  }
}

LoadBalancer reuse and IP address conservation#

External IP addresses are often a limited resource in private and on-premise Kubernetes environments. Ametnes accounts for this by reusing compatible existing load balancers rather than relying exclusively on provisioning new ones.

When external IP capacity is constrained, the platform can place additional services on existing load balancers where the protocol, port and capacity requirements permit. For Layer 4 this means allocating another free port on the load balancer. For Layer 7 it means routing more Ingress hosts or paths through the shared listener.

When a new load balancer cannot be provisioned, Ametnes does not fail the deployment: the service is placed on compatible existing infrastructure and the assigned endpoint is shown in the connection details.

Combined with Layer 4 port-based routing and Layer 7 Ingress-based routing, this allows multiple applications to share external network infrastructure while retaining independent service access. The result is more efficient use of available IP addresses and fewer provisioning constraints caused by load balancer IP exhaustion.

Automatic network management (the default)#

Creating a network access resource is optional. If you do not create one, Ametnes manages network access for the location. It provisions as many load balancers as the location's Kubernetes cluster can provide, distributes services across them, and reuses a load balancer when its protocol, port and capacity requirements permit.

When you create a service without specifying a network, Ametnes automatically:

  • selects or provisions a load balancer for the service,
  • allocates the endpoint address and port, using the service's standard port where possible,
  • issues and renews the endpoint certificate, and
  • releases the port when the service is deleted.

For the standard path - create the service, receive the connection, connect - there is no network step.

Managing network resources yourself (optional)#

Create a network access resource yourself only if you want to control how your services are exposed, for example to:

  • attach several services to a single load balancer, or
  • choose whether the load balancer is public or private.

A network resource you create is managed by you and is not removed automatically when a service is deleted.

Network Visibility#

When a load balancer is used as the network access resource to expose your data service, you can choose for this load balancer to be publicly facing or not.

To create a publicly facing load balancer:

In the Ametnes Cloud console;

  1. Navigate to the Network Access left menu.
  2. On the network access dashboard, click New Network.
  3. Enter Name: TutorialNetwork.
  4. Select Kind: Load Balancer.
  5. Select the Location: Your Data Service Location.
  6. In the config section, uncheck the Visibility: private option.
  7. Click Create Network.

Define your resources#

network.tf
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
# Create a network access resource.
resource "ametnes_network" "network" {
  name = "NETWORK-USE2"
  project = ametnes_project.project.id
  location = data.ametnes_location.location.id
  description = "My Network Access resource"
    config = {
     "visibility" = "private"
   }
}

Attaching a service to your network resource#

If you created a network resource and want a service to use it, select it when you create the service (or set network in Terraform). If you do not, Ametnes provisions and attaches a network resource for you.

When creating a data service in the Ametnes Cloud console;

  1. Navigate to the Services left menu.
  2. On the services dashboard, click New Service.
  3. Enter Name: PostgresService.
  4. Select Kind: PostgreSQL 17.6 Service.
  5. Select the Location: Your Data Service Location.
  6. Select the Network: PostgresTutorialNetwork.
  7. Click Create Service

If you leave the network unset, Ametnes attaches the service to a platform-managed network automatically. If there is only one network access resource in the target data service location, it will be auto-selected.

service.tf
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
# Create a service resource attached to a user-managed network resource.
resource "ametnes_service" "service" {
  name = "Weaviate-Demo-Instance"
  project = ametnes_project.project.id
  location = data.ametnes_location.location.id
  kind = "service/postgres:17.6"
  description = "PostgresTutorialNetwork"
  network = ametnes_network.network.resource_id
  capacity {
    storage = 10
  }
   config = {
     "architecture" = "Starter"
     "admin.user" = "admin"
     "admin.password" = "fo9ruk3kee7uJe1vi"
   }
  nodes = 1
}

Public Cloud Deployments#

When deploying on a public cloud and a load balancer is used for your network access resource, your cloud provider will provision a load balancer for you. This load balancer must allow for Layer 4 traffic.

On-prem Deployments#

For on-prem deployments, the cluster must be able to service Service type LoadBalancer, which is how Ametnes exposes provisioned services. Install a load balancer implementation such as MetalLB or Cilium in L2 mode to provide external addresses (see Production Kubernetes Cluster). Alternatively, you can use the Citrix ADC load balancer.