Unit 1.1: The IONOS Cloud Platform Map

Introduction

Before any deep dive, you need a frame that the rest of the course fills in. IONOS Cloud is not a catalogue of unrelated services; it is a small number of product families that compose into solutions, all provisioned through one console and all scoped inside one organising boundary. This unit draws that map once so that every later unit, whether it designs a network or builds a database cluster, has a known place on it. We open it on the enterprise we will design throughout: FinCorp.

1. The Product Families and How They Relate

The platform divides into a handful of families that sit in a predictable relationship to each other. Compute provides the servers that run workloads. Networking connects them and exposes them, through Local Area Networks (LANs), load balancers, gateways, and DNS. Data services persist state, spanning block and shared file storage, S3-compatible Object Storage, the managed relational and NoSQL databases, the in-memory cache, and managed event streaming. Containers (Managed Kubernetes and the Container Registry) and the AI tier (the managed inference and model services) sit above compute and lean on the same networking and data layers beneath them. Operations, the audit, metrics, logging, and cost tooling, observes all of it.

The relationship is the important part. Networking is the substrate the other families plug into: a database, a Kubernetes node pool, and a load balancer are all attached to LANs inside the same boundary. Data services are reached privately from compute rather than exposed directly. Operations wraps the whole estate rather than belonging to any one workload. You will rarely deploy a family in isolation; you compose them, and the composition is where the architecture lives.

For FinCorp, a German financial-services firm operating under GDPR and the BSI security baseline, the map already implies the shape of the engagement. FinCorp runs a large existing VMware estate it must migrate and wants to build a new AI capability. On this map, the VMware estate lands on Private Cloud, a distinct product family running on dedicated single-tenant VMware hardware with its own control surface (the vSphere Client and NSX-T Manager, not the Data Center Designer or the IONOS Cloud API v6), the AI capability sits in the AI tier feeding off the data services, and the AI/data/networking families are bound by the shared networking substrate and observed by the same operations tooling, while Private Cloud remains a largely self-contained island outside that shared control plane. The course walks these decisions one family at a time; this unit only establishes where each one sits.

2. The Control Surface and the Organising Boundary

Two constructs hold the whole map together, and confusing them is a common early error.

The Data Center Designer (DCD) is the control surface. It is IONOS Cloud's graphical web application for creating and managing infrastructure, a drag-and-drop interface in which you model servers, storage, and networks visually and then provision them. Everything you build in this course you build through the DCD (or, equivalently, its API and tooling). The DCD is how you act on the platform; it is not where your resources live.

The Virtual Data Center (VDC) is the organising boundary. A VDC is a collection of cloud resources, the processors, memory, disk, and networks from which your infrastructure is assembled, that together form one enterprise-grade environment. Critically, a VDC is created against a single region, so every resource inside it shares that location. That single fact makes the VDC the natural unit of segmentation: you place a workload in a VDC and you have simultaneously chosen its region, its blast radius, and the network it shares with its neighbours. Region-locked artifacts such as uploaded images and reserved IPs reinforce this, since they cannot simply move between regions.

The mental model to carry forward is therefore: you operate the DCD (the surface) to build resources inside one or more VDCs (the boundaries), each pinned to a region. For FinCorp, this means the first real decision is not which database to run but which VDC, in which region, the regulated workload belongs to, a placement choice this course treats as nearly permanent. The reference diagram every later module fills in is exactly this: a region, a VDC inside it, the three networking tiers, and the compute, data, container, AI, and operations families attached in their places.

Decision Summary

The first design move on any IONOS engagement is to decide the VDC-and-region placement of each workload, because region-locked images and IPs make that decision expensive to reverse. Everything later in the course attaches to that choice.

Summary

IONOS Cloud is a compact set of product families, compute, networking, data services, containers, AI, and operations, that compose into solutions, all built through the Data Center Designer and all organised inside region-pinned Virtual Data Centers. Holding this map in mind lets every later unit slot into a known place, and lets the FinCorp engagement be reasoned about as one coherent system rather than a pile of services.

Key Points:

• The platform is a few composable families, not a flat catalogue; networking is the substrate the others attach to, and operations wraps the whole estate.
• The Data Center Designer is the control surface (how you act); the Virtual Data Center is the organising boundary (where resources live).
• A VDC is pinned to one region, which makes it the unit of segmentation and makes placement an early, near-permanent decision.
• FinCorp (German fintech, GDPR/BSI, a large VMware estate to migrate, an AI capability to build) is the single scenario every later unit's decision feeds into.