SaaS Runtime locations

Preview

This product or feature is subject to the "Pre-GA Offerings Terms" in the General Service Terms section of the Service Specific Terms. Pre-GA products and features are available "as is" and might have limited support. For more information, see the launch stage descriptions.

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.