10 min read

Learning Objectives

By the end of this module, you will be able to:

  • Design a three-tier VDC topology (public edge, private application, private data) and explain why segmentation, not a rule set, is the load-bearing isolation control on IONOS.
  • Plan LAN addressing correctly: the /24 default, the reserved managed-service range, the gateway addresses, and where static addressing beats DHCP.
  • Decide when to reserve a static public IPv4, who can reserve it, and how the IPv6 allocation model differs.
  • Build the three-LAN topology with NICs and a reserved public IP in the Data Center Designer.

Unit 3.1: VDC Topology and Segmentation

Introduction

The first real decision in any IONOS architecture is not which server to build but which network each tier sits on, because on this platform the LAN a resource lives on is the primary thing that determines whether it is reachable from the internet. A LAN inside a Virtual Data Center is private until you explicitly connect it to the internet, so exposure is something you add deliberately rather than something you remove later. This unit fixes the topology that every subsequent build in the module drops into: a public edge LAN, a private application LAN, and a private data LAN. It opens at the addressing and segmentation decisions, and it ends by building that three-LAN shape in the Data Center Designer for FinCorp's first regulated workload.

1. The Private-by-Default Network and the Three-Tier Layout

A LAN becomes public only when an internet-access element is attached to it; without that connection the network is private. That single behaviour is what makes private-by-default the path of least resistance: leave a tier on an unconnected LAN and it is already unreachable from outside the VDC. The three-tier layout falls directly out of this:

  • A public edge LAN carries only the internet-facing entry point (the Layer 7 load balancer in Unit 3.3, plus any IP-failover edge in Unit 3.5).
  • A private application LAN carries the stateless compute or Kubernetes node pool.
  • A private data LAN carries the managed databases, cache, and shared storage, and is reachable only through the internal Layer 4 balancer in Unit 3.4.

The reason this layering is the control, rather than a convenience, is where the platform's filtering binds. NIC-level firewalls and Network Security Groups attach to server NICs at the VDC level only; they do not apply to the Managed Application Load Balancer, the Managed Network Load Balancer, or the Managed Kubernetes cluster abstraction. Because you cannot wrap the managed balancers in a security group, you cannot lean on a firewall rule to compensate for placing a database on a public path. The topology itself has to do the isolation. Segmentation is therefore the load-bearing decision, and the three-LAN split is the minimum that expresses it cleanly. Unit 3.2 then adds firewall and NSG rules as a second layer inside that topology, never as a substitute for it.

For FinCorp, the German financial-services firm carrying its workload under GDPR and BSI expectations, this is the shell the regulated application drops into. The compliance story is materially easier to make when the data tier is architecturally incapable of accepting an inbound connection from outside the VDC, because the argument rests on topology rather than on the correctness of a rule list.

2. LAN Addressing: The /24, the Reserved Range, and the Gateway

Each LAN defaults to a /24 subnet, which is the addressing unit you plan around. Within that /24 the address space is not entirely yours to assign:

  • Addresses .2 through .9 are reserved for managed services within the LAN /24. Do not hand these out to your own VMs.
  • Addresses .10 through .255 are the range from which VM IPs are assigned.

Private LANs draw from the RFC 1918 ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). The maximum transmission unit on the LAN is 1500 bytes; planning for that MTU avoids fragmentation surprises when you later run encrypted tunnels over the same fabric in Unit 3.6.

The static-versus-DHCP decision is made per tier and per role. The application tier can tolerate DHCP because its members are interchangeable and stateless. The data tier and any node that other resources address by IP should hold a static address, because a database endpoint or a load-balancer target that moves on a lease renewal is an outage waiting to happen. The practical guard is to keep DHCP-assigned and statically-assigned addresses in non-overlapping parts of the .10-.255 range so a lease never collides with a pinned address.

Internal traffic between LANs in the same VDC moves at up to 6000 Mbps, and the NIC firewall path is rated to 6 Gbps of throughput, so the segmentation boundary is not a performance bottleneck for east-west traffic between the application and data tiers.

3. Reserved Public IPv4 and the IPv6 Model

A public edge needs a stable address. A reserved IPv4 address is region-bound: it can only be used in the data-center region where it was reserved, and although different IPs from one reserved block may serve different networks, that is still only within the same region. Reserving an IP requires the Reserve IP Blocks privilege, so only contract owners, administrators, or users granted that privilege can do it; everyone else has read-only access to IP Management. A reserved IPv4 block is billed at EUR 5.00 per 30 days per address. IPs cannot be returned individually, only as a block and only when no address in it is in use, and if you return a static IP you cannot reserve that same address again afterwards.

You reserve the public IP before you build the thing that consumes it. The Layer 7 balancer in Unit 3.3, the VPN Gateway and NAT Gateway in Unit 3.6, and the IP-failover edge in Unit 3.5 all expect a reserved public IPv4 to already exist; provisioning the consumer first and hunting for an address afterwards is the most common avoidable rework in the console.

IPv6 follows a hierarchical allocation rather than per-address reservation. A VDC receives a public /56, each IPv6-enabled LAN takes a /64 (chosen from that /56 or auto-assigned), and each NIC receives a /80. A VDC can have up to 256 IPv6-enabled LANs, and the platform supports dual-stack operation. One boundary matters at the topology stage: the managed network services (Application Load Balancer, Network Load Balancer, NAT Gateway, IP Failover, and Managed Kubernetes) are IPv4-only, so an IPv6-facing design still terminates its managed edge on IPv4.

DCD Implementation Walkthrough

You will build FinCorp's three-LAN topology: a public edge LAN, a private application LAN, and a private data LAN, with a server NIC on each tier and a reserved public IPv4 ready for the edge. This realises the segmentation decision from Section 1 before any compute, security, or balancer build lands on top of it.

Build goal: Build the three-LAN topology with NICs and a reserved public IP.

Steps (in the Data Center Designer):

  1. Open the FinCorp VDC created in Unit 2.1 (reuse it; do not create a new region). The region is already fixed and IP reservations will be bound to it.
  2. Go to Menu > Network Services > IP Management and select Reserve IP Blocks. Reserve a public IPv4 block in the same region as the VDC. You cannot pick a specific address; you receive one (or more) from the pool. This is the future edge address, reserved first.
  3. In the Workspace, place the application-tier server and the data-tier server. Each server gets a NIC you will assign to a LAN in the next steps.
  4. Create the private application LAN: drag a LAN onto the workspace (or connect the application server's NIC to a new LAN) and leave it unconnected to the internet so it stays private. Keep the default /24.
  5. Create the private data LAN the same way, as a second private LAN, and attach the data-tier server's NIC to it. Do not connect it to the internet.
  6. Create the public edge LAN by attaching the Internet Access element to a new LAN. This is the only LAN that faces the internet; reserve it for the edge balancer and IP-failover NIC built in later units.
  7. On each NIC, set addressing per tier: a static address from the .10-.255 range for the data-tier NIC (so the database endpoint is stable), DHCP acceptable for the interchangeable application NIC. Keep .2-.9 free for managed services.
  8. Provision the changes. The three-LAN shape now exists with the public IP reserved and the tiers segmented.

Common mistakes:

  • Reserving the public IP after building the consumer. Reserve it first; the balancer, gateway, or failover group expects it to exist.
  • Assigning a VM into the .2-.9 managed-service range or into the .1/.2 gateway space, which collides with platform addressing.
  • Connecting the data LAN to the internet "just to test", which defeats the entire segmentation argument the compliance story rests on.
  • Putting an IP-failover edge or a load balancer on the same public LAN and expecting an NSG to protect it; the managed balancers cannot be wrapped in a security group, so the data tier's safety must come from being on a private LAN.
  • Reserving the IP in the wrong region; a reserved IPv4 is region-bound and unusable elsewhere.

Enterprise Case Study (FinCorp)

FinCorp's regulated customer-facing service is the workload that anchors this module. Its requirement is plain: customers reach a public HTTPS endpoint, but the account data must never be reachable from the internet. The design decision is to express that as topology, not as a rule set. The public edge LAN will later carry the Layer 7 balancer on the reserved IPv4; the application tier runs the business logic on a private LAN with DHCP-assigned, interchangeable NICs; and the relational cluster sits on a private data LAN with a static address, fronted only by the internal Layer 4 balancer built in Unit 3.4. Because the data LAN is never connected to the internet, FinCorp can argue to its auditors that the database cannot accept an external connection by construction, independent of any firewall rule being correct on a given day. Every later build in this module attaches to this exact shape.

Summary

The network tier a resource sits on is the primary control over its exposure on IONOS, because a LAN is private until explicitly connected to the internet and because the managed load balancers and the Kubernetes cluster cannot be wrapped in a firewall or security group. That makes segmentation, expressed as the three-tier topology (public edge, private application, private data), the load-bearing isolation decision. Addressing is planned around the /24 default with the .2-.9 managed-service range reserved and static addresses pinned for any node addressed by IP. A reserved public IPv4 is region-bound, costs EUR 5.00 per 30 days, requires the Reserve IP Blocks privilege, and should be reserved before the edge construct that consumes it; IPv6 is allocated hierarchically as a /56 per VDC, /64 per LAN, /80 per NIC.

Key Points:

  • A LAN is private until an internet-access element is attached, so private-by-default is the default and exposure is added deliberately.
  • NIC firewalls and NSGs bind to server NICs only, never to the managed ALB/NLB or the Kubernetes cluster abstraction, so topology is the real isolation control.
  • The LAN /24 reserves .2-.9 for managed services and assigns VM IPs from .10-.255; static addressing belongs on any node addressed by IP, DHCP on interchangeable tiers.
  • A reserved IPv4 is region-bound, billed at EUR 5.00 per 30 days, needs the Reserve IP Blocks privilege, and must be reserved before the consuming edge construct.
  • IPv6 is hierarchical (/56 per VDC, /64 per LAN, /80 per NIC, up to 256 IPv6-enabled LANs), but the managed network services are IPv4-only.

Important Terminology:

  • Reserved IPv4 block: a region-bound static public address (or block) reserved in IP Management, returnable only as a whole block and only when unused.
  • Managed-service range (.2-.9): the per-LAN /24 addresses reserved for platform-managed services, never to be assigned to customer VMs.
  • Dual stack: simultaneous IPv4 and IPv6 operation on a LAN; note the managed network services remain IPv4-only.

Further Reading

  • Unit 3.2: Network Security: Firewall and Security Groups (the rule layer inside this topology).
  • Unit 3.4: Load Balancing - Layer 4 (the internal balancer in front of the data LAN).
  • Unit 3.6: Hybrid Connectivity (the gateways that attach to the edge and egress paths).