Compute: instance families, zones, lifecycle and instance pools
The Compute domain checks that you can size and place Elastic Compute instances in Exoscale's zone model, automate their first boot, and scale them without breaking stateful assumptions.
Zones come first
Every instance lives in exactly one zone (for example CH-GVA-2, CH-DK-2, DE-FRA-1, DE-MUC-1 or AT-VIE-1). Zones are independent failure domains: templates, private networks, block storage, Elastic IPs and DBaaS services are all zone-scoped. Not every instance type is offered in every zone, so validate availability before you design around a GPU or memory-heavy SKU.
Instance families
Types are grouped into families - Standard (balanced CPU/RAM), CPU-optimized, Memory-optimized, GPU and Storage-optimized - with sizes expressed as vCPU/RAM pairs plus local disk. Choose by bottleneck: a JVM heap wants Memory-optimized; a build farm wants CPU-optimized; a model server wants GPU. Templates are versioned OS images; you can also save a custom template from an instance, and cloud-init user-data handles first-boot configuration such as packages, users and SSH keys.
Lifecycle and scaling
Instances start, stop, reboot and can be snapshotted through their block volumes. Stopping an instance does not delete its disk, and an automatically assigned public IPv4 can change across stop/start, so bind an Elastic IP to anything that must keep a stable address. Instance Pools wrap a template, a size and a zone into a managed autoscaling group with min/max members, health checks and anti-affinity, which spreads members across hosts.
Worked example
A stateless API must survive the loss of a host and absorb traffic spikes. Reasoning: stateless means members are disposable, so a pool fits; anti-affinity protects against a single-host failure; the pool spans one zone because instances cannot span zones - for zone-level resilience run a second pool in another zone and steer with DNS. Put the Elastic IP on the load balancer, not on a member, so scaling never changes the address clients use. Set min=2 so anti-affinity always has something to spread.
Traps
Designing a multi-zone cluster as one pool; assuming a stopped instance stops billing (disk and addresses persist); rebuilding an instance and expecting the same private address; picking a GPU SKU without confirming the zone stocks it; and baking secrets into cloud-init user-data, which is readable from inside the instance.