Unit 4.2: Images, Disks, and Cloud-Init

Introduction

A server shell is inert until it has a disk to boot from and a way to configure itself on first boot. Two of the disk's properties (its storage type and its availability zone) are fixed at provisioning and cannot be changed afterwards, which makes the disk layout a design decision rather than a runtime one. This unit extends the Dedicated Core server from Unit 4.1: it attaches storage, associates a boot image, and supplies cloud-init user data so the server arrives configured rather than bare. It does not repeat server creation.

1. Block Storage Tiers and the Performance Floor

IONOS Block Storage is network-attached iSCSI block storage, replicated active-active across two storage servers with RAID inside each (four physical copies in total) within a region. It comes in three tiers, and the tier is one of the two disk properties you cannot change later, so it is chosen up front per disk.

The documented per-volume performance is the basis for matching tier to access pattern:

Two facts drive the tiering decision. First, HDD performance is static and independent of volume size, whereas SSD performance scales with the volume size: the per-GB rates above mean a small SSD is a slow SSD. Second, IONOS recommends booking SSD volumes of at least 100 GB to get the full benefit; below that floor, performance is suboptimal, which is why SSD volumes under roughly 100 GB are not recommended for database workloads. For an SSD volume, the system predicts performance from the size, and for volumes above 600 GB the per-volume rates are capped at the documented maxima (an SSD Premium volume tops out at 45,000 read IOPS and 600 MB/s sequential per VM, given enough cores and RAM on the VM).

The practical layout rule follows directly. Use HDD for cold or sequential data (backups, archives, logs staged for export) where its size-independent throughput is fine and its 0.04 EUR per GB per month is the cheapest. Use SSD Standard (0.07 EUR per GB per month) for general workloads, and SSD Premium (0.15 EUR per GB per month) for latency-sensitive and database disks, keeping any database volume at or above the 100 GB floor so it sits in the full-performance band. Volumes run from 1 GiB up to 4096 GiB (4 TiB); a VM attaches up to 24 HDD or SSD Standard volumes, but only 4 SSD Premium volumes, which is a constraint worth checking before you fan out a high-tier data layout. Tiers can be mixed on one VM, so a common pattern is a modest SSD Premium boot/data disk plus HDD volumes for bulk.

2. Images, Immutability, and Region-Locking

A disk becomes bootable by associating an image with it: an IONOS-provided public image (Linux distributions including Alma, Debian, Rocky, and Ubuntu, plus Microsoft images), or your own private image uploaded over FTPS. Private images and snapshots are region-locked: they are usable in the region they were uploaded or created in, and IONOS does not create cross-region redundancy for them. If a workload must exist in two regions, the image is uploaded or copied to each; there is no managed cross-region replication of images to lean on.

Two storage properties are immutable after provisioning and must be right the first time:

• Storage type. You cannot change a volume between HDD, SSD Standard, and SSD Premium after it is provisioned. A retier means creating a new volume and migrating data.
• Availability zone. The volume's zone is fixed at creation; selecting Auto lets the system assign the optimal zone. Note the asymmetry carried from Unit 1.2 and revisited in Module 5: Block Storage offers Zones 1, 2, 3, and Auto, while compute offers only Zones 1, 2, and Auto. Block Storage Zone 3 exists; compute Zone 3 does not.

Volume size, by contrast, can be increased after provisioning (even on a running server, if the operating system supports it) but never reduced. So the safe sizing posture is to start conservative and grow, never to over-provision a disk you cannot shrink. Snapshots, the VM-level rollback mechanism, are also region-local and non-incremental: a snapshot covers the volume's entire allocated capacity (a 100 GB volume holding 10 GB of data still produces a 100 GB snapshot) and is a rollback tool, not a database backup. Their role in the data-continuity plane is covered in Module 5.

3. Cloud-Init for First-Boot Configuration

Cloud-init is the mechanism that turns a freshly booted Linux server from a bare image into a configured node without manual login. You supply user data at creation time, and cloud-init applies it during the first boot. The capability boundary is precise and worth stating: cloud-init is fully supported on all public IONOS Linux images, and SSH-key injection applies to public IONOS Cloud Linux images. It is not supported on Windows. For Windows first-boot configuration you reach for a different mechanism, not cloud-init.

User data is written as a shell script or as cloud-config YAML, and IONOS cloud-init accepts several formats, including a user-data script (beginning with #! or Content-Type: text/x-shellscript), cloud-config data (beginning with #cloud-config), an include file, an upstart job, a cloud boothook, and base64-encoded payloads (which cloud-init decodes and then handles as one of the supported types). On the volume resource the cloud-init user data is set at volume creation and is immutable thereafter, which is consistent with treating first-boot configuration as part of provisioning rather than a later edit. When you need to debug what cloud-init did, the logs live at /var/log/cloud-init-output.log and /var/log/cloud-init.log.

A minimal cloud-config that creates the FinCorp application user and installs a package on first boot illustrates the shape; the architectural point is that this runs exactly once, at first boot, and is fixed on the volume at creation:

#cloud-config
packages:
  - nginx
runcmd:
  - systemctl enable --now nginx

DCD Implementation Walkthrough

This walkthrough extends the Dedicated Core server provisioned in Unit 4.1. It attaches a boot volume on the right storage tier, associates a Linux image, and supplies cloud-init user data so the FinCorp application server arrives configured. The prerequisite is the Unit 4.1 server shell in the FinCorp VDC. Do not recreate the server.

Build goal: Attach and configure storage; supply cloud-init user data.

Steps (in the Data Center Designer):

1. In the Workspace, select the Unit 4.1 Dedicated Core server. From the Palette, drag a storage element (HDD or SSD) onto the server to connect it; the server expands to show a storage section.
2. Select the new storage element to open the Inspector. Give it a VDC-unique name.
3. Choose the storage type (for the FinCorp app boot/data disk, SSD Premium). This is immutable after provisioning, so confirm the tier now.
4. Set the Availability Zone (Auto lets the system assign the optimal zone). This is also immutable after provisioning.
5. Set the Size, keeping an SSD volume at or above the ~100 GB floor for full performance. Size can be increased later but never reduced.
6. Under Image, associate an image: choose an IONOS public Linux image, or select Own Images for a private uploaded image. Set the root/administrator Password (required for Remote Console access) and/or an SSH key.
7. Mark the volume as the boot device (click BOOT / Make Boot Device) so the server starts from it.
8. Expand the cloud-init / user-data field and paste the cloud-config or user-data script. Confirm the image reports cloud-init support. Click Provision Changes to apply.

Common mistakes:

• Choosing the wrong storage type or zone, both of which are immutable. A retier or a zone move means rebuilding the volume, not editing it.
• Putting a database on a sub-100 GB SSD volume. Below the floor the SSD runs at suboptimal IOPS; keep DB volumes at or above 100 GB.
• Expecting cloud-init on Windows. Cloud-init is for public Linux images; SSH-key injection is scoped to public IONOS Cloud Linux images.
• Assuming an image is available everywhere. Private images and snapshots are region-locked; upload or copy to each region you need.
• Over-provisioning a disk to be safe. Volumes can grow but never shrink, so start conservative and increase later.

Summary

A server becomes useful when it has a disk and a first-boot configuration. Block Storage comes in three tiers whose performance and price differ, with SSD performance scaling by size and a ~100 GB floor that keeps small SSDs (and therefore small database disks) out of the full-performance band. Storage type and availability zone are immutable after provisioning, while size can grow but never shrink, so disk layout is a design decision. Images are region-locked with no managed cross-region replication, and cloud-init configures public Linux images on first boot (not Windows), set once on the volume at creation. The walkthrough extends the Unit 4.1 server into a configured FinCorp application node.

Key Points:

• HDD performance is size-independent; SSD performance scales with size, so a small SSD is a slow SSD and DB volumes belong at or above ~100 GB.
• Storage type and availability zone are immutable after provisioning; size grows but never shrinks.
• Block Storage has Zones 1, 2, 3, and Auto; compute has only Zones 1, 2, and Auto.
• Images and snapshots are region-locked, with no managed cross-region replication.
• Cloud-init configures public Linux images on first boot (SSH-key injection on public IONOS Linux images); it is not supported on Windows, and the user data is fixed on the volume at creation.

Important Terminology:

• SSD performance floor: the ~100 GB minimum below which an SSD volume runs at suboptimal IOPS; the reason small DB disks are discouraged.
• Cloud-init: the first-boot configuration mechanism for public Linux images, supplied as user data and applied once at boot.
• Region-locked image: a private image or snapshot usable only in the region it was uploaded or created in.

Further Reading

• Unit 4.1: Compute Class Selection (the server this unit extends).
• Unit 5.7: Data Protection and Lifecycle (snapshots, backup, and PITR composed into a continuity plane).
• Unit 7.3: Performance Engineering (storage performance floors as a latency lever).