8 min read

Learning Objectives

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

  • Distinguish the contract as the commercial, governance, and audit boundary from the Virtual Data Center as the regional segmentation primitive inside it.
  • Decide when a workload requires a separate contract versus a separate VDC.
  • Account for boundary stickiness: region-locked IPs and images, and the absence of native cross-contract sharing or audit aggregation.
  • Create the scenario's first VDC in the Data Center Designer, fixing region and naming as permanent decisions.

Unit 2.1: Resource Model: Contracts, VDCs, and Boundaries

Introduction

Before any compute or network is drawn, an enterprise has to settle two structural questions: where the commercial and audit line falls, and how regional segmentation is organised beneath it. On IONOS those two questions map to two distinct primitives, the contract and the Virtual Data Center, and confusing them is one of the most expensive mistakes an architect can make, because several of the decisions are effectively irreversible once a workload lands. This unit fixes the meaning of each boundary, shows where the platform deliberately does not let you cross it, and ends by creating FinCorp's first VDC in the Data Center Designer with the region and name set as permanent choices.

1. The Contract Boundary and the VDC Beneath It

The contract is the top-level commercial, governance, and audit boundary. It is the unit a bill is rendered against, the scope an Activity Log is queried for, and the realm a contract owner governs. Exactly one contract owner exists per contract; that account is created automatically for whoever first registered with IONOS Cloud, has full access to all resources, and cannot be revoked. Administrators (unlimited per contract) share that owner's reach across all contracted resources except changing the payment method. Everything else, every user, group, VDC, IP block and image, lives inside a single contract and does not natively cross out of it.

The Virtual Data Center is the organising boundary inside the contract. A VDC is a collection of cloud resources for building an enterprise-grade IT infrastructure, scoped to one region, and it is where the network, compute and storage of an environment actually live. A contract can hold many VDCs; a VDC belongs to exactly one contract and one region. The mental model to carry forward is that the contract draws the commercial and compliance line, and the VDC draws the regional and environmental line beneath it.

The two boundaries answer different questions, so the decision to split one is independent of the decision to split the other.

Split a new ... When the driver is Because the boundary governs
Contract Compliance isolation, separate billing/ownership, a distinct legal entity or audit scope Billing, the contract owner, IAM realm, and the Activity Log query scope
VDC A different region, a network/environment separation (prod vs non-prod), or a project that must bill as its own line item Regional placement, network topology, and resource grouping inside one contract

A separate VDC already produces a separate section on the monthly bill, so cost separation alone does not justify a second contract. Reach for a new contract only when the driver is genuinely commercial or compliance-level: a different owner, a different legal entity, or an audit scope that must not see the other workloads. Reach for a new VDC for region, environment, or network separation within the same governance realm.

2. Boundary Stickiness: What Does Not Cross

The platform enforces these boundaries strictly, and the enforcement is itself a design input rather than a limitation to route around.

Several attributes are region-locked. A reserved IPv4 address can only be used in the data-center region where it was reserved; you cannot reserve a specific address, only a block, and a different IP from one block may serve a different network but only within that same region. Images and snapshots are likewise region-local, and IONOS does not provide cross-region replication as a managed feature, so moving an image to another region means re-uploading or using Backup Service or Object Storage as the transfer medium. The practical consequence is that the region you choose for a VDC at creation propagates into every region-bound resource that VDC later holds.

The contract boundary is equally firm. There is no native cross-contract resource sharing and no cross-contract audit aggregation: an Activity Log is scoped to a single contract and queried per contract, so an organisation that splits workloads across two contracts must aggregate audit data itself, externally. Naming and region are permanent decisions in the same spirit. A VDC's region is fixed at creation and cannot be changed afterward, and because that region locks IPs and images, treating the name and region as one-way doors is the correct posture.

For FinCorp, this shapes the very first decision. The regulated, GDPR/BSI-scoped workloads sit in a single governance contract so that one Activity Log and one billing relationship cover them, and the first VDC for that estate is pinned to a German region (the residency filter settled in Unit 1.4) with a naming convention that signals environment and region at a glance, for example fincorp-prod-de rather than an unscoped label. Because the region cannot be changed later, this pin is made deliberately and once.

DCD Implementation Walkthrough

You will create FinCorp's first Virtual Data Center, fixing its region and name. This is structure only; no compute is provisioned here (the server build is Module 4). The goal is to lay down the regional segmentation primitive that every later FinCorp build attaches to, with its two irreversible attributes set correctly.

Build goal: Create the scenario's first VDC, fixing region and naming.

Steps (in the Data Center Designer):

  1. In the DCD, choose to create a new Virtual Data Center. The creation dialog is where the two permanent attributes are set, so treat this screen as the decision point.
  2. Enter the VDC Name using the agreed convention that encodes environment and region (for example fincorp-prod-de). The name should be readable on the bill and in the Activity Log later.
  3. Select the Region / Location. Choose the German data-center region required by FinCorp's residency filter. This selection is permanent for the life of the VDC and locks the region for every reserved IP and image the VDC will hold, so confirm it before proceeding.
  4. Open the new VDC in the Workspace. It starts empty; resources are added later by dragging elements from the Palette.
  5. Click PROVISION CHANGES in the Inspector pane to commit. The Provision Data Center dialog opens; review the changes in the Validation tab and confirm with your password to start provisioning.

Common mistakes:

  • Treating the region as changeable later. It is not; a VDC's region is fixed at creation, and it locks IPs and images, so a wrong region means rebuilding the VDC.
  • Using a second contract to separate cost. A separate VDC already produces its own line on the monthly bill; reserve a new contract for compliance, ownership, or legal-entity separation.
  • Leaving the VDC unnamed or generically named. The name surfaces on the bill and in audit queries; an unscoped name makes both harder to read at enterprise scale.
  • Expecting to share a reserved IP or image across regions. Both are region-bound; plan placement per region from the start.

Summary

The contract is the commercial, governance, and audit boundary; the VDC is the regional segmentation primitive beneath it, scoped to one contract and one region. Split a contract for compliance, ownership, or billing-entity reasons, and split a VDC for region, environment, or network separation. Because region and naming are permanent and because IPs, images, and audit scope do not cross these boundaries, the first VDC for FinCorp's regulated estate is created deliberately, pinned to a German region with a convention-driven name.

Key Points:

  • The contract draws the commercial, governance, and audit line; the VDC draws the regional and environmental line inside it. There is exactly one (non-revocable) contract owner per contract.
  • A separate VDC already bills as its own line item, so split a new contract only for compliance, ownership, or legal-entity separation, not merely for cost visibility.
  • Region and naming are permanent at VDC creation; the region locks reserved IPs and images, none of which replicate across regions as a managed feature.
  • There is no native cross-contract sharing or audit aggregation; an Activity Log is per contract, so multi-contract organisations aggregate audit data externally.
  • FinCorp's first VDC is pinned to a German region for residency and named by convention so it is legible on the bill and in audit queries.

Important Terminology:

  • Contract: The top-level commercial, governance, and audit boundary; the scope of billing, the contract owner, the IAM realm, and Activity Log queries.
  • Virtual Data Center (VDC): A region-scoped collection of cloud resources inside one contract; the unit of network, compute, and storage organisation.
  • Reserved IP block: A region-bound allocation of public IPv4 addresses usable only in the region where it was reserved.