The resources used by each service are impacted by location in different ways. Before adding a resource locations constraint to your organization policy, review the appropriate section below to see how the resources you are applying the policy to will behave.
App Engine
in App Engine is a property of the application
resource.
The location property is enforced for all environments when you create an
application
. You can create only one App Engine application
in each
project. A Cloud Storage bucket is automatically created in the same location
as the application
. If you create an application
with a broad location that
doesn't comply with the organization policy, you will have to create a new
project and App Engine application
.
When you disable an application
, it won't be served in future, but replicated
code and data will remain in locations the application
was stored in. To
completely erase this data, delete the parent project.
The App Engine flexible environment is built on top of Compute Engine. Auto-scaling instances can fail if any locations where scaling happens aren't in the list of allowed locations that are defined in the organization policy.
For a list of available locations, see App Engine Locations.
Compute Engine
Compute Engine uses a large number of resources, and these can be global, regional, or zonal. Regional and zonal resources are subject to the resource locations constraint. For example, you can use Compute Engine to create a virtual machine, and its physical location can be restricted by the resource locations constraint. Cloud Router, CDN Interconnect, and Cloud VPN resources are also regional and can be restricted by this constraint.
Some resources, such as Compute Engine snapshots
and Compute Engine images
, are
global, but have the resource locations constraint enforced on them. A
snapshot
resource is created in a particular location decided by the user,
or in an automatically selected location if one has not been specified. For more
information about the location of Compute Engine resources, see
Global, Regional, and Zonal resources.
Enforcement of the resource locations is handled at the level of the Compute Engine resource at the time you create it. The enforcement isn't retroactive: it only restricts the creation of resources in the listed regions, and doesn't restrict against movement of data.
Global resources, such as Compute Engine images
and Cloud DNS
resources, aren't subject to location-based enforcement. Note that some
services, such as Virtual Private Cloud and Cloud Load Balancing, use both global and
regional resources. For example, VPC networks are global, but
subnetworks are regional and subject to resource locations constraint
enforcement.
VM instance groups are subject to location-based enforcement. Instance groups can be zonal (deployed to a single zone) or regional (deployed to multiple zones in the same region). Regional resources that enforce the resource locations constraint require that all zones provided by the user or selected by default match the defined locations. For example, if only one zone from a given region is restricted, then the user can still create a regional instance group, but must select zones that are not location restricted.
When you use an instance group, the effective organization policy is evaluated on the creation of each instance. This will affect autoscaling, autohealing, auto-updating, and manually recreating the instances or increasing the size of the instance group.
For a list of available locations, see the Compute Engine Regions and Zones page.
Google Kubernetes Engine
Google Kubernetes Engine uses Compute Engine regions and zones. Enforcement of the resource locations is handled at the level of the Compute Engine resource when you create the VM for a cluster. If you want to scale a cluster by adding more instances or adding another zone, these new additions must also be in an allowed location.
To create clusters with sufficient redundancy, use value groups to control the locations that are restricted. If you set the locations manually, all zones in that region must be in the allowed list to have the same level of redundancy. Auto-scaling clusters can break if any of the locations in which scaling happens aren't in the list of allowed locations defined in the organization policy.
Cloud Bigtable
A Cloud Bigtable instance resource is a logical container of clusters. Each of these clusters is located in a zone. All data in an instance is replicated uniformly to all clusters that are contained in that instance. Organization policy is enforced when a cluster is created. You can't create new storage containers in a location that is denied in the organization policy. Existing instances and clusters will continue to operate even if they are in locations that are denied by the organization policy.
For a list of available locations, see the Cloud Bigtable Locations page.
Datastore
The Datastore database
resources are directly dependent on the
App Engine application in the parent project and its defined location.
Disabling the App Engine application will block API access for the associated
database. To delete replicated data from the physical locations, delete the
project as described in the App Engine section.
For a list of available locations, see the Datastore Locations page.
Cloud Spanner
Organization policy is enforced when you create an instance. Instances are either regional or multi-regional resources. If an instance is blocked by the resource locations organization policy, the only way to bring the resource into compliance is by deleting the instance. Instances that are blocked by the resource locations organization policy will still allow for reads, writes, and the creation of database resources.
For a list of available locations, see the Cloud Spanner Instances page.
Cloud SQL
Organization policy is enforced when you create an instance. The instance is a regional resource that will create a zonal database, for which the resource location is not enforced. When you create read replicas or database clones, you locate the new resources in the same region as the original, so the resource locations organization policy isn't enforced.
For a list of available locations, see the Cloud SQL Instance Locations page.
Cloud Storage
Organization policy is enforced when you create a bucket
resource. Bucket
resources are regional or multi-regional. Object
resources can be added to
any existing bucket
even if the object
is in a location that is denied by
the resource locations organization policy. To ensure that your
resources are in compliance with the resource locations organization policy,
create new bucket
resources after the organization policy is applied, and then
migrate data from old bucket
resources to the new ones.
For a list of available locations, see the Cloud Storage Bucket Locations page.
Persistent Disk
The organization policy is enforced when you create a disk
resource, which can
then be attached to virtual machines:
- After you create a zonal
disk
resource, you can attach it to virtual machine instances in the same zone. - After you create a regional
disk
resource, you can attach it to virtual machine instances in one of the two zones thedisk
resides in.
Organization policy compliance isn't enforced retroactively. To enforce a
new resource locations organization policy on existing disk
resources, you
need to delete the disk
resources and then create them again with the
organization policy applied to the parent resource.
For a list of available locations, see the Compute Engine Regions and Zones page.
BigQuery
BigQuery dataset
resources can be both regional and multi-regional.
Organization policy compliance isn't enforced retroactively. To enforce a new
resource locations constraint on an existing dataset
, delete the
dataset
resource and create it again with the organization policy applied
to the parent resource.
You can create Database
resources within a dataset
resource with a location
that is denied by the resource locations organization policy. The location of
the dataset
resource does not dictate the location of the database
resource. To enforce a new resource locations constraint on an existing
disk
, delete the disk
resource and create it again with the
organization policy applied to the parent resource.
For a list of available locations, see the BigQuery Dataset Locations page.
Dataflow
The organization policy is enforced when you create a job
. A job
is a
regional resource that uses both Cloud Storage and Compute Engine.
You can configure Compute Engine workers to execute in a zone outside
the region of the job by specifying the zone parameter. In this case, the
Dataflow control plane will execute in the specified region,
while data processing workers will execute in the specified zone. If you don't
specify the zone of workers, the workers will be created within the region in
which the job
is configured to run.
If you don't specify the zone of the job
, the location of the workers will be
in one of the zones within the region in which the job
is configured to run.
Dataflow will select the zone based on the available capacity
in the zone. All zones within the region of the job
should be set as allowed
values in the resource locations organization policy.
Auto-scaling clusters can break if any of the locations in which scaling happens isn't in the list of allowed locations defined in the organization policy.
For a list of available locations, see the Dataflow Regional endpoints page.
Dataproc
When you create a cluster
, the organization policy is enforced based on the
region you specify in the creation request. The location of a job
is
bound by the location of the cluster
that is its parent when the
submit
method is called.
For a list of available locations, see the Dataproc Regional endpoints page.
Pub/Sub
The resource locations organization policy affects the locations in
which messsages published to a topic
can be persisted at rest. The
organization policy is enforced when you publish messages to a topic
. Note
that a topic
is still a global resource that is accessible from anywhere in
the world to authorized clients.
Changes to the organization policy are not automatically applied to existing
topics
. If a new resource resource locations organization policy denies a
location where messages published to a topic
are already stored, those
messages will not automatically be moved.
For more information, see the Pub/Sub Restricting Pub/Sub resource locations page.
Key Management Service
KMS resources can be created in regional, dual-regional, multi-regional, or global locations. The organization policy will be enforced at the time you create that resource.
For more information, see the KMS locations page.