Exoscale Certified Cloud Professional cheat sheet

Exoscale compute instances are KVM-based virtual machines; instance types are named by family (Standard, CPU, GPU, Memory, Storage) plus a size suffix where the number indicates vCPUs.

Instance families: Standard = balanced; CPU = high clock speed / compute-optimized; Memory = high RAM-to-vCPU ratio; Storage = large local disk; GPU = NVIDIA accelerators.

Instances can be started, stopped, rebooted, and destroyed via the Exoscale API, CLI (exo), or portal; stopping an instance preserves its disk, destroying it removes the instance and its local disk (attached block storage persists).

Instance templates (images) include Linux distributions and Windows Server; custom templates can be registered from qcow2 images up to the platform limit (typically 10 GiB compressed).

User data (cloud-init) can be supplied at instance creation; it is executed on first boot and is limited in size (typically 32 KiB base64-encoded).

Anti-affinity groups constrain instances to distinct physical hosts; instances in the same anti-affinity group cannot run on the same hypervisor.

Instance resize: changing the instance type may require a stop/start; local disk size cannot be shrunk, only grown.

Elastic IPs can be attached to instances to provide a static public address; the instance's default public IP is dynamic and changes on stop/start unless an Elastic IP is attached.

Instance metadata service is reachable at 169.254.169.254; it exposes instance ID, zone, and user data, and can be secured with a metadata token in newer configurations.

Block storage volumes are network-attached SSD-backed disks; they can be attached to one instance at a time and detached/re-attached to another instance in the same zone.

Block storage volume size can be increased online (grow only); shrinking is not supported. Snapshots are point-in-time copies of a volume and can be used to create new volumes.

Object storage (SOS) is S3-compatible and organized into buckets; buckets are globally unique per region and access is controlled by bucket policies and ACLs.

SOS objects are immutable; updates replace the whole object. Multipart upload is required for objects above the single-PUT limit (typically 5 GiB).

SOS supports pre-signed URLs for time-limited access without exposing credentials; pre-signed URL expiry is set at generation time.

SOS storage classes: standard vs. a lower-cost infrequent-access tier; lifecycle rules can transition or expire objects.

File-level storage is not a native Exoscale primitive; shared file access is typically achieved via an NFS server on a compute instance or an S3-compatible gateway.

Volume performance scales with volume size; larger volumes generally provide higher IOPS and throughput. Check the published IOPS/throughput table for the target size.

Snapshots and volumes are zone-scoped; cross-zone disaster recovery requires copying snapshots or objects to another zone/region.

Exoscale DBaaS offers managed PostgreSQL, MySQL, Kafka, Valkey (Redis-compatible), OpenSearch, and Grafana; each service is provisioned per zone.

DBaaS plans are defined by node count, CPU, RAM, and storage; HA plans run multiple nodes across availability zones within a zone group where supported.

Connection is via a service URI containing host, port, database, and credentials; TLS is enforced and the CA certificate must be downloaded from the service.

Automated backups are taken daily; point-in-time recovery (PITR) is available for PostgreSQL and MySQL within the retention window (typically up to 30 days).

Maintenance windows can be configured; minor version upgrades may be applied automatically during the window.

DBaaS services are reachable over the public internet by default; restrict access with IP filters (allowlists) or place the service in a private network via Private Connect / private endpoints.

Scaling: vertical scaling changes the plan (may trigger a restart); horizontal scaling adds read replicas for supported engines.

Service users and databases are managed via the API/CLI; the admin user is created at provisioning and its password is shown once.

Kafka and OpenSearch have engine-specific plan limits (partitions, shards, node counts); verify the plan matrix before sizing.

Exoscale zones are independent data centers (e.g., CH-GVA-2, DE-FRA-1, AT-VIE-1); private networks are zone-scoped and cannot span zones.

Private networks are isolated L2 segments; instances attached to the same private network can communicate without public IPs.

Security groups are stateful firewalls applied at the instance's virtual NIC; default deny inbound, allow all outbound. Rules reference CIDR or other security groups.

Elastic IPs are static public IPv4 addresses that can be moved between instances in the same zone; they are billed while reserved.

Load balancers operate at L4 (TCP) and L7 (HTTP/HTTPS); they require a private network and a service (target port) plus a health check.

DNS: Exoscale provides a managed DNS service with zones, records, and DNSSEC support; records are managed via API/CLI.

Private Connect (formerly Private Peering) links a private network to an external network (e.g., on-premises or another cloud) via a dedicated interconnect.

IPv6 is available on instances and can be enabled per instance; dual-stack is supported in most zones.

Network usage: internal traffic within a zone is free; egress to the internet is billed per GiB; ingress is free.

IAM uses API keys (key + secret) scoped to an account; keys can be restricted to specific operations and resources via IAM policies.

IAM roles can be assumed by compute instances via instance metadata, avoiding long-lived keys on disk.

Security groups are stateful; return traffic is automatically allowed. Rules are evaluated as a union (allow-only model).

Secrets: never embed API secrets in user data or templates; use IAM roles or a secrets manager.

Encryption at rest: block storage and SOS are encrypted at rest by the platform; customer-managed keys are not exposed as a primitive for all services, so verify per service.

TLS: DBaaS enforces TLS; load balancers support TLS termination with uploaded certificates; SOS supports HTTPS endpoints.

Audit: API activity can be reviewed via the audit log / event history; enable it and forward to a SIEM for retention.

Anti-affinity groups and private networks reduce lateral exposure; combine with security groups for defense in depth.

Password and key rotation: rotate API keys and DB credentials regularly; Exoscale does not auto-rotate customer API keys.

Concrete AI is Exoscale's managed GPU/AI offering; GPU instances are available in selected zones (e.g., CH-GVA-2, DE-FRA-1) and are billed per minute/hour.

GPU instance types expose NVIDIA GPUs (e.g., A100, H100 class depending on zone); GPU drivers and CUDA are pre-installed on the GPU templates.

GPU instances support block storage and private networks like standard instances; they can join anti-affinity groups.

For distributed training, place GPU instances in the same private network and use high-bandwidth instance types; check the zone's GPU availability before planning.

AI workloads often need object storage (SOS) for datasets and model artifacts; use pre-signed URLs or IAM roles for access.

GPU instances are not covered by the same SLA as standard compute unless stated; verify the SLA document for the specific instance family.

Cost control: stop GPU instances when idle (billing stops for compute, disk still billed); use snapshots to preserve state.

Concrete AI may include managed inference endpoints; confirm current availability in the zone and the pricing model before designing around it.

Exoscale publishes a trust center with certifications, subprocessors, and security documentation; the trust center is the authoritative source for compliance evidence.

Shared responsibility: Exoscale secures the physical infrastructure, hypervisor, and managed service control planes; customers secure guest OS, applications, identities, and data.

Exoscale is a Swiss company; data processing agreements (DPA) and standard contractual clauses are available for GDPR transfers.

Subprocessors are listed publicly; customers are notified of changes per the DPA.

Penetration test summaries and SOC reports are available under NDA via the trust center.

Vulnerability disclosure: Exoscale publishes a security contact and a responsible disclosure policy.

Data deletion: on account termination, customer data is deleted per the DPA retention schedule; backups expire per the retention window.

Incident response: Exoscale publishes status and incident post-mortems; subscribe to status notifications for operational awareness.

Zones map to countries: CH-GVA-2 (Switzerland), DE-FRA-1 (Germany), AT-VIE-1 (Austria), and others; choosing a zone determines the physical data location.

Data residency is achieved by provisioning all resources (compute, storage, DBaaS, backups) in zones within the required jurisdiction; cross-zone replication must be disabled or restricted.

Exoscale is ISO/IEC 27001, ISO/IEC 27017, ISO/IEC 27018, and SOC 2 Type II certified; verify current scope on the trust center.

GDPR: Exoscale acts as a processor; a DPA is required. Swiss FADP applies to Swiss zones.

Backups and snapshots are stored in the same zone by default; cross-zone copy is a customer action and must be evaluated for residency impact.

Managed services (DBaaS, SOS) store data in the zone of provisioning; confirm the service's replication behavior before assuming single-country residency.

Audit logs and metadata may be processed outside the zone for platform operations; review the DPA and subprocessor list for details.

For regulated workloads, combine zone selection with customer-managed encryption, private networking, and IAM least privilege.