Entenda como funcionam os Data Centers da AWS e como são distribuídos em Regiões em Zonas de Disponibilidade. Aprenda a como configurar sua VPC e sub-redes públicas e privadas com segurança.
O objetivo desse post é servir como um guia dos conceitos importantes em se tratando de Networking (Redes) na AWS, e especialmente para ajudar quem está estudando para as certificações da AWS.
Regiões e Zonas de Disponibilidade
A Nuvem da AWS abrange possui uma infra-estrutura global com mais de 69 zonas de disponibilidade (AZs) em mais de 22 regiões geográficas em todo o mundo. Consulte a página de Infraestrutura Global para ver o número mais atual de Regiões de AZs.
Cada região da AWS fornece redundância, e contrário dos outros provedores de nuvem, que definem uma região como um único datacenter, as regiões da AWS consistem em várias zonas de disponibilidade, ou AZs (normalmente, três).
Cada AZ é uma partição totalmente isolada da infraestrutura da AWS composta por datacenters.
Cada datacenter conta com energia, redes e conectividade redundantes e está hospedado em instalações separadas.
Imagine, por exemplo, que uma Região poderia ser São Paulo, que teria 3 data centers fisicamente isolados (AZs), um em Campinas, outro em São Bernardo do Campo e outro no bairro da Lapa.
As AZs permitem alta disponibilidade, tolerância a falhas e escalabilidade em níveis superiores aos que um único datacenter pode oferecer.
As AZs são fisicamente separadas por uma distância significativa (vários quilômetros) de todas as outras AZs, embora todas estejam a um raio de até 100 km uma da outra.
Todas as AZs são interconectadas por redes de banda larga e baixa latência, usando fibra dedicada e totalmente redundante para proporcionar redes de alto vazão e baixa latência.
O desempenho da rede é suficiente para realizar a replicação síncrona entre as AZs.
A AWS associa um data center físico a AZ da sua conta ex: us-east-1, que não necessariamente é o mesmo data center físico de outra conta da AWS com esse mesmo nome, dessa forma a AWS faz um balançamento de carga entre os servidores.
Edge Locations
Além das Regiões e AZs a AWS também o Conceito de Edge Computing (em português, se traduz computação de borda).
A ideia básica é que você pode ter caching, distribuição de conteúdo estático e até funções lambda sendo executadas em locais adicionais que podem estar mais perto da request dos usuários gerando um latência reduzida para as requisições.
Por exemplo, a AWS não tem (pelo menos em Agosto de 2019) uma Região com AZs no Rio de Janeiro, mas tem um Edge Location na cidade que pode usado por esses serviços para atender requests com menor latência.
Fundamentos da Infra Global da AWS
Veja nessa palestra do re:Invent uma visão geral sobre a infraestrutura Global da AWS:
VPC
Uma VPC (Virtual Private Cloud) permite provisionar uma seção da Nuvem AWS isolada logicamente na qual é possível executar recursos da AWS em uma rede virtual que você mesmo define.
Você tem controle total sobre seu ambiente de redes virtuais, incluindo a seleção do seu próprio intervalo de endereços IP, a criação de sub-redes e a configuração de tabelas de rotas e gateways de rede. Você pode usar IPv4 e IPv6.
Você pode criar uma sub-rede pública para os servidores web que têm acesso à Internet e dispor os sistemas de back-end, como bancos de dados ou servidores de aplicativos, em uma sub-rede privada sem acesso à Internet.
Você pode usar várias camadas de segurança, incluindo grupos de segurança e listas de controle de acesso à rede, para ajudar a controlar o acesso às instâncias do EC2 em cada sub-rede.
Quando você cria uma VPC, é necessário especificar um intervalo de endereços IPv4 para a VPC sob a forma de um bloco, por exemplo, 10.0.0.0/16.
Uma VPC abrange todas as zonas de disponibilidade na região.
Atualmente há um limite de 5 VPCs que podem ser criadas por região em cada conta da AWS, consulte os limites atualizados.
Recomendo a seguinte palestras para você se aprofundar na VPC:
VPC e Subnets
Uma Sub-rede ou Subnet é um segmento de um intervalo de endereços IP da VPC onde é possível dispor de grupos de recursos isolados.
Depois de criar uma VPC, você pode adicionar uma ou mais sub-redes em cada zona de disponibilidade.
Ao criar uma sub-rede, você especifica o bloco CIDR para a sub-rede, que é um subconjunto do bloco CIDR da VPC.
Cada sub-rede deve residir inteiramente dentro de uma zona de disponibilidade. Cada sub-rede recebe um ID exclusivo.
Você também pode atribuir opcionalmente um bloco CIDR IPv6 a sua VPC e atribuir blocos CIDR IPv6 às suas sub-redes.
VPC e Internet Gateway
Um gateway da internet permite comunicação através da Internet, e uma conexão de rede privada virtual (VPN) permite comunicação com a rede corporativa.
Se o tráfego de uma sub-rede for roteado para um gateway de internet, a sub-rede será conhecida como uma sub-rede pública.
Se você desejar que a instância em uma sub-rede pública se comunique com a internet por meio do IPv4, ela deve ter um endereço IPv4 público ou um endereço IP elástico (IPv4).
Se uma sub-rede não tiver uma rota para o gateway da internet, a sub-rede será conhecida como uma sub-rede privada.
Se uma sub-rede não tiver uma rota para o gateway da Internet, mas tiver seu tráfego roteado para um gateway privado virtual de uma conexão do Site-to-Site VPN, a sub-rede será conhecida como uma sub-rede somente VPN.
O Internet Gateway é redudante e escala horizontalmente se necessário, sem risco de indisponibilidade ou limite de banda,
O Internet Gateway permite que as instâncias públicas sejam acessadas pela Internet, já as instâncias que possuem apenas IPs privados, permanecem com visibidade apenas dentro da VPC.
No caso de IPv6 todos os endereços na AWS são globalmente únicos e consequentemente públicos, nesses casos você pode usar um Egress Only Internet Gateway (gateway só de saída) para assegurar que apenas o trafego externo (outbond) seja permitido. Saiba mais.
NAT
Você pode usar um dispositivo NAT para permitir que instâncias em uma sub-rede privada da sua VPC se conectem à Internet (saída – por exemplo, para atualizações de software) ou a outros serviços da AWS, mas evitar que a Internet inicie uma conexão com essas instâncias (entrada).
O Internet Gateway conecta sua VPC a Internet e o NAT Gateway conecta sua Private Subnet (Subrede privada) a Internet.
O dispositivo NAT encaminha o tráfego para as instâncias na sub-rede privada para a Internet ou outros serviços da AWS e depois envia a resposta de volta às instâncias.
Quando o tráfego é encaminhado para a Internet, o endereço IPv4 de origem é substituído pelo endereço do dispositivo NAT; do mesmo modo, quando o tráfego de resposta volta para essas instâncias, o dispositivo NAT converte o endereço de volta nos endereços IPv4 privados dessas instâncias.
Os dispositivos NAT não são compatíveis com tráfego IPv6, somente IPv4 — no caso de IPv6 você não precisa de NAT, apenas do Internet Gateway de Saída (porque todo IPv6 na AWS é público por padrão).
A AWS oferece dois tipos de dispositivos NAT — NAT Gateway ou uma Instâncias NAT.
Os NAT gateway oferecem maior disponibilidade e largura de banda do que as instâncias NAT. É um serviço gerenciado criado em um AZ específico que não requer administração alguma e escala automaticamente sem que você precise se preocupar.
Um NAT gateway comporta atualmente 5 Gbps de largura de banda e escala automaticamente até 45 Gbps. Se você precisar de mais, é possível distribuir a carga de trabalho dividindo os recursos em várias sub-redes e criando um gateway NAT em cada sub-rede. Confira os limites atualizados.
Já a instância NAT é executada em uma AMI NAT no EC2, e você deve administrar e manter a instância manualmente.
NAT: Checagem de Origem e Destino
Por padrão, toda Instância EC2 executa verificações de origem e destino.
Isso significa que a instância deve ser a origem ou destino do tráfego que enviar ou receber.
Entretanto, a instância NAT deve poder enviar e receber tráfego quando ela não é a origem nem o destino.
Por isso, você deve desativar as verificações de origem/destino na instância NAT. Para isso bata desativar o atributo SrcDestCheck para a instância NAT em execução.
Roteamento (Routing) na VPC
Uma tabela de rotas (routing table) contém um conjunto de regras, ou rotas, que são usadas para determinar para onde o tráfego de rede deve ser direcionado.
Toda sub-rede (subnet) em sua VPC deve ser associada a uma tabela de rotas que controla o roteamento para a sub-rede.
Uma sub-rede só pode ser associada a uma única tabela de rotas por vez, mas é possível associar várias sub-redes a uma mesma tabela de rotas.
Toda tabela de rotas contém uma rota local para comunicação dentro da VPC por meio de IPv4.
Toda subnet precisa ter uma tabela de rotas principal (default). Você não pode excluir a tabela de rotas principal, mas pode substituí-la por uma tabela personalizada que você mesmo cria.
Se a VPC tiver mais de um bloco CIDR IPv4, as tabelas de rotas conterão um rota local para cada bloco CIDR IPv4 e se tiver associado um bloco CIDR IPv6 à VPC, as tabelas de rotas conterão uma rota local para o bloco CIDR IPv6. Você não pode modificar nem excluir essas rotas.
Border Gateway Protocol
Em se tratando de roteamento um outro conceito importante.
O BGP foi projetado para evitar laços de roteamento em topologias arbitrárias, o mais sério problema de seu antecessor, o EGP (Exterior Gateway Protocol).
O BGP permite o Roteamento Baseado em Política (policy-based routing), um roteamento com base em um conjunto de regras não técnicas, definidas pelos Sistemas Autônomos.
O GCP permite definir pesos diferentes para rotas diferentes, permitindo que a melhor rota tenha preferência quando houver mais de uma alternativa.
Dimensões e Máscaras
Ao criar uma VPC, você deve especificar um bloco CIDR IPv4 para a VPC.
O tamanho permitido para o bloco é entre uma máscara de rede /16 (65.536 endereços IP) e uma máscara de rede /28 (16 endereços IP).
Quando você cria uma VPC, recomenda-se que você especifique um bloco CIDR (de /16 ou menor) , ex:
10.0.0.0–10.255.255.255(prefixo 10/8)172.16.0.0–172.31.255.255(prefixo 172.16/12)192.168.0.0–192.168.255.255(prefixo 192.168/16)
O bloco CIDR de uma sub-rede pode ser igual ao bloco CIDR para a VPC (para uma única sub-rede na VPC) ou um subconjunto do bloco CIDR para a VPC (para várias sub-redes).
O tamanho do bloco permitido é entre uma máscara de rede /28 e máscara de rede /16.
/16= 255.255.0.0 = 65.024 Hosts
18= 255.255.255.240 = 16 Hosts
Se você criar mais de uma sub-rede em uma VPC, os blocos CIDR das sub-redes não podem se sobrepor.
Por exemplo, se você criar uma VPC com o bloco CIDR 10.0.0.0/24, ela oferece suporte a 256 endereços IP.
Você pode quebrar esse bloco CIDR em duas sub-redes, cada um oferecendo suporte a 128 endereços IP.
Uma sub-rede usa o bloco CIDR 10.0.0.0/25 (para endereços 10.0.0.0 – 10.0.0.127) e o outro usa o bloco CIDR 10.0.0.128/25 (para endereços 10.0.0.128 – 10.0.0.255).
Os primeiros quatro endereços IP e o último endereço IP em cada bloco CIDR de sub-rede não estão disponíveis para você usar e não podem ser atribuídos a uma instância. Por exemplo, em uma sub-rede com bloco CIDR 10.0.0.0/24, os seguintes cinco endereços IP são reservados:
10.0.0.0: Endereço de rede.10.0.0.1: Reservado pela AWS para o roteador da VPC.10.0.0.2: Reservado pela AWS.10.0.0.3: Reservado pela AWS para uso futuro.10.0.0.255: Endereço de transmissão de rede.
Você não pode aumentar ou diminuir o tamanho de um bloco CIDR existente. Por isso é importante é planejar-se antes da criação, a ferramenta gratuita SubNet Calculator pode te ser útil nessa tarefa.
O Modelo OSI
Especialmente para você quer deseja entender mais profundamente sobre redes ou quer obter as certificações da AWS é importante conhecer o funcionamento as 7 camadas do modelo OSI:
Para aprender mais, veja a explicação de Paulo Kretcheu para conhecer o modelo:
Em se tratando de gestão de infra-estrutura na Nuvem, as camadas 1 e 2 são de responsabilidade da AWS, e na maioria das vezes, você será responsável pelas demais camadas.
Protolocos da Camada 4
TCP: Um protocolo com estado, baseado em conexão que querer confirmação de recebimento, usado na Web, e-mail, FTP.
UDP: Sem conexão, sem estado, sem confirmação. Ideal para Streaming de Vídeo.
ICMP: Usado por equipamentos de rede, e comando como traceroute e ping.
Portas Efêmeras ou Dinâmicas
As portas efêmeras são portas utilizadas na comunicação entre computadores, e geralmente o sistema operacional reserva um determinado intervalo de portas para serem usadas de forma dinâmica, ou seja, a cada sessão, o número da porta utilizada pode variar.
Numa comunicação entre client e server, quando o client faz a requisição ao servidor ele pode enviar o número da porta efêmera que o servidor deve usar para retornar o conteúdo da requisição (request).
Muitos Kernels de Linux (incluindo o do Amazon Linux) usam portas 32768-61000 como Portas Efêmeras.
Solicitações originadas do Elastic Load Balancing usam as portas 1024 a 65535.
Os sistemas operacionais Windows até o Windows Server 2003 usam portas 1025-5000. O Windows Server 2008 e versões posteriores usam portas 49152-65535.
Um gateway NAT usa as portas 1024 a 65535. Por exemplo, se uma solicitação chegar ao servidor web de sua VPC de um client Windows XP na Internet, sua Network ACL precisará de uma regra de saída para permitir o tráfego destinado às portas 1025-5000.
Se uma instância em sua VPC for o cliente que está iniciando uma solicitação, sua Network ACL precisará de uma regra de entrada para permitir o tráfego destinado para as portas efêmeras específicas ao tipo de instância (Amazon Linux, Windows Server 2008 etc.).
Na prática, para abranger os diferentes tipos de client que podem iniciar tráfego para instâncias voltadas para o público em sua VPC, você pode abrir as portas efêmeras 1024 a 65535.
Você também pode adicionar regras à ACL para negar tráfego a qualquer porta mal-intencionado dentro do intervalo.
Conectando sua Rede na AWS
Há várias formas de conectar sua rede numa VPC da AWS. Essas opções de conectividade incluem o uso da Internet ou de uma conexão direta (AWS Direct Connect):
- AWS Managed VPN – Estabelece uma conexão VPN de seu equipamento de rede em uma rede remota para o equipamento de rede gerenciado pela AWS e anexado a sua VPC.
- AWS Direct Connect – Estabelece uma conexão lógica e privada de sua rede remota com a VPC, usando conexão direta de seu provedor com o backbone da AWS. Há uma série de provedores parceiros da AWS que suportam Direct Connect tais como Equinix, UOL e Tivit. Veja a lista completa.
- AWS Direct Connect + VPN – Estabelece uma conexão criptografada privada de sua rede remota para a VPC com AWS Direct Connect.
- AWS VPN CloudHub – Estabelece de um modelo hub-and-spoke para conectar filiais remotas.
- VPN via Software – Estabelece uma conexão VPN de seu equipamento em uma rede remota para um appliance VPN de software gerenciado pelo usuário em execução numa VPC. Esse modelo é extramemente flexível, mas você precisa tomar conta da instalação do software e da redundância manualmente.
- Transit VPC – Estabelece uma rede de trânsito global na AWS usando o software VPN em conjunto com a VPN gerenciada pela AWS. Ideal para organizações que precisam conectar redes espalhadas em diferentes regiões geográficas.
- Transit Gateway: O AWS Transit Gateway é um serviço que permite que os clientes conectem suas VPCs e suas redes locais a um único gateway. Hoje você pode conectar pares de Amazon VPCs usando VPC Peering, mas, gerenciar a conectividade ponto-a-ponto em muitas da Amazon VPCs, sem a capacidade de gerenciar centralmente as políticas de conectividade, pode ser oneroso e complicado em termos operacionais. Com o Transit Gateway, você só precisa criar e gerenciar uma única conexão do gateway central a cada Amazon VPC, datacenter ou ponto de rede. O Transit Gateway atua como um hub que controla como o tráfego é roteado entre todas as redes conectadas.
Para aprender mais sobre esse tema confira o WhitePaper Amazon Virtual Private Cloud Connectivity Options.
Conectando diferentes VPCs
É como também a necessidade de integrar várias VPCs da Amazon em uma rede virtual maior. Isso é útil se você usar mais de uma VPCs devido à por segurança, por estar presente em diferentes regiões, por usar mais de uma contas da AWS na sua empresa.
Você também pode combinar esses padrões com as opções de conectividade Network-to-Amazon VPC para criar uma rede corporativa que abranja redes remotas e várias VPCs.
A conectividade VPC funciona melhor quando se utiliza intervalos IP não sobrepostos para cada VPC. Recomenda-se a alocação de um único bloco CIDR, não sobreposto, a ser usado por cada VPC.
Essas são opções de conectividade entre VPCs na AWS:
- VPC Peering: Aproveita o backbone da AWS (não usa internet), não depende de instâncias de VPN ou de um hardware físico separado, não tem ponto único de falha (SPOF), não tem gargalo de largura de banda, como limitação o emparelhamento de VPC não oferece suporte a relacionamentos de pareamento transitivo (ou seja, se a VPC A fala com B e a B fala com a C, a A não fala com a C). É possível parear VPCs da mesma conta da AWS ou em contas distintas.
- Private Link: Permite conectar serviços em diferentes VPCs da AWS através de endpoints de interface, usando o backbone da AWS. Usados por serviços como DynamoDB, S3, API Gateway, CloudFormation, etc.
Recomendo as seguintes palestras para você se aprofundar na gestão de múltiplas VPCs:
Otimizando Performance de Rede
Se você tem necessidade de performances de rede muito acima do normal, a AWS oferece alguns recursos interessantes para esses casos de uso.
A AWS tem instâncias de servidores otimizadas para rede com Network Adapters de 10Gb ou 25Gb, se você tem esse requisito certifique-se de escolher uma dessas instâncias com as i3, por exemplo.
Um deles são os Placements Groups, que garantem que diversos servidores fiquem próximos um do outro garantindo baixa latência entre os servidores. Há um limite de 7 instâncias num Placements Group por AZ (21 instâncias numa região com 3 AZs) Confira os limites atuais.
DNS e Route 53
A grosso modo, o DNS (Domain Name System) é o que permite que o seu domínio na Internet (ex: andrefaria.com) seja roteado para um determinado servidor que responde com o devido conteúdo ou serviço como envio e recebimento de e-mails, website, FTP, etc.
Para isso o servidor de DNS deve armazenar uma série de registros. Existem diversos tipos de registros com diferentes finalidades, os principais são:
- A (Host address)
- AAAA (IPv6 host address)
- ALIAS (Auto resolved alias)
- CNAME (Canonical name for an alias)
- MX (Mail eXchange)
- NS (Name Server)
- TXT (Descriptive text)
Na AWS, o Route 53 é o serviço para você fazer a gestão de DNS, ele permite que você registre domínios, faça o roteamento dos domínios para recursos da AWS, e performa Health Checks.
O nome desse serviço é Route 53 porque a porta de serviço do DNS é a de número 53.
Os registros de alias do Route 53 fornecem uma extensão específica à funcionalidade do DNS e permitem que você roteie o tráfego para recursos da AWS selecionados, como CloudFront, S3 e EC2.
Uma zona hospedada (Hosted Zone) é um contêiner para registros de DNS, e os registros contêm informações sobre como você quer rotear o tráfego para um domínio específico, como andrefaria.com e seus subdomínios (blog.andrefaria.com, intranet.andrefaria.com). Uma zona hospedada e o domínio correspondente têm o mesmo nome. Há dois tipos de zonas hospedadas: privada (private) para trafego dentro da VPC, e pública para trafego aberto a internet.
O Route 53 permite que você defina uma série de políticas para distribuição do trafego, alguns deles são.
- Simples: Simplesmente passa o trafego para o destino.
- Failover: Roteia se o health check da principal falhar.
- Geolocation: Roteia para o mais próximo do client.
- Latency: Roteia para a menor latência.
- Multivalue: Distribiu para múltiplos destinos (round-robin).
- Weighted: Distribui para diferentes destinos de acordo um percentual pré-definido (ex: 70% – 30%).
Confira também o post sobre segurança na AWS.
Elastic Load Balancer
O Elastic Load Balancing (ELB) distribui automaticamente o tráfego de entrada de aplicativos entre diversos destinos, como instâncias do EC2, contêineres, endereços IP e funções Lambda.
O serviço pode lidar com a carga variável de tráfego dos aplicativos em uma ou em diversas zona de disponibilidade (AZs).
O Elastic Load Balancing oferece três tipos de load balancers, todos eles com a alta disponibilidade, a escalabilidade automática e a segurança robusta necessárias para tornar os aplicativos tolerantes a falhas.
O ALB, Application Load Balancer atua na Camada 7 (Aplicação), o Network Load Balancer na Camada 4 (Transporte), e o Classic Load Balancer em qualquer uma das duas.
O Application Load Balancer é mais adequado ao balanceamento de carga de tráfego HTTP e HTTPS e oferece roteamento avançado de solicitações para a entrega de arquiteturas modernas de aplicativos, incluindo microsserviços e contêineres. O Application Load Balancer roteia tráfego a destinos dentro de uma VPC.
O Network Load Balancer é mais adequado ao balanceamento de carga de tráfego TCP (Transmission Control Protocol), UDP (User Datagram Protocol) e TLS (Transport Layer Security) que exige performance muito alta.
Operando no nível de conexão (camada 4), o Network Load Balancer roteia tráfego para destinos dentro da VPC e é capaz de lidar com milhões de solicitações por segundo, mantendo latências muito baixas.
O ALB, dá suporte a Sticky Session e SNI, além de Path e Host Based Routing, o NLB por estar em camada mais baixa não, sendo o roteamento feito principalmente por número de porta. O NLB tem menos funcionalidades, mas naturalmente, oferece maior desempenho.
Você pode usar o ELB para endpoints públicos, mas também para privados.
Veja essas palestras de Deep Dive no ELB e no NLB para aprender mais sobre Load Balancing na AWS:
Cloud Front
O Amazon CloudFront é um serviço rápido de rede de entrega e distribuição de conteúdo (CDN) que entrega dados, vídeos, aplicativos e APIs, globalmente, com segurança, baixa latência e altas velocidades de transferência.
O CloudFront funciona de forma transparente com serviços como AWS Shield para mitigação de ataques DDoS; Amazon S3, Elastic Load Balancing ou Amazon EC2 como origens para os aplicativos; e Lambda@Edge para executar código personalizado mais perto dos usuários dos clientes e personalizar a experiência dos usuários.
Por fim, se você usar origens na AWS, como Amazon S3, Amazon EC2 ou Elastic Load Balancing, a transferência de dados entre esses serviços e o CloudFront não será cobrada.
Em se tratando de redes os conceito mais importantes do Cloud Front são referentes a criptografia dos dados em transito, e para isso há duas soluções IP Dedicado e SNI.
A Indicação de Nome de Servidor (SNI – Server Named Indication) é uma extensão do protocolo TLS, compatível com os navegadores e clientes lançados após 2010. Se você configurar o CloudFront para atender a solicitações HTTPS usando SNI, o CloudFront associará seu nome de domínio alternativo a um endereço IP para cada ponto de presença.
Quando um visualizador envia uma solicitação HTTPS para seu conteúdo, o DNS a roteia para o endereço IP do ponto de presença correto.
O endereço IP para o seu nome de domínio é determinado durante a negociação do handshake SSL/TLS.
Com SNI, o endereço IP não é dedicado à sua distribuição.
Se você optar por IP Decidado em vez de SNI, porque tiver usuários que não podem fazer a atualização para um navegador ou cliente lançado após 2010,
Se você configurar o CloudFront para atender a solicitações HTTPS usando endereços IP dedicados, será cobrado um adicional por mês. A cobrança começará quando você associar seu certificado SSL/TLS a uma distribuição e habilitar a distribuição.
Aprenda mais sobre o Cloud Front assistindo a essa palestra apresentada no re:Invent:
Conclusão
Um bom design de redes na nuvem é essencial para suporta e aumentar a segurança eu suas aplicações. Em aplicações cada vez mais distribuídas pensar é fundamental pensar na comunicação em rede, e conhecer VPCs, VPN, Netowork ACLs é essencial.
