Fundamentos de redes em nuvem

Uma aplicação em nuvem precisa de uma rede, além de computadores. Uma rede virtual é uma rede privada definida por software. Você escolhe seus endereços e conexões sem instalar switches ou cabos. Redes separadas podem manter o trabalho de produção isolado dos testes.

Leia os endereços

A AWS chama sua rede de Amazon VPC; a Microsoft usa Azure Virtual Network, ou VNet; o Google Cloud usa rede VPC. Uma VPC da AWS ou VNet do Azure tem uma faixa geral de endereços. Suas sub-redes obtêm faixas menores a partir dela. Uma VPC do Google Cloud não tem faixa geral: cada sub-rede recebe a sua.

A notação 10.0.0.0/16 é a notação CIDR. O número após a barra conta os bits iniciais fixos do endereço. Um número menor significa uma faixa maior. Esse /16 abrange de 10.0.0.0 a 10.0.255.255: 65.536 endereços. Os blocos privados são 10.0.0.0/8, 172.16.0.0/12 e 192.168.0.0/16. A internet pública não roteia esses endereços privados.

Uma sub-rede fornece endereços a uma parte de uma rede. Por exemplo, 10.0.3.0/24 abrange de 10.0.3.0 a 10.0.3.255. Um banco de dados nela poderia receber 10.0.3.20. Sub-redes separadas para web, aplicação e banco de dados permitem que as equipes apliquem rotas e regras de segurança diferentes. As faixas de sub-redes de uma mesma rede não podem se sobrepor. Os provedores reservam endereços para serviços de rede: AWS e Azure reservam cinco por sub-rede; o Google Cloud reserva quatro na faixa principal de uma sub-rede. Uma sub-rede de 256 endereços, portanto, deixa 251 endereços na AWS ou no Azure.

Distribua recursos entre zonas

Considere uma loja na AWS que usa 10.0.0.0/16. Na zona A, ela coloca servidores web em 10.0.1.0/24, servidores de aplicação em 10.0.2.0/24 e seu banco de dados em 10.0.3.0/24. Para continuar atendendo durante uma interrupção da zona, ela repete as camadas na zona B usando 10.0.11.0/24, 10.0.12.0/24 e 10.0.13.0/24. As sub-redes separam funções; o uso de duas zonas separa locais de falha. Criar várias sub-redes em uma única zona não faria isso.

Conecte redes de forma planejada

Redes virtuais fornecem isolamento lógico de outros clientes e outras redes. A comunicação exige um caminho de rede e permissão. Uma conexão de emparelhamento permite que duas redes se comuniquem por endereços privados pela rede do provedor. O emparelhamento pode cruzar regiões e limites de contas, assinaturas ou projetos, mas as faixas de endereços não podem se sobrepor.

Verifique as faixas de escritórios e parceiros antes de escolher faixas para a nuvem. Se um escritório e uma VPC usarem 10.0.0.0/16, um destino como 10.0.3.20 poderá pertencer a qualquer um dos lados. Escolher 10.1.0.0/16 para a nuvem evita esse conflito. Corrigir um plano de endereçamento após a implantação de servidores pode interrompê-los.

O emparelhamento não é transitivo. Se A estiver emparelhada com B e B com C, A ainda precisará de sua própria conexão com C. Além disso, um caminho privado não criptografa os dados: use criptografia para isso. A criação da rede virtual em si é gratuita nesses provedores; gateways, endereços IPv4 públicos e transferência de dados podem gerar cobranças.

Um endereço de destino informa à rede para onde o tráfego está tentando ir. Uma tabela de rotas informa o próximo lugar para onde enviá-lo. O roteamento fornece um caminho; as regras de segurança decidem se o tráfego pode usá-lo.

Escolha a rota correspondente

Cada rota associa uma faixa de destino a um alvo. Uma rota local conecta sub-redes dentro da mesma rede virtual. A rota padrão IPv4, 0.0.0.0/0, corresponde a todos os endereços, mas uma rota correspondente mais específica tem prioridade. Um número de prefixo maior após a barra indica uma faixa mais específica.

Suponha que uma sub-rede de aplicações da AWS use estas rotas:

Uma requisição de 10.0.2.15 para o banco de dados 10.0.3.20 corresponde às duas faixas. O /16 é mais específico que /0, portanto a requisição permanece local. Uma requisição ao servidor de atualização 203.0.113.50 corresponde apenas à rota padrão e vai para o gateway NAT. As regras de segurança devem permitir cada conexão.

Permita o acesso público de forma planejada

Na AWS, um gateway de internet conecta uma VPC à internet. Uma sub-rede com uma rota padrão para esse gateway é uma sub-rede pública. Sua faixa de endereços ainda pode ser privada, como 10.0.1.0/24. “Pública” descreve seu roteamento, não a notação de seus endereços.

Para acessar um servidor pela internet, três elementos devem estar presentes: um caminho para a internet, um endereço IP público no servidor ou em um balanceador de carga à sua frente e regras de segurança que permitam a conexão. Uma sub-rede da AWS pode ser pública enquanto um servidor específico nela não tem acesso público direto.

O Azure e o Google Cloud fornecem caminhos integrados para a internet sem um gateway de internet criado por você como na AWS. Suas regras de segurança e seu endereçamento público continuam sendo importantes. Uma sub-rede privada, no sentido geral, não oferece aos usuários da internet um caminho direto para seus recursos. Isso a torna útil para bancos de dados e servidores de aplicação internos.

Forneça acesso de saída a servidores privados

Um gateway NAT permite que um servidor privado inicie uma conexão com a internet. Ele substitui o endereço privado de origem por um endereço público, acompanha a conexão e entrega a resposta ao servidor correto. Ele não aceita uma nova conexão iniciada por um usuário da internet em direção a esse servidor privado.

Na AWS, um gateway NAT público fica em uma sub-rede pública. A rota padrão da aplicação privada aponta para ele, e a sub-rede do gateway NAT tem uma rota para o gateway de internet. A aplicação pode buscar atualizações enquanto sua sub-rede de banco de dados, que tem apenas uma rota local, não tem caminho para a internet. O Azure NAT Gateway é associado a uma sub-rede; o Google Cloud oferece o Cloud NAT. Serviços NAT geram cobranças pelo tempo de funcionamento e pelo processamento de dados.

Verifique as configurações padrão do provedor

As sub-redes da VPC padrão da AWS são públicas e normalmente atribuem endereços públicos a novas instâncias. Uma VPC criada por você precisa que um gateway de internet seja adicionado. Endereços públicos estáticos reservados permanecem iguais; a AWS chama um deles de Elastic IP. Endereços atribuídos automaticamente podem mudar depois que uma máquina é interrompida e iniciada novamente. Desde fevereiro de 2024, a AWS cobra por cada endereço IPv4 público, inclusive os que estão em uso.

O Azure usa “sub-rede privada” especificamente para uma sub-rede com acesso de saída padrão desativado. Ela precisa de um método de saída explícito, como NAT ou um IP público atribuído, e essa configuração, por si só, não bloqueia o tráfego de entrada. O portal cria sub-redes privadas por padrão. Para a versão da API lançada após 31 de março de 2026, novas redes virtuais também recebem sub-redes privadas por padrão; versões anteriores da API mantêm o comportamento antigo, e as redes existentes não são alteradas.

Um serviço gerenciado pode funcionar fora da sua rede virtual. Um ponto de extremidade é o endereço que os clientes usam para acessá-lo, geralmente por meio de um nome DNS. O caminho de rede do ponto de extremidade e as permissões de dados do serviço resolvem problemas diferentes.

Separe o alcance público do acesso aos dados

Um ponto de extremidade público é resolvido para um endereço IP público. Clientes na internet podem tentar se conectar, mas isso não torna públicos os dados armazenados. Credenciais e permissões normalmente controlam o acesso. Alguns serviços também permitem acesso anônimo quando configurados para isso; um erro de permissão no armazenamento de objetos pode expor arquivos.

Use HTTPS, que usa criptografia TLS, para o tráfego do serviço. Quando houver suporte, exija HTTPS e restrinja os endereços ou redes que podem se conectar. Acessibilidade pública, permissão de acesso e criptografia são configurações separadas. Uma aplicação autorizada pode usar um ponto de extremidade público com segurança, enquanto um serviço mal configurado ainda pode vazar dados em uma rede privada.

Adicione um endereço privado

Um ponto de extremidade privado dá a um serviço compatível um endereço privado dentro da sua rede. O provedor cria uma interface de rede em uma sub-rede, e o tráfego para esse endereço permanece na rede dele.

Sistemas de escritório também podem acessar pontos de extremidade privados por uma VPN ou conexão dedicada. Redes emparelhadas podem acessá-los quando as configurações de roteamento, DNS e segurança permitem o caminho.

Faça o nome do serviço encontrar o ponto de extremidade

Aplicações geralmente se conectam usando um nome de serviço, não um endereço IP fixo no código. O DNS privado faz esse nome ser resolvido para o endereço privado do ponto de extremidade dentro da rede. Por exemplo, um cliente interno pode resolver o nome de seu serviço de armazenamento para 10.0.2.40. Clientes externos ainda podem receber o endereço público.

Criar o ponto de extremidade, por si só, não altera a resposta DNS de todos os clientes. Se um cliente interno continuar resolvendo o endereço público, ele continuará usando o caminho público. Vincule a zona DNS privada à rede e forneça encaminhamento de DNS para clientes nas instalações da organização. Para exigir acesso privado, desative ou restrinja também o ponto de extremidade público do serviço. Criar um ponto de extremidade privado mantém as configurações de acesso público existentes.

Reconheça opções relacionadas

Um ponto de extremidade de gateway da AWS acessa o S3 ou o DynamoDB por uma entrada na tabela de rotas. Ele não cria a interface de rede privada usada por um ponto de extremidade de interface e não gera cobrança adicional pelo ponto de extremidade. Um ponto de extremidade de serviço do Azure identifica uma sub-rede permitida e transporta seu tráfego para o serviço pela rede da Microsoft, mas o serviço ainda tem um endereço IP público. O Private Google Access permite que máquinas com endereços internos acessem APIs e serviços do Google.

Considere um servidor de análise de dados que lê 500 GB de armazenamento de objetos regional por dia. Enviar essas leituras por NAT faz o serviço NAT processar todos os 500 GB. Na AWS, um ponto de extremidade de gateway do S3 adequado encaminha esse tráfego de serviço pela rota do ponto de extremidade sem tarifa adicional pelo ponto de extremidade de gateway. Pontos de extremidade de interface e privados têm suas próprias tarifas, portanto compare o caminho completo e suas cobranças. O ponto de extremidade altera a conectividade; o TLS continua fornecendo criptografia em trânsito.

Um servidor pode ter uma rota para outra rede e ainda rejeitar seu tráfego. Um grupo de segurança atua como um firewall virtual para recursos. Regras de entrada controlam o tráfego que chega a um recurso; regras de saída controlam o tráfego que sai dele.

Leia uma regra

Para TCP ou UDP, leia o protocolo, a porta e a origem ou o destino em conjunto. A regra “permitir TCP 443 de 198.51.100.7/32” permite tráfego HTTPS de um endereço. A origem 0.0.0.0/0 significa todos os endereços IPv4. Uma origem de entrada também pode identificar um grupo de segurança, de modo que o acesso acompanhe a função de um servidor quando seu endereço IP muda.

Portas úteis incluem SSH 22, RDP 3389, HTTP 80, HTTPS 443, DNS 53, MySQL 3306, PostgreSQL 5432 e Microsoft SQL Server 1433. O ICMP, usado pelo ping, tem tipos de mensagem em vez de portas TCP ou UDP.

Entenda a filtragem com estado

Um filtro com estado registra as conexões permitidas. Se uma regra de entrada permite uma nova conexão HTTPS, as respostas podem sair sem uma regra de saída separada para elas. Isso não permite que o servidor inicie qualquer conexão de saída não relacionada. Novas conexões ainda precisam de sua própria permissão.

Grupos de segurança da AWS são associados a interfaces de rede. Vários recursos podem compartilhar um grupo, e um recurso pode ter vários grupos. Suas regras de permissão são combinadas: o tráfego passa se uma regra aplicável o permitir. A ordem das regras não tem efeito, e não há regra de negação explícita para se sobrepor a uma permissão ampla. Um grupo recém-criado não permite tráfego de entrada e permite tráfego de saída até ser alterado.

Crie uma cadeia de funções permitidas

Para uma aplicação de três camadas, conceda a cada camada apenas as conexões de entrada necessárias:

1. O balanceador de carga permite TCP 443 de usuários da internet.
2. Os servidores web permitem TCP 443 do grupo do balanceador de carga. A administração por TCP 22 é limitada ao endereço do escritório do administrador.
3. O banco de dados MySQL permite TCP 3306 do grupo dos servidores web.

Quando um servidor web substituto entra no grupo dos servidores web, ele recebe o acesso pretendido ao banco de dados sem uma nova regra baseada em endereço. Uma requisição direta da internet ao banco de dados falha porque sua origem não é permitida. Se um segundo grupo associado permitir amplamente a mesma porta do banco de dados, porém, a permissão ampla continua valendo; não há uma negação mais restrita no primeiro grupo que a cancele.

Compare filtros dos provedores

Um grupo de segurança de rede do Azure, ou NSG, pode ser associado a uma sub-rede, a uma interface de rede ou a ambas. As prioridades personalizadas vão de 100 a 4096, antes das regras padrão integradas em 65000, 65001 e 65500. As regras padrão de entrada permitem tráfego da rede virtual e do balanceador de carga do Azure e depois negam outros tráfegos de entrada. O Google Cloud seleciona máquinas de destino usando etiquetas ou contas de serviço; suas regras implícitas negam tráfego de entrada e permitem tráfego de saída.

Aplique o privilégio mínimo: permita apenas as portas necessárias para o menor conjunto útil de origens. Abrir SSH ou RDP para toda a internet expõe serviços de logon administrativo a ataques automatizados. As opções de acesso gerenciado incluem AWS Systems Manager Session Manager, Azure Bastion e Google Cloud Identity-Aware Proxy. Um filtro de portas não consegue reconhecer um ataque oculto em tráfego HTTPS permitido; defesas da aplicação e controles de logon protegem essa camada.

Uma lista de controle de acesso à rede da AWS, ou ACL de rede, filtra o tráfego que cruza o limite de uma sub-rede. Ela se aplica a todos os recursos nessa sub-rede. Cada sub-rede tem uma ACL de rede, e a mesma ACL pode atender a várias sub-redes.

Siga a primeira regra correspondente

Regras de ACL de rede podem permitir ou negar tráfego. A AWS as verifica a partir do menor número de regra e para na primeira correspondência. Uma regra final * nega o tráfego que não correspondeu a nenhuma regra. A ACL padrão da VPC permite tráfego de entrada e saída; uma ACL personalizada recém-criada nega tráfego até que você adicione regras de permissão.

Suponha que a regra 100 permita TCP 443 de todos os endereços IPv4, enquanto a regra 110 negue tráfego de 203.0.113.0/24. Uma requisição de 203.0.113.77 para a porta 443 corresponde primeiro à regra 100 e passa. A negação posterior nunca é aplicada. Mova essa negação para a regra 90 para bloquear a faixa antes da permissão ampla de HTTPS.

Acompanhe a resposta como um pacote separado

Uma ACL não tem estado: ela não registra que uma conexão foi permitida. Uma requisição web usa a porta de destino 443 do servidor, mas a resposta retorna à porta temporária, ou efêmera, do cliente. Ela pode ter um número alto, como 50432.

Para um site com uma rota e um grupo de segurança funcionando:

1. Um cliente envia uma requisição de sua porta temporária para a porta 443 do servidor.
2. A ACL da sub-rede admite o pacote de entrada usando sua regra de HTTPS.
3. O servidor responde à porta temporária do cliente.
4. A ACL de saída verifica essa porta de destino de forma independente.

Uma regra de saída que permite apenas a porta de destino 443 não cobre essa resposta. A resposta precisa de uma permissão de saída que cubra sua porta de destino; TCP 1024–65535 é uma faixa ampla de portas efêmeras comumente usada. A faixa necessária depende dos clientes e do tráfego atendidos. A permissão de um grupo de segurança com estado não dispensa a decisão separada da ACL.

Compare as duas camadas da AWS

O tráfego de entrada da internet deve passar pelas duas camadas. O tráfego entre dois recursos na mesma sub-rede não cruza o limite da sub-rede, portanto a ACL dessa sub-rede não o filtra. Os grupos de segurança dos recursos continuam sendo aplicados.

Use camadas independentes

A defesa em profundidade limita os danos de uma configuração incorreta. Grupos de segurança dão a cada função da aplicação permissões precisas. ACLs adicionam controles de proteção para toda a sub-rede, como negar uma faixa reconhecidamente maliciosa. Firewalls de sistema operacional, firewalls de rede gerenciados, firewalls de aplicações web, TLS e verificações de identidade protegem outras partes do caminho. Registros de fluxo registram fluxos de rede permitidos e rejeitados; o Amazon Inspector ajuda a identificar vulnerabilidades e exposição não intencional de cargas de trabalho.

O Azure não tem uma ACL de rede separada como a da AWS: NSGs de sub-rede e de interface fornecem essas camadas, e ambos têm estado. Para o tráfego de entrada no Azure, o NSG da sub-rede e depois o NSG da interface devem permiti-lo. O Google Cloud usa regras de firewall de VPC com estado e políticas de firewall mais abrangentes, incluindo políticas de organização e de pasta.

As pessoas lembram nomes como www.example.com; os computadores enviam tráfego para endereços IP. O DNS, Sistema de Nomes de Domínio, conecta os dois. Provedores de nuvem hospedam registros pelo Amazon Route 53, Azure DNS e Google Cloud DNS.

Acompanhe uma consulta de nome

Um cliente solicita um endereço a um resolvedor. Se o resolvedor não tiver uma resposta em cache, ele pergunta a um servidor raiz onde encontrar os servidores de .com. Esses servidores identificam os servidores de nomes autoritativos do domínio. Um servidor autoritativo contém os registros do domínio e retorna a resposta, que o resolvedor armazena em cache para clientes posteriores. O Route 53 atribui quatro servidores de nomes autoritativos a uma zona hospedada pública. O cliente então se conecta ao endereço retornado. O DNS não transporta o tráfego da aplicação do site.

Uma zona é o conjunto gerenciado de registros de um domínio. Para usar a zona pública de um novo provedor, configure os servidores de nomes desse provedor no registrador do domínio. Hospedagem de zonas e registro de domínios são serviços separados: o Route 53 oferece ambos, enquanto o Azure DNS hospeda zonas sem vender registros de domínio.

Escolha o registro

O ápice da zona é o domínio sem prefixo, como example.com. Um CNAME padrão não pode ficar ali porque o ápice também precisa de registros NS e SOA. Registros de alias do Route 53 e conjuntos de registros de alias do Azure podem apontar registros compatíveis no ápice para recursos de nuvem e acompanhar mudanças em seus endereços.

Considere as respostas em cache

O TTL, ou tempo de vida, de um registro indica por quantos segundos um resolvedor pode armazenar a resposta em cache. Suponha que um resolvedor armazene em cache uma resposta de 3.600 segundos às 9:55. Alterar o registro às 10:00 não apaga essa cópia: ela pode continuar válida até as 10:55. Reduza um TTL para 300 segundos pelo menos um TTL antigo antes de uma mudança planejada, para que as cópias antigas de longa duração tenham tempo de expirar. Reduzi-lo no instante da mudança não pode encurtar a duração das cópias já armazenadas em cache.

Políticas de roteamento DNS influenciam as respostas às consultas. O roteamento simples fornece uma resposta direta. O roteamento ponderado fornece respostas nas proporções escolhidas, como 90% para a versão atual e 10% para uma nova versão; o roteamento por latência favorece a menor latência medida; o roteamento por geolocalização seleciona pela localização do usuário; o roteamento de failover muda de um ponto principal para um em espera quando verificações de integridade indicam uma falha. Cada verificador de integridade do Route 53 normalmente envia uma verificação a cada 30 segundos. O Azure Traffic Manager e o Google Cloud DNS também oferecem opções de roteamento baseado em DNS.

Em uma loja com um ponto principal em Frankfurt e um em espera na Irlanda, uma falha na verificação de integridade do principal faz as novas respostas apontarem para o ponto em espera. As respostas já armazenadas em cache continuam válidas até expirarem; um TTL curto, como 60 segundos, reduz esse atraso. Da mesma forma, o roteamento ponderado distribui respostas DNS, não quantidades exatas de usuários ou requisições da aplicação: uma resposta em cache pode atender a muitos usuários. Um balanceador de carga atua sobre o tráfego de entrada em outra camada.

Resolva nomes internos

Uma zona DNS privada fornece respostas às redes virtuais vinculadas. Ela pode associar db.internal.example.com a um endereço privado de banco de dados ou direcionar um nome de serviço a um ponto de extremidade privado. Clientes nas instalações da organização precisam de um caminho adequado de encaminhamento de DNS pela VPN ou conexão dedicada, usando opções como pontos de extremidade do Route 53 Resolver ou Azure DNS Private Resolver. Um túnel de rede em funcionamento, por si só, não informa a um resolvedor do escritório onde consultar os nomes privados da nuvem.

O Route 53 e o Azure DNS publicam SLAs de 100% de disponibilidade para seus serviços de DNS. Um SLA é um compromisso contratual de serviço; uma resposta em cache ainda pode apontar para um servidor de aplicação indisponível.

Uma rede de distribuição de conteúdo, ou CDN, mantém cópias temporárias de conteúdo perto dos usuários. Sua origem contém os arquivos originais ou produz as respostas da aplicação. Amazon CloudFront, Azure Front Door e Google Cloud CDN fornecem esse serviço por meio de locais de borda em todo o mundo.

Acompanhe uma requisição

O navegador resolve o nome da CDN e se conecta a um local de borda próximo. O CloudFront pode direcionar usuários com respostas DNS; o Azure Front Door e o Google Cloud CDN usam endereçamento anycast, no qual vários locais anunciam o mesmo endereço IP e o roteamento leva os usuários a um local próximo. Um local de borda não é uma região de nuvem completa, e os provedores operam muito mais locais de borda do que regiões.

Um acerto de cache ocorre quando a borda tem uma cópia atualizada e utilizável e a fornece. Em uma falha de cache, a borda busca o conteúdo na origem, entrega-o e pode armazená-lo em cache para requisições posteriores. Imagens, scripts, folhas de estilo, downloads e vídeos costumam ser adequados porque muitos usuários solicitam o mesmo conteúdo.

Meça o benefício

Requisições a longa distância levam mais tempo em cada ida e volta pela rede. Uma página visualizada de Sydney precisa de quatro idas e voltas sequenciais até sua origem em Frankfurt. A 250 ms por percurso de ida e volta, ela passa 1.000 ms aguardando esses percursos. Com uma borda em Sydney que leva 15 ms por percurso de ida e volta, os quatro percursos levam 60 ms. Este exemplo mede o atraso das idas e voltas, não o tempo completo de carregamento da página.

A taxa de acertos de cache é:

Com 9.200 acertos em 10.000 requisições, a taxa é de 92%. Neste exemplo simples, as 800 falhas chegam à origem. Uma taxa de acertos alta reduz o trabalho da origem e os dados que ela envia, o que ajuda durante um aumento repentino de visitantes.

Controle a atualização do conteúdo

O TTL de uma CDN controla por quanto tempo o conteúdo pode ser reutilizado. A origem pode enviar Cache-Control: max-age=86400, permitindo um dia de armazenamento em cache, ou as configurações da CDN podem controlar a duração. Alterar um arquivo na origem não substitui imediatamente as cópias atualizadas em cache.

Para publicar uma correção urgente, invalide ou remova o caminho em cache. Outra abordagem é publicar um novo nome de arquivo, como app.v2.js, e atualizar a página para solicitá-lo. O novo nome identifica um objeto diferente. Impeça que páginas personalizadas, como uma página de conta ou um carrinho de compras, sejam compartilhadas como conteúdo público em cache. Mesmo quando uma resposta não pode ser armazenada em cache, a borda pode melhorar a entrega ao encerrar o TLS em um local próximo e reutilizar conexões com a origem.

Diferencie o cache de outros serviços de rede

Balanceadores de carga podem ser regionais ou globais. O Global Accelerator fornece endereços anycast fixos e pode ser adequado para tráfego de jogos ou voz que não se beneficia do armazenamento em cache de conteúdo web.

A borda também pode aplicar certificados HTTPS e regras de firewall de aplicações web. Sua ampla rede absorve muitos ataques DDoS; o CloudFront inclui o AWS Shield Standard. Restrições na origem, como o controle de acesso à origem do CloudFront para S3, podem impedir que usuários contornem a CDN. As cobranças dependem principalmente dos dados entregues e da quantidade de requisições. Usuários que já estão perto da origem, ou aplicações com respostas quase inteiramente únicas, se beneficiam menos do cache. As cópias na borda são temporárias e podem ser removidas, portanto a origem ainda precisa de armazenamento confiável e cópia de segurança próprios.

Um escritório pode precisar usar uma aplicação em um endereço privado na nuvem. Uma rede híbrida conecta redes nas instalações da organização a redes em nuvem. Uma VPN, ou rede privada virtual, transporta esse tráfego em um túnel criptografado pela internet pública.

Escolha o que se conecta

Uma VPN entre sites conecta toda a rede de um escritório ou centro de dados. Um roteador ou firewall compatível com VPN gerencia o túnel para esse local. Uma VPN entre cliente e site, ou VPN de cliente, conecta um dispositivo individual que executa um software cliente. O AWS Client VPN e as conexões entre cliente e site do Azure VPN Gateway atendem a usuários remotos.

VPNs entre sites usam IPsec. As extremidades do túnel autenticam uma à outra, geralmente usando uma chave compartilhada ou certificados. O IKE, troca de chaves pela internet, define as chaves de criptografia; o IPsec então protege os pacotes pelo túnel. Uma VPN usa um caminho compartilhado pela internet, embora seu conteúdo seja criptografado.

Identifique as duas extremidades

Na AWS, um gateway privado virtual é associado a uma VPC; um gateway de trânsito pode atender a várias VPCs. O Azure implanta seu gateway de VPN em uma sub-rede dedicada chamada GatewaySubnet. O Google Cloud oferece gateways HA VPN. No escritório, um roteador ou firewall com endereço público fornece a outra extremidade; a AWS o chama de dispositivo de gateway do cliente.

Os gateways também precisam de rotas. Elas podem ser configuradas estaticamente ou aprendidas com BGP, protocolo de roteamento entre sistemas autônomos. O BGP permite que roteadores troquem as faixas de endereços que conseguem acessar. Um túnel criptografado sem as rotas corretas não fornece à aplicação um caminho utilizável de ponta a ponta.

Acompanhe uma requisição privada

Considere um escritório que usa 192.168.10.0/24 e uma VPC da AWS que usa 10.0.0.0/16:

1. A equipe cria o gateway na nuvem e configura o roteador do escritório para a VPN.
2. A rota do escritório para 10.0.0.0/16 aponta para o túnel.
3. A rota da nuvem para 192.168.10.0/24 aponta de volta pelo gateway de VPN.
4. O grupo de segurança da aplicação permite o tráfego necessário do escritório.

O dispositivo do escritório 192.168.10.25 agora pode se conectar à aplicação 10.0.2.15. Seu tráfego é criptografado entre as extremidades da VPN. As faixas que não se sobrepõem permitem que cada lado diferencie destinos locais de remotos. Nomes de serviços privados precisam também de encaminhamento de DNS; o túnel não o configura automaticamente.

Elimine pontos únicos de falha

Uma conexão AWS Site-to-Site VPN fornece dois túneis para pontos de extremidade diferentes da AWS. Configure ambos para que um possa transportar tráfego durante manutenção ou falha. O Azure oferece suporte a gateways ativo-ativo. O Google Cloud HA VPN pode fornecer um SLA de disponibilidade de 99,99% com a configuração redundante de túneis exigida nas duas interfaces. Um segundo roteador no escritório e um segundo provedor de internet protegem contra falhas que dois túneis apenas no lado da nuvem não conseguem resolver.

VPNs geralmente podem ser configuradas em horas usando o acesso à internet existente. Os custos incluem principalmente tempo de conexão e transferência de dados. O congestionamento da internet e a distância afetam a latência e a vazão; um túnel padrão da AWS oferece suporte a até 1,25 Gbps, não uma taxa sustentada de transferência garantida. Uma VPN costuma fornecer acesso inicial enquanto um circuito dedicado é instalado e depois permanece como caminho de contingência criptografado. Um site público já destinado a usuários da internet não precisa de uma VPN entre sites para esses visitantes.

Algumas organizações precisam de uma conexão com a nuvem que ofereça desempenho mais estável que um caminho pela internet. Uma conexão privada dedicada liga a rede da organização ao provedor sem passar pela internet pública. Os serviços são AWS Direct Connect, Azure ExpressRoute e Google Cloud Interconnect.

Acompanhe o caminho físico

Provedores de nuvem se encontram com clientes e redes de telecomunicações em centros de dados de colocation, onde muitas redes têm equipamentos. Se o roteador do cliente já estiver lá, uma interconexão física, um cabo físico curto, liga-o ao equipamento do provedor. Caso contrário, um parceiro de telecomunicações ou conectividade estende um circuito do escritório ou centro de dados até esse ponto de encontro.

Contratar a porta no lado da nuvem não elimina a necessidade de chegar a esse centro de dados. A instalação pode envolver uma carta de autorização, uma solicitação de interconexão física, um circuito de telecomunicações e testes coordenados. Conte com semanas de preparação. As cobranças podem incluir a porta, o serviço do parceiro, o circuito de telecomunicações e os dados transferidos.

Escolha o serviço conforme a capacidade

Uma porta dedicada é oferecida em grandes capacidades fixas. O AWS Direct Connect oferece conexões dedicadas de 1, 10, 100 e 400 Gbps. Opções fornecidas por parceiros, como conexões hospedadas da AWS e Google Partner Interconnect, oferecem incrementos menores de capacidade, a partir de cerca de 50 Mbps. O ExpressRoute geralmente é fornecido por um provedor de conectividade.

Uma conexão hospedada de 50 Mbps tem menos capacidade que um túnel VPN padrão da AWS com limite de 1,25 Gbps. A palavra “dedicada” descreve o arranjo de conectividade; ela não é uma promessa de superar toda VPN em largura de banda. Compare a capacidade realmente contratada e a vazão medida.

Separe privacidade de criptografia

Evitar a internet compartilhada melhora a estabilidade do desempenho e fornece um caminho privado. Circuitos de alta capacidade atendem a grandes transferências regulares, e caminhos privados podem cumprir requisitos de que o tráfego permaneça fora da internet pública. A transferência de dados de saída da AWS pelo Direct Connect também tem tarifas por gigabyte menores que a transferência de saída pela internet, embora os custos fixos do circuito continuem sendo importantes.

Um circuito privado não é criptografado por padrão. Se a confidencialidade exigir criptografia, escolha um método adequado: TLS nas aplicações, uma VPN IPsec sobre a conexão privada ou MACsec em portas dedicadas compatíveis. O TLS protege sessões de aplicação; o IPsec protege o tráfego IP no túnel; o MACsec criptografa quadros em conexões compatíveis. Um requisito de usar um caminho privado e um requisito de criptografar o tráfego devem ser atendidos separadamente.

Planeje para uma falha de conexão

Um circuito físico pode falhar por causa de um cabo cortado, falha de roteador ou interrupção no centro de dados. Um circuito ExpressRoute tem duas conexões com dois roteadores de borda da Microsoft, mas cargas de trabalho críticas ainda se beneficiam de conexões por dois locais. Duas conexões pelo mesmo centro de dados mantêm esse centro como ponto de falha compartilhado.

Uma VPN entre sites pode fornecer uma alternativa de contingência de menor custo se a conexão privada falhar. Suas rotas e permissões devem estar prontas, e sua vazão menor ou mais variável deve ser suficiente para o tráfego essencial. O caminho pela internet da conexão de contingência pode não atender a um requisito rigoroso de que o tráfego permaneça sempre fora da internet; tanto os requisitos de disponibilidade quanto os de caminho afetam a escolha.

Conexões dedicadas acessam recursos de redes virtuais por endereçamento privado. Com configuração adicional, elas também podem acessar serviços públicos de nuvem compatíveis, como por meio de uma interface virtual pública da AWS ou do emparelhamento Microsoft do ExpressRoute. Elas são conexões de rede com a nuvem; os servidores existentes da organização permanecem onde estão.

A escolha de uma conexão começa pelo trabalho ao qual ela deve dar suporte. Identifique quem precisa de acesso, quantos dados são transferidos, o prazo, a estabilidade necessária, a data de instalação, os requisitos de segurança e o efeito de uma interrupção. Respostas diferentes levam a conexões diferentes.

Restrinja as opções

Uma empresa com 40 funcionários no escritório e prazo para a próxima semana pode começar com uma VPN entre sites. Para 300 funcionários trabalhando separadamente de casa, uma VPN de cliente dá a cada dispositivo acesso a ferramentas internas. Um banco que transfere terabytes diariamente pode justificar conexões dedicadas em locais distintos e criptografia. Uma fabricante que aguarda um circuito pode usar uma VPN inicialmente e mantê-la como contingência.

Verifique a janela de transferência

Largura de banda é a capacidade da conexão; vazão é a taxa realmente atingida. Latência é o atraso de um percurso. Uma conexão de grande capacidade pode transferir um arquivo grande rapidamente, enquanto uma longa distância ainda torna cada ida e volta demorada.

Use unidades decimais de dados: 1 GB é um bilhão de bytes e 1 TB é um trilhão de bytes. Cada byte contém 8 bits. Mantenha a quantidade de dados e a taxa em unidades de bits compatíveis:

Uma cópia de segurança de 2 TB contém 16 trilhões de bits. Com uma vazão efetiva de 500 Mbps, divida por 500 milhões de bits por segundo para obter 32.000 segundos, cerca de 8,9 horas. Isso ultrapassa uma janela de 8 horas. Com 10 Gbps sustentados, o cálculo resulta em 1.600 segundos, cerca de 27 minutos. Use a vazão efetiva para uma estimativa prática; a velocidade anunciada de uma porta, por si só, não considera a sobrecarga de protocolos, a disputa por recursos ou um disco de origem lento.

Para uma migração única excepcionalmente grande, uma rede pode demorar demais mesmo quando totalmente utilizada. Enviar 500 TB por 1 Gbps leva 4.000.000 de segundos, cerca de 46 dias. Serviços de transferência física, como o Azure Data Box, podem transferir grandes volumes de dados pelo envio de um dispositivo carregado. Compare todo o cronograma de migração, não apenas a transferência pela rede.

Verifique a segurança e o comportamento em falhas

Uma VPN fornece transporte criptografado pela internet. Uma conexão dedicada fornece um caminho privado e precisa de criptografia adicional quando exigida. Um requisito que inclua as duas propriedades exige os dois controles. Se uma conexão dedicada falhar, uma VPN de contingência restabelece um caminho, mas pode não transferir os mesmos dados dentro da janela original. Decida quais aplicações devem continuar funcionando e o que a conexão de contingência pode transportar.

Qualquer que seja o transporte, verifique faixas de endereços que não se sobreponham, rotas nos dois sentidos, permissões de firewall dos recursos e encaminhamento de DNS para nomes privados. Um circuito maior não resolve um conflito de endereços nem uma rota de retorno ausente. Da mesma forma, um túnel em funcionamento não faz um nome privado ser resolvido sem o caminho adequado até o resolvedor.

Para a decisão final, relacione cada escolha a uma necessidade declarada. “VPN porque o escritório precisa de acesso privado amanhã e o tráfego é moderado” é uma explicação útil. “Dedicada porque é mais rápida” deixa de considerar a capacidade contratada, a janela de transferência, o prazo de instalação e o plano para falhas.