Por padrão, você não escolhe onde suas instâncias EC2 ficam fisicamente. A AWS decide o posicionamento otimizando o uso do próprio datacenter, não o seu caso de uso. Na maioria das vezes isso não importa. Mas quando importa, o problema aparece de duas formas opostas: rede lenta demais entre instâncias que precisam trocar dados o tempo todo, ou instâncias caindo juntas porque compartilhavam o mesmo hardware sem você saber. Placement Groups existem para dar controle explícito sobre essa decisão nos dois sentidos.
Os dois problemas que ele resolve
Latência de rede. Instâncias espalhadas em racks e switches diferentes do datacenter têm mais saltos de rede entre si. Para workloads que trocam dados constantemente (treinamento de ML distribuído, processamento paralelo, HPC), isso vira o gargalo real, não CPU, não disco, a rede.
Falha correlacionada. Sem nenhum controle, duas instâncias podem acabar no mesmo host físico. Se aquele host, rack ou fonte de energia falhar, você perde as duas ao mesmo tempo, mesmo achando que eram independentes. Isso é especialmente grave para sistemas que dependem de réplicas (banco distribuído, cluster de mensageria): a tolerância a falha só existe de verdade se as réplicas estiverem em domínios de falha diferentes.
Repare que os dois problemas pedem soluções opostas: um quer instâncias próximas, o outro quer instâncias separadas. Por isso existem três tipos de Placement Group, cada um resolvendo um lado dessa equação.
Os três tipos
| Tipo | Objetivo | Limite | Escopo |
|---|---|---|---|
| Cluster | Baixa latência, alta largura de banda | Sem limite fixo | Uma única AZ |
| Spread | Isolar falha de hardware por instância | 7 instâncias por AZ | Uma ou mais AZs na região |
| Partition | Isolar falha por grupo, em escala | 7 partições por AZ | Uma ou mais AZs na região |
Cluster: quando a rede é o gargalo
Agrupa as instâncias no mesmo rack, ou em racks adjacentes com switches de altíssima performance, dentro de uma única AZ. O ganho é latência baixa e throughput alto entre elas, inclusive viabilizando redes de 10, 25 ou até 100 Gbps com EFA (Elastic Fabric Adapter) em instâncias que suportam.
Quando usar:
- Múltiplas instâncias trocando volume alto de dados entre si em tempo real: treinamento de ML com vários nós GPU sincronizando gradientes, cluster Hadoop/Spark processando dados em paralelo, HPC
- Você já mediu (ou sabe por experiência do workload) que a rede entre instâncias é o limitador de performance
Quando não usar:
- Poucas instâncias sem troca intensa de dados entre si (ex: uma API e um banco)
- Workload sensível a falha correlacionada: concentrar tudo no mesmo hardware é o oposto do que você quer nesse caso
Trade-off físico: como as instâncias competem por capacidade num conjunto limitado de hardware, lançar várias de uma vez pode esbarrar em falta de capacidade disponível (InsufficientInstanceCapacity). A recomendação da AWS é lançar todas de uma vez, no mesmo pedido, para reduzir esse risco.
Spread: quando cada instância importa individualmente
Garante que cada instância vá para hardware fisicamente distinto, rack, fonte de energia e switch próprios, dentro da AZ. Não há ganho de latência aqui, o objetivo é puramente isolar falhas.
Quando usar:
- Punhado de instâncias onde cada uma é crítica individualmente, e perder duas ao mesmo tempo por acaso de hardware é inaceitável: nós líderes de um sistema de consenso, poucos servidores segurando estado importante sem redundância trivial
Quando não usar:
- Mais de 7 instâncias por AZ (o limite físico do Spread não escala além disso)
- Quando perder duas instâncias ao mesmo tempo não muda nada pro negócio (auto scaling já cobre, workload não é crítico)
Partition: quando o Spread não escala
Divide o grupo em até 7 partições por AZ, cada uma com seu próprio conjunto de racks, sem hardware compartilhado entre partições diferentes. Dentro da mesma partição, instâncias podem compartilhar hardware. A instância consegue consultar sua própria partição via metadata (IMDS), o que permite alinhar as partições lógicas da sua aplicação distribuída aos domínios de falha físicos reais.
Quando usar:
- Sistemas distribuídos que já gerenciam replicação e particionamento nativamente e têm dezenas ou centenas de nós: Cassandra, Kafka, HDFS, HBase
- Você quer mapear uma partição lógica da aplicação (ex: um rack do Cassandra) a um domínio de falha físico real
Quando não usar:
- Sistema distribuído com menos de ~10 nós, onde Spread já resolve com menos complexidade
Como funciona fisicamente
O mecanismo é sempre sobre a mesma coisa: quais racks, switches e fontes de energia a AWS escolhe para suas instâncias.
- Cluster aloca no mesmo rack ou em racks adjacentes com poucos saltos de rede entre si.
- Spread ativamente evita hardware compartilhado, cada instância recebe um rack isolado, o que explica o limite de 7 por AZ: existe um número finito de racks que a AWS consegue garantir isolados o suficiente.
- Partition mapeia cada partição a um conjunto de racks próprio, sem sobreposição entre partições, mas permite compartilhamento dentro de cada uma, o que é o que permite escalar além do limite do Spread.
Restrições que valem a pena saber
- Um placement group não pode ser mesclado com outro, nem uma instância existente é movida para dentro de um sem antes ser parada.
- Cluster placement group não atravessa AZ: todas as instâncias precisam estar na mesma AZ.
- Instâncias
t2/t3(burstable) não são suportadas em Cluster placement group. - Spread e Partition podem atravessar múltiplas AZs dentro da mesma região, mas o limite de instâncias/partições vale por AZ.
O que ele não resolve
Placement Group é um recurso de EC2, não de serviços gerenciados. RDS e ElastiCache não suportam placement group, a AWS controla o posicionamento por trás desses serviços, e a ferramenta equivalente para alta disponibilidade ali é Multi-AZ, não placement group. Também não tem relação com EBS Multi-Attach: um resolve proximidade física de instâncias, o outro resolve múltiplas instâncias acessando o mesmo volume, são mecanismos independentes que podem até ser combinados, mas nenhum exige o outro.
Preço
Criar e usar um placement group, qualquer um dos três tipos, é gratuito. Você paga o custo normal das instâncias, armazenamento e transferência de dados, o placement group só influencia onde elas ficam, não adiciona nenhuma cobrança própria.
Trade-offs
| Ganha | Paga |
|---|---|
| Cluster: baixa latência e alto throughput entre instâncias | Maior risco de falta de capacidade ao lançar, e falha correlacionada se o hardware cair |
| Spread: isolamento forte de falha de hardware | Limite de 7 instâncias por AZ, não escala |
| Partition: isolamento em escala, alinhado à topologia da aplicação | Mais complexidade de configuração, só compensa com dezenas+ de nós |
Referências
- AWS. Placement groups for your EC2 instances. Documentação oficial dos três tipos, limites e restrições.
- AWS. Elastic Fabric Adapter (EFA). Rede de alta performance usada em conjunto com Cluster placement group.
- AWS. Amazon EC2 pricing. Confirma que placement groups não têm custo próprio.