Quase sempre que falamos sobre redes na AWS, todos os tipos de dúvidas aparecem. Eu costumo dividi-las em três categorias:

1. Cloud Native: Do ambiente corporativo tradicional a startup mais descolada, sempre há dúvidas. Também somada àquela sensação de desconhecimento com o ambiente operacional, esta questão traz uma certa insegurança para os clientes.
2. Integração com OnPremises: Normalmente as dúvidas daqui são de clientes vindos de um ambiente corporativo maduro, eles querem saber quais são as diferenças entre as redes tradicionais e o Cloud Native, além de “como se conectar fisicamente às AWS”;
3. Serviços Integração: O campeão aqui é o DNS, mas há diversas dúvidas com Load Balancer, Endpoints e WAF. Estes serviços costumam se tornar um grande ponto de interrogação na cabeça dos clientes.

Com o grupo Mirae Asset não foi diferente. As dúvidas existiram desde o primeiro projeto (Cloud Native), passando também por interligações com VPN Site-to-Site, até uma estrutura complexa, com arquitetura híbrida, Direct Connect triplamente redundante, para operações financeiras de alta performance e baixa latência.

Nesse post tentaremos sanar o maior número de dúvidas possíveis, criando uma relação à realidade da Mirae Asset e sua trajetória na adoção de Cloud focada no mercado latino-americano e a realidade da Darede.

A Mirae Asset

A Mirae Asset é um grupo multinacional coreano 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 trabalha com a células: corretora de valores e gestora de fundos. No Brasil o grupo é atendido pela Darede há muitos anos.

O primeiro workload que realizamos 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, algumas questões 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)
• 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 uma variedade de perguntas como estas, eu digo: “Fique tranquilo, todas as respostas serão aquelas 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:

Agora 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 se uma sub-rede é 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), claramente há outros controles que garantem 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 antigamente não suportava VPC, mas agora suporta.

• IPs Privados: Assim 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.

Dito isso, há duas boas notícias.

A primeira boa notícia, além de perceber como é flexível rede na AWS, é que todos esses serviços podem ser usados sem custo, pois o modelo de cobrança é por uso, você paga por dados (bytes) transferidos de dentro para fora da VPC, do contrário não há cobrança. A segunda 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, o interesse pelo Cloud cresceu surgindo 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 algumas dúvidas do time de TI também apareceram:
• 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. Clique aqui e confira a parte 2!

Flávio Rescia
CTO & Co-Fundador
flavio.rescia@darede.com.br

Sócio Fundador da empresa Darede, graduado em Redes de Computador e Sistemas de Informação, docente em Redes de Computadores no SENAI e hoje ministra diversos treinamentos de serviços AWS. Possuí vasta experiência com provedores de Internet, tecnologia para mercado financeiro e Cloud Computing.