Provisioning your first VM, deliberately

Why this matters

Most teams click 'create droplet' and accept the defaults, then discover three months later they're on the wrong instance family, the wrong region, the wrong disk type, or running on a kernel they can't update. A few minutes spent at provisioning time — picking the region close to your users, the instance type matched to your workload (CPU-bound vs memory-bound vs network-bound), and a base image you understand — saves weeks of migration pain later. This isn't premature optimization; it's the difference between 'I'll redo the box on Saturday' and 'I have to migrate prod next quarter.'

Demo

Sizing rule of thumb for a CRUD API at Day 0: 1 vCPU, 2 GB RAM, 25 GB SSD, in the same region as your DB. You can serve a few hundred concurrent users on this — modern languages can push 1k+ req/sec on a single core if the DB keeps up. Pick the region by where your users (or your DB) are. Pick an instance family marked 'general purpose' (DigitalOcean: regular; AWS: t-class; GCP: e2-medium). Pick an SSD-backed disk, never spinning. And pin your base image (Ubuntu 24.04 LTS, Debian 12) — don't 'use the latest'.

Try it yourself

1. Look at your current/last VM: what region is it in, what's the instance family, what disk type, what kernel/OS version? Document it in a README. You should know this without checking.
2. Pick a region using a real signal: where your users actually are (check Google Analytics country breakdown) OR where your DB lives. Don't pick the cheapest region if your users are 200ms away.
3. Run curl -s http://ipinfo.io/json | jq from your VM. Confirm region and AS-number match what you provisioned.
4. Set up unattended-upgrades. Run cat /var/log/unattended-upgrades/unattended-upgrades.log after a week — you should see security patches applied automatically.

Prompt your AI

Use these three in order. Each builds on the one before.

1. Basics & terminology

What's the difference between 'general purpose', 'compute optimized', 'memory optimized', and 'burstable' instance families? When does each one matter for a web service?

2. Why it works (the mechanism)

Why does it matter whether my VM and my DB are in the same region (vs same provider, different region)? Walk me through what a `SELECT id FROM users WHERE id=42` looks like in network terms when they're cross-region.

3. Advanced — application & what's next

I have a Python API on a t3.small in us-east-1 talking to an RDS Postgres in us-west-2. p99 is 280ms. Break down where that latency is going and what I'd change to get it under 50ms. Quantify each step.

References

• AWS EC2 instance types — overview
• DigitalOcean droplet types