Key differences between Trusted Cloud and Google Cloud

Trusted Cloud by S3NS is a local, isolated cloud based on Google Cloud. Not all products, features, and workflows that are available in Google Cloud can be used in Trusted Cloud. This page explains the key differences between Google Cloud and Trusted Cloud. You can learn more about Trusted Cloud and its use cases in the Trusted Cloud overview page.

If you're already familiar with Google Cloud, you should read and understand the differences in this guide carefully. We also recommend that you review the detailed differences guide for each Trusted Cloud product you want to use: these guides appear in each individual product's documentation set. How you design, run, and manage your applications might require some changes from what you're used to in Google Cloud.

Service and feature availability

Products and services in Trusted Cloud have the same names as their Google Cloud counterparts and use the same Google-developed code and infrastructure. However, they don't always provide exactly the same capabilities. For example, only Autopilot mode is available in Google Kubernetes Engine (GKE), older VM types for Compute Engine are unavailable, and you can't use certain Identity and Access Management (IAM) policies. Some services are not available yet in Trusted Cloud.

Additional differences include the following:

  • New features that launch in Google Cloud might not launch at the same time in Trusted Cloud.
  • Service level agreements (SLAs) are managed by each Trusted Cloud operator. These SLAs might differ from those offered in Google Cloud. Contact your Trusted Cloud operator with any questions around SLAs.

To be notified when new services and features deploy in Trusted Cloud, subscribe to the release notes. If there's a particular service or feature you want, contact support.

Service and platform management

Some product or feature names in Trusted Cloud might include "Google-managed", but that doesn't mean that Google actually manages your data. Your Trusted Cloud operator always manages products, services, and your data.

Instead, think of products or features as being "Google-powered". Some product or feature names have changed for Trusted Cloud to make this clearer. For example, "Google-managed encryption keys" have been renamed to make it clear that they're not managed or accessible by Google. Instead, keys are named "Google Cloud-powered encryption keys / Managed in Trusted Cloud by [operator]". The feature uses the same technology as in Google Cloud, but your Trusted Cloud operator implements and manages it.

Trusted Cloud has its own Site Reliability Engineering (SRE) team that monitors and manages the environment. The SRE team uses independent monitoring and alerting stacks that are separate from Google Cloud.

Billing is handled by your Trusted Cloud operator, not Google. For more information, see Trusted Cloud billing or contact your Trusted Cloud operator.

Key differences for developers

As a developer, the following high-level differences can help you build applications that run in Trusted Cloud:

  • Default API service names are the same as in Google Cloud, such as bigquery.googleapis.com. These service names are visible when you enable or disable APIs, for example. The service endpoint FQDN is different, based on the Trusted Cloud hostname. For example, bigquery.googleapis.com becomes bigquery.s3nsapis.fr.
  • OAuth scopes are consistent between Google Cloud and Trusted Cloud. If an OAuth scope includes the term "Google", it continues to do so when running inside Trusted Cloud.
  • Unlike in Google Cloud, you need to specify your target universe (in this case, Trusted Cloud) when setting up and using developer tools like the Google Cloud CLI and client libraries. For example, you must set a GOOGLE_CLOUD_UNIVERSE_DOMAIN environment variable before running any code samples that use our client libraries. For more information, see Set up the gcloud CLI for Trusted Cloud and Use client libraries in Trusted Cloud.
  • You must provide the appropriate Trusted Cloud prefix, such as s3ns:, to identify projects. This prefix is automatically prepended to the names of any projects you create in Trusted Cloud. For example, the project named example-project must be referenced as s3ns:example-project.
  • Because there's no Cloud Shell in Trusted Cloud, you must install command line tools locally or on a VM that runs in Trusted Cloud. If you have workflows or tools that expect access to Cloud Shell, update them for locally-installed access using client libraries or the Google Cloud CLI.

To learn more about additional differences between Google Cloud and Trusted Cloud, review the product-specific differences page for each product.

Key differences for architects and operators

Carefully review existing architecture practices and designs that you use in Google Cloud. The same design might not work appropriately in Trusted Cloud. The following differences are important for admins, architects, and operators:

  • Trusted Cloud has no inter-region redundancy, only a single region that contains multiple zones. If your architecture and applications are built on a multi-region approach for redundancy or load balancing, change the design to accommodate a single-region Trusted Cloud.
  • Compute Engine provides a limited selection of VM types in Trusted Cloud compared to Google Cloud. Update your applications if workloads are designed for a particular size or family of VM that are unavailable in Trusted Cloud, including any Infrastructure as Code (IaC) resources like Terraform files or scripts.
  • You can only use external identities through Workforce Identity Federation or service accounts for authentication and authorization in Trusted Cloud. Google Accounts are not supported. For more information about configuring an identity provider, see Set up an identity provider.
  • There's no Cloud Shell in Trusted Cloud, so you must install command line tools locally or on a VM that runs in Trusted Cloud. Update workflows or tools that expect access to Cloud Shell for locally-installed access using client libraries or the Google Cloud CLI.

To learn more about additional differences between Google Cloud and Trusted Cloud, review the product-specific differences page for each product.

General differences

The following sections detail some key top-level differences between Trusted Cloud and Google Cloud. In addition to these differences, each supported product has its own specific differences page in its documentation set to provide more detail about how the product works in Trusted Cloud. Carefully review these pages along with this guide if you plan to use a product or service in Trusted Cloud.

If you run into any issues, contact support.

Hardware and OS

  • Trusted Cloud doesn't provide the same hardware and OS support as Google Cloud. For example, Compute Engine doesn't support ARM-based images, and TPUs are unavailable. Review the Compute Engine differences pages for more information.
  • A public release of a new machine type or operating system in Google Cloud doesn't indicate future support in Trusted Cloud.

Availability and disaster recovery

  • Trusted Cloud doesn't have multiple regions. Instead, Trusted Cloud runs in one region, u-france-east1, that has three zones. Use multiple zones rather than multiple regions to duplicate resources across different locations for redundancy. Multi-region Google Cloud features are unavailable. Review and update any existing applications or architectures that assume multi-region redundancy or load balancing before you deploy them in Trusted Cloud.

  • Even though Trusted Cloud doesn't have multiple regions, global resources (such as the global Cloud Key Management Service location or the Secret Manager global Secret resource) are still available. Like in Google Cloud these resources are scoped across the entire universe. Unlike in Google Cloud, however, the universe only has one region, and so the result is the same as using resources scoped to u-france-east1.

    You might want to use global if, for example, you want to reuse existing Google Cloud code that addresses global endpoints, or if you are using CMEK with Cloud KMS to protect resources created in the global location.

Cost management

  • Pricing for products and features in Trusted Cloud might differ from that in Google Cloud. Contact your Trusted Cloud operator for any pricing questions.
  • There's no free trial tier in Trusted Cloud.
  • Trusted Cloud quotas might be different to those you are used to in Google Cloud. If you need a quota increase adjustment, you must contact Trusted Cloud support.

Integrations

  • Some products and features might be unavailable if they interact with other products that are unavailable in Trusted Cloud. Review the product-specific differences page to understand what integrations might be unavailable in Trusted Cloud.

Security and access control

  • Use third-party identities through Workforce Identity Federation, such as from Microsoft or Okta platforms, or service accounts for authentication and authorization in Trusted Cloud. Google Accounts and groups are unavailable for Identity and Access Management (IAM) in Trusted Cloud.

Network

  • Trusted Cloud runs a separate, distinct network that's isolated from Google Cloud. The data center infrastructure for Trusted Cloud isn't shared with Google Cloud.
    • Inter-data center network traffic uses a separate WAN that isn't shared with Google Cloud.
    • There's separate connectivity to the Internet, using peering or transit.
  • Create or assign a Virtual Private Cloud (VPC) for applications to use when you create a project in Trusted Cloud. Unlike in Google Cloud, a default network isn't created automatically for projects.

Workflows and tools

  • Cloud Shell is unavailable in Trusted Cloud. Instead, you must install command line tools locally. Update or adapt any workflows or tools that expect access to Cloud Shell , including any documentation examples that include an integrated Cloud Shell experience.
  • By default, the gcloud CLI works with Google Cloud and uses Google Accounts for authentication and authorization. Using the gcloud CLI with Trusted Cloud requires some additional setup to target Trusted Cloud and to use an external identity. For more information, see Set up the gcloud CLI for Trusted Cloud.
    • Update workflows or processes to ensure that the gcloud CLI targets Trusted Cloud.
    • If a feature or products is unavailable in Trusted Cloud, the corresponding gcloud CLI commands and parameters are also unavailable.
  • Ensure that you have set your target GOOGLE_CLOUD_UNIVERSE_DOMAIN environment variable when using client libraries.
  • Provide the appropriate Trusted Cloud prefix, such as s3ns, to identify projects in Trusted Cloud. For example, a project named example-project must be referenced as s3ns:example-project
  • In Trusted Cloud, the operator creates and provides you with an empty organization. You can't create a new organization yourself, unlike in Google Cloud.

Service names, endpoints, and resources

Review these differences carefully if you plan to use Trusted Cloud services programmatically or from the command line, particularly if you intend to reuse existing Google Cloud code or scripts.

  • Service names: Service names such as bigquery.googleapis.com are the same in Trusted Cloud and Google Cloud. These are the names that you'll see, for example, when you enable or disable APIs for your project.

  • Service endpoints: Service endpoints (also known as API endpoints) are the URLs used to make requests to Trusted Cloud APIs, including the Discovery service. Unlike service names, these are different in Trusted Cloud, with a different universe-specific domain. For example, bigquery.googleapis.com becomes bigquery.s3nsapis.fr.

  • Service resources: If you use a unique full resource name (FRN) to specify a service resource, the FRN is the same as the one you'd use in Google Cloud. For example, //bigquery.googleapis.com/projects/my-project/datasets/my-dataset is the same in both universes.

    However, if you specify a service resource using its URL, that URL uses the universe-specific service endpoint domain and so is different to Google Cloud. For example, https://bigquery.googleapis.com/projects/my-project/datasets/my-dataset becomes https://bigquery.s3nsapis.fr/projects/my-project/datasets/my-dataset in Trusted Cloud.

What's next

Review the product-specific differences page for each product to learn more about additional differences between Google Cloud and Trusted Cloud.

To get started using Trusted Cloud, review the following pages: