How a Czech Micro-MSP Replaced AWS Reselling with Apache CloudStack to Boost Hosting Margins from 5% to 60%

2

Read 14 min.

When a company sells not servers but the result — customers’ working systems — its infrastructure needs to have predictable costs and be manageable without unnecessary manual work. This case study shows how a managed IT services provider from the Czech Republic moved its customers’ systems from a hyperscaler to a single leased dedicated server with a private Apache CloudStack cloud. The company gained a fixed bill, customer isolation, and built-in usage tracking while reducing infrastructure costs by more than four to five times.

Context

The client is a managed IT services provider from the Czech Republic. The company serves several dozen B2B customers in the region and manages their entire IT environment: workstation and server support, backups, monitoring, email, accounting systems, VPN, and internal applications. Computing resources are a tool rather than a product: customers’ systems run on virtual machines, and the MSP is responsible for them under support contracts.

The server-side systems of the customers were hosted in the public AWS cloud in the Frankfurt region. The MSP provisioned infrastructure separately for each customer and included its cost in the monthly support fee with a markup of approximately 5% on average, according to the client.

Goals and Results

The goals of the pilot project were:

The Problem

For the MSP, public-cloud infrastructure was a pass-through cost. The bill consisted of dozens of line items and changed from month to month: hourly charges for CPU and memory, separate fees for outbound traffic, storage, and snapshots. It was impossible to tell the customer the exact amount before the end of the month. Pricing changes were absorbed by the MSP, while earnings on the infrastructure portion of contracts were limited to a markup of approximately 5%.

The second problem was management. Some customers wanted to create, stop, and roll back their own virtual machines without contacting MSP employees. Giving customers access to the MSP’s shared cloud infrastructure was unacceptable, while separate accounts for each customer required individual permission configurations, separate billing, and separate accounting for every customer.

The MSP approached INTROSERV with a request for a pilot project: lease a dedicated server in a European data center and deploy a ready-to-use private cloud on it as a replacement for the hyperscaler for typical customer systems, with the option to expand to multiple nodes later.

Infrastructure Configuration

INTROSERV provided a dedicated server hosted in a Tier III data center in the Netherlands with a guaranteed network availability of 99.99%.

Main server:

• CPU: 2x Intel Xeon Gold 6130 — 32 physical cores, 64 threads, 2.10 GHz base frequency, up to 3.70 GHz turbo

• RAM: 256 GB REG ECC DDR4, expandable to 1 TB

• NVMe: 2x 3.84 TB in software RAID 1 — 3.84 TB of local storage for VM disks

• SATA: 4x 14 TB in software RAID 10 — 28 TB for backups and secondary storage

• Network: two 25 Gbps ports, unlimited traffic; 10 Gbps private VLAN network

• Management: iDRAC

• DDoS protection: 20 Gbps

• Redundant power supply

A backup server for virtual machines is connected to the main server via a private 10 Gbps VLAN network.

INTROSERV’s backup service, based on NAKIVO Backup & Replication, costs €49 per month for 5 TB. The entire server is backed up: the host operating system, CloudStack configuration, and management server database. If the server fails, the system is deployed on new hardware from this backup, after which the virtual machines are restored from the backup server.

The configuration meets the requirements for single-machine-level fault tolerance:

• Network: two independent 25 Gbps ports are bonded into a fault-tolerant link. Failure of one port or link does not interrupt the operation of the virtual machines.
• Power: two power supply units. Failure of one does not shut down the server.
• Disks: all drives are configured in RAID arrays. Failure of one NVMe or one SATA drive does not result in data loss or server downtime.
• Storage: VM disks are stored on a local NVMe array without network storage between the hypervisor and the data. This provides minimal I/O latency for customers’ databases and accounting systems.
• Backups: virtual machine backups are transferred to a separate physical server over a private 10 Gbps network, without using external ports or incurring traffic charges. A full server backup is stored in the 5 TB backup service storage.

The server bill covers everything that would be charged separately by a hyperscaler: traffic, redundant network and power, disk fault tolerance, high-speed local storage, a private network to the backup server, and remote management through iDRAC. The two backup-related items are fixed-cost items.

The Solution

The INTROSERV team deployed Apache CloudStack on the server in a single-node configuration: the management server and KVM host run on the same machine. The work was performed as part of an hourly system administration service, after which platform management was handed over to the client.

Why Apache CloudStack Instead of Proxmox VE

Both platforms are open source and run on KVM. Proxmox VE is distributed under AGPLv3 and works without payment; a paid subscription per CPU socket is only required for access to the enterprise update repository and vendor technical support. Apache CloudStack is distributed under the Apache License 2.0 with no fees for sockets, cores, or VMs. Licensing was not the deciding factor. The key factors were four functions built into CloudStack that require external tools in Proxmox VE:

• Multi-tenancy. Domains, Accounts, and Projects with resource limits and quotas for each customer. Customers who wanted to manage their own VM fleet received their own account with a dedicated role: they can see only their own resources, create and stop VMs, and take snapshots and rollbacks within their allocated quota. Quota enforcement is handled by the platform rather than by a manual process.
• Usage tracking. The built-in Usage Server records CPU, memory, disk, and traffic consumption for each account; the Quota plugin maintains balances based on pricing plans. Data for internal cost calculations and customer billing is taken directly from the platform rather than collected manually.
• Kubernetes. CloudStack Kubernetes Service deploys and updates Kubernetes clusters for customers from the console or via API, with node scaling and the ability to connect CloudStack disks as cluster volumes. Customers running containerized applications receive a cluster without the need for a separate platform.
• Network services. Isolated networks with a virtual router for each customer: firewall, NAT, load balancing, and VPN.

Adding a new customer became a standardized operation: create a domain and account, an isolated network with a virtual router, a quota, and virtual machines from a ready-made template. Everything can be performed from the console or via API and the Terraform provider in minutes rather than hours of manual configuration in a hyperscaler console. Snapshots provide rollback points before customer-system updates, while templates provide identical base images for all customers.

Fault-Tolerance Level

System availability is important for the MSP’s customers, but the workload — accounting systems, email, and internal applications — does not require high availability with automatic VM restart on another host within minutes. The first group of customers does not have continuous-operation systems where several hours of downtime would result in direct losses; a planned maintenance window or recovery from backup is acceptable for them.

Therefore, a high-availability cluster was considered excessive for the pilot: it requires multiple nodes and shared storage. A single node with machine-level redundancy was selected, and this configuration proved sufficient. Component failures are covered at the hardware level: two bonded 25 Gbps ports, two power supply units, and all disks in RAID arrays. Array degradation and insufficient host resources are monitored proactively, and drives are replaced before an issue affects the virtual machines.

A complete server failure is covered by two levels of backups: the host backup in NAKIVO restores the operating system and CloudStack on a new server without requiring reconfiguration, while virtual machine backups restore customers’ systems to operation. High availability is planned for the expansion stage when the infrastructure grows to multiple nodes — additional hosts will be added to the same CloudStack without changing the platform.

Work Completed

1. Server preparation: OS installation, software RAID arrays (RAID 1 on NVMe, RAID 10 on SATA), bonding of two 25 Gbps ports into a fault-tolerant link, and configuration of a private VLAN network to the backup server.

2. Installation of the CloudStack management server and KVM agent on a single node, configuration of the database and system VMs.

3. Creation of the zone, pod, and cluster; primary storage on the NVMe array and secondary storage on the SATA array.

4. Network model: isolated networks with a virtual router for each customer, a public IP range, firewall rules, and NAT.

5. OS templates (Ubuntu, Debian, AlmaLinux, Windows Server) and service offerings for three standard VM sizes.

6. Backup of virtual machines to a separate backup server over a private 10 Gbps network; connection of the server to INTROSERV’s NAKIVO-based backup service with a schedule for full-server backups.

7. Domains and Accounts for MSP customers, roles and resource limits, activation of the Usage Server and Quota plugin; activation of CloudStack Kubernetes Service and registration of ISO images containing Kubernetes binaries.

8. Proactive monitoring: host operating system status (CPU, memory, disk space, network interfaces, system services) and disk arrays (RAID status, drive SMART metrics), with notifications sent to INTROSERV engineers.

9. Testing: test VMs of all three sizes, snapshots and rollbacks, external network access, VM backup testing, and full-server backup testing. 

10. Client handover: CloudStack console, API keys, configuration documentation, and iDRAC access.

The total scope of work was 16 hours. After handover, INTROSERV provides support based on monitoring alerts or customer requests: drive replacement, hypervisor and management-server updates, and configuration expansion.

Virtual Machine Placement

During the pilot, 20 VMs supporting customer systems of three standard sizes were migrated to the node. Memory is allocated without overcommitment: 64 GB remains available for the management server, system VMs, and the next customer systems. All virtual machine disks are located on the server’s local NVMe array, giving each VM the disk performance that would have required a separate charge under the hyperscaler’s storage pricing for guaranteed IOPS.

Virtual CPUs are allocated with minimal overcommitment — 72 vCPUs for 64 threads — while actual CPU utilization during business hours does not exceed 50%. Approximately 700 GB remains free on the NVMe array. The project is a pilot, and this capacity reserve was intentional: additional customer systems can be added to the same node without changing the configuration, while expanding memory to 1 TB and adding drives increases node capacity several times over.

Infrastructure as a Strategic Advantage

The solution implemented by the INTROSERV team replaced the hyperscaler as the provider of computing resources for the MSP’s customer systems. A single leased server with Apache CloudStack took on the first group of 20 virtual machines with room for growth and a level of fault tolerance appropriate to the workload.

The client gained capabilities that were not available in the public cloud: customer isolation and usage tracking at the platform level, self-service for customers with their own accounts, Kubernetes clusters from the same console, and proactive monitoring of the host and disk arrays. Network and power redundancy, RAID-protected disks, local NVMe storage, unlimited 25 Gbps ports, and DDoS protection are included in the server cost.

Economics

The majority of traffic passes through customers’ VPN servers: the node’s outbound traffic is 20–35 TB per month. An equivalent set of resources from the previous provider — 20 virtual machines with the same profile, storage, snapshots, and this volume of outbound traffic at the current Frankfurt-region rates — costs approximately €4,000–5,100 per month, or around €54,000 per year. Between €1,500 and €2,600 of this amount is traffic: at the hyperscaler, every gigabyte delivered through VPN to customers’ employees is charged separately.

INTROSERV costs €1,017 per month: €671 for the main server, €157 for the backup server, €49 for full-server backup, with the remainder covering on-demand administration and amortization of the one-time deployment. Two 25 Gbps ports with unlimited traffic are included in the server rental, so the outbound traffic generated by customer systems does not affect the bill whether it is 35 or 50 TB per month.

The cost base is four to five times lower, the amount is fixed, and it is known before the beginning of the month. This allowed the client to include infrastructure in a fixed support fee, offer customers more favorable terms, and increase the profitability of the infrastructure portion of its contracts. As the customer portfolio grows, the gap with the hyperscaler increases — the server bill does not depend on traffic or changes in instance pricing. The client was fully satisfied with the cost of the solution.

Next Steps

The open platform with no licensing fees resolved the scaling question: expanding memory to 1 TB increases node capacity several times over, while a second node can be added to the existing CloudStack cluster without changing tools. Customer data remains on dedicated servers in a European data center within a perimeter controlled by the client. For a company serving customers in the EU under GDPR requirements, this is a mandatory condition. Following the pilot, the MSP will decide whether to migrate additional groups of customer systems to CloudStack.

Does your infrastructure cost more at a hyperscaler than it should, while the bill remains impossible to predict? Entrust the migration to the INTROSERV team: we will select the right server configuration, deploy Apache CloudStack, and hand over a ready-to-use  private cloud.