adminA virtual machine is a software-defined server running on cloud infrastructure.
It gives teams control over operating system, packages, runtime, firewall, storage mount, background services, and deployment process.
For a cloud architect, a VM is useful when the workload needs control, compatibility, persistent service behavior, or traditional system administration skills.
Cloud Architecture Brief
Many teams either overuse VMs because they are familiar or avoid them because newer tools look more modern.
Companies still use VMs for legacy applications, custom software, databases, jump hosts, monitoring nodes, build servers, and workloads requiring OS-level control.
A VM is a cloud compute unit that behaves like a server: it has CPU, memory, disk, network interface, operating system, and security configuration.
If you understand OS patching, image management, boot process, storage attachment, network interface, and access control, you can operate cloud VMs across providers and on-prem virtualization.
Architecture Decision
three_tier
web_application
public_cloud
A load balancer sends traffic to multiple VM instances in private subnets. Each VM runs the application service, ships logs to monitoring, uses IAM role for cloud access, and connects to managed database.
Use VMs when control and compatibility matter more than abstraction.
VMs are flexible and understandable, but they increase operational responsibility for patching, hardening, monitoring, scaling, and recovery.
Run production on one VM; expose SSH to the internet; install everything manually; store only database backups on the same server; skip image automation.
VMs offer control and compatibility but require more maintenance than serverless or fully managed platforms.
Cloud Building Blocks
VMs run full operating systems and can host web servers, workers, agents, cron jobs, custom runtimes, or legacy apps.
VMs should usually be placed in private subnets with access through load balancer, VPN, bastion, or identity-aware access.
Use block storage for OS and app data, object storage for backups and artifacts, and avoid storing critical data only on local ephemeral disks.
Applications on VMs should connect to managed databases or properly designed database clusters, not random local databases without backup.
Use OS hardening, firewall rules, IAM roles, SSH key control, patching, vulnerability scanning, and secret management.
Monitor uptime, CPU, memory, disk, process health, system logs, security logs, network traffic, and application logs.
Enterprise Readiness
Use multiple VMs across zones, load balancer health checks, golden images, backups, and recovery automation.
Scale VMs with autoscaling groups or managed instance groups when applications are stateless and image-based.
Disable password login, restrict SSH, patch packages, use least privilege cloud role, and log admin activity.
Right-size VM shape, schedule non-production shutdown, remove idle disks, use reserved capacity for stable workloads, and clean old snapshots.
Check load balancer target health, instance status, OS logs, disk usage, service status, firewall rules, and recent package or deployment changes.
Failure & Job Readiness
Full disk, failed boot, bad patch, exposed SSH, expired certificate, no backup, memory leak, and manual drift between servers.
Confirm backups; confirm patch status; confirm no public admin port; confirm disk alert; confirm image version; confirm service restart policy.
Roll back image, replace instance, restore disk snapshot, scale new VM, close public access, or rebuild from infrastructure code.
A company has a legacy billing application that cannot yet run in containers and must be migrated safely to cloud.
When is a VM still the right choice even when containers and serverless exist?
Create a VM-based architecture for a legacy app with private subnet, load balancer, managed database, backup, monitoring, patching, and rollback plan.
Compute Layer; OS Hardening; Load Balancer; Backup; Golden Image