Networking model

This page explains the networking architecture behind Aether clusters. For hands-on instructions, see the Networking guide.

Per-tenant network isolation

Aether separates tenants at several specific layers. Read these as the scope of what the platform does, not as a blanket claim of security:

• Worker network. Each cluster’s worker nodes sit on their own VLAN, separate from every other cluster’s, and communicate over it privately.
• Control plane. Each cluster has its own control plane, and its state lives in a dedicated per-tenant datastore database.
• Load balancers. A cluster’s LoadBalancer Services are served by a load-balancer VM per Service, dedicated to that cluster.

The Cilium CNI provides pod networking inside the cluster, and you layer your own NetworkPolicy / CiliumNetworkPolicy rules on top to control pod-to-pod traffic.

The API server endpoint

Every cluster gets a public API server endpoint at a stable domain, assigned when the cluster is created:

<cluster>.<org>.<region>.aetherplatform.cloud:6443

That address is what your kubeconfig points at, so kubectl reaches the cluster from your laptop or a CI runner without a VPN. The endpoint is additive: your worker nodes keep talking to the API server over the cluster’s private network, and that path is always permitted regardless of how you configure the public one.

The endpoint is mandatory: every cluster has one, and its address carries a flat €4 per month charge — see the Billing model. Private-network-only connectivity to the API server, which would make the public endpoint optional, is a future capability and is not available today.

Restricting who can reach it

Two controls guard the endpoint, and you configure both per cluster:

• Authorized networks — the list of source CIDRs allowed to reach the API server.
• Connection rate limiting — a cap on new connections per second, to absorb abusive traffic.

The allow-list starts empty

An empty authorized-networks list means reachable from anywhere — the endpoint isn’t closed until you populate it. Authentication still applies, so nothing gets in without a valid credential, but the port is open to the internet. Set the list to your known ranges — your office, your VPN, your CI provider’s egress ranges — before you treat the cluster as locked down. On the public endpoint, your cluster’s own worker and platform ranges are always permitted in addition to your list, and don’t need listing.

Set the list in the portal (your cluster → API server access → Edit, one CIDR per line) or over the REST API, with a PUT to the cluster’s /network resource. Both write the same list.

See Connect with kubectl for how to get the matching kubeconfig.

Managed load balancers

When you create a Kubernetes Service of type LoadBalancer, Aether provisions a managed load balancer with an external IP and wires it to your service — no manual setup. This is how you expose workloads (or an ingress controller) to the outside world. L7 routing and ingress controllers inside the cluster remain your responsibility.

Outbound internet access

Workloads running on your nodes have outbound internet access — they can pull dependencies, call third-party APIs, and reach external services. Inbound access from the internet reaches your workloads only where you create it — through a LoadBalancer Service. (The cluster’s public API endpoint fronts the Kubernetes API, not your workloads.)

Learn more

• Networking — network policies, load balancers, and ingress in practice.
• Platform model — tenant isolation overall.