SaaS Runtime locations

Regions

SaaS Runtime is available in the following regions. For more information about regions and zones, see Geography and regions.

Asia Pacific

The following table lists the available regions in Asia Pacific.

Region description	Region name
Tokyo, Japan	`asia-northeast1`
Osaka, Japan	`asia-northeast2`
Seoul, South Korea	`asia-northeast3`
Taiwan	`asia-east1`
Hong Kong	`asia-east2`
Mumbai, India	`asia-south1`
Delhi, India	`asia-south2`
Singapore	`asia-southeast1`
Jakarta, Indonesia	`asia-southeast2`
Sydney, Australia	`australia-southeast1`
Melbourne, Australia	`australia-southeast2`

Europe

The following table lists the available regions in Europe.

Region description	Region name
Hamina, Finland	`europe-north1`
Stockholm, Sweden	`europe-north2`
Warsaw, Poland	`europe-central2`
St. Ghislain, Belgium	`europe-west1`
London, England	`europe-west2`
Frankfurt, Germany	`europe-west3`
Milan, Italy	`europe-west8`
Paris, France	`europe-west9`
Berlin, Germany	`europe-west10`
Turin, Italy	`europe-west12`
Eemshaven, Netherlands	`europe-west4`
Zurich, Switzerland	`europe-west6`
Madrid, Spain	`europe-southwest1`

Americas

The following table lists the available regions in the Americas.

Region description	Region name
Moncks Corner, South Carolina	`us-east1`
Columbus, Ohio	`us-east5`
Ashburn, Virginia	`us-east4`
The Dalles, Oregon	`us-west1`
Los Angeles, California	`us-west2`
Salt Lake City, Utah	`us-west3`
Las Vegas, Nevada	`us-west4`
Council Bluffs, Iowa	`us-central1`
Dallas, Texas	`us-south1`
Montréal, Canada	`northamerica-northeast1`
Toronto, Canada	`northamerica-northeast2`
Queretaro, Mexico	`northamerica-south1`
São Paulo, Brazil	`southamerica-east1`
Santiago, Chile	`southamerica-west1`

Middle-East and Africa

The following table lists the available regions in the Middle-East and Africa.

Region description	Region name
Johannesburg, South Africa	`africa-south1`
Doha, Qatar	`me-central1`
Tel Aviv, Israel	`me-west1`

The `saas.locations` field

The saas.locations field, within the SaaS offering resource, defines where your SaaS Runtime units can reside, and how your rollouts are managed. The saas.locations field serves as a single source of truth for the supported regions of your SaaS offering.

Rollout regionalization considerations

Supported locations for rollouts are determined by the top-level regions defined in your SaaS offering's supported regions (saas.locations).

Rollouts read the list of supported regions directly from the associated SaaS offering's saas.locations field.

Resource replication

When you create SaaS Runtime resources like releases and unit kinds, they need to be propagated across all of the regions specified in the saas.locations field of your SaaS offering in addition to the global region.

Replication of your resources ensures consistency and availability across your SaaS offering's supported regions.

For example, if saas.locations is set to ['us-central1', 'eu-west1'], you should have three SaaS offering resources:

One in global (with .location = 'global')
One in us-central1 (with .location = 'us-central1')
One in eu-west1 (with .location = 'eu-west1')

All three SaaS offering resources will have the same .locations field (['us-central1','eu-west1']). SaaS Runtime likewise would need unit kinds and releases in global, us-central1, and eu-west1.

Handling edits to the saas.locations field or other resources that are replicated across regions is limited. You need to manually apply edits to each replicated resource.

Replication using Google Cloud console versus Google Cloud CLI

Resource replication functions differently depending on whether you use SaaS Runtime using Google Cloud console, or Google Cloud CLI/API.

Using Google Cloud console: SaaS Runtime will create resources in global and in each of the regions listed in saas.locations automatically.
Using Google Cloud CLI or API: You are responsible for creating resources in global, and in each of the regions listed in saas.locations manually.

Using global as a region

Including global as a region within the saas.locations field is generally not recommended. Rollouts cannot deploy to the global region.

Rollouts always create regional rollouts in each region listed in the saas.locations field. You can use global for orchestration, but avoid listing global as a deployment target within the saas.locations field.

Artifact Registry and Developer Connect locations

The locations of your Artifact Registry repository and Developer Connect instance have specific requirements:

The region of your Artifact Registry repository and Developer Connect instance can be any valid Google Cloud region. They don't need to be included in saas.locations.
The region of your Artifact Registry repository must match the region of your Developer Connect instance.
During unit provisioning, SaaS Runtime copies the artifact from your Artifact Registry repository to the region where the unit is being deployed.

This necessitates the presence of SaaS offering, release, and unit kind resources in all regions listed in saas.locations, even though the Artifact Registry and Developer Connect reside in a single (potentially different) region.
Units can only be created in regions specified in the saas.locations field. Units aren't propagated to global unless explicitly specified and it's not recommended to do so.

Example SaaS Runtime regions configuration

We have provided this example to demonstrate how regionalization works when using SaaS Runtime.

For example, if you wanted to deploy your SaaS offering in us-central1 and europe-west4, while hosting your Artifact Registry repository and Developer Connect instance in us-east1, your SaaS Runtime regions infrastructure would be something like:

saas.locations: ['us-central1', 'europe-west4']
Artifact Registry repository region: us-east1
Developer Connect instance region: us-east1
SaaS offering, unit kind, and release resources: Created by SaaS Runtime in global, us-central1, and europe-west4 using SaaS Runtime in Google Cloud console.

Note: If you are using SaaS Runtime through the API or CLI, you are responsible for creating SaaS offering, unit kind, and release in each region.
Units: Units could be created in either us-central11, or europe-west4.

This configuration lets you manage your deployments across two regions while keeping your artifact management centralized in a third, distinct region. You should consider your latency, compliance, and data residency requirements carefully when selecting your regions.