This document explains the behavior, restrictions, and billing of placementpolicies.

By default, you manage the location of your Compute Engine instances onlyby specifying their zones. Placement policies let you further specify therelative placement of your instances in a zone. Based on the policy that youapply to your instances, you can reduce network latency across instances(compact policy) or improve resiliency against location-specific disruptions(spread policy).

To learn how to create and apply placement policies, see the documentation forusing compact placement policiesandusing spread placement policies.

To learn about other ways of controlling instance placement, see thedocumentation forsole-tenancy andregional managed instance groups (MIGs).

About placement policies

Each compute instance runs on a physical server—ahost—that is ona server rack. Each server rack is part of acluster that is located in adata center for a zone. When you have multiple instances in the same zone,Compute Engine places these instances in different hosts by default. Thisplacement minimizes the impact of potential power failures. However, when youapply a placement policy to instances in the same zone, you can further controlthe relative locations of those instances in the zone based on the needs ofyour workload.

You can create the following types of placement policies:

• Compact placement policy. This policy places instances close to eachother in a zone, which reduces network latency among the instances. Acompact placement policy is helpful when your instances need to communicateoften with each other—for example, when running high performancecomputing (HPC), machine learning (ML), or database server workloads.

  To learn more, seeAbout compact placement policiesin this document.

• Spread placement policy. This policy places instances on separate,distinct hardware, which you can use to increase your workload'sreliability. Specifically, spreading instances helps to reduce the number ofinstances that are simultaneously impacted by location-specific disruptions,such as hardware errors. Additionally, if you use a spread placement policytooverprovision capacity in multiple locations,you can help ensure that you still have sufficient capacity even when onelocation is disrupted. For this reason, spread placement policies can alsobe helpful for large-scale, distributed, and replicated workloads, such asHadoop Distributed File System (HDFS), Cassandra, or Kafka.

  To learn more, seeAbout spread placement policies in this document.

About compact placement policies

When you apply a compact placement policy to compute instances,Compute Engine tries to place the instances as close to each other aspossible. This placement is subject to the machine type and zone availability ofthe instances, and instance compactness is achieved only on a best-effort basis.If your application is latency-sensitive and requires instances to be as closetogether as possible (maximum compactness) in a zone, then specify amaximumdistance value (Preview). Lower maximumdistance values ensure closer instance placement, but can result in feweravailable machines for instance placement.

The following table outlines the supported machine series, maximum number ofinstances, andhost maintenance policyfor each maximum distance value:

After you create a compact placement policy and apply it to compute instances,you can verify the physical location of the instances in relation to otherinstances that specify the same compact placement policy. For more information,seeVerify the physical location of an instance.

About spread placement policies

When creating a spread placement policy, you can specify the number ofavailability domains—up to eight—to spread its compute instancesacross. Availability domains provide isolated, distinct hardware to minimize theimpact of localized disruptions. However, they're still impacted by sharedinfrastructure failures, such as data center power outages.

To reduce the proportion of your instances that are impacted whenever anavailability domain is disrupted, spread your instances across at least twoavailability domains—each additional availability domain further reducesthe proportion of your instances that are impacted. Alternatively, you mightspread your instances across a small number of availability domains to try tolimit network latency between those instances or due to zonal restrictions.

When you apply a spread placement policy to an existing instance, the instancemight need to be relocated to a different availability domain. During thisprocess, Compute Engine stops or live migrates the instance based on itshost maintenance policy.

Restrictions

The following sections outline the restrictions for placement policies.

Restrictions for all placement policies

For all placement policies, the following restrictions apply:

• Placement policies areregional resources,and they only work in the region where they are located. For example, if youcreate a placement policy in regionus-central1, then you can only applyit to Compute Engine resources located inus-central1 or in a zoneinus-central1.

• You can only apply one placement policy per Compute Engine resource.

• You can replace or remove placement policies only from compute instances.Replacing or removing placement policies from other Compute Engineresources isn't supported.

• You can only delete a placement policy if it's not applied to anyCompute Engine resource.

• You can't apply placement policies to future reservation requests or toon-demand reservations that Compute Engine creates to fulfill anapproved future reservation.

• You can't apply placement policies to instances that specify sole-tenantnodes.

Restrictions for compact placement policies

In addition to therestrictions for all placement policies, compactplacement policies have the following restrictions:

• If a compact placement policy specifies amaximum distance value, then this value affectsthe maximum number of compute instances that you can apply the placementpolicy to, as well as the machine series and host maintenance policy thatthe instances can use.

• If you want to apply a compact placement policy to on-demand reservations,then make sure of the following:

  • You can only apply compact placement policies to on-demand,single-project, standalone reservations. Shared reservations andreservations attached to commitments aren't supported.

  • You can't apply compact placement policies that specify a maximumdistance value of1.

  • You can only apply a compact placement policy to one reservation at atime.

Restrictions for spread placement policies

In addition to therestrictions for all placement policies, spreadplacement policies have the following restrictions:

• You can apply a spread placement policy to 256 instances maximum.

• You can't apply spread placement policies to reservations.

Billing

There are no additional costs associated with creating, deleting, or applyingplacement policies to a compute instance.

What's next

• Learn how to create and apply placement policies to compute instances:

  • Create and apply spread placement policies to instances

  • Reduce latency by using compact placement policies