Mongo Atlas, porque utilizar o recurso de VPC Peering no seu cluster?
Tags: mongodb, aws, convenia, architecture
Published: 2022-12-29 12:39:52

---
canonical_url: https://coodesh.com/blog/candidates/mongo-atlas-por-que-utilizar-o-recurso-de-vpc-peering-no-seu-cluster/
---

Nesse post quero compartilhar uma dica bem valiosa que adotamos na [Convenia](https://convenia.com.br). Nossa stack é composta de microserviços e utilizamos extensamente MongoDB e RabbitMQ, esse último para comunicação entre os serviços, como mostrado [nesse post](https://imasters.com.br/php/aprenda-agora-arquitetura-event-driven-com-laravel-pigeon).

Toda infra da Convenia roda dentro da AWS e a AWS não tem uma boa opção gerenciada de MongoDB ou RabbitMQ, então utilizamos o [ Mongo Atlas](https://www.mongodb.com/atlas/database) e o [CloudAmqp](https://www.cloudamqp.com/) para aliviar o trabalho de manutenção nesses serviços.

## Problemas
Vamos tomar como exemplo a comunicação entre o serviço gerenciado do Mongo Atlas e a nossa aplicação, após provisionar tudo da maneira mais simples devemos chegar a essa arquitetura:


![Diagrama Mongo Atlas sem VPC Peering](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/phc8xmngjxws55uesr9l.png)

Na verdade isso funciona relativamente bem, a aplicação funcionaria de maneira aceitável no entando parece um caminho longo da nossa aplicação(API) até o banco de dados o que não é o ideal, na verdade o banco de dados deve ficar o mais "perto" possível da nossa aplicação, na arquitetura acima eu consigo pontuar alguns problemas:

1. Custo: o [NAT gateway](https://docs.aws.amazon.com/pt_br/vpc/latest/userguide/vpc-nat-gateway.html) faz parte de toda arquitetura de rede que inclui uma subnet privada, a grosso modo ele é responsável por prover acesso à internet aos componentes internos da rede. O gande problema é que esse NAT é um elemento caro na infraestrutura pois tem um custo apenas por existir(pois tem ip público) e também cobra um custo relativo ao tráfego que passa por ele. No nosso caso os dados da nossa aplicação estão passando por ele para chegar ao MongoDB, o mesmo não aconteceria se o banco estivesse dentro da mesma subnet da aplicação, nesse caso a aplicação conseguiria conversar diretamente com o banco.

2. Performance: Claro, sair pelo internet gateway para internet e passar "sei la por onde" até chegar no nosso banco de dados vai introduzir um pouco de latência e naturalmente diminuir a resiliência da aplicação, o mesmo não aconteceria com um banco na mesma subnet da nossa aplicação.

3. Segurança: De todos os pontos, este é o item mais preocupante, principalmente no caso da Convenia que trafega dados pessoais em época de LGPD. A conexão entre a aplicação e os serviços externos é criptografada, isso significa que é relativamente segura pois mesmo se o tráfego for interceptado os dados não podem ser acessados. Mas mesmo com a criptografia é desconcertante ter o tráfego suscetível a um ataque, seria melhor se esses dados nem passassem pelo mundo externo.

## Solução

Pensando bem, nosso cluster de MongoDB está provisionado dentro da AWS, nossa aplicação também está dentro da AWS, nossa aplicação realmente precisa fazer toda essa volta para chegar até o banco? Para o nosso bem a resposta para essa pergunta é "não", quase todos os possíveis serviços que você pode pensar em consumir oferecem uma maneira de garantir que a comunicação com eles permaneça inteiramente dentro da AWS, a maneira mais comum é o [VPC Peering](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html) que tanto o [Mongo Atlas](https://www.mongodb.com/docs/atlas/security-vpc-peering/) quanto o [CloudAmqp](https://www.cloudamqp.com/blog/amazon-vpc-peering.html) fornecem. O [Datadog](https://www.datadoghq.com/) por exemplo fornece um [endpoint](https://docs.datadoghq.com/agent/guide/private-link/?tab=useast1) para acesso direto, dessa forma todo o tráfego permanece dentro da rede interna da AWS e nem passa pelo NAT Gateway.


![Diagrama Mongo Atlas com VPC Peering](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/zgkkzj42gm3e1q74oe1j.png)

Após criar o VPC Peering do Mongo Atlas como [nesse passo a passo](https://www.mongodb.com/docs/atlas/security-vpc-peering/), chegamos na arquitetura acima, essa arquitetura é muito mais segura, performática e elimina o custo do NAT Gateway. A outra arquitetura nem deveria ser considerada, principalmente se a empresa trabalha com dados sensíveis. Perceba que no diagrama acima nem aparecem os "Internet Gateways", isso porque a partir de agora a aplicação vai consumir a aplicação diretamente através do Peering.

Com relação aos problemas apontados anteriormente, uma vez que não precisamos mais sair para internet para chegar até nosso banco de dados, o custo com Tráfego do Nat Gateway deve reduzir, talvez se nossa aplicação não precisar de algum outro recurso interno seria possível até remover o NAT Gateway.

O banco de dados já estava próximo à nossa aplicação, nossa aplicação apenas não conseguia chegar até ele da maneira mais fácil, após fazer o Peering nossa aplicação passa a conhecer o melhor caminho até o banco, ficando a poucos saltos do banco e melhorando a performance e resiliência.

Por último devemos notar que agora é impossível de um elemento desconhecido interceptar o tráfego entre nossa aplicação e o banco, isso diminui muito a superfície de ataque que um suposto Hackerzinho malvado poderia utilizar.

## Últimas configurações

Agora já conseguimos atingir 90% dos nossos objetivos, mas para finalizar precisamos impedir que o Mongo Atlas seja acessível externamente. Geralmente esse tipo de serviço gerenciado relacionado a infraestrutura tem uma área de Network como a do Atlas:


![Configurando regras de acesso ao cluster de mongo](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/kyt701oqp3zzbxoqjytd.png)

A imagem acima contém as regras de acesso da Convenia para o Atlas, temos dois peerings logo temos 2 regras de acesso permitindo apenas acessos vindos das 2 VPCs da Convenia. Aqui o ideal é remover qualquer regra permitindo o intervalo `0.0.0.0/0`, esse intervalo permite acesso global ao cluster.

## Conclusão

A utilização de recursos como VPC Peering e VPC Endpoints podem aumentar a performance e melhorar a segurança da sua aplicação, bem como diminuir o custo com tráfego no Nat gateway. Aliás mantenha distância do Nat gateway, saia para internet apenas quando for realmente necessário.