Host Setup: AWS

Deploy this workshop on a fresh AWS EC2 host instead of your own bare-metal box. Same 8 exercises, same custom/scripts/ pre-lab automation. Only the host changes.

Automation is entirely rodeo-cli. This repo's aws/ directory ships the plan.

For a bare-metal host instead, see Host Setup.

Requirements

Resource	Value
AWS account	Permissions for EC2 (RunInstances, Describe*, ModifyInstanceAttribute, security groups). No extra IAM needed.
VPC/subnet	Any subnet with an internet gateway (public IP reachable)
Local machine	Just rodeo-cli installed and AWS credentials configured (aws configure / SSO). No bare-metal resources needed.

Instance tiers

Set via provider.instance_tier in rodeo-plan.yaml (default: recommended), or pin provider.instance_type directly to skip tiers entirely. Specs below come from AWS's own instance-type data (aws ec2 describe-instance-types). Prices are on-demand Linux, eu-north-1, pulled live from the AWS Price List API on 2026-09-14.

Always check current pricing for your region. These change over time.

Tier	Instance	vCPU	RAM	Local storage	~$/hr (eu-north-1)	Notes
recommended	m8id.8xlarge	32	128 GiB	1× 1900 GB NVMe (single device)	$2.22	Best fit for this profile's real ~1560 GB need (500 GB × 3 Harvester nodes + 60 GB Rancher). Live-verified end to end 2026-09-14.
performance	m7i.metal-24xl	96	384 GiB	EBS only (bare metal)	$5.14	Bare-metal instance for max nested-virtualization performance, when extra vCPU/RAM matters more than local NVMe

The deploy itself takes 30-90 minutes on recommended. Total cost is that plus however long you keep the instance running afterward.

There's no budget tier for this 3-node profile. An EBS-only, more-vCPU/RAM instance (m7i.16xlarge) actually costs more than recommended here, since local NVMe matters more for nested Harvester's Longhorn I/O than raw compute. So it isn't a real budget option. rodeo-cli ships a genuinely cheaper path as a separate profile (virt-workshop-aws-2n, 2-node Harvester on a smaller instance) if you want one, but it isn't wired into this repo's docs or deploy flow.

Confirm your AWS credentials work before starting:

aws sts get-caller-identity

Install rodeo-cli (on your local machine)

curl -fsSL https://raw.githubusercontent.com/avaleror/rodeo-cli/main/install.sh | bash

Unlike the bare-metal path, this installs on your laptop, not the lab host. rodeo-cli here acts as the control plane: it provisions EC2, then the EC2 host bootstraps its own copy of rodeo-cli to actually deploy.

Deploy this workshop

git clone https://github.com/avaleror/suse-virt-workshop.git
cd suse-virt-workshop/aws

Edit rodeo-plan.yaml's provider: block for your own AWS account:

provider:
  type: aws
  region: eu-central-1          # <- your region
  subnet_id: subnet-CHANGE-ME   # <- must be in a VPC with an internet gateway
  instance_tier: recommended    # recommended | performance (no budget tier, see below)

Then:

rodeo up --profile virt-workshop-aws --target aws
# or override the tier without editing the file:
rodeo up --profile virt-workshop-aws --target aws --instance-tier performance

This will:

1. Provision the EC2 instance (region/subnet/size from rodeo-plan.yaml above)
2. Create and scope a security group to your current public IP (skip by setting provider.security_group_ids yourself)
3. SSH in and bootstrap rodeo-cli on the host
4. Drive the full pipeline remotely: kvm_host → vms → pxe_server → cluster → rancher → finalise → custom_scripts
5. Print Harvester / Rancher URLs and where to find passwords

Typical time: 30-90 minutes. Faster than bare-metal, thanks to AWS's NVMe and consistent CPU generation. No tmux needed: the local rodeo up process holds the connection until the remote deploy finishes.

Known limitation: on a very long remote deploy, the SSH connection between your machine and the EC2 host can occasionally drop silently. That's a network-level timeout, not a rodeo-cli bug. If rodeo up seems to hang with no new output for well past its usual phase timing, check whether the process is still alive. If the connection died, SSH into the host directly and check rodeo status. Phases already completed are cached and won't re-run, so you can resume cleanly instead of starting over.

Watch progress (from a second terminal)

ssh -i ~/.rodeo/ssh/id_ed25519 ec2-user@<host-ip>
rodeo status                 # VM state + VIP reachability, no sudo needed
sudo tail -f /root/.rodeo/logs/aws-up.log

rodeo ssh <vm> needs sudo on AWS

sudo rodeo ssh harvester1

rodeo status and other read-only commands don't need sudo.

harvester_auto_import stays false

Same as bare-metal: rodeo-plan.yaml sets harvester_auto_import: false on purpose. Importing Harvester into Rancher is Exercise 1.

Verify before students start

ssh -i ~/.rodeo/ssh/id_ed25519 ec2-user@<host-ip>

# All 3 Harvester nodes Ready
export KUBECONFIG=~/.rodeo/harvester-kubeconfig
kubectl get nodes

# Exercise 4/6 pre-lab state (custom_scripts)
kubectl get vm -n prod webserver-prod daily-batch-processor
sudo systemctl is-active rodeo-image-cache.service
sudo exportfs -v

External UI access (from your own machine, outside AWS):

curl -sk https://<host-ip>:8443/v1 | jq -r '.apiVersion'
curl -sk https://<host-ip>:30002/v3 | jq -r '.type'

See the pre-lab checklist for the full gate. It's written with bare-metal in mind, but the verification steps apply here too.

Hand students

Item	Value
Harvester UI	https://<host-ip>:8443
Rancher UI	https://<host-ip>:30002
Username	admin
Passwords	harvester_admin_password and rancher_admin_password, via ssh ec2-user@<host-ip> "cat ~/.rodeo/secrets.yaml"
Lab guide	https://avaleror.github.io/suse-virt-workshop/

Both UIs use self-signed certificates. Students need to accept the browser warning.

If students need to SSH into the host themselves, share the private key file (~/.rodeo/ssh/id_ed25519 on your machine) securely. Or set up per-student IAM/key access for a real multi-attendee workshop. This single-host setup assumes one instructor/student pair per instance.

Tear down

cd suse-virt-workshop/aws
rodeo destroy --cloud --yes

Terminates the EC2 instance and deletes the security group rodeo created. Nothing else in your AWS account gets touched. Verify no billable resources remain:

aws ec2 describe-instances --region <region> \
  --filters "Name=tag:ManagedBy,Values=rodeo" "Name=instance-state-name,Values=pending,running,stopping,stopped" \
  --query 'Reservations[].Instances[].[InstanceId,State.Name]' --output text

An empty result means clean.

Cost safety

For a workshop you might forget to tear down, arm a self-terminate timer as a backstop:

aws ec2 modify-instance-attribute --region <region> --instance-id <id> \
  --instance-initiated-shutdown-behavior terminate
ssh -i ~/.rodeo/ssh/id_ed25519 ec2-user@<host-ip> "sudo shutdown -h +180"   # 3 hours

Verify with sudo shutdown -c to cancel, or check who -b/last style timing if you're not sure it's armed.

Further reading

• Deploy on a bare-metal host instead
• Lab overview
• rodeo-cli's virt-workshop-aws profile. This workshop's AWS deploy re-seeds from this bundled profile on the remote host. See its README for live-verification details.