Quando alguém começa a usar AWS, uma das primeiras dificuldades é entender a nomenclatura das instâncias. Nomes como t3.medium, m6g.large ou r5.2xlarge parecem códigos aleatórios, mas cada parte carrega uma intenção muito clara.
Compreender essa lógica muda completamente a forma de escolher instâncias. Em vez de “chutar um tamanho” ou ir para a maior por segurança, você passa a escolher com contexto, equilibrando custo, performance e necessidade real.
Antes de tudo, é importante entender que as instâncias da AWS são organizadas em famílias, gerações e arquiteturas. A AWS organiza suas instâncias em famílias que refletem o perfil da carga de trabalho.
Por exemplo: m6g.large
m → representa família (perfil do workload), 6 → representa a geração, g → representa a arquitetura do processador e large → representa o tamanho da instância. Cada parte da sigla responde a uma pergunta diferente:
Para que tipo de carga ela foi pensada?
Quão moderna ela é?
Qual arquitetura usa?
Quanta capacidade entrega?
Família T — Burstable (de uso variável)
As instâncias da família T são pensadas para ambientes em que o uso de CPU é irregular, com longos períodos de baixa atividade intercalados por picos curtos.
Elas funcionam muito bem quando o sistema passa a maior parte do tempo “em espera”, acumulando créditos de CPU que podem ser usados quando a carga aumenta. Em desenvolvimento, teste ou aplicações pequenas, isso costuma ser suficiente e econômico.
O risco surge quando esse padrão muda sem que ninguém perceba. Uso constante consome créditos rapidamente e, quando eles acabam, a performance cai. Por isso, T exige observação contínua, para não ser usada fora do contexto de consumo para o qual foi criada.
Exemplos de uso comuns dessa família são ambientes de desenvolvimento/testes, aplicações pequenas ou bancos de dados com acessos esporádicos.
Exemplo prático:t3.micro para um banco de desenvolvimento ou uma API interna pouco acessada.
Família M — General Purpose (equilíbrio)
As instâncias da família M oferecem uma proporção balanceada entre CPU, memória e capacidade de rede, o que as torna adequadas para cargas de trabalho mistas, onde diferentes tipos de consumo acontecem ao mesmo tempo.
Em bancos de dados, isso é especialmente comum: consultas variam de simples a mais pesadas, há períodos de pico e momentos de estabilidade, e nem sempre é óbvio se o limite está na CPU ou na memória. Por isso, M costuma ser uma escolha consciente para produção inicial ou ambientes que estão em fase de observação.
Não é a instância mais barata nem a mais potente em um aspecto específico, mas é aquela que erra menos quando o comportamento do sistema ainda está sendo compreendido.
Exemplos de uso comuns dessa família são ambientes de aplicações web, serviços de backend ou bancos de dados de uso moderado.
Exemplo prático:m6g.large para um PostgreSQL de produção com carga mista e previsível.
Família R — Memory optimized
As instâncias da família R fazem sentido quando o consumo de memória deixa de ser um detalhe e passa a ser o fator dominante do sistema. Em bancos de dados, isso acontece com frequência: muitas conexões simultâneas, caches internos maiores, consultas que mantêm conjuntos de dados relevantes em memória e cargas de trabalho em que a lentidão vem da falta de memória, não de CPU.
Nesses cenários, aumentar apenas processamento não resolve. A família R existe para garantir que o banco consiga manter dados acessíveis em RAM, reduzindo latência e evitando degradações sutis que aparecem ao longo do tempo. É uma escolha que costuma trazer estabilidade, desde que usada para resolver um gargalo real, previamente identificado.
Exemplos de uso comuns dessa família são bancos de dados, caches, cargas de trabalho que mantêm muitos dados em memória (RAM).
Exemplo prático:r6g.xlarge para um banco de dados analítico ou um banco de dados transacional com muitas conexões simultâneas.
Família C — Compute optimized
A família C é indicada quando o gargalo está claramente no processamento. São instâncias projetadas para cargas de trabalho que executam muitas operações computacionais, onde o tempo de CPU define o desempenho do sistema.
Elas fazem sentido em cenários como processamento batch, transformação de dados ou serviços que executam cálculos intensivos. Em bancos de dados tradicionais, a família C aparece menos, porque a maioria dos problemas não está apenas na CPU, mas em memória, I/O ou desenho do modelo de dados.
Usar C sem essa clareza costuma resultar em custo elevado sem ganho real. Quando o problema é cálculo, no entanto, essa família entrega exatamente o que promete.
Exemplos de uso comuns dessa família são processamento de dados, jobs intensivos, workloads CPU-bound
Exemplo prático:c6g.large para processamento batch ou serviços que fazem muitos cálculos.
Outras famílias (menos comuns no dia a dia)
São as famílias que aparecem em cenários mais especializados.
- X → memória extrema
- I → storage otimizado (IOPS altos)
- P / G → GPU
As instâncias X são voltadas para workloads que exigem volumes extremamente altos de memória, como bases analíticas muito grandes ou aplicações que precisam manter praticamente todo o conjunto de dados em RAM.
Já a família I é otimizada para armazenamento de alto desempenho, indicada quando o gargalo está em I/O e latência de disco, com necessidade de IOPS elevados e acesso rápido a dados persistidos.
As famílias P e G, por sua vez, são focadas em GPU e fazem sentido em cenários como machine learning, processamento gráfico ou cargas altamente paralelizáveis.
Em todos esses casos, o uso só se justifica quando existe uma demanda clara; fora desse contexto, elas tendem a gerar custo elevado sem benefício real.
Geração
O número que aparece no nome da instância indica sua geração e, embora pareça um detalhe pequeno, ele faz muita diferença na prática. Quanto maior o número, mais recente ela será.
Cada nova geração costuma trazer melhorias importantes de performance, eficiência e capacidade de rede e I/O, além de avanços no próprio hardware. Isso significa que, para o mesmo tipo de carga de trabalho, instâncias mais novas tendem a entregar mais desempenho com melhor custo-benefício.
Um exemplo comum é a comparação entre m5 e m6: em muitos cenários, uma m6 consegue suportar a mesma carga com menor latência ou até com menos recursos, reduzindo custo ao longo do tempo. Por isso, sempre que possível, faz sentido priorizar gerações recentes, como m6 em vez de m5 ou r6 em vez de r5.
Em bancos de dados, a diferença entre gerações fica ainda mais evidente. Imagine um PostgreSQL rodando em uma instância m5 que começa a apresentar aumento de latência em horários de pico. Ao migrar para uma m6 da mesma família e tamanho, é comum observar melhor throughput de rede, I/O mais eficiente e tempos de resposta mais estáveis, mesmo sem alterar o tamanho da instância.
Na prática, isso significa menos consultas lentas, melhor aproveitamento de recursos e, em alguns casos, a possibilidade de atender a mesma carga com menor consumo ou até reduzir custos ajustando o dimensionamento. É por isso que, sempre que possível, faz sentido preferir gerações mais novas para cargas de trabalho de banco de dados.
Processadores
Aqui está uma das partes mais importantes (e também uma das mais ignoradas) da nomenclatura das instâncias: a arquitetura do processador. Quando aparece um “g” no nome, como em m6g ou r6g, isso indica que a instância utiliza processadores AWS Graviton, baseados em arquitetura ARM.
Na prática, isso costuma significar melhor custo-benefício, menor consumo de energia e excelente performance para muitas cargas de trabalho. Hoje, grande parte dos serviços gerenciados da AWS já suporta Graviton muito bem, inclusive bancos de dados como PostgreSQL e MySQL, o que torna essa arquitetura uma escolha bastante atrativa. Ainda assim, é importante validar compatibilidade de aplicações, extensões e dependências antes de adotar, especialmente em ambientes mais complexos.
Quando não há o “g” no nome — ou quando aparece um “i” — estamos falando, em geral, de instâncias baseadas em arquitetura x86, usando processadores Intel ou AMD, como m5 ou r5. Essas instâncias continuam absolutamente válidas, principalmente em cenários com softwares legados, dependências específicas ou aplicações que ainda não foram testadas ou homologadas para ARM. A escolha não é sobre certo ou errado, mas sobre contexto e compatibilidade.
Juntando tudo na prática, a leitura do nome da instância começa a fazer sentido. Em r6g.large, por exemplo, o r indica que é uma instância otimizada para memória, o 6 mostra que pertence a uma geração mais recente, o g revela o uso de Graviton e o large define o tamanho. O resultado é uma instância moderna, focada em memória, com bom custo-benefício. Já em um t3.medium, o t indica uma instância burstable, pensada para uso variável, o 3 mostra que é uma geração mais antiga e o medium define um tamanho intermediário. Ela funciona bem para cargas leves, mas não para uso constante ou produção mais exigente.
O erro mais comum continua sendo escolher instâncias apenas pelo tamanho ou pelo medo de falta de performance. Esse tipo de decisão quase sempre leva a ambientes superdimensionados, caros e pouco eficientes. A escolha certa começa com perguntas simples, mas poderosas: o uso é constante ou variável? O gargalo está em CPU ou memória? Esse ambiente cresce rápido ou é estável? Custo previsível é importante? Responder essas perguntas vale muito mais do que decorar siglas, porque transforma a escolha da instância em uma decisão consciente, e não em tentativa e erro.
Deixe um comentário