Introduction
A virtual machine (VM) is a software-emulated computer that runs on top of a physical host, sharing that host's CPU, memory, storage, and network with other VMs via a hypervisor. Cloud providers such as AWS (EC2), Azure (Virtual Machines), and Google Cloud (Compute Engine) let you rent VMs by the second or hour instead of buying physical servers, giving you an operating system, root/administrator access, and configurable hardware resources on demand.
Cricket analogy: Renting a VM is like a touring team hiring a fully-equipped practice facility by the day rather than building its own stadium — AWS, Azure, and Google Cloud let you rent computing power the way a venue lets you book nets and a bowling machine on demand, with full control over how you use the session.
Explanation
Every cloud VM is launched from an 'instance type' — a predefined bundle of virtual CPU (vCPU) count, memory, network bandwidth, and sometimes local disk or GPU. Instance type families are typically optimized for a workload shape: general-purpose (balanced CPU/memory), compute-optimized (high CPU-to-memory ratio for batch processing or gaming servers), memory-optimized (large RAM for in-memory databases or caches), and storage-optimized (high-throughput local disks for data warehousing). Choosing the right size is a tradeoff: an oversized instance wastes money on idle capacity, while an undersized instance causes CPU throttling, memory pressure, or slow response times under load. Right-sizing usually starts with a smaller instance and scales up only after monitoring shows real utilization.
Cricket analogy: An instance type is like a squad role: an all-rounder is general-purpose, a strike bowler is compute-optimized for short intense spells, a stonewalling opener is memory-optimized for long innings, and a keeper handling constant deliveries is storage-optimized; picking the wrong role wastes resources or leaves you exposed under pressure, so teams usually start conservative and upgrade after seeing real match data.
Beyond sizing, cloud providers offer several pricing models for the same underlying hardware. On-demand pricing charges a fixed per-second or per-hour rate with no upfront commitment — you pay full price but can start and stop whenever you like, which suits unpredictable or short-lived workloads. Reserved (or committed-use) pricing requires you to commit to running an instance type in a region for a fixed term, typically 1 or 3 years, in exchange for a significant discount (often 30-70% off on-demand) because the provider can plan capacity around your commitment. Spot (or preemptible) pricing sells a provider's unused capacity at a steep discount (often 60-90% off on-demand), but the instance can be reclaimed by the provider with little notice (seconds to minutes) whenever that capacity is needed elsewhere, so spot instances are only appropriate for fault-tolerant or interruptible workloads.
Cricket analogy: On-demand pricing is like paying full price to book nets whenever you want with no commitment; reserved pricing is like signing a 3-year facility contract at a steep discount because the venue can plan around it; spot pricing is like grabbing unused practice slots at a huge discount, knowing the venue can bump you with little notice if a paying team needs the space.
Example
# Example: launching an on-demand EC2 instance with the AWS CLI
aws ec2 run-instances \
--image-id ami-0abcdef1234567890 \
--instance-type t3.medium \
--key-name my-key-pair \
--count 1 \
--tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=web-server}]'
# Example: requesting a spot instance instead, capped at a max price
aws ec2 run-instances \
--image-id ami-0abcdef1234567890 \
--instance-type t3.medium \
--instance-market-options '{"MarketType":"spot","SpotOptions":{"MaxPrice":"0.015"}}'Analysis
A common real-world pattern mixes pricing models: a baseline of reserved instances covers predictable steady-state traffic at a low fixed cost, on-demand instances absorb short-term spikes above that baseline, and spot instances handle large, interruptible batch jobs (such as video transcoding or CI test runs) at minimal cost. Picking the wrong model is a frequent source of cloud bill surprises — running a long-lived production database on spot instances risks unexpected termination, while running a rarely-used dev/test environment on a 3-year reservation locks in cost you may not need.
Cricket analogy: A well-run academy covers its core training schedule with a fixed 3-year facility contract, absorbs extra sessions before a big tour with pay-as-you-go bookings, and handles bulk fitness camps on discounted off-peak slots — but scheduling the national team's must-happen final prep on a bumpable off-peak slot risks disaster, just as locking a rarely-used facility into a 3-year deal wastes money.
Key Takeaways
- A VM is an emulated computer running on a shared physical host via a hypervisor; instance types bundle vCPU, memory, and network capacity for different workload shapes.
- On-demand pricing offers flexibility with no discount; reserved pricing offers a large discount in exchange for a 1-3 year commitment; spot pricing offers the deepest discount but can be reclaimed with little notice.
- Right-sizing means matching instance type to real, monitored utilization rather than guessing — oversizing wastes money and undersizing causes performance problems.
- Production, always-on workloads typically use reserved or on-demand instances; interruptible batch workloads are ideal candidates for spot instances.
Practice what you learned
1. What primarily distinguishes a spot instance from an on-demand instance?
2. Which pricing model requires a 1- or 3-year commitment in exchange for a lower rate?
3. A workload needs guaranteed availability and unpredictable start/stop timing with no long-term commitment. Which pricing model fits best?
4. Why might an oversized VM instance type be a problem even though it never runs out of resources?
Was this page helpful?
You May Also Like
Cloud Service Models (IaaS, PaaS, SaaS)
How IaaS, PaaS, and SaaS differ in what the provider manages versus what the customer manages.
Cost Optimization Basics
Learn concrete cloud cost-optimization levers such as right-sizing, reserved and spot instances, storage tiering, and auto-scaling.
Auto-Scaling Basics
Learn the difference between horizontal and vertical auto-scaling and how scaling policies use metrics like CPU utilization to trigger scaling actions.
Cloud Regions and Availability Zones
Understand how cloud providers organize infrastructure into regions and independently-failing availability zones for fault tolerance.