Overview
An instance is just a virtual machine on Atlas infrastructure. KVM does the virtualization and CloudStack orchestrates it, but none of that matters much in practice. What you get is a machine you can make bigger or smaller depending on what it has to do, whether that’s a small web server ticking along or a box chewing through a large dataset.
Key Features
Sizing is the choice you’ll make most often, and it comes down to a compute offering from the Atlas.aN range. On Linux the smallest is Atlas.a4 at 1 vCPU, 4 GiB of memory, and a 20 GiB disk; the largest, Atlas.a8, jumps to 16 vCPU, 64 GiB, and 320 GiB. If you need Windows, the Atlas.a6w, Atlas.a7w, and Atlas.a8w offerings cover it, with a licensing surcharge on top for the Windows license itself. Rather than memorize the table, check the pricing page, which always lists the complete catalog and rates.
A couple of things hold true no matter which size you pick. The Root Volume sticks around across reboots, so you won’t lose the OS when the machine restarts. The instance also sits inside an isolated Guest Networks or VPC, which keeps its traffic walled off from other tenants. And you log in with an SSH key, injected when the VM boots, instead of a password you’d have to manage.
Managing Instances
Launching an Instance
It’s one form. Open Compute > Instances and click Add Instance. Zone is the easy field, since is1 is the only one Atlas runs. The two that matter are the Template, which sets the OS (Ubuntu 24.04 is a fine default), and the Compute Offering, which sets CPU and RAM. The rest are quick: leave the data disk alone unless you want extra storage from the start, attach a Guest Network or VPC Tier so the VM has somewhere to talk, and select an SSH key you’ve already uploaded (the SSH Key Pairs guide handles that) so you can get in once it boots.
Lifecycle Actions
A running instance has a handful of actions in the console. Stop shuts the OS down and pauses compute metering, though storage keeps being metered while the VM sits there. Reboot is the usual OS restart, the same as running reboot inside it. Destroy deletes the instance and its root volume for good, so treat it as final. And if SSH ever stops cooperating, View Console opens a VNC session straight to the machine for emergency access.
Connecting
Reach the instance over its public IP if one is mapped through NAT, or over the internal IP from a VPN or private network:
ssh root@<PUBLIC_IP>The login name comes from the template, not you, root, ubuntu, or rocky depending on the image, so try the distro default if root bounces.
Advanced Configuration
Beyond launching and connecting, a few features come up once you start running real workloads.
The first is User Data. Hand an instance a cloud-init script when it launches and it’ll configure itself on first boot, installing packages, writing config files, creating users, whatever you script. That’s how you go from a bare template to a ready service without ever logging in by hand, and it’s the same mechanism the Terraform tutorials lean on. The User Data Library collects scripts you can start from. The payoff is repeatability: rebuild the instance and you get the identical setup every time, which matters far more than it sounds the first time you have to recreate a box from memory at an awkward hour.
Traffic control works differently depending on the network type, which catches people out. In a VPC you reach for Network ACLs, stateless rules that apply at the subnet level. Isolated guest networks don’t use ACLs; they use firewall rules for inbound and egress rules for outbound (see Public IP Addresses and Guest Networks). The catch worth repeating: an isolated guest network blocks everything outbound until you add egress rules, so a VM that can’t apt update or resolve DNS is almost always missing them.
Finally, Instance Snapshots capture a volume at a moment in time. Take one before a risky change and you have a clean restore point to roll back to.
A note on cost while you’re managing instances: stopping a VM pauses the compute charge, but the storage behind it keeps billing because the disk still exists whether the machine is on or off. So a stopped instance costs less than a running one, though its storage still bills. If you’re truly done with a VM and its data, destroying it is what stops the storage charge, just remember that destroy takes the root volume with it and there’s no undo. When in doubt, snapshot first, then destroy. The short version: stop a VM you’ll come back to, snapshot anything you might want again, and destroy what you’re genuinely finished with.