Descomplicando Rede e Conectividade – Parte 1
Quase sempre que falamos sobre redes na AWS, diversas dúvidas surgem, desde as mais simples até as mais complexas. Eu costumo dividir as dúvidas em três categorias:
1. Cloud Native: Do ambiente corporativo padrão mais tradicional, à startup mais ‘modernesca’, sempre há dúvidas e aquela sensação de desconhecimento mesmo com o ambiente operacional;
2. Integração com OnPremises: Em geral essas dúvidas são de clientes com ambiente corporativo maduro, e as dúvidas vêm das diferenças entre redes tradicionais e Cloud Native, além é claro de “como se conectar fisicamente às AWS”;
3. Serviços Integração: O campeão aqui é DNS, mas há diversas dúvidas com Load Balancer, Endpoints e WAF são uma grande interrogação na cabeça de muitos;
Com o grupo Mirae Asset não foi diferente. As dúvidas sempre existiram, desde o primeiro projeto (Cloud Native), passando por interligações com VPN Site-to-Site, até uma estrutura complexa, com arquitetura híbrida, Direct Connect triplamente redundante, para operações financeira de alta performance e baixa latência.
Nesse post vamos tentar esclarecer o maior número de dúvidas possíveis, tendo em vista a realidade da Mirae Asset, sua trajetória na adoção de Cloud, focada no mercado latino americano e nossas realidades.
A Mirae Asset é um grupo multinacional Coreana de serviços financeiros. Composto por diversas células de negócio: Banco de Investimentos, Gestora de Fundos, Seguradora, Corretora e Gestora de Patrimônio. A Mirae Asset está em 15 países, com mais de 25 escritórios espalhados pelo mundo. No Brasil o grupo conta com a “Corretora de Valores” e “Gestora de Fundos”, ambas são atendidas pela Darede a muitos anos.
O primeiro workload que subimos na Mirae Asset, foi uma aplicação para hospedar uma aplicação web, sem integração com o ambiente OnPremises. Apesar de ser uma aplicação Cloud Native, as dúvidas começaram a aparecer:
• Mas vai ficar tudo público?
• É seguro?
• Posso instalar um firewall? (acredite, em diversos casos você não precisará de um firewall rs)
• Posso segregar o banco de dados, backend e frontend?
• Eu subi uma instância EC2 com IP Público, mas ela só tem IP Privado, por quê?
• Qual a velocidade do link de Internet e seu preço?
Quando recebo um “set” de pergunta dessa, posso responder tranquilamente: “Fique tranquilo, todas as respostas serão as que você espera!”
O diagrama abaixo representa uma arquitetura padrão, implementada na maioria dos nossos clientes e que atende quase todos os cenários:
Com o diagrama na mão, vamos as explicações:
VPC: É como um Switch Core (L3) em uma Região, porém estendido em múltiplos Datacenters (ou Avaliabilty Zones, as AZs);
Sub-redes: Elas são como as VLANs em uma rede OnPremises, uma sub-rede só pode estar em um Datacenter. Por padrão, todas as sub-redes de um mesmo VPC tem conectividade entre elas.
Tabelas de Roteamento: É aqui que definimos que uma sub-rede é mesmo pública ou privada, o que determina isso é a rota que existe, principalmente para default gateway (“0.0.0.0” e “::/0”). Fica claro aqui, que podemos ter redes totalmente isoladas, se decidirmos dessa forma e assim configurarmos.
IGW: O Internet Gateway é a interconexão mais usada entre a rede privada e a Internet na AWS. Somente com o uso de IGW, você consegue acesso originado na Internet para um recurso com IP Público no VPC, uma vez que é apenas por um deles que IPs Públicos funcionam para expor serviços privados (novamente, podemos filtrar por porta, origem, etc com Security Group).
NAT Gateway ou NAT Instance: É um recurso que permite que serviços internos ao VPC acessem serviços na Internet, usando Source NAT (Tradução de Endereço IP de Origem). Porém, requisições originadas na Internet, não alcançam os serviços internos à VPC. NAT Instance é quando usamos uma instância EC2 (Windows, Linux, FreeBSD, etc) para essa função, é assim que implementamos um Firewall Appliance (Fortinet, Sophos, Cisco, etc). Já NAT Gateway é um serviço gerenciado pela AWS que realiza essa função.
Serviços Públicos: Alguns serviços da AWS são originalmente públicos, esses serviços funcionam sem o VPC (mas veremos mais a frente que funcionam também com VPC), é claro que há outros controles para garantir a segurança, mas é importante entender essa característica. São exemplos de serviços originalmente públicos: S3, SQS, SNS, DynamoDB, CloudFront, Secret Manager, Rekognition e outros. Lambda é um exemplo de serviço que não suportava VPC e agora suporta.
IPs Privados: Como no mundo OnPremises, são IPs não roteados à Internet e são distribuídos em TODAS as sub-redes, o que incluí nos servidores (EC2).
IPs Públicos: São IPs acessíveis apenas no IGW, a AWS faz um NAT 1:1 para o “IP Privado” do recurso ao qual o “IP Público” foi associado. É assim que mesmo com IP privado, conseguimos alcançar uma instância EC2 pelo seu IP público.
Além disso há camadas extras de segurança, como “Security Group”, que são regras de firewall statefull em cada recurso, ou ACL, que são regras de firewall stateless que funcionam no nível de todo o VPC.
A boa notícia, além de perceber como é flexível rede na AWS, é que todos esses serviços podem ser usados sem custo (identifiquei com “$” quando houver cobrança), pois o modelo de cobrança é por uso, você paga por dados (bytes) transferidos, de dentro para fora da VPC, para o contrário não há cobrança. Outra boa notícia que é não há limitação de transferência na sua rede da AWS. Sim, você tem acesso a banda do backbone AWS para download e upload! As limitações são os gargalos convencionais, como uma interface de rede de uma instância/servidor e escrita em disco.
AWS Endpoints
E se eu precisar usar serviços AWS que respondem somente publicamente? Para isso existem os ‘endpoints’, que são como gateways que te levam aos serviços da AWS sem passar pela Internet, sem necessidade de IGW ou NAT como demostrado abaixo:
Tão logo a Mirae Asset percebeu as vantagens no uso da AWS, e o gosto por Cloud cresceu e surgiu a necessidade de trazer outros workloads para Cloud, alguns desses precisavam de conectividade com o ambiente físico para projetos como “Disaster Recovery Site” e “Backup em Cloud”. A necessidade de uma rede hibrida surgiu, e com ela outras tantas dúvidas do time de TI também surgiram:
• Como interligar OnPremises e AWS de forma segura?
• Como fica a redundância?
• Preciso usar a Região São Paulo para algumas aplicações, mas queremos usar outras Regiões para outros workloads;
• Como conectar duas VPCs AWS?
Era hora de evoluir para uma arquitetura mais avançada. Em breve parte 2!