AWS IaaS Resource Model

This is the public-cloud layer that exists before Ansible ever touches virt-01. It lays down the outer host and guest-disk substrate first.

Ownership Split

The CloudFormation layer is intentionally split into two scopes.

Tenant stack owns:

• VPC
• public subnet
• internet gateway
• public route table
• persistent Elastic IP reserved for virt-01

Host stack owns:

• security group for virt-01
• imported EC2 key pair
• virt-01 EC2 instance
• guest EBS volumes and attachments

The CloudFormation layer does not own:

• host subscription and package configuration
• /dev/ebs/* udev naming inside virt-01
• OVS, firewalld, libvirt, or guest VM provisioning inside virt-01

Those remain part of the Ansible bootstrap and lab orchestration.

Current discovered resource intent

The discovered guest-volume recreation set is captured in:

• cloudformation/virt-01-volume-inventory.yml

That inventory includes:

• support VM root disks
• OpenShift control-plane root disks
• OpenShift worker root disks
• OpenShift infra root disks
• OpenShift infra ODF data disks

The unused haproxy-01 volume is explicitly excluded from the intended stack.

Template shape

The rendered tenant-only CloudFormation template is:

• cloudformation/tenant.yaml

The rendered host-only CloudFormation template is:

• cloudformation/virt-host.yaml

The legacy full-stack CloudFormation template remains available as a compatibility path:

• cloudformation/virt-lab.yaml

The rendered template is produced from:

• cloudformation/virt-01-volume-inventory.yml
• cloudformation/templates/tenant.yaml.j2
• cloudformation/templates/virt-lab.yaml.j2
• cloudformation/templates/virt-host.yaml.j2
• cloudformation/render-virt-lab.py

Example parameter files are:

• cloudformation/parameters.tenant-example.json
• cloudformation/parameters.example.json

Deployment helpers are:

• cloudformation/deploy-stack.sh
• cloudformation/deploy-virt-lab.sh

Recommended deploy order for a full fresh environment is:

1. cloudformation/deploy-stack.sh tenant
2. cloudformation/deploy-stack.sh host

Current design notes

• virt-01 uses m5.metal
• the current discovered RHEL image is a private/shared Red Hat RHEL 10.1 AMI
• the host stack imports an EC2 key pair from supplied public key material
• the host stack renders a cloud-init user-data payload for virt-01
• cloud-init sets:
  • hostname: virt-01
  • fqdn: virt-01.workshop.lan
  • manage_etc_hosts: true
• cloud-init adds the operator SSH public key to ec2-user
• cloud-init assigns a supplied SHA-512 password hash to ec2-user so Cockpit can be used through an SSH SOCKS proxy without exposing port 9090
• cloud-init installs and enables cockpit.socket
• the bootstrap layer later enforces the same FQDN and 127.0.1.1 host entry so the rebuilt host identity stays stable
• the tenant stack creates the preferred persistent Elastic IP for virt-01
• the host-only stack can associate an existing Elastic IP allocation to virt-01
• a persistent Elastic IP is preferred so SSH access and SOCKS-proxied Cockpit access remain stable across host power cycles
• all guest disks are tagged with GuestDisk and Purpose
• the Ansible bootstrap derives the current active guest-volume map from AWS by GuestDisk tag and then renders and installs /etc/udev/rules.d/99-ebs-friendly.rules so /dev/ebs/* names remain deterministic after a rebuild
• the Ansible bootstrap can source the RHEL guest image from either:
  • <project-root>/images/rhel-10.1-x86_64-kvm.qcow2, or
  • lab_execution_guest_base_image_url when a Red Hat direct-download URL is supplied
• the host and legacy full stacks are rendered from the same volume inventory so the AWS EBS resource list does not drift from the hypervisor naming layer
• fresh AWS RHEL hosts are expected to bootstrap against Red Hat CDN content, not RHUI-only content, because the host requires the fast-datapath repository for openvswitch3.6
• fresh AWS RHEL hosts also install the Cockpit and PCP services needed for the lab; the exact package and service inventory is tracked in ORCHESTRATION GUIDE
• fresh AWS RHEL hosts are updated before idm-01 and bastion-01 are built, and bootstrap reboots the hypervisor when the package transaction requires it

Current recommendation

• use tenant when standing up a fresh AWS environment from zero
• use host when rebuilding virt-01 inside an already-provisioned tenant
• keep full only as a backward-compatible convenience path while the project transitions fully to the two-stack model

Calabi versus native cloud fanout

The main reason to do this on one metal host is architectural realism, not raw cost reduction.

The project name is intentional: Calabi is shorthand for a Calabi-Yau manifold, which is a useful metaphor here. The lab folds what would normally be a spread-out datacenter footprint into one host while still keeping clear network, storage, and service boundaries.

The lab keeps a shape that still feels like a real deployment:

• separate support services
• a full 3 control-plane / 3 infra / 3 worker cluster
• realistic storage carve-up
• network boundaries that map cleanly to what you would do across multiple hosts
• Windows AD guest for hybrid identity testing

That is the first win. You get a deployment pattern that is much easier to relate to a real environment than a toy single-node build, while still keeping it small enough to run on one public-cloud metal instance.

Native instance equivalents

Pricing the current guest estate as individual EC2 instances in us-east-2, rounding each guest up to the nearest practical instance type:

EBS storage

EBS cost is essentially the same in both models. All guest disks are gp3 volumes attached to virt-01 in the Calabi model and would attach directly to each instance in the native model. The current volume layout:

At current gp3 pricing ($0.08/GiB/month) plus IOPS and throughput overages on the master volumes (6000 IOPS, 250 MB/s), total EBS cost is approximately $544/month in both models. The native model drops the virt-01 root but the total stays within a few dollars either way.

Monthly cost comparison

Short-run cost comparison

For short-lived lab events the EBS cost is amortized across the month regardless of runtime, so the per-event savings come entirely from compute hours:

How oversubscription widens the gap

The Calabi cost is fixed at $4.608/hr regardless of how many vCPUs or how much memory the guests consume. The native cost scales linearly with every guest uplift.

The current layout already demonstrates this:

• 122 guest vCPUs on 72 physical CPUs (1.69:1 oversubscription)
• 360 GiB committed guest memory on 384 GiB host (0.94:1)
• the Gold/Silver/Bronze tier model ensures degradation is intentional
• KSM, zram, and THP provide the memory safety margin

If the same lab had stayed at the original 3 x 4 vCPU worker shape with 48 GiB infra nodes, the native fanout cost would have been lower, and the Calabi cost advantage would have been marginal. The progression:

The argument

The one-host model is already worthwhile for realism and repeatability. Once the host carries a larger guest footprint through controlled oversubscription, it wins on cost as well:

• native cloud buys every guest uplift literally, at the nearest instance shape
• Calabi absorbs uplift into policy: more vCPU and memory on the same host, managed by tier weights and kernel memory efficiency
• the cost gap widens with each guest uplift because the native side scales linearly while the Calabi side stays flat
• the Windows AD guest is a particularly clear example: native AWS charges a license premium per hour, while Calabi runs it as a plain KVM domain

All pricing is US East (Ohio) on-demand as of March 2026. Reserved or savings-plan pricing reduces both sides proportionally but does not change the relative gap.