Executando verificação de segurança...
1
Nalla
1 min de leitura ·

Subir uma API + DB em uma única instância EC2 é uma boa?

Saudações, comunidade TabNews!

Estou desenvolvendo uma aplicação (um sistema web jurídico) e atualmente estou avaliando as opções de deploy.

Como meu orçamento é baixo, quero economizar o máximo possível. Por isso, optei por hospedar o front-end (Next.js) na Vercel, aproveitando o plano gratuito, e a API na AWS, que oferece 12 meses de uso free.

Pensando já no futuro, estou analisando as formas de manter o custo o mais baixo possível na AWS. Como as primeiras versões do meu sistema serão simples (um MVP), pensei em subir tanto a API quanto o banco de dados (PostgreSQL) em uma única instância EC2, cada um rodando em um container Docker.

Gostaria de saber se essa abordagem é viável para um MVP e quais cuidados devo ter em relação à segurança e disponibilidade — mesmo sabendo que, inicialmente, o número de acessos será minimo.

Além disso, a migração do banco para o RDS seria simples quando for necessário escalar?

Não tenho muita experiência com deploy, então ficaria muito grato por dicas, sugestões e opiniões de quem já passou por algo parecido! 🙏

Carregando publicação patrocinada...
1
lecioneto

A máquina é fraca principalmente se o processamento for diretamente proporcional a quantidadede usuários. Tenho WordPress com milhares de acesso nela usando cloudflare cacheando tudo na frente. No caso de API sugiro dar uma olhada no projeto supabase. Tem plano free e tudo que precisa pro back e front.

1
cassioscofield

Não é uma ideia ruim, mas há outros se o objetivo é redução de custo também após os primeiros 12 meses há outras opções melhores.
A AWS é gratis os primeiros 12, nas extremamente cara depois disso e mesmo a máquina gratis é bem ruinzinha, tem outras opções que começam gratis ou muito baratas e depois não são tão caras para manter de forma perene.
Algumas opções: fly e aiven ainda tem planos gratis, heroku e hostinger não tem mais planos gratis, mas são apenas por volta 5-10$/mês.

1
g00dev

Cara onde?! Com 9 dólares ele roda numa instância boa. Se souber das manhas, depois de 12 meses consegue rodar ate com 1 dólar um backend que use até 2 GB de RAM (eu faço isso há anos).

E a instância micro é ruim onde?! Só se for pra quem não sabe programar e usa low code. Aí até instância com 16 GB de RAM não dá conta 😂

1
cassioscofield

A instância micro tem apenas 1gb de RAM e para rodar ela em SP o valor é mais próximo a 13$/mês, como eu mencionei, não é ruim, mas você consegue uma máquina melhor por pouco mais da metade do preço em outros provedores.

1
rodrigozolio

Acho uma péssima ideia.

Por que usar um banco relacional? Esse seria meu primeiro questionamento. O MongoDB tem um plano gratuito que atende bem.

A AWS oferece o Lightsail (https://aws.amazon.com/pt/lightsail/pricing/), que roda Docker com ótimo preço e pelo que entendi voce tem um monólito. Você pode rodar o banco em um serviço gratuito e depois migrar para o RDS — por exemplo, o Neon (https://neon.com/pricing).

Para quem diz que a AWS é cara, discordo: o custo de manter um servidor próprio é ainda maior. Lembre que, no EC2, você é responsável por atualizar o ambiente, configurar o firewall etc.

1
g00dev

Pra que adotar NoSQL no caso dele?

Aliás, na situação dele um banco relacional é o mais adequado, pois ele com certeza tem entidades com forte relação e acoplamento, então não fazer sentido usar NoSQL nesse caso, ainda mais se tratando de uma plataforma jurídica.

Como comentei acima, no free tier ele não precisa gastar um centavo sequer, tendo instância pra API, Banco de dados e site, totalmente apartados

1
g00dev

Amigo, o free tier da AWS deixa voce ter uma instância EC2 (micro), uma instância micro no RDS (PostgreSQL, MySQL ou MariaDB) de graça por um ano! Tá tudo no free tier incluído!

Sobre hospedagem do frontend, se for estático hospeda no S3 como site e usa o CloudFront com certificado SSL, tudo isso de graça incluído no free tier!

Aliás, o free tier deixa você utilizar cerca de 90% dos mais de 400 serviços da AWS de graça.

Vocês precisam ler as condições antes de sair pensando em alternativas. 😅

Pro seu MVP uma instância micro é mais que suficiente. No caso voce teria uma micro pra API e uma micro pro PostgreSQL

1
Azeveco

O free tier da AWS mudou em julho desse ano, infelizmente. Tá bem limitado.

Então se você não tinha uma conta free tier de antes da mudança, é triste :(

1
g00dev

Verdade, vi agora que mudou mesmo, porém os serviços mais utilizados ainda estao disponíveis no free tier, como o EC2, RDS, S3, no caso do post.

1
misterioso013

Se não está consumindo muitos recursos vai apenas de Nextjs, da uma olhada no Next 16 e usa o neon para banco de dados.

Dependendo do tipo de uso vai aguentar até 20 usuários tranquilamente no gratuito e depois disso você já deverá estar ganhando o suficiente para manter.

1
Pilati

tenho diversos clientes em setups parecidos, rodando na maquina grátis da oracle cloud.

Em uma mesma maquina rodam front, back, serviços e bancos de 3, 4 clientes diferentes

no meu servidor mais lotado tenho quase 40 containers na mesma VPS.

não, não é uma má ideia

apenas defina limites de memória e CPU para cada uma, um limite que não faça a aplicação passar fome e não consuma todos os recursos sozinha.

e a API na AWS, que oferece 12 meses de uso free.

O problema é esse, a aws oferece uma maquina que é quase uma mixaria, com tão pouco recurso fica difícil manter tantos containers.

a migração do banco para o RDS

tenho bancos relativamente grandes no docker e nunca tive problema, se vc precisar migrar pra RDS com certeza vc vai ter que tiver contratados para trabalhar para você

1
g00dev

Realmente, não é uma má ideia e sim uma PÉSSIMA ideia.

Se a instância for derrubada, cai todos os serviços.

Pra que tomar esse risco se ele pode rodar tudo separado e de graça no free tier da AWS por 1 ano?!

1
Pilati

Se a instância for derrubada, cai todos os serviços.

Em 3 anos nunca tive esse problema.

não lembro das minhas instâncias ficarem fora do ar simplesmente "porque caiu"

Só lembro de problemas grandes como a IX.br com problema

Edit

Moço, se tiver em instancias separadas tudo vai cair do mesmo jeito, se qualquer um dos serviços [ui, api, DB] caírem, a aplicação fica completamente inutilizada

1
g00dev

Amiguinho, só cai a aplicação pra quem não sabe projetar sistemas.

Se a API cair, tem como a aplicação continuar no ar parcialmente (ou até integralmente dependendo da estratégia de cloud).

O problema que vocês não trabalham em escala, então não passam por problemas de alta demanda. No dia que tua aplicação atender alta demanda, volta aqui pra ver uma coisa

1
Pilati

Deixa de arrogância pessoa!

não é porque tu tem uma necessidade diferente dos outros que você é melhor que qualquer um.

Meter o argumento de escalabilidade em um post que o autor fala que não tem dinheiro para pagar uma sequer instância é típico de desenvolvedor que só gasta o dinheiro dos outros, que nunca empreendeu, que nunca precisou começar do nada.

Aprenda o contexto do local que você está conversando antes de vender uma solução que não serve para o autor!

1
g00dev

Amiguinho, hoje em dia se consegue escalar sem gastar praticamente nada.

Não tenho culpa se voce nao sabe como fazer isso, mas falta de dinheiro não é desculpa.

E outra, amiguinho, eu já empreendi e continuo empreendendo em muito.

Aliás, eu já levantei startup sem um centavo sequer e usei a AWS em larga escala sem gastar um centavo.

Mais uma vez, pra escalar e fazer direito, não precisa de dinheiro

1
klawdyo

Tenho meus sistemas em maquinas da hostinger usando coolify. API, bancos, front, tudo na mesma máquina com backup ativado. Nunca caiu em mais de 4 anos. E se cair, tem lá um monitoramento ativado pra me avisar.
Se até aws cai, pq o meu não pode cair? Isso é frescura pra justificar over Engineering.
Hoje, cada sistema tá em uma máquina, mas já houve um tempo em que deixei até 3 sistemas lá, inclusive API de whatsapp etc. e funcionava de boa.

1
g00dev

AWS cai onde?! Nem a recente crise na AWS não derrubou os serviços principais.

No seu caso, voce não deve ter escala, aí não vira alvo de ataques. Quando você tiver escala, aí volta aqui.

1
Ofido

para um MVP é ótimo, mas olhando pelo ponto de vista de segurança, a ideia é pessima.
se por algum motivo alguma vulnerabilidade possa ser explorada todos os serviços serão afetados, ou até mesmo se por algum motivo algum serviço usar muita memória pode afetar os outros.

1
Guilhermea

Uma VPS de baixo custo vai suprir a sua necessidade por um bom tempo, podendo escalar recurso. É chato configurar um ambiente, mas depois de configurado, fica bem tranquilo.
Futuramente, você pode separar as responsabilidades, deixando o banco de dados em uma vps dedicada.

Vejo que a maioria dos desenvolvedores iniciantes optam por esses serviços mais caros pela dificuldade de configurar um ambiente, e no final das contas, acabam matando o projeto logo nos primeiros meses/anos de vida.

1
pablodurans

Considerando aplicações já consolidadas onde é garantida uma demanda razoável, sinto lhe dizer: colocar DB e o servidor de aplicações no mesmo EC2 é uma péssima idéia.
Mas considerando que aparentemente essa é mais uma abordagem exploratória, que pode ou não gerar receita, diminuir o custo é a melhor forma de diminuir o risco, e colocar ambos no mesmo EC2 pode ser uma boa ideia.
Encontrar a melhor configuração para isso é um desafio, e rodar em containers separados inicialmente simplificada a configuração, mas não alocação de recursos. Mas é possível sim limitar e reservar recursos (cpu e memória) para cada container, lembre de configurar isso.
Outra abordagem, que seria a escolhida por mim, é usar um banco de dados embutido (claro que estou falando do SQLite).
Qualquer uma das soluções vai servir para uma baixa demanda, por isso, fique livre em escolher o que vai ser melhor agora. Concentre seu esforço em entregar uma boa aplicação para que utilizar só um ec2 seja um problema (um bom problema).