No meu dia a dia na DoiT, atendo startups que estão dando os primeiros passos na nuvem.
E vejo os mesmos erros se repetirem o tempo todo.
Reuni alguns deles aqui para que você consiga evitá-los antes que virem dor de cabeça (e prejuízo):
1\. A conta AWS é aberta no e-mail pessoal de um fundador
É muito comum a primeira conta AWS ser criada com o Gmail pessoal de um dos fundadores.
Nesse cenário, a conta pertence — legal e operacionalmente — a uma pessoa, não à empresa.
Se o fundador sair, houver um conflito ou (no pior cenário) acontecer algo com ele, a titularidade vira um sério risco para o negócio.
Fora isso, o e-mail pessoal costuma ser menos seguro do que uma caixa corporativa: sem MFA obrigatório, sem auditoria centralizada, governança de identidade mais frágil e um baita obstáculo na hora de uma auditoria de certificação.
Comprometer o e-mail do fundador, na prática, costuma significar controle total sobre o ambiente AWS da empresa.
Isso também cria um ponto único de falha.
Boa prática:
Crie uma caixa de e-mail compartilhada, por exemplo: [email protected]
Inclua pelo menos duas pessoas do time (sempre tem alguém doente, de férias ou em um evento) e use plus-addressing para separar ambientes em diferentes contas AWS:
2\. Criar recursos na Management Account
Toda startup começa com uma única conta AWS que abriga tudo: produção, desenvolvimento, demos e o playground dos devs.
Conforme a empresa cresce, é preciso separar os ambientes. O caminho mais óbvio parece ser transformar essa conta única na Management Account do AWS Organizations e criar novas contas membro a partir dela.
O problema: a Management Account é a única conta que não pode ser governada por controles aplicados a toda a organização.
Documentação das Service Control Policies do AWS Organizations
Políticas típicas que você costuma querer aplicar:
- Todos os volumes EBS do EC2 precisam ser criptografados.
- Recursos não podem ser criados em regiões não autorizadas.
- Tipos de instância caros (GPU) ficam restritos.
- Usuários IAM são proibidos (apenas roles permitidas).
Nada disso vale para a Management Account, que, nesse caso, também é a conta de produção.
Pior: a AWS não permite converter uma Management Account em conta membro.
Quando a conta de produção é também a de gerenciamento, a única saída é uma migração organizacional completa: refazer a organização, recriar políticas, reconfigurar permissões e reonboardar cada colaborador em um novo endpoint de Single Sign On (SSO).
Se você ainda está naquele estágio em que tudo roda em uma única conta AWS e quer começar a separar ambientes, crie uma nova conta AWS independente, defina-a como Management Account no AWS Organizations e convide a conta de produção atual para entrar como conta membro nessa nova organização.
3\. Deixar a conformidade para depois
Se a sua estratégia é vender para grandes clientes, mais cedo ou mais tarde vão pedir conformidade:
- SOC 2 / ISO 27001 para SaaS B2B
- HIPAA para saúde
- PCI DSS para fintechs e meios de pagamento
Adequar um produto e uma empresa já em operação a novos requisitos de conformidade é extremamente difícil.
Isso impacta não só a arquitetura de nuvem, mas também os fluxos de desenvolvimento, o controle de acesso e até os contratos de trabalho (propriedade intelectual, confidencialidade, gestão de dispositivos, etc.).
Ajustar a infraestrutura de nuvem é trabalhoso, mas dá. Mudar contratos e processos organizacionais depois é muito mais complicado. Por isso, contar com um parceiro de consultoria em conformidade desde as primeiras linhas de código do seu produto torna a jornada bem mais tranquila.
4\. Todos os ovos na mesma cesta
A AWS permite gerenciar registro de domínio, renovação e DNS dentro do Route 53. É prático — e perigoso.
Se a conta AWS for suspensa (por um problema de cobrança, incidente de segurança ou chave IAM vazada), seu domínio pode ir junto.
E quando o e-mail para de funcionar, fica muito difícil falar com o suporte da AWS para resolver o problema.
posts do r/aws no Reddit.com
Boa prática:
Mantenha o domínio principal da empresa fora da conta AWS de produção — em um provedor separado, como GoDaddy ou NameCheap, ou em uma conta AWS dedicada. Se ficar bloqueado da conta de produção, você ainda consegue mexer nos registros de DNS pelo outro provedor ou conta.
5\. Tenha um calendário de vencimentos para não perder datas críticas de renovação
Já no primeiro ano, uma startup acumula rapidamente:
- Contratos
- Chaves de API
- Cartões de crédito
O que todos eles têm em comum é uma data de vencimento.
Os efeitos colaterais indesejados costumam ser:
- Contas AWS bloqueadas por falta de pagamento.
- Quedas de serviço inesperadas por causa de uma chave de API expirada.
- Negociações de renovação contratual feitas às pressas, com datas perdidas ou prestes a vencer.
Um calendário compartilhado com lembretes automáticos ("Cartão de crédito 3344 vence em 30 dias", "Renovação do contrato com o MAP Provider em 45 dias") ajuda a evitar esse tipo de problema.
Para fechar
Os desafios são muitos. Recomendo fortemente buscar um mentor que já tenha fundado e liderado outras startups. Conselho de quem viveu a jornada vale ouro.
Se você quer construir sua nuvem do jeito certo desde o primeiro dia, a DoiT traz tecnologia, expertise e anos de experiência ajudando startups e grandes empresas globais a evitar exatamente esses erros — e muitos outros.
Vamos transformar a sua nuvem em motor de crescimento, e não em fator de risco.