Infraestrutura global de nuvem e organização de recursos

Uma região é uma área geográfica onde um provedor oferece serviços de nuvem a partir de um grupo de centros de dados. A escolha de uma região coloca a maioria dos recursos, como um banco de dados, nessa área. As regiões são projetadas para operar de forma independente, o que ajuda a conter falhas regionais.

Identifique a localização corretamente

AWS, Microsoft Azure e Google Cloud usam nomes diferentes para locais semelhantes. Um nome de exibição ajuda as pessoas a reconhecer um lugar; um código o identifica em comandos e modelos.

Um nome sozinho pode enganar. A região West Europe do Azure (westeurope) fica nos Países Baixos; North Europe fica na Irlanda. A região europe-west4 do Google Cloud fica nos Países Baixos, enquanto europe-west1 fica na Bélgica. A região Europe (Frankfurt) da AWS usa eu-central-1. Para atender a um requisito de país, verifique a localização física documentada.

Os provedores operam várias dezenas de regiões nas Américas, Europa, Ásia-Pacífico, Oriente Médio e África. Sua presença continua crescendo. Um mapa de infraestrutura atualizado é mais útil para decidir uma localização do que uma quantidade de regiões memorizada.

Separe localização de escopo

O escopo de um recurso descreve a área à qual ele pertence ou que pode atender.

A classificação regional, por si só, diz pouco sobre a proteção contra falhas. Um recurso regional pode ser acessível de várias zonas, mas depender de infraestrutura em uma só. Verifique sua configuração de redundância para saber se ele resiste a uma interrupção de zona.

A localização também exige uma verificação do fluxo de dados. Um banco de dados pode funcionar na região escolhida enquanto um recurso de cópia de segurança ou replicação copia seus dados para outro lugar. O armazenamento com redundância geográfica do Azure é um exemplo. Verifique para onde vão os dados primários, as cópias de segurança e as réplicas antes de considerar a região um limite completo de residência de dados.

Verifique o que a região oferece

Listas de serviços e preços variam por região. Confirme se o recurso de banco de dados, o tamanho de máquina e as opções de resiliência necessários estão disponíveis. Uma conta também pode precisar ter o acesso ativado: regiões da AWS introduzidas após 20 de março de 2019 ficam desativadas por padrão, e algumas regiões do Azure têm acesso restrito.

Suponha que uma máquina tenha sido criada em eu-west-1, mas uma lista de recursos da AWS esteja mostrando us-east-1. A lista vazia não significa que a máquina foi excluída. Mude para a região de criação e verifique a conta selecionada e os filtros. Mudar a visualização deixa a máquina em funcionamento e as cobranças continuam.

Uma zona de disponibilidade é um grupo isolado de um ou mais centros de dados dentro de uma região. Sua energia, refrigeração e rede são independentes das outras zonas. AWS e Azure a chamam de zona de disponibilidade; o Google Cloud a chama de zona.

Entenda as camadas físicas

Um centro de dados é um edifício que contém servidores e equipamentos de suporte. Uma zona pode usar vários desses edifícios, e uma região agrupa zonas. Tratar uma zona como exatamente um edifício dá uma imagem errada dos limites de falha do provedor.

As zonas ficam distantes o suficiente para reduzir a exposição conjunta a um incêndio local, problema de energia ou inundação, mas próximas o suficiente para uma comunicação rápida. A AWS coloca zonas a aproximadamente 100 km umas das outras; o Azure as descreve como geralmente situadas a até 100 km e busca comunicação de ida e volta em menos de cerca de 2 ms. Conexões rápidas tornam a replicação síncrona viável: uma gravação só é confirmada depois que as cópias necessárias são armazenadas entre zonas.

Um grande evento regional ainda pode afetar várias zonas. Várias zonas oferecem proteção contra a falha de uma zona; uma segunda região oferece um local separado para recuperação regional.

Interprete os identificadores de zona

A AWS acrescenta uma letra ao código de uma região, como em eu-central-1a. O Google Cloud acrescenta um hífen e uma letra, como em europe-west4-a. O Azure usa números de zonas lógicas, como 1, 2 e 3.

Nomes iguais entre clientes podem enganar. A zona 1 do Azure pode corresponder a zonas físicas diferentes em assinaturas diferentes. A AWS mapeou nomes de forma independente em suas regiões mais antigas para contas criadas antes de novembro de 2025; contas mais recentes usam mapeamento consistente. Um AZ ID da AWS, como euc1-az1, identifica a mesma zona física entre contas. Equipes que coordenam o posicionamento físico comparam AZ IDs ou mapeamentos documentados de zonas físicas.

A AWS informa que toda região tem pelo menos três zonas. Muitas regiões do Azure têm três, mas algumas não têm nenhuma. As regiões do Google Cloud têm várias zonas. Verifique em conjunto a região selecionada e o suporte do serviço a zonas.

Escolha a proteção necessária

O Azure Storage ilustra por que a quantidade de cópias, por si só, não basta. O LRS mantém três cópias locais em um centro de dados. O ZRS distribui cópias entre três zonas. O GRS acrescenta uma cópia em uma segunda região para recuperação. Três cópias em um edifício ainda compartilham os riscos desse edifício; a distribuição em três zonas elimina essa dependência específica.

Os provedores escalonam atualizações entre zonas para limitar os efeitos de uma alteração defeituosa. As cópias também podem gerar custos de transferência: em outubro de 2026, AWS e Google Cloud cobram por muitas transferências entre zonas, enquanto o Azure não cobra por transferências entre zonas na mesma região. A precificação específica de cada serviço ainda importa ao comparar um projeto completo.

Um local de borda, ou ponto de presença (PoP), aproxima serviços selecionados dos usuários. Esses locais oferecem cache e pontos de entrada na rede. Eles não oferecem o amplo catálogo de computação e bancos de dados de uma região. Os provedores têm centenas de locais de borda, distribuídos mais amplamente que suas regiões.

Acompanhe uma requisição por uma CDN

Uma rede de distribuição de conteúdo (CDN) armazena cópias reutilizáveis perto dos leitores. Amazon CloudFront, Azure Front Door e Google Cloud CDN são exemplos.

1. O roteamento envia a requisição para um local de borda adequado. O CloudFront usa seleção baseada em DNS; outros serviços usam anycast, em que vários locais anunciam o mesmo endereço IP, ou uma combinação dos dois.
2. O local verifica seu cache, um armazenamento de conteúdo reutilizável.
3. Em um acerto de cache, ele retorna uma cópia armazenada utilizável. Em uma falha de cache, ele busca o objeto na origem, o armazenamento ou servidor de referência.
4. O conteúdo elegível permanece em cache para requisições posteriores, sujeito ao seu tempo de vida (TTL) e às regras de cache.

O CloudFront também usa caches de borda regionais maiores entre muitos locais de borda e a origem. Um objeto removido de um cache pequeno ainda pode estar disponível ali, evitando outra viagem até a origem.

As imagens de um site de notícias têm origem em Frankfurt. Um leitor em São Paulo está a cerca de 9.800 km em linha reta. Mesmo uma ida e volta ideal por fibra leva cerca de 98 ms, e percursos reais levam mais tempo. Uma falha de cache ainda exige uma busca na origem. Leitores posteriores podem receber a imagem em cache localmente em poucos milissegundos.

Imagens, vídeos, scripts, folhas de estilo e downloads funcionam bem porque muitas pessoas requisitam os mesmos bytes. Um carrinho de compras privado normalmente precisa de uma nova resposta da origem. A borda pode ajudar com a conexão sem tornar todas as respostas armazenáveis em cache. Locais de borda também podem responder a consultas DNS, como no Route 53, ou receber tráfego na rede principal de um provedor, como no AWS Global Accelerator.

Diferencie opções de infraestrutura próxima

O Azure Arc acrescenta uma conexão de gerenciamento: o Azure Resource Manager pode gerenciar servidores e clusters Kubernetes fora do Azure, inclusive nas instalações da organização e em outras nuvens. Ele não transforma um edifício do cliente em uma região do Azure.

Acompanhe dados em cache entre fronteiras

Uma CDN global pode armazenar conteúdo em vários países. Uma regra que bloqueia visualizadores estrangeiros controla o acesso do público; ela não determina onde as cópias em cache ou o processamento ocorrem. Conteúdo com um limite nacional rigoroso precisa de uma CDN que garanta os locais permitidos ou de um caminho de entrega que evite armazená-lo em cache no exterior. Verifique isso separadamente da região da origem.

Alta disponibilidade significa continuar atendendo aos usuários quando componentes falham. Um ponto único de falha é qualquer dependência cuja perda interrompe a aplicação. Dois servidores web ainda compartilham um ponto único de falha se ambos dependem de um único banco de dados desprotegido.

Proteja todo o caminho da requisição

Execute instâncias da aplicação em zonas diferentes. Um balanceador de carga verifica sua integridade e envia requisições para instâncias íntegras. Proteja também a camada de dados, usando um banco de dados com redundância de zona ou uma réplica em espera síncrona em outra zona, como em uma configuração Amazon RDS Multi-AZ.

Sempre que possível, mantenha as instâncias da aplicação sem estado. Armazene a sessão de um usuário em um serviço de dados compartilhado e resiliente, em vez de mantê-la apenas na memória de uma instância. Assim, uma instância íntegra em outra zona pode responder à próxima requisição sem perder o carrinho ou a sessão do usuário.

Uma única máquina virtual permanece na zona selecionada. Escolha várias instâncias zonais ou uma opção de serviço que ofereça redundância de zona.

Converta tempo de funcionamento em tempo de interrupção

Em um ano de 365 dias, há 8.760 horas. Converta a disponibilidade em uma fração, subtraia-a de um e multiplique pelo período:

Com 99,9%, a fração de indisponibilidade é 0,001, então o tempo de interrupção é de 8,76 horas por ano. Com 99,95%, é de 4,38 horas. Com 99,99%, é de cerca de 52,6 minutos. Essas conversões descrevem uma porcentagem durante esse período; um acordo de serviço real também define como a disponibilidade é medida.

Para uma ilustração ideal, suponha que qualquer uma de duas zonas possa executar a aplicação completa, que cada uma esteja disponível 99,9% do tempo e que suas falhas sejam independentes. A probabilidade de ambas estarem indisponíveis é:

A disponibilidade resultante é de 99,9999%, cerca de 32 segundos de interrupção anual. Erros de software compartilhados, erros de configuração e dependências regionais invalidam a suposição de independência. Esse cálculo explica o benefício da redundância; ele não é o tempo de funcionamento prometido da aplicação.

Deixe capacidade suficiente nas zonas restantes

Uma loja on-line precisa de seis instâncias no pico de carga. Duas instâncias em cada uma de três zonas fornecem seis normalmente, mas apenas quatro após a falha de uma zona. Para manter seis após a perda de qualquer zona, cada uma das duas zonas restantes deve fornecer três instâncias. Implante nove no total.

Com duas zonas, cada uma deve comportar todas as seis, então o total passa a 12. Em geral, para quantidades iguais de instâncias entre zonas:

Aqui, $N$ é a capacidade necessária no pico e $z$ é o número de zonas. Arredonde para cima porque uma instância é uma unidade inteira. Para dez instâncias em quatro zonas, dez dividido por três é arredondado para quatro por zona: 16 no total. A perda de uma zona deixa 12, o que é suficiente. Esse plano pressupõe que a capacidade necessária já esteja em funcionamento; esperar por novas instâncias acrescenta uma dependência à recuperação.

Uma segunda região permite a recuperação de um desastre regional. Ela também pode atender usuários distantes, cumprir regras de localização específicas de um país ou oferecer um serviço ou capacidade indisponível na primeira região. Cada motivo acrescenta requisitos diferentes ao projeto.

Defina dois objetivos de recuperação

O objetivo de ponto de recuperação (RPO) é a perda máxima aceitável de dados, expressa em tempo. O objetivo de tempo de recuperação (RTO) é o tempo máximo aceitável para restaurar o serviço. Uma cópia de segurança pode preservar dados recentes, mas demorar demais para ser restaurada; uma reinicialização rápida ainda pode perder dados demais.

Uma empresa copia sua cópia de segurança noturna às 01:00 e perde a região principal às 17:00. A cópia de recuperação disponível não contém 16 horas de alterações. Isso não atende a um RPO de uma hora. São necessárias cópias de segurança concluídas com maior frequência ou replicação contínua; uma programação só é útil quando as cópias realmente chegam a tempo ao local de recuperação.

Ajuste o nível de prontidão ao tempo de recuperação

Manter mais recursos em funcionamento geralmente custa mais e reduz o trabalho de recuperação. Cópia de segurança e restauração costuma levar horas ou mais. A estratégia ativo-ativo pode recuperar o serviço em segundos a minutos, mas o projeto da aplicação completa determina o resultado.

Entenda a diferença entre as cópias de dados

Entre regiões, a replicação geralmente é assíncrona: uma gravação é confirmada antes de a cópia remota estar concluída. Frankfurt e a área de Washington, D.C. ficam a cerca de 6.500 km uma da outra, então apenas uma ida e volta ideal por fibra leva cerca de 65 ms. Esperar esse percurso a cada gravação acrescentaria atraso.

O intervalo entre os dados atuais e a cópia remota é o atraso de replicação. Ele pode aumentar durante carga intensa ou problemas de rede. Monitore-o em relação ao RPO. Uma segunda região com uma réplica antiga oferece separação geográfica sem atender ao objetivo de perda de dados.

Use os pares do Azure corretamente

O Azure forma pares com muitas regiões, como North Europe com West Europe e East US com West US. O pareamento permite atualizações escalonadas da plataforma, priorização da recuperação e replicação geográfica de alguns serviços. A maioria dos pares permanece em uma área geográfica. Brazil South é uma exceção: seu par é South Central US.

Um par não implanta uma cópia da aplicação nem organiza todas as etapas de failover. Muitas regiões mais recentes do Azure não têm par, e um cliente pode escolher outra região secundária permitida. Verifique o comportamento de replicação de cada serviço.

O roteamento global pode direcionar usuários para regiões íntegras por meio do Route 53, Azure Front Door ou balanceamento de carga global do Google Cloud. Inclua no orçamento recursos duplicados e transferências entre regiões e teste todo o caminho de recuperação, incluindo cotas e etapas manuais. Se os dados precisarem permanecer em um país com apenas uma região, use suas zonas e opções de recuperação local; uma cópia no exterior violaria o requisito de localização.

Latência é o atraso de percurso. O tempo de ida e volta (RTT) mede o tempo de uma requisição e sua resposta, geralmente em milissegundos. A largura de banda mede a quantidade de dados que uma conexão transporta a cada segundo. Mais largura de banda ajuda a transferir um arquivo grande, mas não elimina o tempo de percurso até uma região distante.

Estime o mínimo físico

A luz viaja pela fibra a aproximadamente 200.000 km/s. Cada quilômetro acrescenta cerca de 5 microssegundos em um sentido. Para estimar um RTT mínimo, multiplique a distância por dois para considerar a ida e a volta, divida por essa velocidade e converta segundos em milissegundos:

Isso resulta em cerca de 1 ms a cada 100 km. Uma distância em linha reta é um limite inferior: cabos reais seguem rotas mais longas, e roteadores, filas e processamento acrescentam atraso.

Para usuários em Sydney, Singapura fica a cerca de 6.300 km. Multiplicar por dois resulta em 12.600 km. Dividir por 200.000 resulta em 0,063 segundo, ou cerca de 63 ms. O norte da Virgínia fica a cerca de 15.700 km, resultando em pelo menos cerca de 157 ms. Uma região em Sydney pode reduzir o percurso a alguns milissegundos.

Conte os percursos repetidos

Um atraso pode parecer pequeno até que uma tarefa o repita. Suponha que abrir uma conexão e obter uma primeira resposta leve quatro idas e voltas sequenciais. Com 157 ms cada, o tempo de percurso é de 628 ms. Com 5 ms cada, é de 20 ms. O número exato de percursos depende da reutilização da conexão e do comportamento do protocolo; conte as idas e voltas que a carga de trabalho realmente faz.

O mesmo efeito ocorre entre partes da aplicação. Uma página faz 50 consultas ao banco de dados em sequência. Se cada consulta remota acrescenta 15 ms, a sequência acrescenta 750 ms. Com 1 ms dentro da mesma região, ela acrescenta 50 ms. Esses são tempos de comunicação das consultas; o trabalho do banco de dados pode acrescentar mais tempo. Manter juntos os componentes que se comunicam com frequência evita pagar repetidamente o custo da distância.

Escolha a mudança adequada

Um cache de borda ajuda quando pode responder à requisição. Ele não pode tornar uma transação de banco de dados não armazenada em cache local para cada usuário. Da mesma forma, aumentar a largura de banda deixa a distância até a origem inalterada.

Meça a partir dos locais reais dos usuários

As rotas de rede seguem as conexões disponíveis, os emparelhamentos de redes e as condições de tráfego, não a linha mais curta em um mapa. Compare os RTTs medidos ou os tempos de resposta da aplicação nos locais de onde os usuários realmente se conectam. Teste horários e requisições representativos antes de se comprometer com uma região. Uma região próxima é uma forte candidata; as medições determinam se seu percurso real atende bem à carga de trabalho.

Uma escolha útil de região começa pela carga de trabalho: quem a usa, de quais serviços ela precisa, para onde seus dados podem ir e como ela deve se recuperar. Comparar regiões sem esses requisitos pode resultar em um preço baixo para um local que não consegue executar a aplicação.

Filtre antes de pontuar

Seis fatores costumam importar: conformidade e residência de dados, latência para os usuários, disponibilidade de serviços e recursos, preço, opções de resiliência e sustentabilidade. Separe requisitos obrigatórios de preferências. Uma restrição de país ou a ausência de um serviço essencial elimina uma região da avaliação. Um bom preço não compensa o descumprimento desse requisito.

Para as regiões restantes, escolha uma escala de pontuação consistente e pesos que somem 100%. Pontuações maiores devem sempre significar maior adequação, incluindo uma pontuação maior para preço quando o custo for menor. Multiplique cada pontuação por seu peso e some os resultados.

Resolva uma decisão

Uma empresa na Alemanha exige que os dados sejam armazenados na UE. Ela elimina uma região dos Estados Unidos antes de comparar duas candidatas permitidas. As pontuações vão de 1 a 5, sendo 5 a melhor.

A empresa atribui peso de 50% à latência, 30% ao preço e 20% aos serviços:

B fica ligeiramente à frente. Para uma tela de negociação, a empresa muda os pesos para 70%, 20% e 10%:

A recomendação muda porque a prioridade da empresa mudou. Informe os pesos e as evidências por trás das pontuações para que outra pessoa possa entender a escolha. Um total que parece preciso só é útil na medida em que esses dados são úteis.

Calcule o custo da configuração completa

Os preços de computação variam entre regiões conforme energia, terreno, demanda e outros custos locais. Inclua armazenamento, cópias de segurança, capacidade na segunda região e movimentação de dados na comparação. Transferências entre regiões e de saída para a internet costumam ser cobradas; a entrada de dados geralmente é gratuita. Colocar partes da aplicação que transferem muitos dados em regiões diferentes pode anular uma pequena economia no preço de computação.

A resiliência exige verificar o suporte a zonas e um local de recuperação permitido. A sustentabilidade exige examinar a eletricidade usada na região; os provedores publicam indicadores como a parcela regional de energia livre de emissões de carbono do Google Cloud. Eletricidade mais limpa pode reduzir a pegada ambiental da mesma carga de trabalho.

Por fim, teste as regiões mais bem classificadas com medições reais de latência e a calculadora de preços do provedor. Registre o local selecionado, os requisitos obrigatórios, os pesos e os motivos. Migrar recursos e dados armazenados exige trabalho, então reavalie a escolha quando mudarem os locais dos usuários, as leis, os serviços ou a distribuição regional do provedor.

Residência de dados descreve onde os dados são armazenados e processados. Localização obrigatória de dados é uma exigência legal de manter dados especificados dentro de um país. Soberania de dados diz respeito às leis e autoridades que podem reger os dados, inclusive por meio da empresa que os detém. Armazenamento local e controle legal estão relacionados, mas respondem a perguntas diferentes.

Acompanhe mais do que o banco de dados

Um banco de dados na região germanywestcentral do Azure coloca seu armazenamento primário na Alemanha. Examine também cópias de segurança, réplicas, registros, acesso de suporte, serviços globais de identidade e caches de CDN. Qualquer um deles pode introduzir outra localização. O EU Data Boundary da Microsoft, concluído em fevereiro de 2025, acrescenta compromissos de armazenamento e processamento na UE/EFTA para serviços e dados cobertos, com escopo e exceções documentados.

Uma análise eficaz pergunta para onde vai cada cópia e qual organização pode obter acesso. Políticas podem restringir as localizações dos recursos; chaves de criptografia controladas pelo cliente e controles de acesso de suporte tratam de outras partes do problema. Um único controle não responde a todas as perguntas.

Aplique a estrutura de transferências do GDPR

O Regulamento Geral sobre a Proteção de Dados (GDPR) aplica-se ao tratamento dentro de seu âmbito territorial. Isso inclui estabelecimentos no EEE e determinadas organizações no exterior que oferecem bens ou serviços a pessoas na UE ou monitoram essas pessoas. O EEE inclui a UE, a Islândia, Liechtenstein e a Noruega. O GDPR permite armazenamento no exterior quando suas condições aplicáveis são cumpridas; ele não impõe uma regra geral de armazenamento exclusivo no EEE.

Para uma transferência a um destinatário distinto fora do EEE, o Capítulo V prevê estas vias:

Japão, Reino Unido e Suíça são exemplos de destinos com decisão de adequação. O Quadro de Privacidade de Dados UE–EUA (DPF), adotado em 10 de julho de 2023, cobre organizações participantes certificadas dos Estados Unidos. Ele substituiu a via anterior do Escudo de Privacidade, invalidada no julgamento Schrems II em 16 de julho de 2020. O Tribunal Geral rejeitou uma contestação ao DPF em setembro de 2025; havia um recurso pendente em outubro de 2026. Uma decisão de transferência exige verificar a situação atual do quadro e a certificação do destinatário.

Separe acesso de armazenamento

Disponibilizar dados mantidos no EEE a uma organização de suporte distinta fora do EEE pode ser uma transferência, mesmo que o banco de dados permaneça local. O EDPB diferencia isso do acesso aos dados por um funcionário do mesmo controlador enquanto está no exterior; esse acesso não é uma transferência a outro destinatário nos termos do Capítulo V. O tratamento ainda precisa de proteção adequada.

A Lei CLOUD dos Estados Unidos de 2018 pode exigir que provedores sujeitos à jurisdição dos Estados Unidos apresentem dados sob sua posse, custódia ou controle, incluindo dados armazenados no exterior, mediante o processo legal aplicável. Portanto, o endereço de um servidor, por si só, não resolve a questão da soberania.

Uma clínica holandesa que usa um provedor sediado nos Estados Unidos escolhe uma região da UE, mapeia destinatários no exterior e fluxos de suporte, verifica a via aplicável do DPF ou das SCCs e gerencia chaves de criptografia e políticas de locais permitidos. Ela documenta essas escolhas junto com suas outras obrigações de proteção de dados. Outros países e contratos acrescentam suas próprias restrições, especialmente para registros de saúde, financeiros e governamentais.

Uma nuvem soberana acrescenta controles sobre dados, operações e dependência de sistemas globais para atender aos requisitos de uma jurisdição. Uma região comum no país correto oferece uma escolha de localização. Uma oferta soberana também pode mudar quem opera o serviço e com que independência ele pode funcionar.

Faça três perguntas diferentes

A soberania de dados pergunta onde os dados são mantidos e quem controla o acesso e as chaves de criptografia. A soberania operacional pergunta quem administra o serviço e presta suporte, e onde essas pessoas trabalham. A soberania técnica pergunta se o ambiente pode operar sem os sistemas globais do provedor. Avalie cada dimensão em relação ao requisito legal, contratual ou de segurança real.

Compare ambientes separados

Ambientes governamentais oferecem suporte a programas como o FedRAMP, com cobertura específica por serviço e responsabilidades do cliente. Os ambientes da China são separados dos serviços globais e exigem contas e pontos de extremidade apropriados. Partições de nuvem separadas têm seus próprios limites de identidade e API; um logon na nuvem global não acessa automaticamente seus recursos.

Identifique o nível da oferta europeia

Em outubro de 2026, o AWS European Sovereign Cloud está disponível, tendo lançado sua primeira região em Brandemburgo, na Alemanha, em janeiro de 2026. Ele é física e logicamente separado de outras regiões da AWS, com operações sediadas na UE por residentes da UE em empresas constituídas na Alemanha.

O Microsoft Sovereign Cloud inclui controles Sovereign Public Cloud em regiões públicas, Sovereign Private Cloud usando Azure Local nas instalações de um cliente e nuvens nacionais operadas por parceiros, como Bleu na França e Delos Cloud na Alemanha. Essas opções oferecem arranjos operacionais diferentes.

A linha do Google Cloud inclui controles Data Boundary na nuvem pública, ofertas Dedicated em infraestrutura separada operada por parceiros e ambientes Air-Gapped baseados no Google Distributed Cloud que funcionam desconectados do Google e da internet. O S3NS na França e a oferta da Thales na Alemanha ilustram a abordagem de parceiro local. Nomes de produtos, por si só, não estabelecem quais serviços, localizações ou compromissos de independência um contrato inclui.

Escolha controle suficiente sem perder a capacidade necessária

Um varejista pode atender a seus requisitos com uma região comum da UE, garantias de transferência e chaves gerenciadas pelo cliente. Um órgão com um requisito de qualificação nacional verifica se uma oferta específica de parceiro ou soberana possui essa qualificação para os serviços necessários. Trabalho classificado fora de redes pode exigir um ambiente isolado fisicamente de redes externas.

Um isolamento mais rigoroso pode reduzir a escolha de serviços, atrasar novos recursos, aumentar o custo e deixar menos regiões de recuperação. Compare o catálogo real de serviços, a elegibilidade, os compromissos operacionais e os locais de recuperação permitidos. A classificação soberana, por si só, não estabelece imunidade a todas as leis estrangeiras.

Os provedores colocam recursos de serviços implantados dentro de contêineres de gerenciamento. Esses contêineres separam custos, acesso e limites de serviço. Seus nomes diferem: uma conta da AWS, uma assinatura do Azure e um projeto do Google Cloud cumprem funções semelhantes em linhas gerais.

Diferencie um contêiner de uma pessoa

Uma pessoa pode acessar vários contêineres, e um contêiner pode atender muitas pessoas. Compartilhar acesso não coloca um recurso em um segundo contêiner. Por exemplo, conceder a um analista permissão para consultar um conjunto de dados em outro projeto mantém a propriedade do conjunto de dados em seu projeto original.

Uma conta da AWS tem um ID de conta de 12 dígitos. Seu usuário raiz está associado ao e-mail de criação da conta e tem privilégios excepcionais. Proteja-o com autenticação multifator e reserve-o para tarefas que exigem o usuário raiz. O trabalho diário normalmente usa funções e outras identidades autorizadas. Um ID de conta identifica um limite de recursos, não um funcionário específico.

Entenda a relação do Azure com o diretório

Um locatário do Microsoft Entra é o diretório de identidades de uma organização. Uma assinatura é um limite de gerenciamento de recursos e faturamento que confia em exatamente um locatário. Um locatário pode dar suporte a muitas assinaturas. Uma pessoa conectada pode ter permissão em algumas delas e nenhuma em outras.

A expressão “conta do Azure” pode se referir a uma identidade de logon ou a um arranjo de faturamento, então é vaga demais ao discutir onde uma máquina virtual pertence. Identifique a assinatura e o locatário separadamente.

Interprete os identificadores de projeto do Google Cloud

Um projeto tem um nome de exibição, um ID do projeto permanente e um número do projeto atribuído pelo provedor. O nome pode mudar e não precisa ser único. O ID é globalmente único e não pode mudar após a criação. Ele usa de 6 a 30 letras minúsculas, dígitos ou hífens, começa com uma letra e não pode terminar com hífen. Por exemplo, lumen-shop-prod é um ID de projeto, enquanto “Lumen Shop Production” pode ser seu nome de exibição.

Projetos organizam serviços implantados, enquanto recursos de organização e pasta organizam os projetos acima deles. O faturamento é vinculado separadamente, então vários projetos podem compartilhar uma conta de faturamento sem se tornarem um único projeto.

Divida o trabalho em limites úteis

Uma empresa separa sua loja em desenvolvimento, teste e produção. Ela usa três contas da AWS, três assinaturas do Azure ou três projetos do Google Cloud. Cada ambiente recebe um escopo distinto de permissões e uma visão de custos separada. A separação limita os danos que um erro de desenvolvimento pode causar quando as permissões são configuradas de acordo.

Os contêineres também têm cotas, como limites regionais de CPUs virtuais. Novos contêineres podem começar com cotas baixas, e muitos limites podem ser aumentados mediante solicitação. Um ambiente de recuperação precisa de cota suficiente antes de uma falha; um modelo funcional, por si só, não reserva capacidade nem aumenta esses limites.

As equipes costumam dividir contêineres por ambiente, departamento ou produto para manter custos e acesso compreensíveis. O posicionamento geográfico é uma escolha separada: um contêiner pode conter recursos em várias regiões.

Recursos criados, alterados e removidos juntos compartilham um ciclo de vida. Os grupos de recursos do Azure fazem desse ciclo de vida um limite de gerenciamento. Etiquetas e rótulos acrescentam descrições pesquisáveis aos recursos sem mudar seu posicionamento físico.

Use grupos de recursos do Azure

Para recursos comuns de serviços implantados no Azure, um grupo de recursos fica dentro de uma assinatura. Cada recurso desse tipo pertence a um grupo; grupos não podem conter outros grupos. Recursos de nível de assinatura e objetos de gerenciamento existem em escopos superiores, então a hierarquia também tem objetos fora dos grupos de recursos.

Um grupo tem uma localização para seus metadados, os registros que descrevem o grupo e seus recursos. Essa localização não obriga todos os membros a estar na mesma região. Um servidor web em uma região e seu recurso de recuperação em outra podem compartilhar um grupo.

Excluir um grupo de recursos exclui seu conteúdo. Isso é conveniente para trabalho temporário e perigoso quando recursos de produção não relacionados são incluídos. Um bloqueio de exclusão pode impedir a exclusão acidental até que uma pessoa autorizada o remova. Escolha um grupo cujos membros possam compartilhar com segurança decisões de criação, acesso e desativação.

Por exemplo, este comando da CLI do Azure cria um grupo para a loja em produção:

az group create --name rg-shop-prod-weu --location westeurope

Um grupo separado rg-shop-test contém um ambiente de teste descartável. Remover esse grupo de teste remove seu conteúdo de uma vez. O grupo de produção permanece separado. O padrão no nome identifica tipo de recurso, aplicação, ambiente e localização, facilitando a leitura das listas.

O acesso atribuído a um grupo, como Reader, aplica-se a seus recursos. Muitos tipos de recurso podem ser movidos entre grupos ou assinaturas, sujeitos às restrições do serviço. Essa movimentação altera a posição no gerenciamento; ela não migra um recurso para outra região.

Compare o agrupamento da AWS

O AWS Resource Groups pode reunir recursos por meio de etiquetas correspondentes ou de uma pilha do CloudFormation. Um recurso pode aparecer em vários desses grupos. Excluir um AWS Resource Group remove o agrupamento e mantém seus recursos. Isso difere do contêiner de ciclo de vida obrigatório do Azure para recursos comuns implantados. No Google Cloud, os projetos fornecem o principal limite de agrupamento de recursos de serviços.

Acrescente etiquetas e rótulos úteis

Etiquetas na AWS e no Azure e rótulos no Google Cloud associam descrições em pares de chave e valor. Exemplos incluem environment=prod, cost-center=4120 e owner=web-team. Eles ajudam a filtrar inventários e relatórios de custos ou a selecionar recursos para automação.

Use chaves e valores acordados. Se uma equipe escreve “prod” e outra escreve “Prod”, um relatório pode separar recursos que pertencem ao mesmo grupo. As etiquetas de grupo de recursos do Azure não são transmitidas aos recursos membros por padrão; uma política ou automação pode aplicar os valores pretendidos.

Uma etiqueta é um metadado descritivo. Um rótulo que diz “privado” não isola o tráfego de rede, e chamar um grupo de “Europa” não move seus recursos para lá. Regras de acesso, redes e configurações de região fornecem esses controles.

Uma hierarquia de gerenciamento organiza contêineres em uma árvore. Escopos superiores permitem que uma organização gerencie muitas contas, assinaturas ou projetos em conjunto. Herança significa que configurações aplicáveis em um elemento pai são transmitidas a seus descendentes.

Compare as árvores dos provedores

O Azure dá a cada locatário um grupo de gerenciamento raiz, chamado “Tenant root group” por padrão. Grupos de gerenciamento podem ser aninhados em seis níveis de profundidade, excluindo a raiz e o nível da assinatura. Cada grupo de gerenciamento ou assinatura tem um elemento pai.

O AWS Organizations tem uma conta de gerenciamento que cria a organização e paga as faturas consolidadas. Unidades organizacionais (OUs) agrupam contas e podem ser aninhadas em cinco níveis abaixo da raiz. Uma conta pertence a uma organização por vez. A conta de gerenciamento tem uma função distinta e não é controlada pelas políticas de controle de serviço da organização.

A organização do Google Cloud está associada ao domínio da empresa. Pastas exigem uma organização e podem conter pastas aninhadas. Um aluno que usa uma avaliação gratuita pode ter um projeto sem uma organização.

Acompanhe uma regra herdada

Uma empresa separa Varejo e Logística, cada um com produção e desenvolvimento. O Azure usa grupos de gerenciamento departamentais com assinaturas abaixo deles. A AWS usa OUs departamentais com contas abaixo delas. O Google Cloud usa pastas departamentais com projetos abaixo delas.

Se uma política de grupo de gerenciamento do Azure permite implantações apenas em regiões da UE, as assinaturas abaixo dele herdam essa restrição. O nome do grupo é apenas um rótulo; a política aplica a regra de localização. Na AWS, uma política de controle de serviço (SCP) de uma OU pode definir um limite máximo de permissões para as contas-membro. Uma SCP não concede, por si só, permissão a um usuário para trabalhar nessas contas.

Entenda o acesso herdado

No controle de acesso baseado em função do Azure e nas políticas de permissão do IAM do Google Cloud, as concessões se somam entre escopos. Uma concessão somente de leitura em um elemento filho não cancela o acesso de gravação herdado de um elemento pai. Para remover esse acesso amplo, altere o escopo que o concede ou use um controle de negação apropriado.

O Azure Policy pode rejeitar configurações de recursos em não conformidade, como uma localização proibida. Ele é separado das atribuições de função que concedem acesso. As políticas de negação do Google Cloud podem bloquear permissões especificadas. As políticas do AWS Organizations também diferem das concessões de acesso a contas; o IAM Identity Center pode atribuir conjuntos de permissões a várias contas.

Uma equipe de auditoria que receba acesso de leitura adequado no topo de uma hierarquia do Azure ou do Google Cloud pode ler recursos nos departamentos abaixo dela. A associação a uma OU da AWS, por si só, não dá a essa equipe acesso às contas.

Mantenha a árvore separada do mapa

Mover uma assinatura ou projeto altera suas políticas e seu acesso herdados. Os recursos permanecem em suas regiões existentes. Revise as regras efetivas do novo ramo antes de uma movimentação: uma reorganização lógica pode afetar as permissões de muitas pessoas sem mover um único servidor.

Um botão no navegador, um comando e um programa podem solicitar a mesma operação na nuvem. Cada um envia uma requisição autenticada a uma interface de programação de aplicações (API). A interface muda a forma como uma pessoa ou aplicação trabalha; permissões e limites de serviço continuam se aplicando.

Associe a interface à tarefa

As ferramentas gráficas são o AWS Management Console, o portal do Azure e o console do Google Cloud. Os principais programas de CLI são aws, az e gcloud. O Azure PowerShell e o AWS Tools for PowerShell oferecem outro estilo de comando. Aplicativos móveis são úteis para verificações de status e alertas.

Por exemplo, aws ec2 describe-instances --region eu-central-1 lista instâncias do EC2 em Frankfurt. az group list lista grupos de recursos do Azure, e gcloud compute zones list lista zonas do Google Cloud. Esses são clientes de API, não inventários separados de recursos.

AWS CloudShell, Azure Cloud Shell e Google Cloud Shell oferecem a CLI correspondente em um navegador. Eles reduzem o trabalho de instalação e usam o contexto de nuvem da sessão autenticada. Você ainda precisa verificar a qual conta, assinatura ou projeto a sessão está direcionada.

Siga o caminho correto da API

No Azure, operações do plano de controle criam, alteram ou excluem recursos por meio do Azure Resource Manager. Ele aplica autorização e políticas às requisições de gerenciamento de recursos. Operações do plano de dados usam o ponto de extremidade do próprio serviço, como ao enviar um arquivo para uma conta de armazenamento existente. Um programa pode realizar os dois tipos de operação por meio de clientes diferentes.

SDKs oferecem suporte a linguagens como Python, JavaScript, Java, C# e Go. Eles ajudam com assinatura de requisições, chamadas de serviço e novas tentativas após falhas temporárias. Uma aplicação web usa um SDK quando cada envio de usuário deve acionar uma operação de armazenamento; ela não precisa de uma pessoa operando o console.

Verifique o contexto de destino

Configurações padrão podem escolher silenciosamente o destino errado. A configuração da AWS pode definir uma região padrão. A configuração do Google Cloud pode selecionar um projeto e uma região de computação, por exemplo, com gcloud config set project lumen-shop-prod e gcloud config set compute/region europe-west4.

O Azure usa uma assinatura selecionada, enquanto os comandos de criação de recursos usam seus parâmetros de localização ou padrões documentados. A localização dos metadados de um grupo de recursos não seleciona necessariamente a localização de todos os recursos. Verifique o destino do comando antes de executá-lo.

Use credenciais de curta duração, como funções ou sessões autenticadas, quando disponíveis. Mantenha chaves de acesso fora do código-fonte e de documentos compartilhados. Mudar do console para uma CLI não contorna os controles de acesso: uma operação de API negada continua negada independentemente do cliente que a envia.

Criar manualmente um recurso temporário pode ser conveniente. Reconstruir o mesmo ambiente para teste, produção e recuperação exige um processo que evite pequenas diferenças entre cliques repetidos. A infraestrutura como código (IaC) armazena a descrição dos recursos em arquivos de texto e usa uma ferramenta de implantação para criar ou atualizar o ambiente.

Descreva um estado ou uma sequência

Um modelo declarativo diz o que deve existir, como duas máquinas virtuais com tamanho e localização escolhidos. A ferramenta de implantação compara esse estado desejado com o ambiente atual e determina as alterações. Um script imperativo lista ações em ordem, como “crie o grupo e depois crie as máquinas”.

Uma pilha agrupa os recursos gerenciados por uma implantação do CloudFormation. Valores de parâmetros permitem que uma equipe reutilize um modelo para localizações ou tamanhos diferentes sem manter vários arquivos copiados.

Reutilize um ambiente testado

Uma equipe tem um modelo de loja virtual testado em Frankfurt, eu-central-1. Para preparar sua infraestrutura de recuperação na Irlanda, ela fornece eu-west-1 como parâmetro de região. Para teste, fornece um tamanho de máquina menor. O controle de versão registra o modelo e suas alterações revisadas, tornando a configuração pretendida visível para a equipe.

Reutilizar código de infraestrutura não copia os dados atuais da aplicação. Cópias de segurança ou replicação ainda fornecem esses dados, e a região de recuperação escolhida ainda precisa ter os serviços, permissões e cotas necessários e atender aos requisitos legais. Os modelos tornam repetível a construção de infraestrutura consistente; o plano completo de recuperação inclui essas outras dependências.

Aplique alterações de forma consistente

Uma operação idempotente pode ser repetida sem acrescentar outra alteração depois que seu resultado pretendido foi alcançado. Com configuração, entradas e recursos inalterados, uma implantação declarativa que já alcançou o estado desejado não deve produzir outras alterações na infraestrutura. Um script composto apenas por comandos de criação pode falhar ou criar duplicatas quando executado novamente.

Desvio de configuração é uma diferença entre a configuração declarada e os recursos em funcionamento. Alguém pode aumentar o tamanho de uma máquina no console sem atualizar seu modelo. A detecção de desvios do CloudFormation ou um terraform plan pode ajudar a identificar essas diferenças. Um plano do Terraform mostra alterações propostas; revise-as antes de aplicá-las.

A IaC torna as alterações revisáveis, preserva seu histórico e ajuda a reconstruir ambientes perdidos. Ela também exige manter os arquivos e entender a ferramenta. Use a interface manual para uma exploração pontual e depois coloque em código as alterações estáveis e repetidas do ambiente para que a descrição revisada permaneça precisa.