Skip to main content
Ottili Cloud

Networks and routes

How Ottili Cloud connects virtual networks and routing — routes, ingress via load balancer and DNS, egress, firewall boundaries and peering. Today in Early Access; networking and routing are not yet self-service orderable.

Überblick

Networks and routes* describe how Ottili Cloud resources are connected to each other and to the outside world. A virtual network isolates your resources; routing decides which traffic flows between those networks, to your instances and to the internet. Load balancers, DNS and firewalls are the building blocks that carry this routing.

Ottili Cloud is today in Early Access* (preview, not generally available). Compute is reachable through the Early Access program, while networking and routing are part of the platform build-out and are not yet self-service orderable. This page describes the intended structure, not a live procedure.

What networks and routes include

  • Virtual networks (VNets)*: isolated networking between your cloud resources within a project and a region.
  • Routes and route tables*: rules that decide where packets flow — internally between instances, outward (egress) or through an entry point (ingress).
  • Ingress*: inbound traffic reaches your services through load balancers and resolved DNS names.
  • Egress*: outbound traffic leaves the VNet through defined default routes.
  • Firewall boundaries*: firewall rules control allowed and denied traffic at subnet and instance boundaries.
  • Peering*: where offered, peering connects virtual networks — even across regions.

How routing works

Routing in Ottili Cloud follows a software-defined model: the VNet is the isolation unit, and a route table maps destinations to routes.

  • An instance joins a virtual network* and thereby receives its internally reachable address.
  • A load balancer fronts a group of instances* and distributes inbound traffic across the healthy targets.
  • DNS resolves the names* clients use; an ingress path leads from the public name through DNS and the load balancer to your instances.
  • Egress routes* determine how your workloads talk to the internet or to external services.
  • Firewall rules* apply at the subnet or instance boundary and filter traffic before the actual routing.

Routes in context with compute, regions and DNS

Routing is tightly interwoven with the rest of Ottili Cloud:

  • Compute*: an instance is placed in a VNet; its routing depends on the associated route table.
  • Regions*: networking and routing are laid out per region. Region choice therefore determines how your network is built and where peering is possible.
  • DNS*: resolves the public and internal names through which routing destinations are reached.
  • Security*: firewalls and routes together define which traffic may even reach a boundary.

The fundamentals of networking, load balancing, DNS and firewalls are described in [Networking](/docs/cloud-networking); this article focuses on the routing itself.

Availability

Networking and routing are part of the Ottili Cloud Early Access build-out and are not yet self-service orderable today. This page describes the intended structure rather than a live procedure. When networking and routing become reachable through Early Access, operational steps will be documented and the feature status will be shown on the product and status pages.

We do not describe routing configuration as available today, and we do not publish limits or SLAs that are not yet defined. Until then, the honest Early Access status of Ottili Cloud applies: Compute is reachable, networking and routing are in development.

Related

  • Read the [Cloud overview](/docs/ottili-cloud) for status and platform embedding.
  • Connect resources with [Networking](/docs/cloud-networking).
  • Place workloads in [Regions](/docs/cloud-regions).
  • Run them on [Compute](/docs/cloud-compute).
  • Secure boundaries with [Security](/docs/cloud-security).

Was this article helpful?