Neste documento, ajudamos arquitetos de nuvem e profissionais de operações como decidir a forma de conectar o Google Cloud a outros provedores de serviços em nuvem (CSP, na sigla em inglês), como a Amazon Web Services (AWS) e o Microsoft Azure. Em um projeto multicloud, as conexões entre CSPs permitem transferências de dados entre suas redes virtuais. Neste documento, fornecemos também informações sobre como implementar a opção escolhida.
Muitas organizações operam em várias plataformas de nuvem, seja como uma medida temporária durante uma migração ou porque a organização tem uma estratégia multicloud em longo prazo.
Para troca de dados entre o Google Cloud e outros CSPs, várias opções são discutidas neste documento:
- Transferir dados por meio de endereços IP públicos pela internet.
- Como usar um serviço de VPN gerenciado entre o Google Cloud e o outro CSP.
- Como usar a Interconexão por parceiro no Google Cloud para se conectar a um parceiro que possa se conectar diretamente com o outro CSP.
- Como usar a Interconexão dedicada no Google Cloud para transferir dados a outro CSP por meio de um ponto de presença comum (POP).
- Como usar o Cloud Interconnect no Google Cloud para uma conexão gerenciada com outro CSP.
Essas opções diferem em termos de velocidade de transferência, latência, confiabilidade, contratos de nível de serviço (SLAs, na sigla em inglês), complexidade e custos. Neste documento, descrevemos em detalhes cada opção, bem como as respectivas vantagens e desvantagens. Depois, terminamos com uma comparação de todas as opções.
Neste documento, abordamos as transferências de dados entre máquinas virtuais que residem no Google Cloud e em outras redes virtuais do CSP. Para dados armazenados em outros produtos do Google Cloud, como o Cloud Storage e o BigQuery, consulte a seção que abrange esses produtos.
Este documento serve como um guia para avaliar as opções de transferência de dados entre o Google Cloud e um ou mais CSPs, com base nos seus requisitos e recursos.
Os conceitos neste documento se aplicam em vários casos:
- Quando você planeja transferir grandes quantidades de dados por um curto período de tempo, por exemplo, para um projeto de migração de dados.
- Se você executa transferências de dados contínuas entre vários provedores de nuvem, por exemplo, porque as cargas de trabalho de computação são executadas em outro CSP, enquanto as cargas de trabalho de Big Data usam o Google Cloud.
Considerações iniciais
Antes de escolher como conectar os ambientes de nuvem, é importante observar quais regiões você escolhe em cada ambiente e se você tem uma estratégia para transferir dados que não residam em ambientes de VPC.
Escolher as regiões da nuvem
Se o Google Cloud e outros recursos do CSP estiverem em regiões geograficamente próximas, há uma vantagem de custo e latência para transferências de dados entre provedores de nuvem.
O diagrama a seguir ilustra o fluxo de dados entre o Google Cloud e outros CSPs.
Independentemente do método de transferência, os dados fluem do Google Cloud para o outro CSP da seguinte maneira:
- Da região do Google Cloud em que os recursos estão hospedados ao POP de extremidade do Google.
- Através de uma instalação de terceiros entre o Google Cloud e outro CSP.
- Do outro POP de borda do CSP para a região onde os recursos estão localizados dentro da rede do outro CSP
Os dados que fluem do outro CSP para o Google Cloud percorrem o mesmo caminho, mas na direção oposta.
O caminho completo determina a latência da transferência de dados. Para algumas soluções, os custos de rede também aumentam quando os POPs de borda de ambos os provedores não estão em uma área metropolitana. Os detalhes estão listados na seção de preços após cada solução.
Escolha regiões adequadas em cada nuvem que possa hospedar as cargas de trabalho pretendidas. Visite a página Locais do Google Cloud e páginas semelhantes de outros CSPs, como a tabela de regiões da AWS ou produtos do Azure por região. Para informações gerais sobre como selecionar um ou vários locais no Google Cloud, consulte as Práticas recomendadas para a seleção de região do Compute Engine.
Transferir dados no Cloud Storage e no BigQuery
Por padrão, somente os dados que residem em um ambiente de VPC do Google Cloud passam por um túnel do Cloud VPN ou por uma conexão do Cloud Interconnect.
Se você quiser transferir dados de e para outros serviços do Google, use o Private Service Connect e o Acesso privado do Google para hosts locais do ambiente do outro CSP.
Se você quiser transferir o armazenamento de objetos e de dados, o banco de dados ou outros produtos de outro CSPs, verifique na documentação se os dados podem passar por seu produto VPN de interconexão ou gerenciado. Caso contrário, transmita esses dados por meio de máquinas virtuais de proxy configuradas no ambiente do respectivo CSP para fazer com que eles passem pela conexão desejada.
Para transferir dados para o Cloud Storage ou o BigQuery, também é possível usar o Serviço de transferência do Cloud Storage ou o Serviço de transferência do BigQuery.
Transferir por meio de endereços IP externos pela Internet
A maneira mais fácil de transferir dados entre o Google Cloud e outro CSP é através da Internet e com a transferência dos dados usando endereços IP externos.
O diagrama a seguir ilustra os elementos dessa solução.
Entre a extremidade da rede do Google e a outra extremidade do CSP, os dados passam pela Internet ou usam um peering direto entre o Google Cloud e o outro CSP. Os dados só podem passar entre recursos que têm endereços IP públicos atribuídos.
Como o Google se conecta a outras redes
Os POPs de extremidade do Google são onde a rede do Google se conecta a outras redes que formam coletivamente a Internet. O Google está presente em vários locais do mundo todo.
Na Internet, cada rede recebe um número autônomo do sistema (ASN, na sigla em inglês) que engloba a infraestrutura e as rotas da rede interna da rede. O ASN principal do Google é 15169.
Há duas maneiras principais de uma rede enviar ou receber tráfego no Google:
- Comprar o serviço de Internet de um provedor de serviços de Internet (ISP) que já tenha conectividade com o Google (AS15169). Essa opção é geralmente chamada de transporte de IP e é semelhante ao que os consumidores e empresas compram de provedores de acesso em suas casas e empresas.
- Conectar-se diretamente ao Google (AS15169). Essa opção, chamada de peering, permite que uma rede envie e receba tráfego diretamente para o Google (AS15169) sem usar uma rede de terceiros. Em escala, o peering é geralmente preferível em relação ao transporte, porque os operadores de rede têm mais controle sobre como e onde o tráfego é trocado, permitindo a otimização do desempenho e do custo. O peering é um sistema voluntário. Ao optar por fazer peering, os operadores de rede decidem em conjunto quais instalações serão conectadas, a quantidade de largura de banda a ser provisionada, como dividir os custos de infraestrutura e outros detalhes necessários para configurar as conexões. O AS15169 tem uma política de peering aberta, o que significa que, desde que uma rede atenda aos requisitos técnicos, o Google fará peering com eles.
O peering é um acordo privado e mutuamente vantajoso entre duas redes independentes e, como tal, as redes geralmente não divulgam publicamente com quem fazem peering em locais específicos, quanta largura de banda está disponível etc. No entanto, devido à escala e a uma política aberta, o Google faz peering direto com quase todos os principais ISPs e provedores de serviços de nuvem em vários locais e regiões. A equipe da Rede do Google trabalha diretamente com seus colegas nessas redes para fornecer capacidade de peering suficiente para atender à demanda.
Leia mais sobre como o peering de Internet funciona no Manual de peering de Internet.
Implementação
Nesta configuração, todas as máquinas virtuais que transferem dados entre o Google Cloud e outros provedores de serviços em nuvem devem ter um endereço IP público. De um lado, o firewall precisa ser aberto para permitir uma conexão do endereço IP público do outro provedor em nuvem. Nenhuma outra etapa é necessária porque a troca de dados acontece por meio da conectividade com a Internet atual.
Velocidade de transferência e latência
Embora não haja velocidade e latência garantidas no caminho pela Internet, normalmente, os principais CSPs e o Google trocam dados diretamente em vários locais ao redor do mundo. A capacidade é compartilhada com outros clientes e serviços, mas, muitas vezes, devido à conexão direta entre os dois provedores, a latência é semelhante ou menor que as outras opções.
Recomendamos que você teste a latência e a largura de banda entre o Google Cloud e outros CSPs nas regiões escolhidas. É possível fazer um comparativo de mercado rápido usando ferramentas como iperf ou netperf ou executar um comparativo de mercado personalizado mais completo com base no seu app. Embora as condições possam sofrer alterações ao longo do tempo, o comparativo de mercado pode fornecer uma indicação do desempenho esperado e se essa solução atende às suas necessidades. Se você precisar de uma largura de banda dedicada entre os dois ambientes, escolha outra solução.
Produtos de diferentes fornecedores podem ter características de desempenho que nem sempre estão alinhados. Por exemplo, a capacidade da VPN IPsec por túnel pode variar de fornecedor para fornecedor.
Segurança
O tráfego pela Internet não é criptografado e pode passar por provedores de acesso à Internet (ISPs, na sigla em inglês), sistemas autônomos e instalações de terceiros. Portanto, criptografe o tráfego confidencial na camada de aplicativo ou escolha outra solução.
Confiabilidade e SLA
Em geral, o Google Cloud tem vários caminhos diferentes para a conectividade de Internet das regiões, e há conexões de peering direto com outros principais CSPs em vários locais ao redor do mundo.
No entanto, o Google Cloud não fornece SLAs para conectividade com outros CSPs pela Internet. É necessário verificar os SLAs de seus outros CSPs, mas eles geralmente se referem apenas à conectividade com a Internet como um todo e não a provedores específicos.
Os provedores podem ter políticas de roteamento diferentes que podem afetar a disponibilidade. Por exemplo, na página peeringdb, a Amazon explica que muitas regiões da AWS anunciam apenas rotas locais, porque as VPCs da AWS são apenas regionais (as VPCs do Google Cloud são globais). Isso significa que os clientes podem depender de links em um único local de peering, já que o tráfego que sai do Google Cloud só pode usar esses links para chegar ao destino. Isso não é um problema na operação normal com tráfego sendo trocado na região. No entanto, é aconselhável que os clientes façam arquitetura para implantações multirregionais para tolerar falhas regionais. Isso pode incluir a configuração de gateways adicionais, VPNs de alta disponibilidade, peering de VPC ou outras topologias multirregionais na nuvem de terceiros.
Os aplicativos também devem ser criados de forma que retornem "fail open", conforme recomendado pelo Google SRE no livro SRE. Por exemplo, se você criar um aplicativo que depende de capacidade de alcançar um serviço de terceiros por meio do roteamento pela Internet, verifique se o aplicativo ainda funciona ou se ele retorna mensagens de erro úteis ao usuário caso ocorram problemas de conectividade.
Quando ocorrem problemas de roteamento da Internet, a equipe de rede do Google tenta restaurar a conectividade com o terceiro. No entanto, nem todos os problemas estarão sob controle do Google. Portanto, em alguns casos, o reparo pode depender de um terceiro (ISP ou provedor de nuvem) realizar uma ação restauradora. Os clientes têm mais influência sobre como os operadores respondem a interrupções. Portanto, verifique se você tem cobertura de suporte com todos os provedores e um plano para encaminhar problemas caso algo dê errado. Faça também exercícios de simulação periódicos do BCP (processo de continuidade dos negócios) para garantir a resiliência dos aplicativos arquitetados em várias nuvens.
Preços
Para transferências de dados pela Internet, as taxas normais de saída da Internet se aplicam ao tráfego que sai do Google Cloud. Nos casos em que a latência não é fundamental, o uso do Nível de serviço de rede padrão fornece um nível de preços mais baixo.
Os outros CSPs têm as próprias cobranças para transferências de dados. Em muitos casos, somente o tráfego que sai da rede deles é cobrado. Consulte a lista de preços do seu CSP. Por exemplo, para a AWS, consulte Taxas de transferência de dados do EC2 e, no Azure, consulte Detalhes do preço de largura de banda.
VPN gerenciada entre provedores de nuvem
É possível usar serviços de VPN gerenciados dos dois provedores de nuvem, que têm dois benefícios. Ele fornece um canal criptografado entre redes virtuais em ambos os ambientes de nuvem e permite transferir dados usando endereços IP particulares. Essa é uma extensão da solução anterior de transferência pela Internet sem a necessidade de hardware ou parceiros.
O diagrama a seguir ilustra os elementos dessa solução.
Com essa solução, os dados são criptografados no Google Cloud usando o Cloud VPN e uma solução de VPN para outro CSP. A transferência de dados entre o Google Cloud e o outro CSP usa a Internet, como na solução anterior.
Implementação
O Google oferece o Cloud VPN como um serviço gerenciado de VPN para túneis IPsec criptografados, que podem ser usados no Google. Outros CSPs oferecem os próprios produtos de VPN gerenciados, que podem ser usados para criar túneis VPN IPsec entre os dois ambientes. Por exemplo, a AWS oferece a VPN site a site da AWS e o Azure oferece o gateway de VPN do Azure. Você pode conectar suas redes virtuais entre os ambientes usando túneis VPN.
Os endereços IP nos dois ambientes não podem se sobrepor porque não há nenhuma funcionalidade de conversão de endereço de rede (NAT) disponível no Cloud VPN. No Cloud Router, rotas sobrepostas podem ser removidas de serem trocadas entre ambientes. Entretanto, nenhuma comunicação entre os serviços que usam esses endereços IP é possível.
Com o Cloud Router no modo de roteamento dinâmico global, é possível alcançar todas as regiões em uma rede VPC global usando apenas túneis VPN para essa região. Para outros CSPs, pode ser necessário ter túneis VPN por região. Se você tiver várias redes virtuais em um ambiente de nuvem que não tenham peering, será necessário conectar todas as redes virtuais que precisam se comunicar de maneira independente usando uma VPN.
O Google Cloud oferece guias de interoperabilidade com instruções passo a passo para configurar túneis VPN para outros grandes provedores de nuvem:
- Gateway do Alibaba Cloud VPN sem redundância: compatível somente com rotas estáticas.
- Gateway do Alibaba Cloud VPN com redundância: compatível somente com rotas estáticas.
- AWS: compatível com roteamento dinâmico com o Cloud Router.
- Microsoft Azure: compatível com roteamento dinâmico com o Cloud Router.
Velocidade de transferência e latência
Quando você usa túneis VPN gerenciados, os dados ainda seguem o mesmo caminho da Internet, como se fossem trocados diretamente usando endereços IP públicos. A latência observada precisa ser semelhante à opção anterior, com apenas uma pequena sobrecarga de latência para o túnel VPN. A largura de banda disponível é limitada pela largura de banda máxima por túnel VPN no Google Cloud, a largura de banda máxima dos outros túneis do CSP e a largura de banda disponível no caminho da Internet.
Para maior largura de banda, implante vários túneis em paralelo. Para mais informações sobre como implantar essa solução, consulte Como criar VPNs de alta capacidade.
É possível testar a latência e a largura de banda conforme descrito na última seção, mas as condições podem variar com o tempo e não há garantias de latência ou largura de banda.
Segurança
O tráfego via túneis VPN IPsec é criptografado usando criptografia compatível com os dois CSPs. Para mais informações, consulte Criptografia IKE compatível com o Cloud VPN, Perguntas frequentes sobre VPN da AWS e Parâmetros IPsec/IKE de VPN do Azure.
Confiabilidade e SLA
O Cloud VPN oferece um SLA de 99,9% a 99,99%, dependendo da VPN selecionada: clássica ou de alta disponibilidade. Outros CSPs às vezes oferecem SLAs nos produtos de VPN gerenciados. Por exemplo, SLA de VPN site a site da AWS e SLA do Azure para gateway de VPN. No entanto, esses SLAs cobrem apenas a disponibilidade dos gateways de VPN e não incluem conectividade com outros CSPs pela Internet, portanto, não há SLA na solução completa.
Para aumentar a confiabilidade, considere o uso de vários gateways e túneis VPN no Google Cloud e nos outros CSPs.
Preços
Para o serviço de VPN gerenciado, aplicam-se cobranças. Uma cobrança por hora é aplicada para o Google Cloud. Consulte Preços da Cloud VPN. Para outros CSPs, consulte as respectivas listas de preços. Por exemplo, consulte Preços de conexão VPN site a site da AWS ou Preços de gateway de VPN do Azure.
Além do preço por hora do serviço de VPN, você também paga pelos dados transferidos pelos gateways da VPN. Para o Google Cloud e muitos CSPs, são aplicadas as cobranças padrão de transferência de dados da Internet, conforme detalhado em Transferir por endereços IP externos pela Internet. Em muitos casos, as cobranças pela transferência de dados excedem o custo fixo dessa solução.
Interconexão por parceiro com parceiros ativados por várias nuvens
A Interconexão por parceiro permite conectar uma nuvem privada virtual a outras redes virtuais de um CSP por meio da rede de parceiros selecionados que oferecem soluções diretas multicloud. Você se conecta implantando uma ou mais instâncias de roteamento virtual que se encarregam da configuração necessária do Border Gateway Protocol (BGP).
Veja no diagrama a seguir uma configuração redundante usando duas conexões da Interconexão por parceiro.
As rotas são trocadas entre o Cloud Router e o gateway no outro CSP por meio de uma instância de roteamento virtual gerenciado pelo parceiro que fornece a interconexão. O tráfego flui pela rede do parceiro entre o Google Cloud e o outro CSP.
Implementação
Esta solução requer a configuração de vários componentes:
- Com relação ao Google Cloud, configure a Interconexão por parceiro com um provedor de serviços de interconexão que atende às regiões do Google Cloud e oferece conectividade multicloud ao outro CSP.
- No outro CSP, use o produto de interconexão para se conectar ao mesmo parceiro. Por exemplo, na AWS, use a Conexão direta e, no Azure, use o ExpressRoute.
- Com relação ao parceiro do provedor de serviços, configure o equipamento de roteamento virtual que fornece as sessões do BGP ao Google Cloud e ao outro CSP.
Se o espaço de endereço IP entre os dois ambientes de CSP se sobrepor, o parceiro poderá oferecer funcionalidade NAT para o equipamento de roteamento virtual. Consulte a documentação dos parceiros para detalhes.
Velocidade de transferência e latência
Essa solução oferece capacidade dedicada entre o Google Cloud e outros CSPs. Dependendo do parceiro e do outro CSP, a capacidade de anexo disponível pode variar. Com relação ao Google Cloud, a interconexão por parceiro está disponível com uma capacidade de anexo entre 50 Mbps e 10 Gbps.
A latência para essa solução é a soma dos seguintes itens:
- Latência entre a região onde seus recursos estão hospedados no Google Cloud e o local de interconexão onde o parceiro se conecta ao Google Cloud.
- Latência na rede de parceiros para, de e por meio da instância de roteamento virtual em direção ao outro CSP.
- Latência do outro local de extremidade do CSP em que a interconexão com o parceiro ocorre na região onde os recursos estão hospedados no CSP.
Para a menor latência possível, os locais de extremidade do Google Cloud e do outro CSP devem estar na mesma área metropolitana, junto à instância de roteamento virtual. Por exemplo, a conexão poderá ser de baixa latência se as regiões de nuvem do CSP, bem como o POP da extremidade e a instância de roteamento virtual estiverem localizadas na área de Ashburn, Virgínia.
Embora o Google Cloud e muitos outros CSPs não ofereçam garantias de latência para o tráfego em direção à extremidade da rede, como há um caminho e uma capacidade dedicados por meio do parceiro, normalmente a latência nessa solução é menos variável do que se você usa endereços IP externos ou uma solução de VPN.
Segurança
O tráfego via Interconexão por parceiro não é criptografado por padrão. Para proteger o tráfego, implante a VPN de alta disponibilidade pelo Cloud Interconnectno lado do Google Cloud da conexão. Alguns outros CSPs permitem que você use o serviço de VPN gerenciado por meio de uma interconexão. Por exemplo, a VPN site a site da AWS pode ser usada no AWS Direct Interconnect. Também é possível usar um dispositivo virtual que criptografa o tráfego no outro CSP.
Outra opção é criptografar o tráfego na camada do aplicativo em vez de usar a VPN.
Confiabilidade e SLA
Essa solução envolve três SLAs diferentes: um do Google, um do parceiro de interconexão e um do outro CSP.
Ao usar a Interconexão por parceiro de forma redundante, o Google oferece SLAs mensais de 99,9% a 99,99%, dependendo da topologia escolhida. Não há SLA em uma única conexão de Partner Interconnect.
Consulte a documentação do outro CSP sobre o SLA no produto de interconexão. Por exemplo, SLA de conexão direta do AWS ou, no Azure, SLA para ExpressRoute.
Consulte a documentação ou os termos do provedor de serviços do Partner Interconnect do respectivo SLA para saber sobre a disponibilidade da conectividade e da instância de roteamento virtual. Por exemplo, consulte o contrato de serviços globais do Megaport.
Preços
Com relação ao Google Cloud, há uma taxa mensal para cada anexo da Interconexão por parceiro, dependendo da largura de banda. A saída de tráfego por meio da Interconexão por parceiro é cobrada a uma taxa menor que o tráfego da Internet. Para mais informações, consulte a página de preços do Partner Interconnect.
Consulte a página de preços do produto de interconexão do outro CSP, por exemplo, os preços de Conexão direta da AWS ou os preços do Azure ExpressRoute. Normalmente, os preços também têm uma taxa mensal para as tarifas de interconexão e transferência de dados por meio da interconexão a uma taxa menor que a da Internet.
O parceiro fornece cobranças de serviços de interconexão de acordo com os próprios preços, que podem ser encontrados no site ou consultando a equipe de vendas para uma cotação. Normalmente, se todas as transferências de dados ocorrerem na mesma área metropolitana, as cobranças serão muito menores do que se os dados tiverem que percorrer uma distância maior em uma rede parceira.
Quando os dados são transferidos regularmente em volumes suficientemente altos, dependendo dos preços de outros CSPs, essa solução pode às vezes oferecer o menor custo total devido às taxas de saída com desconto. Mesmo ao adicionar custos mensais para a interconexão do Partner Interconnect, o outro CSP e o parceiro do provedor de serviços, o uso dessa solução pode proporcionar uma economia significativa. Como os parceiros e os preços de outros CSPs podem ser alterados sem aviso prévio, faça sua própria comparação usando cotações atualizadas de todas as partes envolvidas.
Interconexão dedicada por meio de um POP comum
Ao usar um ou mais dispositivos de roteamento físico em uma instalação de interconexão comum entre o Google Cloud e o outro CSP, é possível conectar os dois provedores de nuvem usando a Interconexão dedicada no Google Cloud e um produto equivalente no outro CSP. O local da interconexão não está necessariamente no mesmo local da região onde os recursos estão localizados.
Veja no diagrama a seguir uma configuração redundante usando duas conexões de Interconexão dedicada:
As rotas são trocadas entre o Cloud Router e o gateway no outro CSP por meio de um roteador físico que você coloca em uma instalação comum de interconexão. O tráfego flui pelo roteador entre o Google Cloud e o outro CSP.
Implementação
Essa solução requer que você hospede e mantenha dispositivos de roteamento físico em uma instalação de colocation onde o Google e o CSP com os quais você quer se conectar estejam presentes. A partir desse dispositivo de roteamento, realize duas conexões físicas com a instalação: uma para o Google Cloud usando a Interconexão dedicada e outra para o outro provedor de serviços usando um produto equivalente, por exemplo, Conexão direta da AWS ou Azure ExpressRoute. No dispositivo de roteamento, o BGP precisa ser configurado para permitir trocas de rotas entre os dois ambientes de nuvem.
Verifique a lista de locais de instalação de colocation do Google Cloud e do outro CSP, por exemplo, locais de conexão direta da AWS ou locais de peering do Azure ExpressRoute, para identificar locais adequados para essa configuração.
Os intervalos de endereços IP entre as redes virtuais não podem se sobrepor, a menos que o dispositivo de roteamento físico seja capaz de executar NAT entre os ambientes ou que você restrinja algumas trocas de rota entre os ambientes.
Essa solução será eficaz se você usar a conectividade dedicada para também se conectar ao seu ambiente local, além da conexão com outro CSP.
Em outros casos, essa solução é complexa porque exige que você possua e mantenha equipamentos físicos, além de um contrato com uma instalação de colocation. Essa solução só será recomendável se pelo menos um dos itens a seguir for verdadeiro:
- Você já tem equipamentos em instalações adequadas para outra finalidade e um contrato existente com a instalação.
- Você transfere grandes quantidades de dados regularmente, por isso é uma opção econômica, ou você tem requisitos de largura de banda que os parceiros não podem atender.
Velocidade de transferência e latência
Essa solução oferece capacidade dedicada entre o Google Cloud e outro CSP. No Google Cloud, a Interconexão dedicada está disponível com o uso de uma ou várias conexões físicas de 10 ou 100 Gbps.
A latência para essa solução é uma soma dos seguintes itens:
- Latência entre a região onde seus recursos estão hospedados no Google Cloud e o local de interconexão em que você interage com o Google Cloud.
- Latência por meio da instalação e o equipamento físico, geralmente insignificante quando comparada com qualquer latência devido ao comprimento da fibra
- Latência do local de interconexão por meio da rede do outro CSP para a região em que os recursos são hospedados no CSP
Embora nenhuma garantia de latência seja oferecida, essa solução normalmente permite a menor latência e as maiores velocidades de transferência entre o Google Cloud e outros ambientes de nuvem em endereços IP privados.
Segurança
Por padrão, o tráfego via Interconexão dedicada não é criptografado. Para proteger o tráfego, implante a VPN de alta disponibilidade pelo Cloud Interconnect no lado da conexão do Google Cloud. Alguns outros CSPs permitem que você use o serviço de VPN gerenciado por meio de uma interconexão. Por exemplo, a VPN site a site da AWS pode ser usada no AWS Direct Interconnect. Como alternativa, você também pode usar um dispositivo virtual criptografando o tráfego no outro CSP.
Outra opção é criptografar o tráfego na camada do aplicativo em vez de usar a VPN.
Confiabilidade e SLA
Ao usar a Interconexão dedicada de forma redundante, o Google oferece SLAs mensais de 99,9% a 99,99%, dependendo da topologia escolhida. Não há SLA em uma única conexão de Interconexão dedicada.
Para mais informações, consulte a documentação do outro CSP para o SLA no produto de interconexão, por exemplo, SLA de conexão direta da AWS ou SLA do Azure para ExpressRoute.
A instalação de colocation ou o fornecedor de hardware do equipamento de roteamento físico também podem oferecer SLAs nos serviços deles.
Preços
Com relação ao Google Cloud, há uma taxa mensal para cada porta de Interconexão dedicada, bem como para cada anexo da VLAN que se conecta a um ambiente VPC. O tráfego que sai pela Interconexão dedicada é cobrado a uma taxa menor que o tráfego da Internet. Para mais informações, consulte a página de preços da Interconexão dedicada.
Consulte a página de preços do produto de interconexão do outro CSP, por exemplo, os preços de conexão direta da AWS ou os preços do Azure ExpressRoute. Normalmente, os preços também têm uma taxa mensal para as tarifas de interconexão e transferência de dados por meio da interconexão a uma taxa menor que a da Internet.
Além disso, é necessário incluir taxas nos serviços de instalação de colocation, fornecendo espaço, energia elétrica e conexões físicas para os dois ambientes de nuvem, bem como qualquer custo e contratos de serviço contínuos com o fornecedor do equipamento de roteamento físico. Se a conexão entre os dois CSPs não for possível na mesma instalação e a conectividade for necessária entre as instalações, o preço desses serviços poderá ser muito maior.
Conexões gerenciadas do Cloud Interconnect
É possível conectar suas redes VPC do Google Cloud a suas redes virtuais em outro CSP usando o conjunto de redes do Google. De certo modo, essa configuração funciona como a Interconexão por parceiro, mas com o SLA do Google abrangendo as redes do Google e as próprias interconexões.
O diagrama a seguir mostra uma configuração do Cloud Interconnect com o número mínimo de conexões.
As rotas são trocadas entre o Cloud Router e o gateway no outro CSP sobre a estrutura da rede do Google. O tráfego flui pelo tecido entre o Google Cloud e o outro CSP.
Implementação
Quando você compra o Cloud Interconnect, o Google provisiona uma conexão física dedicada entre a rede do Google e a de outro provedor de serviços de nuvem. É possível usar essa conexão para fazer peering da rede de nuvem privada virtual (VPC) do Google com a rede hospedada por um provedor de serviços em nuvem compatível.
Depois de provisionar a conexão, o Google será compatível com ela até o ponto em que ele atingir a rede do outro provedor de serviços de nuvem. O Google não garante o tempo de atividade do outro provedor de serviços de nuvem. No entanto, o Google continuará sendo o ponto de contato principal para o serviço completo e notificará você se precisar abrir um caso de suporte com o outro CSP.
Nesta solução, é necessário seguir o processo de configuração do outro CSP, incluindo a escolha de onde as duas redes serão interconectadas. Somente determinados CSPs são compatíveis.
Velocidade de transferência e latência
Essa solução oferece capacidade dedicada entre o Google Cloud e outro CSP. No lado do Google Cloud, a Interconexão dedicada está disponível usando um ou vários pares de conexões físicas de 10 Gbps ou 100 Gbps.
A latência para essa solução é uma soma dos seguintes itens:
- Latência entre a região em que seus recursos estão hospedados no Google Cloud e o local entre nuvens.
- Latência entre o local de borda do Google e o local de extremidade do outro CSP (geralmente na mesma instalação)
- Latência do outro local de borda do CSP em que o Cloud Cross-Cloud Interconnect é implantado na região em que os recursos estão hospedados no CSP.
Embora nenhuma garantia de latência seja oferecida, essa solução normalmente permite a menor latência e as maiores velocidades de transferência entre o Google Cloud e outros ambientes de nuvem em endereços IP privados.
Segurança
Como o tráfego no Cross-Cloud Interconnect não é criptografado, recomendamos o uso da criptografia da camada de aplicativos para tráfego confidencial.
Se todo o tráfego precisar ser criptografado, os dispositivos virtuais disponíveis dos parceiros do Google Cloud no Cloud Marketplace podem fornecer soluções para criptografia do tráfego para o ambiente do outro CSP.
Confiabilidade e SLA
O Cloud Interconnect usa o SLA do Cloud Interconnect. Para se qualificar para o SLA, a configuração do Cloud Interconnect precisa usar um ou mais pares de conexões, conforme descrito na seção Contrato de nível de serviço do Visão geral do Cloud Interconnect.
O SLA abrange tudo no Google até a borda da rede do outro provedor de nuvem. Não abrange a rede do outro CSP. Para mais informações, consulte a documentação do outro CSP para o SLA no produto de interconexão, por exemplo, SLA de conexão direta da AWS ou SLA do Azure para ExpressRoute.
Preços
Há uma taxa por hora para cada conexão do Cross-Cloud Interconnect, bem como para cada anexo da VLAN que se conecta a um ambiente VPC. O tráfego de saída por meio do Cross-Cloud Interconnect é cobrado a uma taxa menor que o tráfego da Internet. Para mais informações, consulte Visão geral do Cloud Interconnect.
Consulte a página de preços do produto de interconexão do outro CSP, por exemplo, os preços de conexão direta da AWS ou os preços do Azure ExpressRoute. Normalmente, há uma cobrança mensal para a interconexão. As cobranças pela transferência de dados por meio da interconexão geralmente são menores do que as da transferência de dados pela Internet.
Não há custos separados para locais de interconexão ou equipamentos.
Comparação de opções
As opções apresentadas variam em velocidade, disponibilidade, complexidade, segurança e preço. Avalie todas as opções cuidadosamente de acordo com suas necessidades.
O diagrama a seguir o guiará pelo processo de escolha de uma das soluções mencionadas neste documento usando um fluxograma simples.
Normalmente, recomendamos as seguintes opções:
- Para muitos cenários em que os dados são trocados de vez em quando ou com baixo volume e as transferências não são críticas, a transferência de dados pela Internet é a opção mais simples e ainda fornece latência relativamente baixa e alta largura de banda.
- Se a criptografia ou transferência de dados usando endereços IP particulares for necessária, considere usar o Cloud VPN e um serviço de VPN gerenciado no outro CSP.
- Se você transferir grandes quantidades de dados, o uso da Interconexão por parceiro com um parceiro ativado para várias nuvens oferece vários benefícios: capacidade dedicada, menor custo para transferências de dados e, dependendo da topologia, um SLA para cada parte da solução. A capacidade do Partner Interconnect normalmente é menor que 10 Gbps por conexão.
- Se você conectar seu equipamento local a várias nuvens, o uso de Interconexão dedicada por meio de um POP comum é uma opção comum. Ela é acompanhada de mais complexidade de gerenciamento do seu próprio hardware e relacionamentos com uma instalação de colocation. A menos que a infraestrutura já esteja em vigor, essa solução é reservada para casos em que as taxas de transferência de dados típicas são de 10 Gbps ou mais.
- Se você não quiser a sobrecarga de gerenciar conexões cruzadas e equipamentos de roteamento em POPs remotos, o Cross-Cloud Interconnect fornece uma solução gerenciada em que o Google cuida de tudo isso para você.
A seguir
- Analise a série de artigos sobre práticas e padrões híbridos e multicloud.
- Confira arquiteturas de referência, diagramas, tutoriais e práticas recomendadas do Google Cloud. Confira o Centro de arquitetura do Cloud.