Principais diferenças entre o Cloud de Confiance e o Google Cloud

Cloud de Confiance by S3NS é uma nuvem local e isolada baseada no Google Cloud. Nem todos os produtos, recursos e fluxos de trabalho disponíveis no Google Cloud podem ser usados noCloud de Confiance. Nesta página, explicamos as principais diferenças entre o Google Cloud e oCloud de Confiance. Saiba mais sobre Cloud de Confiance e os casos de uso na página de visão geral do Cloud de Confiance .

Se você já conhece o Google Cloud, leia e entenda as diferenças neste guia com atenção. Também recomendamos que você consulte o guia detalhado de diferenças para cada produto doCloud de Confiance que você quer usar. Esses guias aparecem no conjunto de documentação de cada produto. A maneira como você cria, executa e gerencia seus aplicativos pode exigir algumas mudanças em relação ao que você está acostumado no Google Cloud.

Devido a essas diferenças entre o Google Cloud e o Cloud de Confiance, a documentação também pode parecer diferente da documentação do Google Cloud. Para mais informações, consulte Sobre a documentação do Cloud de Confiance by S3NS .

Disponibilidade de serviços e recursos

Os produtos e serviços em Cloud de Confiance têm os mesmos nomes que os equivalentes do Google Cloud e usam o mesmo código e infraestrutura desenvolvidos pelo Google. No entanto, eles nem sempre oferecem exatamente os mesmos recursos. Por exemplo, apenas o modo Autopilot está disponível no Google Kubernetes Engine (GKE), os tipos de VM mais antigos do Compute Engine não estão disponíveis, e não é possível usar determinadas políticas do Identity and Access Management (IAM). Alguns serviços ainda não estão disponíveis em Cloud de Confiance.

Outras diferenças incluem:

• Os novos recursos lançados no Google Cloud podem não ser lançados ao mesmo tempo no Cloud de Confiance.
• As versões de prévia dos recursos geralmente não estão disponíveis no Cloud de Confiance.

Para receber notificações quando novos serviços e recursos forem lançados no Cloud de Confiance, inscreva-se para receber as notas da versão. Se você quiser um serviço ou recurso específico, entre em contato com o suporte.

Gerenciamento de serviços e plataformas

Alguns nomes de produtos ou recursos em Cloud de Confiance podem incluir "gerenciado pelo Google", mas isso não significa que o Google gerencia seus dados. Seu operador de Cloud de Confiance sempre gerencia produtos, serviços e seus dados.

Em vez disso, pense em produtos ou recursos como "com tecnologia do Google". Alguns nomes de produtos ou recursos foram alterados paraCloud de Confiance para ficar mais claro. Por exemplo, "chaves de criptografia gerenciadas pelo Google" foram renomeadas para deixar claro que não são gerenciadas ou acessíveis pelo Google. Em vez disso, as chaves são chamadas de "Chaves de criptografia do Google Cloud / Gerenciadas emCloud de Confiance by S3NS". O recurso usa a mesma tecnologia do Google Cloud, mas seu operadorCloud de Confiance a implementa e gerencia.

Cloud de Confiance tem uma equipe própria de engenharia de confiabilidade de site (SRE) que monitora e gerencia o ambiente. A equipe de SRE usa stacks independentes de monitoramento e alertas separadas do Google Cloud.

O faturamento é processado pela sua operadora Cloud de Confiance, não pelo Google. Para mais informações, consulte faturamento doCloud de Confiance ou entre em contato com sua Cloud de Confiance operadora.

Contratos de nível de serviço

Todos os contratos de nível de serviço (SLAs) são com o operador do seu universo. Os SLAs do Google Cloud não se aplicam ao Cloud de Confiance. Para mais detalhes sobre os SLAs, entre em contato com sua operadora.

Principais diferenças para desenvolvedores

Como desenvolvedor, as seguintes diferenças de alto nível podem ajudar você a criar aplicativos que são executados no Cloud de Confiance:

• Os nomes padrão dos serviços de API são os mesmos do Google Cloud, como bigquery.googleapis.com. Esses nomes de serviço ficam visíveis quando você ativa ou desativa APIs, por exemplo. O FQDN do endpoint do serviço é diferente, com base no nome do hostCloud de Confiance . Por exemplo, bigquery.googleapis.com passa a ser bigquery.s3nsapis.fr.
• Os nomes dos escopos do OAuth são consistentes entre o Google Cloud e Cloud de Confiance. Se um escopo do OAuth incluir googleapis no Google Cloud, ele também fará isso no Cloud de Confiance.
• Ao contrário do Google Cloud, você precisa especificar o universo de destino (neste caso, Cloud de Confiance) ao configurar e usar ferramentas para desenvolvedores, como a Google Cloud CLI e bibliotecas de cliente. Por exemplo, é necessário definir uma variável de ambiente GOOGLE_CLOUD_UNIVERSE_DOMAIN antes de executar qualquer amostra de código que use nossas bibliotecas de cliente. Para mais informações, consulte Configurar a CLI gcloud para Cloud de Confiance e Usar bibliotecas de cliente em Cloud de Confiance.
• Você precisa fornecer o prefixoCloud de Confiance adequado, como s3ns:, para identificar projetos. Esse prefixo é adicionado automaticamente aos nomes de todos os projetos criados em Cloud de Confiance. Por exemplo, o ID example-project precisa ser referenciado como s3ns:example-project.
• Como não há Cloud Shell em Cloud de Confiance, é necessário instalar ferramentas de linha de comando localmente ou em uma VM que seja executada em Cloud de Confiance. Se você tiver fluxos de trabalho ou ferramentas que esperam acesso ao Cloud Shell, atualize-os para acesso instalado localmente usando bibliotecas de cliente ou a Google Cloud CLI.

Para saber mais sobre outras diferenças entre o Google Cloud e o Cloud de Confiance, consulte a página de diferenças específicas de cada produto.

Principais diferenças para arquitetos e operadores

Analise com atenção as práticas e os projetos de arquitetura que você usa no Google Cloud. O mesmo design pode não funcionar corretamente em Cloud de Confiance. As seguintes diferenças são importantes para administradores, arquitetos e operadores:

• OCloud de Confiance não tem redundância entre regiões, apenas uma região com várias zonas. Se a arquitetura e os aplicativos forem criados com uma abordagem multirregional para redundância ou balanceamento de carga, mude o design para acomodar uma região única Cloud de Confiance.
• O Compute Engine oferece uma seleção limitada de tipos de VM em Cloud de Confiance em comparação com o Google Cloud. Atualize seus aplicativos se as cargas de trabalho forem projetadas para um tamanho ou família específica de VM que não está disponível em Cloud de Confiance, incluindo recursos de infraestrutura como código (IaC), como arquivos ou scripts do Terraform.
• Só é possível usar identidades externas com a federação de identidade da força de trabalho ou contas de serviço para autenticação e autorização no Cloud de Confiance. Não é possível usar Contas do Google. Para mais informações sobre como configurar um provedor de identidade, consulte Configurar um provedor de identidade.
• Não há Cloud Shell em Cloud de Confiance. Portanto, instale ferramentas de linha de comando localmente ou em uma VM que seja executada em Cloud de Confiance. Atualize fluxos de trabalho ou ferramentas que esperam acesso ao Cloud Shell para acesso instalado localmente usando bibliotecas de cliente ou a Google Cloud CLI.

Para saber mais sobre outras diferenças entre o Google Cloud e o Cloud de Confiance, consulte a página de diferenças específicas de cada produto.

Diferenças gerais

As seções a seguir detalham algumas diferenças importantes de nível superior entre Cloud de Confiance e o Google Cloud. Além dessas diferenças, cada produto compatível tem uma página específica na documentação para fornecer mais detalhes sobre como ele funciona noCloud de Confiance. Leia atentamente essas páginas e este guia se você planeja usar um produto ou serviço emCloud de Confiance.

Se você tiver problemas, entre em contato com o suporte.

Hardware e SO

• OCloud de Confiance não oferece o mesmo suporte de hardware e SO que o Google Cloud. Por exemplo, o Compute Engine não é compatível com imagens baseadas em ARM, e as TPUs não estão disponíveis. Consulte as páginas de diferenças do Compute Engine para mais informações.
• O lançamento público de um novo tipo de máquina ou sistema operacional no Google Cloud não indica suporte futuro noCloud de Confiance.

Disponibilidade e recuperação de desastres

• Cloud de Confiance não tem várias regiões. Em vez disso, Cloud de Confiance é executado em uma região, u-france-east1, que tem três zonas. Use várias zonas em vez de várias regiões para duplicar recursos em locais diferentes para redundância. Os recursos multirregionais do Google Cloud não estão disponíveis. Revise e atualize todos os aplicativos ou arquiteturas atuais que pressupõem redundância ou balanceamento de carga multirregional antes de implantá-los noCloud de Confiance.

• Mesmo que Cloud de Confiance não tenha várias regiões, os recursos do global, como o local do Cloud Key Management Service do global ou o recurso global Secret do Secret Manager, ainda estão disponíveis. Assim como no Google Cloud, esses recursos são definidos em todo o universo. No entanto, ao contrário do Google Cloud, o universo tem apenas uma região. Portanto, o resultado é o mesmo que usar recursos no escopo de u-france-east1.

  Use global se, por exemplo, você quiser reutilizar o código do Google Cloud que aborda endpoints globais ou se estiver usando a CMEK com o Cloud KMS para proteger recursos criados no local global.

Gerenciamento de custo

• Os preços dos produtos e recursos no Cloud de Confiance podem ser diferentes dos do Google Cloud. Entre em contato com sua Cloud de Confiance operadora se tiver dúvidas sobre preços.
• Não há um nível de teste gratuito no Cloud de Confiance.
• Cloud de Confiance podem ser diferentes das que você está acostumado a usar no Google Cloud. Se você precisar de um ajuste no aumento da cota, entre em contato com o suporte doCloud de Confiance .
• Os descontos por compromisso de uso (CUDs) não estão disponíveis em Cloud de Confiance.

Integrações

• Alguns produtos e recursos podem ficar indisponíveis se interagirem com outros produtos que não estão disponíveis em Cloud de Confiance. Consulte a página de diferenças específicas do produto para entender quais integrações podem estar indisponíveis no Cloud de Confiance.

Controle de acesso e segurança

• Use identidades de terceiros com a federação de identidade de força de trabalho, como das plataformas Microsoft ou Okta, ou contas de serviço para autenticação e autorização no Cloud de Confiance. As contas e os grupos do Google não estão disponíveis para o Identity and Access Management (IAM) em Cloud de Confiance.
• Os nomes dos escopos do OAuth são consistentes entre o Google Cloud e Cloud de Confiance. Se um escopo do OAuth incluir googleapis no Google Cloud, ele também fará isso no Cloud de Confiance.

Rede

• OCloud de Confiance executa uma rede separada e distinta isolada do Google Cloud. A infraestrutura do data center para Cloud de Confiance não é compartilhada com o Google Cloud.
  • O tráfego de rede entre data centers usa uma WAN separada que não é compartilhada com o Google Cloud.
  • Há uma conectividade separada com a Internet, usando peering ou trânsito.
• Crie ou atribua uma nuvem privada virtual (VPC) para os aplicativos usarem ao criar um projeto no Cloud de Confiance. Ao contrário do Google Cloud, uma rede padrão não é criada automaticamente para projetos.

Saiba mais sobre as principais diferenças de rede e os recursos disponíveis nos seguintes guias:

• Nuvem privada virtual
• Cloud NAT
• Network Service Tiers
• Cloud VPN
• Cloud Interconnect
• Cloud Router
• Cloud DNS
• Cloud Load Balancing
• Cloud Next Generation Firewall
• VPC Service Controls
• Google Cloud Armor

Workflows e ferramentas

• O Cloud Shell não está disponível em Cloud de Confiance. Em vez disso, instale as ferramentas de linha de comando localmente. Atualize ou adapte todos os fluxos de trabalho ou ferramentas que esperam acesso ao Cloud Shell , incluindo exemplos de documentação que incluem uma experiência integrada do Cloud Shell.
• Por padrão, a CLI gcloud funciona com o Google Cloud e usa as Contas do Google para autenticação e autorização. Usar a CLI gcloud com Cloud de Confiance requer mais configuração para segmentar Cloud de Confiance e usar uma identidade externa. Para mais informações, consulte Configurar a CLI gcloud para Cloud de Confiance.
  • Atualize fluxos de trabalho ou processos para garantir que a CLI gcloud direcione Cloud de Confiance.
  • Se um recurso ou produto não estiver disponível em Cloud de Confiance, os comandos e parâmetros correspondentes da CLI gcloud também não estarão.
• Verifique se você definiu a variável de ambiente GOOGLE_CLOUD_UNIVERSE_DOMAIN de destino ao usar bibliotecas de cliente.
• Forneça o prefixo Cloud de Confianceadequado, como s3ns, para identificar projetos em Cloud de Confiance. Por exemplo, um projeto chamado example-project precisa ser referenciado como s3ns:example-project
• Em Cloud de Confiance, o operador cria e fornece uma organização vazia. Não é possível criar uma nova organização por conta própria, como no Google Cloud.

Nomes de serviços, endpoints e recursos

Analise essas diferenças com cuidado se você planeja usar os serviços do Cloud de Confiance de maneira programática ou na linha de comando, principalmente se pretende reutilizar código ou scripts do Google Cloud.

• Nomes de serviço:nomes de serviço como bigquery.googleapis.com são iguais em Cloud de Confiance e no Google Cloud. Esses são os nomes que aparecem, por exemplo, quando você ativa ou desativa APIs no seu projeto.

• Endpoints de serviço:também conhecidos como endpoints de API, são os URLs usados para fazer solicitações às APIs do Cloud de Confiance, incluindo o serviço de descoberta. Ao contrário dos nomes de serviço, eles são diferentes em Cloud de Confiance, com um domínio específico do universo diferente. Por exemplo, bigquery.googleapis.com passa a ser bigquery.s3nsapis.fr.

• Recursos de serviço:é possível especificar recursos de serviço de várias maneiras. Não se esqueça de que, ao especificar recursos de serviço, todos os IDs de projeto Cloud de Confiancetêm um prefixoCloud de Confiance (s3ns:), que precisa ser incluído ao especificar um projeto como parte de um nome ou URL de recurso.

  • Se você usar um nome completo do recurso (FRN, na sigla em inglês) exclusivo para especificar um recurso de serviço, o FRN será igual ao que você usaria no Google Cloud, incluindo googleapis. Por exemplo, //bigquery.googleapis.com/projects/my-project/datasets/my-dataset é igual nos dois universos.

  • Se você usar um nome de recurso sem a API pai, como projects/my-project/dataset/my-dataset, o nome também será igual ao usado no Google Cloud.

  • Se você usar um URL, ele vai usar o domínio do endpoint de serviço específico do universo e, portanto, será diferente do Google Cloud. Por exemplo, https://bigquery.googleapis.com/bigquery/v2/projects/my-project/datasets/my-dataset se torna https://bigquery.s3nsapis.fr/bigquery/v2/projects/my-project/datasets/my-dataset em Cloud de Confiance.

Contas de serviço

Os endereços de e-mail das contas de serviço (incluindo as contas serviço gerenciado pelo universo, também conhecidas como agentes de serviço) usam domínios específicos do universo e, portanto, são diferentes daqueles usados no Google Cloud:

Google Cloud	Cloud de Confiance	Uso
developer.gserviceaccount.com	developer.s3ns-system.iam.gserviceaccount.com	Usado na conta de serviço padrão do Compute Engine.
iam.gserviceaccount.com	s3ns.iam.gserviceaccount.com	Usado em domínios para a maioria das contas de serviço gerenciado pelo usuário.
	s3ns-system.iam.gserviceaccount.com	Usado para alguns agentes de serviço.
system.gserviceaccount.com	s3ns-system.system.gserviceaccount.com	Usado para alguns agentes de serviço.
Outros usos do gserviceaccount.com	s3ns-system.system.gserviceaccount.com	Usado para alguns agentes de serviço.

Por exemplo:

• A conta de serviço padrão do Compute Engine no seu projeto pode ter o endereço 1234567-compute@developer.s3ns-system.iam.gserviceaccount.com.
• Uma conta de serviço criada pelo usuário pode ter o endereço my-service-account@my-project.s3ns.iam.gserviceaccount.com

Para contas criadas pelo usuário, observe que o prefixo específico do universo do projeto principal não é usado. Em caso de dúvida sobre uma conta de serviço específica, acesse as páginas do Identity and Access Management no console Cloud de Confiance para conferir os nomes completos com domínios de todas as contas de serviço e agentes de serviço do projeto, incluindo os criados por Cloud de Confiance:

Acessar IAM

Se você estiver usando o GKE, os domínios do pool de identidade da carga de trabalho (e todas as ServiceAccounts do Kubernetes que os usam) também serão especificados de maneira diferente em universos diferentes. Leia mais sobre isso na página de diferenças do GKE.

Documentação

A documentação do Cloud de Confiance é adaptada da documentação do Google Cloud, com algumas diferenças. Por exemplo, páginas sobre serviços do Google Cloud que não estão disponíveis em Cloud de Confiance não são incluídas neste site de documentação.

Saiba mais em Sobre a documentação do Cloud de Confiance by S3NS .

A seguir

Consulte a página de diferenças específicas de cada produto para saber mais sobre as diferenças entre o Google Cloud e oCloud de Confiance.

Para começar a usar o Cloud de Confiance, consulte as seguintes páginas:

• Configurar a CLI gcloud para Cloud de Confiance
• Configurar um provedor de identidade