Nesta aula, vamos mergulhar nos conceitos essenciais de rede na nuvem, que são fundamentais para qualquer profissional de DevOps. Entender como as redes virtuais funcionam em provedores como AWS, Azure e Google Cloud é crucial para projetar, implantar e operar aplicações de forma segura e eficiente. Você aprenderá desde os blocos básicos, como VPCs e sub-redes, até tópicos avançados como balanceamento de carga, DNS e segurança de rede.

Dominar esses conceitos permitirá que você crie arquiteturas de rede que atendam aos requisitos de desempenho, disponibilidade e segurança, além de facilitar a automação e o gerenciamento de infraestrutura como código.

VPC e sub-redes (conceito)

Uma VPC (Virtual Private Cloud) é uma rede virtual logicamente isolada dentro de um provedor de nuvem. Ela permite que você defina um espaço de endereçamento IP, crie sub-redes, configure rotas e gateways, e controle o tráfego de entrada e saída. A VPC é o equivalente a ter sua própria rede privada dentro do data center do provedor, mas com a flexibilidade e escalabilidade da nuvem.

Dentro de uma VPC, você pode criar sub-redes, que são segmentos menores do espaço de endereçamento IP. Isso é útil para organizar recursos, aplicar políticas de segurança diferentes e isolar ambientes (como produção e desenvolvimento). Por exemplo, você pode ter sub-redes públicas (com acesso à internet) e sub-redes privadas (sem acesso direto à internet) para colocar servidores de banco de dados ou aplicações internas.

Vamos ver um exemplo de como criar uma VPC e sub-redes usando a AWS CLI:

# Criar uma VPC com CIDR 10.0.0.0/16
aws ec2 create-vpc --cidr-block 10.0.0.0/16 --tag-specifications 'ResourceType=vpc,Tags=[{Key=Name,Value=minha-vpc}]'

# Criar duas sub-redes: uma pública e uma privada
aws ec2 create-subnet --vpc-id vpc-12345678 --cidr-block 10.0.1.0/24 --availability-zone us-east-1a --tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=subnet-publica}]'
aws ec2 create-subnet --vpc-id vpc-12345678 --cidr-block 10.0.2.0/24 --availability-zone us-east-1a --tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=subnet-privada}]'

No exemplo acima, criamos uma VPC com o bloco CIDR 10.0.0.0/16, que oferece 65.536 endereços IP. Em seguida, criamos duas sub-redes: uma pública (10.0.1.0/24) e uma privada (10.0.2.0/24). Note que as sub-redes estão na mesma zona de disponibilidade, mas você pode distribuí-las em várias zonas para alta disponibilidade.

É importante entender que, por padrão, as sub-redes são privadas e não têm rota para a internet. Para torná-las públicas, você precisa associar um Internet Gateway (IGW) à VPC e adicionar uma rota na tabela de rotas da sub-rede para 0.0.0.0/0 apontando para o IGW. Para sub-redes privadas, você pode usar um NAT Gateway para permitir acesso à internet apenas para saída (por exemplo, para baixar atualizações) mantendo a entrada bloqueada.

Load balancers

Load balancers (balanceadores de carga) são componentes críticos para distribuir o tráfego entre múltiplas instâncias ou serviços, garantindo alta disponibilidade e escalabilidade. Eles atuam como um ponto único de entrada para os clientes, encaminhando as requisições para os destinos apropriados com base em regras de balanceamento.

Na nuvem, existem vários tipos de load balancers, como o Application Load Balancer (ALB) na AWS, que opera na camada 7 (HTTP/HTTPS), e o Network Load Balancer (NLB), que opera na camada 4 (TCP/UDP). O ALB é ideal para aplicações web que usam HTTP/HTTPS, pois oferece roteamento baseado em caminho, host ou cabeçalhos. O NLB é mais adequado para tráfego TCP/UDP que exige baixa latência e alto throughput.

Vamos ver como criar um Application Load Balancer usando a AWS CLI, supondo que já temos as sub-redes e um security group apropriado:

# Criar o load balancer
aws elbv2 create-load-balancer --name meu-alb --subnets subnet-12345678 subnet-87654321 --security-groups sg-12345678

# Criar um target group
aws elbv2 create-target-group --name meu-tg --protocol HTTP --port 80 --vpc-id vpc-12345678

# Registrar instâncias no target group
aws elbv2 register-targets --target-group-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/meu-tg/1234567890123456 --targets Id=i-1234567890abcdef0 Id=i-0987654321fedcba

# Criar um listener
aws elbv2 create-listener --load-balancer-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:loadbalancer/app/meu-alb/1234567890123456 --protocol HTTP --port 80 --default-actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/meu-tg/1234567890123456

O load balancer distribui o tráfego entre as instâncias registradas no target group. Ele também realiza health checks para verificar se as instâncias estão saudáveis; se uma instância falhar, o tráfego é desviado das demais. Isso aumenta a disponibilidade e a tolerância a falhas da aplicação.

Além disso, os load balancers podem ser integrados com Auto Scaling para adicionar ou remover instâncias automaticamente com base na demanda, garantindo que a capacidade seja ajustada dinamicamente.

DNS

O DNS (Domain Name System) é o sistema que traduz nomes de domínio legíveis por humanos (como www.exemplo.com) em endereços IP que as máquinas usam para se comunicar. Na nuvem, o DNS é um serviço gerenciado que permite criar zonas hospedadas e gerenciar registros DNS, como A, CNAME, MX, etc.

Um dos principais serviços de DNS na nuvem é o Amazon Route 53, que oferece alta disponibilidade e baixa latência. Ele também integra-se com outros serviços, como load balancers e S3, permitindo criar registros que apontam para esses recursos. Por exemplo, você pode criar um registro A que aponte para o nome DNS do seu load balancer, ou usar políticas de roteamento como latência, geolocalização ou ponderação para direcionar o tráfego.

Vamos ver um exemplo de como criar uma zona hospedada e um registro no Route 53 usando a AWS CLI:

# Criar uma zona hospedada
aws route53 create-hosted-zone --name exemplo.com --caller-reference 2024-01-01-00:00:00

# Saída (exemplo):
# {
#     "HostedZone": {
#         "Id": "/hostedzone/Z1234567890",
#         "Name": "exemplo.com.",
#         ...
#     },
#     "ChangeInfo": { ... },
#     "DelegationSet": { ... }
# }

# Criar um registro A apontando para um load balancer
aws route53 change-resource-record-sets --hosted-zone-id /hostedzone/Z1234567890 --change-batch '{"Changes":[{"Action":"CREATE","ResourceRecordSet":{"Name":"www.exemplo.com","Type":"A","AliasTarget":{"HostedZoneId":"Z35SXDOTRQ7X7K","DNSName":"meu-alb-1234567890.us-east-1.elb.amazonaws.com","EvaluateTargetHealth":false}}}]}'

No exemplo, criamos uma zona hospedada para o domínio exemplo.com e depois um registro A com alias para o load balancer. O alias é um recurso especial que permite apontar diretamente para recursos da AWS sem custo adicional e com atualização automática dos endereços IP.

O DNS é fundamental para a disponibilidade, pois permite redirecionar o tráfego em caso de falha, implementar failover e balanceamento de carga global. É importante configurar o TTL (Time to Live) adequado para equilibrar entre propagação rápida e carga nos servidores DNS.

Segurança de rede

Segurança de rede na nuvem envolve várias camadas de proteção, incluindo firewalls, grupos de segurança, listas de controle de acesso (ACLs) e criptografia. O objetivo é controlar o tráfego de entrada e saída, proteger os recursos contra acessos não autorizados e minimizar a superfície de ataque.

Na AWS, os principais componentes de segurança de rede são os Security Groups (SGs) e as Network ACLs (NACLs). Os SGs são firewalls virtuais que controlam o tráfego para instâncias (nível de instância). Eles são stateful, ou seja, se você permitir tráfego de entrada, a resposta correspondente é automaticamente permitida. Os SGs só têm regras de permissão (não de negação) e são associados a interfaces de rede.

Já as NACLs são firewalls no nível de sub-rede, são stateless (você precisa definir regras de entrada e saída separadamente) e suportam regras de permissão e negação. Elas são avaliadas em ordem numérica, da menor para a maior, e a primeira regra que corresponde é aplicada. É comum usar NACLs como camada adicional de segurança, mas os SGs são a principal defesa.

Vamos ver um exemplo de como criar um security group e adicionar regras usando a AWS CLI:

# Criar um security group
aws ec2 create-security-group --group-name meu-sg --description "Meu security group" --vpc-id vpc-12345678

# Adicionar regra de entrada para SSH (porta 22) apenas de um IP específico
aws ec2 authorize-security-group-ingress --group-id sg-12345678 --protocol tcp --port 22 --cidr 203.0.113.0/32

# Adicionar regra de entrada para HTTP (porta 80) de qualquer lugar
aws ec2 authorize-security-group-ingress --group-id sg-12345678 --protocol tcp --port 80 --cidr 0.0.0.0/0

# Adicionar regra de saída para permitir todo o tráfego (padrão)
aws ec2 authorize-security-group-egress --group-id sg-12345678 --protocol -1 --cidr 0.0.0.0/0

No exemplo, criamos um SG que permite SSH apenas de um IP específico (para administração) e HTTP de qualquer lugar (para o público). É uma boa prática restringir ao máximo as portas e IPs de origem.

Além dos SGs e NACLs, outras práticas de segurança incluem: usar VPC endpoints para acessar serviços AWS sem passar pela internet, usar VPN ou Direct Connect para conexões privadas, e criptografar o tráfego com TLS/SSL. Também é importante monitorar o tráfego com ferramentas como VPC Flow Logs e AWS CloudTrail para detectar atividades suspeitas.

Boas práticas e observações finais

Ao trabalhar com redes na nuvem, é essencial seguir boas práticas para garantir segurança e eficiência. Algumas delas incluem:

  • Planeje o espaço de endereçamento IP com cuidado, evitando sobreposições e deixando espaço para crescimento.
  • Use múltiplas zonas de disponibilidade para alta disponibilidade e resiliência.
  • Implante recursos em sub-redes privadas sempre que possível, expondo apenas o necessário.
  • Configure security groups com o princípio do menor privilégio: permita apenas o tráfego necessário.
  • Use load balancers para distribuir tráfego e habilitar auto scaling.
  • Monitore o tráfego e configure alertas para anomalias.

Essas práticas ajudarão você a construir uma infraestrutura de rede sólida, pronta para produção.

Referências

Exercícios

  1. Exercício 1: Explique a diferença entre uma sub-rede pública e uma sub-rede privada em uma VPC. Quando você usaria cada uma?

    2. ✓ Resposta: Uma sub-rede pública tem uma rota para a Internet Gateway, permitindo que recursos (como instâncias EC2) tenham acesso direto à internet. Uma sub-rede privada não tem essa rota, então os recursos não podem ser acessados diretamente pela internet. Você usaria sub-redes públicas para servidores web que precisam ser acessados por clientes, e sub-redes privadas para bancos de dados ou servidores de aplicação que só devem ser acessados por outros recursos internos.
  2. Exercício 2: Qual é a diferença entre um Application Load Balancer (ALB) e um Network Load Balancer (NLB)? Em que cenário você escolheria cada um?

    3. ✓ Resposta: O ALB opera na camada 7 (HTTP/HTTPS) e oferece roteamento baseado em conteúdo (caminho, host, cabeçalhos), ideal para aplicações web. O NLB opera na camada 4 (TCP/UDP) e é otimizado para baixa latência e alto throughput, adequado para tráfego não HTTP, como jogos ou aplicações de tempo real. Escolha ALB para aplicações web com requisitos de roteamento avançado e NLB para tráfego TCP/UDP que exige desempenho extremo.
  3. Exercício 3: Como o DNS pode ser usado para melhorar a disponibilidade de uma aplicação? Dê um exemplo.

    4. ✓ Resposta: O DNS pode ser usado para failover, roteamento baseado em latência, ou geolocalização. Por exemplo, no Route 53, você pode configurar um registro com failover: se o health check de um recurso principal falhar, o DNS automaticamente responde com o endereço de um recurso de backup em outra região. Isso garante que os usuários sejam direcionados para um endpoint saudável, melhorando a disponibilidade.
  4. Exercício 4: Cite duas diferenças entre Security Groups e Network ACLs e explique quando usar cada um.

    5. ✓ Resposta: Diferenças: (1) Security Groups são stateful (respostas são automaticamente permitidas) e Network ACLs são stateless (é necessário definir regras de entrada e saída separadamente). (2) Security Groups suportam apenas regras de permissão, enquanto Network ACLs suportam regras de permissão e negação. Use Security Groups como primeira linha de defesa para instâncias, e Network ACLs como camada adicional de segurança para sub-redes.
  5. Exercício 5: Escreva um comando AWS CLI para criar um security group que permita tráfego HTTPS (porta 443) de qualquer lugar e tráfego SSH (porta 22) apenas de um IP específico (por exemplo, 203.0.113.10/32).

    6. ✓ Resposta: 
    # Criar o security group (substitua sg-12345678 pelo ID do seu SG)
aws ec2 authorize-security-group-ingress --group-id sg-12345678 --protocol tcp --port 443 --cidr 0.0.0.0/0
aws ec2 authorize-security-group-ingress --group-id sg-12345678 --protocol tcp --port 22 --cidr 203.0.113.10/32