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.
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.
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.
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.
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.