Era hora de evoluir para uma arquitetura mais avançada, como pode ser visto no diagrama abaixo:

Parece complicado certo? Mas vamos explicar pouco mais sobre este conceito:

VGW

O “Virtual Gateway” é um componente lógico (e sem custo) na AWS que conecta a VPC às redes externas. Assim é possível configurar rotas, estáticas ou dinâmicas, em minha tabela de roteamento, para alcançar redes externas.

VPN:

A AWS possuí um serviço chamado “AWS Site-to-Site VPN“, que é uma VPN Gerenciada L2TP (as conhecidas VPN IPSec), que você pode configurar em apenas 5 minutos, já com redundância, exportar o arquivo de configuração do roteador/firewall OnPremises e a partir daí já está pronto para aplicar, ou enviar para seu parceiro. Esse serviço suporta roteamento estático e dinâmico via BGP, que é opcional. Podemos também configurar a VPN em uma instância EC2, nesse caso usamos um Appliance terceiro (ou um Linux). EExistem diversas opções sem custo, também é possível usar soluções de mercado disponíveis no AWS Marketplace, como PFSense, Fortinet, Sophos, Cisco, entre outros.
Peering: Se a necessidade é conectar redes AWS, com o VPC Peering, conseguimos enviar um convite para outro VPC, uma vez aceito, rotas podem ser configuradas. É importante saber/lembrar que as redes não podem conflitar (overlaping). O VPC Peering não tem custo, é pago apenas a transferência de dados realizada por ele.

Com isso percebemos que não só conseguimos realizar tudo que fizemos na camada de rede fora da Cloud, como ganhamos diversos recursos e benefícios inerentes antes indisponíveis.

Como próximo passo, surgiu a necessidade de migrar o ambiente produtivo da Corretora de Valores, a Mirae Asset Securities CCTVM para AWS. O que incluí não apenas workloads corporativos tradicionais como FileServer, Active Directory, Exchange e Aplicações WEB, mas também workloads específicos do mercado financeiro, como SINACOR, Order Management System (OMSs), Marketdata e Sistemas de Risco com bancos de dados em Oracle, SQL e MySQL.

Um ambiente híbrido de alta performance, resiliência e disponibilidade foi requerido, devido a características desse mercado, como:

• Necessidade de interligação com Bolsa de Valores (B3) via “Rede de Comunicação BM&FBOVESPA” (RCB);
• Interconectividade com Banco Central e outros órgãos financeiros (via RTM);
• Uso de Multicast para o Marketdata (UMDF);
• Transição entre OnPremises e AWS;

Com isso, mais uma leva de perguntas tiveram que ser respondidas:

• Posso me conectar fisicamente à AWS? Mas é muito caro, certo?
• E para interligar com Regiões diferente de São Paulo?
• Mas a latência não é alta?
• Preciso me conectar via sub-redes públicas certo? (Não, rs!)
• Como fica a questão de redundância?
• E o DNS, dentro do VPC o DNS é deles certo? Mas eu uso DNS Interno (nesse caso via Windows DNS)
• Sei que é uma boa prática usar várias contas AWS, preciso de vários Links?

Para responder a essas perguntas, trazemos o diagrama com suas modificações necessárias para atender as demandas requeridas:

Vamos aos componentes e seu entendimento:

Direct Connect(DX): Você precisa contratar da AWS (tudo via console, ou API) e se conectar fisicamente até um dos pontos de presença utilizando uma operadora;
Private VIF: É a interface virtual do lado da AWS para conexão com o rotador do ambiente OnPremises. Através do IP do VIF, estabelecemos uma sessão BGP (sim BGP é um pré-requisito para uso de Direct Connect)
Public VIF: É possível subir uma sessão BGP para alcançarmos os serviços públicos AWS (todos IPs públicos da AWS), via Direct Connect, dessa forma, não usamos nem os links de Internet OnPremises, nem Data Transfer Out no VPC. Funciona como um PPT entre sua estrutura OnPremises e a rede pública da Amazon. É possível inclusive subir a VPN por essa conexão, assim temos uma camada extra de criptografia, além de servir de redundância para o caso de falhas nos links físicos.
Direct Connect Gateway (DX-GW): É um recurso lógico da AWS (sem custo) que pode ser utilizado para conectar 1 VIF a vários VGW, logo várias VPCs.

Na América Latina os únicos pontos de presença de Direct Connect são:

• Tivit São Paulo
• Equinix São Paulo (SP4)
• Equinix Rio de Janeiro (RJ2)

É possível subir o link diretamente com uma região diferente de São Paulo, a Equinix, por exemplo, possui esse serviço, mas os custos fixos são elevados. Se conectando via São Paulo, a comunicação com outras regiões é segura e isolada, porém pagamos o valor de Data Transfer entre regiões, de São Paulo para Virgínia do Norte (EUA) por exemplo é 0,04 extra por GB.

Os custos são compostos por para implantação de Direct Connect são:

1. Direct Connect (AWS): Os custos são compostos de valor hora/mês pela conexão/interface e transferência utilizada. Detalhes de custo em link;
2. Operadora: Link de conectividade para chegar até um dos pontos de presença;
3. Customer Gateway: Roteador ou firewall OnPremises com suporte à BGP.

Note que a transferência de dados é mais barata via Direct Connect do que via Internet. Para São Paulo, por exemplo, o custo Data Transfer Out para Internet é de $0,25, enquanto dentro do Direct Connect é $0,11 ( ou seja, 56% mais econômico). Temos notado em cenários de clientes que assim como a Mirae Asset, que com $1.000 de Data Transfer que podem ser roteados via Direct Connect, os custos de conexão (links, interface, etc) “se pagam”.

“Mas o Direct Connect não tem redundância?”

Tem sim, se dermos um Zoom nesse ponto, vemos que não somente temos redundância via VPN, como também de links físicos com Direct Connect:

Além disso, no diagrama acima, conseguimos visualizar que é possível interligar contas diferentes com VIFs diferentes, existe a possibilidade de fazer isso entre VGW x DX-GW, mas essa é uma discussão para um outro post.

Direct Connect Dedicado x Hosted

Essa é uma dúvida bem recorrente também: “qual usar? E quais são as diferenças de ambos para nosso cenário?”
A resposta mais direta para essa pergunta é:
“No dedicado, você chega até um desses datacenteres, e contrata um cross-connection (Golden Jump) até o equipamento da AWS com 1 ou 10Gbps, e tem 50 VIFs por conexão. Já no “Hosted” ou compartilhado, a operadora (Parceiro de Direct Connect, como Telium, Mundivox, Embratel, Algar, etc) se conecta à AWS e te oferece 1 VIF entre 50 e 500Mbps.”

Sendo assim, é preciso entender sua arquitetura, pois em geral o Direct Connect Dedicado tem mais funcionalidades, mas traz um custo um pouco maior, além da gerência, que no Direct Connect Hosted, costuma ter gestão completa feita pelos Parceiros de Direct Connect, ou pela Darede .

DNS

Para resolução de nomes DNS, também há diversas soluções que variam desde o uso de seus próprios servidores DNS, OnPremises ou na AWS, até a integração do serviço de DNS da AWS, Route53 com suas zonas internas para ter o melhor das duas tecnologias! Mas esses detalhes também ficarão para um próximo post.

Além disso na AWS temos diversos outros recursos como o VPC Flow logs que registra todas as conexões que passam pelo VPC, VPC Port Mirror, ferramentas de detecção de ameaças como o GuardDuty, Web Application Firewall.

Dessa forma chegamos em um cenário onde temos a transição entre OnPremises para Cloud, aproveitando os benefícios dos dois mundos com escalabilidade, alta performance, alta disponibilidade, ótimos níveis de segurança e custos alcançáveis ao negócio.

Quer conhecer mais nossos projetos ou trabalhar com a Darede? Estamos procurando clientes e profissionais interessados em viver esse mundo de inovações conosco!

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.

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.