O que é região e zona de disponibilidade na AWS, e por que São Paulo importa

Region e Availability Zone são os dois primeiros conceitos que aparecem no console e em toda certificação AWS. Veja o que cada um significa, como eles se relacionam e por que sa-east-1, a região de São Paulo, costuma ser a escolha certa para quem atende usuários no Brasil.

Nota da redação: a afirmação de que us-east-1, com 6 AZs, tem a maior contagem entre as regiões listadas não pôde ser confirmada na fonte usada. A documentação consultada só traz o número de AZs para quatro das 34 regiões (us-east-1, us-east-2, us-west-1 e us-west-2), então não há como verificar essa comparação contra todas as demais regiões. O leitor deve considerar essa frase como não verificada.

Quando você abre o console da AWS pela primeira vez, no canto superior direito existe um seletor com um nome de cidade e um código estranho, algo como "São Paulo" ou us-east-1. Esse seletor escolhe a Region (região) em que seus recursos vão existir, e é a primeira decisão de qualquer projeto na AWS. Entender o que ela significa, e o que é uma Availability Zone (AZ, zona de disponibilidade) dentro dela, é pré-requisito para qualquer certificação AWS e para não tomar decisão de arquitetura no escuro.

Este texto usa como base a documentação oficial da AWS sobre regiões, que hoje lista 34 Regions disponíveis para contas comerciais padrão.

O que é uma Region, na prática

Uma Region é um cluster de infraestrutura da AWS localizado numa área geográfica específica, isolado operacionalmente das demais regiões. Cada Region tem seu próprio conjunto de data centers, sua própria rede e, em geral, seu próprio catálogo de serviços disponíveis. A região do Brasil se chama South America (São Paulo) e seu código é sa-east-1; é esse código que aparece em comandos de CLI, em URLs de console e em variáveis como AWS_REGION.

Algumas regiões conhecidas, pelo nome e pelo código:

Escolher a região certa não é só estética: ela define latência até o usuário final, quais serviços você tem acesso e, em muitos casos, o preço pago por hora de computação ou por gigabyte armazenado, já que a AWS precifica de forma diferente por região.

Dentro da Region: as Availability Zones

Cada Region é dividida em duas ou mais Availability Zones. Uma AZ é, na prática, um ou mais data centers discretos, com energia, refrigeração e conectividade de rede redundantes e fisicamente separados dos outros, mas ligados entre si por fibra de baixa latência. É assim que a AWS consegue oferecer alta disponibilidade: se uma AZ cai (falta de energia, problema físico), as outras continuam de pé.

Uma analogia que ajuda: pense na Region como uma cidade e cada AZ como um bairro com sua própria subestação de energia. Um apagão num bairro não derruba a cidade inteira, mas os bairros estão perto o bastante para que um banco de dados replique dados entre eles em milissegundos.

O número de AZs varia por região. Segundo a documentação da AWS, us-east-1 (Norte da Virgínia) tem 6 AZs, a maior contagem entre as regiões listadas, enquanto outras como us-east-2 têm 3. A documentação não detalha o número exato de AZs de sa-east-1 na tabela pública, mas o princípio é o mesmo: sempre mais de uma, para permitir que você distribua uma aplicação entre AZs diferentes e sobreviva à queda de qualquer uma delas.

Na prática de arquitetura, isso significa: ao criar um Auto Scaling Group ou um banco RDS com Multi-AZ, você está pedindo para a AWS espalhar as réplicas entre essas zonas fisicamente separadas dentro da mesma Region.

Por que sa-east-1 importa para quem está no Brasil

Se sua aplicação atende usuários no Brasil, rodar em sa-east-1 reduz a distância física entre o servidor e o usuário, o que diminui a latência de rede sentida em cada requisição. É a mesma lógica de escolher um CDN com ponto de presença local: menos quilômetros de fibra, menos milissegundos de resposta.

Há também o motivo regulatório. Para quem trabalha com dados de usuários brasileiros e precisa considerar a LGPD, manter o armazenamento e o processamento dentro do território nacional é um fator recorrente na escolha da região, mesmo que a AWS não imponha isso tecnicamente.

Um ponto prático que a documentação deixa claro: nem todo serviço da AWS está disponível em todas as regiões, sa-east-1 incluída. Antes de desenhar uma arquitetura, vale checar a página AWS Services by Region para confirmar se o serviço que você quer usar já roda em São Paulo ou se vai exigir replicar dados para outra região.

Regiões habilitadas por padrão x regiões com opt-in

Existe uma distinção que confunde quem está começando: nem toda região aparece disponível assim que você cria uma conta. A documentação da AWS explica que toda região lançada depois de 20 de março de 2019 exige habilitação manual (opt-in) antes de poder ser usada; as regiões anteriores a essa data já vêm habilitadas por padrão.

sa-east-1 está na lista de regiões habilitadas por padrão, junto com nomes como us-east-1, eu-west-1 e ap-northeast-1. Isso significa que, assim que você cria uma conta AWS, já pode criar recursos em São Paulo sem nenhum passo extra. Regiões mais novas, como ap-east-2 (Taipei) ou ap-southeast-7 (Tailândia), exigem que você entre no AWS Global View console, vá em Regions and Zones e clique em Enable Region antes de usá-las.

Um detalhe que pega iniciante: tipo de conta

A AWS opera, na verdade, três famílias de conta separadas: a conta comercial padrão (a que praticamente todo leitor deste texto tem), a conta AWS GovCloud (US), voltada a órgãos do governo americano, e a conta Amazon AWS (China), que dá acesso só às regiões de Pequim e Ningxia. Uma conta de um tipo não enxerga nem acessa as regiões de outro tipo. Para quem está no Brasil e abriu uma conta comercial normal, isso é transparente: sa-east-1 e as demais regiões comerciais já estão no seu radar, e GovCloud ou China simplesmente não aparecem como opção.

O primeiro passo prático, dentro do Free Tier

Você não precisa criar nenhum recurso para explorar esse conceito. A forma mais simples é olhar quais regiões sua conta já tem habilitadas, usando a AWS CLI:

aws account list-regions --region-opt-status-contains ENABLED_BY_DEFAULT --query Regions[*].RegionName

Esse comando apenas consulta metadados da sua conta, listando os códigos de região já habilitados por padrão; ele não cria instância nem aloca armazenamento. O retorno é uma lista de códigos, com sa-east-1 entre eles.

Se quiser confirmar se uma região específica precisa de opt-in, o comando equivalente é:

aws account get-region-opt-status --region-name af-south-1

Para não precisar digitar --region sa-east-1 em todo comando daqui pra frente, vale configurar a região padrão da sua CLI uma vez:

aws configure set region sa-east-1

Esse ajuste já deixa qualquer recurso que você criar depois, dentro dos limites do Free Tier, nascendo em São Paulo por padrão.

Fonte: Documentação da AWS, Regiões e Zonas de Disponibilidade (https://docs.aws.amazon.com/global-infrastructure/latest/regions/aws-regions.html)

Fonte: Documentação da AWS — Regiões