A cloud instance is one virtual computer carved out of a big physical server by a hypervisor. You rent it by the hour and pick its size by vCPU and memory. The two things that quietly catch freshers: the cheap free-tier sizes are burstable, so they slow to a crawl once their CPU credits run out, and stopping an instance stops the compute bill but the disk attached to it keeps charging. Learn the lifecycle (launch, stop, terminate) and those two facts before you do anything else.
Freshers and new IT hires who have heard the words EC2, instance, and VM in a standup and nodded along. By the end you will be able to launch one on a free tier, connect to it, read its size, and explain what you are paying for, using AWS, Azure, and Google Cloud examples.
Picture a large office building full of identical desks. You do not buy the building. You rent one desk for as long as you need it, and when you leave, someone else sits there. You get a key, a drawer, and a power socket. The building owner handles the roof, the wiring, and the cleaning. A cloud instance is that desk. The data center is the building, the physical server is one floor packed with desks, and your virtual machine is the single desk you rented this afternoon. You get your own slice. You do not get the floor.
That picture matters because almost everything confusing about cloud compute comes from forgetting it is a shared building. Why is the small free machine sometimes fast and sometimes slow? Shared building. Why does the bill keep ticking after you switched the machine off? You still rent the drawer even when you are not at the desk. Hold the analogy and the rest follows.
What an instance actually is
A virtual machine, or VM, is a complete computer made of software. It has a processor, memory, a disk, and a network card, except none of those are dedicated lumps of metal. They are slices of one big physical server, handed out by a thin layer of software called a hypervisor. The hypervisor is the floor manager. It sits between the real hardware and all the rented desks, and it makes sure each VM thinks it has its own private computer while really they are all sharing the same boxes.
An instance is just the word the cloud providers use for one running VM. On AWS the service is EC2 and a running VM is an instance. On Google Cloud the service is Compute Engine and the running VM is an instance. On Azure it is simply called a virtual machine. Same idea, three names. When a job ad says you should know EC2, it means you should be comfortable creating, connecting to, and tearing down these rented computers.
vCPU and memory: what you are really renting
When a provider says an instance has 2 vCPU, that v matters. A vCPU is not a physical processor core sitting in a box with your name on it. It is a scheduled time-share on a core, usually one hardware thread, handed to you by the hypervisor. On most clouds one vCPU maps to one thread of a physical core, so a 4 vCPU machine is roughly 2 real cores with hyper-threading. Providers also pack more vCPUs across all the VMs than there are physical threads, betting that not everyone runs flat out at once. That bet is invisible when it works and very visible when it does not.
Memory is more honest. When an instance lists 1 GB or 8 GB of RAM, that amount is reserved for you. The two numbers, vCPU and memory, are the first thing you choose for any instance, and most fresher mistakes come from picking on price alone without checking what those two numbers mean for the work the machine has to do.
Families, sizes, and the free machines
Each provider sells instances in families. A family is a design point: general purpose, compute heavy, memory heavy, GPU. Inside a family you pick a size, and sizes step up roughly by doubling. On AWS a name like t3.micro reads as family t3, size micro. On Azure you see names like B1s and B2pts v2. On Google Cloud you see e2-micro and e2-medium. You do not need to memorize the catalogs. You need to know that the small, cheap, free-tier sizes nearly always belong to a burstable family, and burstable behaves differently from what a beginner expects.
Here is what the three providers hand a brand-new account for free compute, as of 2026. Confirm the current page before you rely on any line, because these offers change and the AWS one changed in mid-2025.
| Provider | Free compute | Size | Catch to watch |
|---|---|---|---|
| AWS EC2 | 750 hours/month of t2.micro or t3.micro for 12 months on older accounts; newer accounts get a Free Plan with up to 200 dollars in credits instead | 2 vCPU, 1 GiB | Burstable; storage billed separately |
| Azure VM | 750 hours/month of a B1s, B2pts v2, or B2ats v2 for 12 months | 1 to 2 vCPU, 0.5 to 1 GiB | Burstable; disk billed separately |
| Google Compute Engine | 1 e2-micro per month, always free, in us-west1, us-central1, or us-east1 | 2 vCPU, 1 GB | Region locked; 30 GB disk and 1 GB egress included |
Burstable: the trap nobody warns freshers about
Every free-tier size in that table is burstable, and this is the single most important thing in this whole post. A burstable instance does not give you its full vCPUs all the time. It gives you a low baseline plus a wallet of CPU credits. When the machine is mostly idle it banks credits. When you push it hard it spends credits to run fast. Run hard for long enough and the credits hit zero, at which point the provider throttles you down to the baseline and your fast little machine becomes a slow little machine until the credits refill.
Concrete numbers make it real. An AWS t3.micro earns 12 CPU credits an hour and can bank at most 288. Its baseline is about 10 percent of a vCPU. So if you start with a full balance and then peg the CPU at 100 percent, you get a couple of hours of full speed before the balance empties, and then performance drops to that baseline, which on a 2 vCPU machine works out to roughly a fifth of one vCPU. Azure B-series and Google e2 burstable types follow the same shape with their own numbers. This is why a fresher building a project will swear the cloud machine was quick yesterday and is unusable today. Nothing broke. The credits ran out.
Do not benchmark or load-test on a burstable free-tier instance and trust the result. You are measuring your credit balance, not the machine. If you need steady performance for a test, use a non-burstable size for the hour it takes, then shut it down. For just learning and tinkering, burstable is fine, because tinkering is mostly idle time.
The lifecycle: launch, stop, terminate
An instance has a small set of states, and knowing them saves you both money and panic. You launch it from an image, which is a saved template of an operating system and software. It enters the running state and starts billing for compute. You can stop it, which is like switching the desk computer off but leaving your drawer locked: compute billing pauses, the machine keeps its disk and its data, and you can start it again later. Or you can terminate it, which throws the desk away. The instance is gone, and unless you arranged otherwise its disk goes with it.
Here is the part that costs people real money. Stopping an instance stops the compute charge, but the disk attached to it keeps billing the whole time it is stopped, because the storage still physically exists, holding your operating system and files, ready for restart. On AWS that disk is EBS, on Azure it is a managed disk, on Google Cloud it is a persistent disk. Common advice tells freshers to just stop your instances to save money, and that advice is half right. I disagree with how confidently it is given. Stopping saves the larger compute charge, but if you walk away from a stopped machine for a month thinking it is free, the disk quietly bills the whole time. If you are truly done, terminate it, or take a snapshot and delete the disk. Off is not the same as gone.
On your first cloud team you will be handed instances other people launched, and one of your early tasks will be cleaning up. Knowing that a stopped machine still bills for its disk, and that terminate is what actually ends the cost, is exactly the kind of small, real knowledge that makes a senior trust you with the account. You will also be the person who does not accidentally terminate a machine someone needed, because you understood the difference before you clicked.
The two connection errors you will hit
The first time you try to SSH into a Linux instance, you will almost certainly hit one of two errors, and they mean completely different things. The first is a timeout: the terminal hangs and eventually says ssh: connect to host port 22: Connection timed out. That is a network problem. Your instance is fine, but its firewall, the security group, has no rule allowing inbound traffic on port 22 from your address. Open port 22 to your IP and the timeout clears.
The second is Permission denied (publickey). This one is the opposite kind of news. It means SSH reached the machine and the network is fine, but authentication failed. Nine times out of ten the username is wrong. People use the default username from a guide instead of the one their image expects: Amazon Linux wants ec2-user, an Ubuntu image wants ubuntu, and Google Cloud often uses your own account name. The other causes are the wrong key file or a key file with permissions so loose that SSH refuses to use it. Learn to read these two apart on sight. Timeout means look at the network. Permission denied means look at the username and key. That one habit will save you hours over your first year.
What a small VM actually costs
Numbers anchor all of this. Take an AWS t3.micro running outside the free tier, on-demand, in the Northern Virginia region, with a small disk. Here is the month broken down at the prices listed in mid-2026.
Compute: about 0.0104 dollars per hour, running 24/7 for roughly 730 hours a month, comes to about 7.59 dollars.
Disk: an 8 GB gp3 volume at 0.08 dollars per GB-month is 0.64 dollars.
Total running: about 8.23 dollars for the month.
Now you stop the instance for the whole month to save money. Compute drops to zero, but the 8 GB disk still costs that 0.64 dollars. Leave ten stopped machines like that and forgotten, and you are paying about 6.40 dollars a month for nothing but parked disks. That is how small idle bills creep up.
None of these numbers are huge on their own. The lesson is the shape, not the total: compute is the big lever you control by turning machines off, and storage is the smaller, stubborn lever that keeps charging until you delete it. A real cloud bill is dozens of these little lines, and your job early on is to know which lines stop when you stop a machine and which do not.
What is the difference between a vCPU and a physical CPU core?
A clean answer: a physical core is real hardware on the chip, while a vCPU is a virtual processor the hypervisor presents to your VM, usually mapped to a single hardware thread of a core. Because providers oversubscribe, more vCPUs can be promised across all the VMs on a host than there are real threads, so a vCPU is a scheduled share of a core rather than a dedicated one. Say that, then add the practical note that this is why two machines with the same vCPU count can perform differently, and you sound like someone who has actually used the cloud, not just read about it.
On any free tier, launch one small instance: an e2-micro in a Google Cloud free region, or a t3.micro on an AWS account that still has the 12-month tier, or a B1s on Azure. Connect to it over SSH. Once you are in, run two commands: nproc to print the number of vCPUs, and free -h to print the memory. You should see 2 and roughly 1 GB on the micro sizes.
Now check the result the grown-up way. Stop the instance from the console, wait a minute, and open the billing or cost page. The compute line goes quiet, but you will see the disk still listed. That single screen is the whole stop-versus-terminate lesson made real. When you are done, terminate the instance so nothing lingers.
FAQ
Is a virtual machine the same as a server?
For most purposes, yes. A server is any computer that serves other computers, and a VM is a computer made of software. A cloud instance is a virtual server. The difference is that the VM shares physical hardware with other VMs and you rent it by the hour instead of owning the box.
How many vCPUs and how much memory do I need to start?
For learning, the free micro sizes with 2 vCPU and 1 GB are plenty. They run a small web app or a practice Linux box comfortably as long as you are not load-testing. Start small, watch the machine under real use, and size up only when you see it actually struggle.
Will I get charged if my instance is just sitting idle?
Yes. A running instance bills for every hour it exists, whether it is busy or doing nothing, because you are renting the slice either way. Idle is not free. Only stopping pauses the compute charge, and even then the disk keeps billing.
What is the difference between an instance and an image?
An image is a frozen template: an operating system plus preinstalled software, saved so you can stamp out copies. An instance is a live, running machine launched from that image. One image, many instances. AWS calls its images AMIs; Azure and Google Cloud just call them images.
Can I burn through the free tier without noticing?
Easily, in two ways. You can leave a second instance running past the 750 free hours, or you can rack up charges on things the free tier does not cover, like extra disks, public IP addresses, or data transfer. Set a billing alert on day one. It is the cheapest insurance in the cloud.
Where to go next
If you keep three things from this part, keep these: an instance is a rented slice of a shared machine, the cheap free sizes are burstable so they slow down once their credits run out, and stopping a machine still bills for its disk. Launch one micro instance this week, run nproc and free -h, then stop it and watch the billing page tell you the rest. The next part opens up the second building block, cloud storage, where the difference between object, block, and file storage decides where all that data on your instance actually lives.
References
Key concepts for burstable performance instances (AWS)
Why EBS still charges for a stopped instance (AWS re:Post)
Free services with an Azure free account (Microsoft)
Google Cloud free tier, including e2-micro (Google Cloud)
About The Author
DrJha