Skip to content

Server Groups

Explanation · Updated Jun 2026

Coming from another cloud?

▸AWS·Placement Groups

Placement Groupshigh

  • Policies: cluster/partition/spread vs affinity/anti-affinity.
  • AZ-scoped, no instance moves/merges.
  • Specified at launch via PlacementGroupName.
  • Max 7 partitions per AZ for partition type.
AWS docs ↗
▸Azure·Availability sets

Availability setshigh

  • Uses fault/update domains (max 3/20) for HA, fixed at creation, vs flexible OpenStack server group policies (affinity/anti-affinity).
  • ARM resource (Microsoft.Compute/availabilitySets), VMs assigned at create, no dynamic move.
  • No extra cost, but requires 2+ VMs for SLA; prefers zones/scale sets.
  • Lower latency between VMs in set vs zones, hardware-specific isolation.
Azure docs ↗
▸DigitalOcean·Tags (for grouping Droplets)

Tags (for grouping Droplets)medium

  • DigitalOcean uses tags as a grouping/selection mechanism (filtering, bulk actions, auto-inclusion in firewall/LB configs) rather than OpenStack Nova server groups that implement affinity/anti-affinity placement policies.
  • No documented user-facing placement policy (affinity/anti-affinity) is exposed via tags; tags are for organization and targeting actions, unlike OpenStack server groups which influence scheduling decisions.
  • DigitalOcean’s tags API requires canonical capitalization in the URL (e.g., /v2/tags/PROD/resources), which is a platform-specific behavior not typically present in OpenStack resource tagging.
  • Bulk actions on Droplets can be initiated across resources sharing a tag via DigitalOcean API endpoints, whereas OpenStack server groups are separate resources with policies and memberships managed via Nova.
DigitalOcean docs ↗
▸Google Cloud·Sole-Tenant Nodes / Instance Groups

Sole-Tenant Nodes / Instance Groupshigh

  • MIGs offer autoscaling, autohealing, rolling updates via templates; OpenStack only scheduling policies (affinity etc.).
  • Zonal/regional with HA/load balancing integration; no management in OpenStack groups.
  • App health checks trigger recreation; requires external orchestration in OpenStack.
Google Cloud docs ↗
▸Hetzner·Placement Groups

Placement Groupshigh

  • Only 'spread' type (anti-affinity: servers on different physical hosts); no 'affinity' or policy-based like OpenStack.
  • Max 10 servers/group (spread), 50 groups/project, 1 group/server.
  • Free; add servers via API action (must be off for existing).
  • No rack/host-level control; protects against single host failure only.
Hetzner docs ↗

Server groups

Server groups apply placement policies (affinity or anti-affinity) that control whether your instances land on the same physical host or are spread across different hosts. The Compute service (OpenStack Nova) scheduler honors these policies when you create a server group and assign instances to it at launch time.

What placement policies do#

Affinity policyAnti-affinity policyHost AHost XHost YHost Zinstance 1instance 2instance 3instance 1instance 2instance 3 alternative policy
Click to zoom
Affinity packs instances onto one host; anti-affinity spreads them across hosts for fault isolation

An affinity policy tells the scheduler to place instances in the group on the same compute host. This minimizes network latency between them and can improve cache effectiveness for tightly coupled workloads.

An anti-affinity policy does the opposite: instances are distributed across different physical hosts so that a single host failure does not take down the entire group. This is the foundation of most high-availability designs.

Soft variants of both policies allow the scheduler to make a best-effort attempt. If the preferred placement is impossible because hosts are full or constraints conflict, the scheduler falls back to the best available option instead of failing the request.

When to use server groups#

Use anti-affinity for distributed databases, replicated caches, or any tier where you need fault isolation. If one host goes down, the surviving instances on other hosts keep the service running.

Use affinity when latency between instances matters more than fault tolerance, for example a compute job that exchanges large amounts of data between workers on a shared-memory bus.

Lifecycle#

Create a server group and specify a single policy. When you launch instances, include the server group in the request so the scheduler respects the policy during placement.

Once created, the policy is immutable. You cannot change a server group's policy after the fact. To apply a different policy, create a new group and launch new instances into it. You can list, inspect, and delete server groups through the Console, CLI, or API.

Further reading#

On this platform:

External resources:

Before this

Related content

Was this page helpful?