5.2 VMs vs Hosts, Cloud vs Virtual Hosting, SaaS and IaaS

Virtual machines sit at the center of modern SOC work even when the ticket never uses the word hypervisor. An alert may name an EC2-style instance, a laptop running a local lab VM, or a Microsoft 365 mailbox that was never a VM at all. If you cannot tell a guest from a host, or Infrastructure as a Service (IaaS) from Software as a Service (SaaS), you will assign the patch to the wrong owner and look in the wrong logs. This independent study section covers virtualisation and cloud basics that appear in SAL1 training content, including service models with real-world examples.

Physical hosts versus virtual machines

A physical host is the real computer: CPU, RAM, storage, and network interfaces you could touch. It runs firmware and, unless it is a dedicated hypervisor appliance, a host operating system.

A virtual machine (VM) is a guest: software that presents virtual CPU, memory, disk, and a virtual NIC (network interface card) to a guest operating system. The guest believes it has hardware. The hypervisor schedules real hardware underneath and keeps guests isolated enough to share one box.

Consequences for analysts:

• A process inside the VM is not visible on the physical host unless you have hypervisor-level or agent-level telemetry in that guest.
• A compromised guest can still share a physical NIC, so network sensors outside the VM may see its traffic.
• Snapshots and templates mean the same golden-image weakness can appear on many guests at once.
• Time drift, cloned machine identifiers, and duplicated hostnames show up in investigations when VMs are copied carelessly.

The host and guest vocabulary matters in tickets. Patch the host might mean the hypervisor box, the laptop under a Type 2 product, or the guest OS. Write the layer you mean.

Hypervisors: Type 1 and Type 2

A Type 1 hypervisor (bare metal) runs directly on physical hardware. Datacenter products in this category include VMware ESXi, Microsoft Hyper-V in a server role, and Xen-based designs. There is no general-purpose desktop OS underneath the hypervisor as a required parent. Type 1 is what most on-prem server virtualisation and many cloud control planes resemble conceptually.

A Type 2 hypervisor runs as an application on a conventional host OS such as Windows, macOS, or Linux. Desktop lab tools such as VirtualBox and VMware Workstation are the usual examples. The host OS still owns devices; the hypervisor is a program. If malware owns the host OS, it can attack the hypervisor and every guest.

You do not need to memorize every vendor SKU for SAL1-style questions. You do need the layering: Type 1 sits on hardware; Type 2 sits on a host OS; guests sit on the hypervisor.

Cloud versus on-prem virtual hosting

On-premises virtual hosting means your organization, or a colocation site you control, owns or leases the physical servers and runs a hypervisor there. You still get VMs, snapshots, and virtual switches, but capacity planning, hardware failure, and hypervisor patching are yours or your datacenter vendor's. Access is typically over VPN or private circuits, not a public cloud API as the primary control plane.

Cloud computing means a provider pools hardware, exposes services through APIs and consoles, and bills for consumption. You pick a region, deploy in minutes, and share physical tenancy with other customers at the provider's layer; logical isolation is the provider's job. Key public providers analysts will see named in logs and documentation include Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP). Naming them does not imply any exam-sponsor partnership; they are simply the platforms that dominate enterprise telemetry.

Differences that change investigations:

Virtual hosting in this module is about virtualisation location and control, not the older web-hosting phrase that many websites share one HTTP server. If a question mentions websites sharing one Apache instance, that is a different idea.

SaaS, PaaS, and IaaS with real examples

Cloud service models describe how much of the stack you operate.

IaaS (Infrastructure as a Service) sells virtual machines, virtual networks, and virtual disks. An EC2-style VM — AWS Elastic Compute Cloud and equivalents such as Azure Virtual Machines or Google Compute Engine — is IaaS. You choose the image, log in with SSH (Secure Shell) or RDP (Remote Desktop Protocol), install software, and you patch the guest operating system. The provider patches the hypervisor and the physical plant.

PaaS (Platform as a Service) sells a managed runtime or data service. A managed database such as Amazon RDS, Azure SQL Database, or Cloud SQL is PaaS: you do not RDP into the database OS to apply engine patches; the provider does. You still configure firewall rules, accounts, and query-level security. Analysts should not open a patch Windows ticket against a managed database host they cannot log into.

SaaS (Software as a Service) sells the full application. Microsoft 365 and Gmail are the examples to keep. You do not patch Gmail's servers. You manage identities, sharing, mailbox rules, OAuth (Open Authorization) apps, and data classification. Compromise looks like inbox rules, token theft, and tenant misconfiguration, not a missing Windows KB on a mailbox server you own.

Shared responsibility at analyst level: who patches the OS?

Shared responsibility is the phrase cloud providers use for the split. For an entry-level analyst, translate it into one operational question: who is supposed to patch this operating system?

• IaaS guest VM: the customer team that owns the instance, or the image pipeline, patches Windows or Linux. An unpatched SMBv1 finding belongs here.
• PaaS managed database: the provider patches the OS and usually the engine; the customer patches nothing at the OS layer. A mis-set public IP or weak database user is still the customer's problem.
• SaaS mailbox: there is no customer OS to patch. Multi-factor authentication (MFA) gaps and over-privileged OAuth apps are the customer problem.

If a playbook says isolate the host, confirm whether that host is a laptop, an IaaS VM, a hypervisor, or a SaaS tenant. Isolating a Microsoft 365 user is an identity action, not a hypervisor snapshot.

In practice: three alerts, three owners

1. Endpoint detection reports vulnerable OpenSSH on instance i-0a1b2c3d in AWS. This is IaaS. Check the guest, patch or replace the image, and review security groups.
2. A managed PostgreSQL instance accepts 0.0.0.0/0 on the data port. This is PaaS. You will not install a Windows patch; you will tighten the service firewall and credentials.
3. Impossible-travel sign-in on a Microsoft 365 mailbox. This is SaaS. Hunt refresh tokens and inbox rules; do not ask facilities to patch a Gmail OS.

Keep provider names factual and generic. AWS, Azure, and GCP appear in real SOC queues worldwide. Do not invent a special SAL1 relationship with any of them.

A final trap: lifting an on-prem VM into the cloud does not automatically make it SaaS. If you still RDP into Windows and install patches, you brought IaaS with you. If users only open a browser to a vendor app, you are in SaaS. Classify the stack you actually operate, not the billing brand on the invoice.