Se você já subiu uma aplicação na AWS e precisou armazenar uma senha de banco de dados, uma chave de API ou um token de serviço, provavelmente se deparou com a mesma dúvida: “Uso o Secrets Manager ou o Parameter Store?”.
A resposta mais comum nos fóruns é “depende” o que tecnicamente está certo, mas é completamente inútil sem contexto. A verdade é que a escolha errada aqui não é apenas uma questão de preferência arquitetural. Ela pode gerar uma fatura inesperada no final do mês, ou pior: deixar um segredo exposto por meses sem que ninguém perceba.
O Que São os Dois Serviços
O AWS Systems Manager Parameter Store é um serviço de armazenamento de configuração e segredos com dois tiers: Standard (gratuito, até 10.000 parâmetros) e Advanced (cobrado por parâmetro/hora). Ele armazena strings simples, StringList e SecureString (criptografado com KMS). Foi criado originalmente para gerenciar configurações de aplicação, feature flags, endpoints, parâmetros de ambiente, e evoluiu para suportar segredos também.
O AWS Secrets Manager foi construído desde o início com um propósito diferente: gerenciar o ciclo de vida de segredos, especialmente com rotação automática. Ele cobra por segredo armazenado (US$ 0,40/segredo/mês) e por 10.000 chamadas de API (US$ 0,05). Não tem tier gratuito.
1. O Problema que o Secrets Manager Resolve de Verdade
Guardar uma senha de banco de dados é a parte fácil. O problema real é o que acontece com essa senha ao longo do tempo.
Em ambientes sem rotação automatizada, credenciais de banco de dados costumam ter um ciclo de vida assim: são criadas uma vez, armazenadas em algum lugar, e ficam lá por meses ou anos. Ninguém rotaciona porque é trabalhoso, e ninguém sabe quais aplicações dependem dessa credencial. Quando uma rotação manual acontece — geralmente depois de um incidente — vira um mutirão de atualização de configs em produção.
O Secrets Manager resolve exatamente isso. Com a rotação automática nativa para Amazon RDS, Amazon Redshift, Amazon DocumentDB e outros serviços suportados, ele pode trocar a senha do banco em intervalos configuráveis (ex: a cada 30 dias) sem intervenção manual. O processo cria uma nova versão do segredo, atualiza o banco, e mantém a versão anterior disponível por um período de transição para evitar que aplicações em execução quebrem imediatamente.
Isso não é possível com o Parameter Store. Ele armazena o valor, mas não tem mecanismo nativo de rotação. Você pode construir rotação com Lambda, mas estará reinventando o que o Secrets Manager já faz — e assumindo o custo de manutenção dessa automação.
2. Custo: Onde o Parameter Store Vence (e Onde Perde)
O Parameter Store Standard não cobra nada para até 10.000 parâmetros, com até 4.096 bytes por parâmetro. Para aplicações com dezenas ou centenas de configurações não-sensíveis (URLs de endpoints, timeouts, feature flags), ele é a escolha econômica óbvia.
O problema começa quando times migram todos os segredos para o Secrets Manager sem avaliar se precisam das funcionalidades extras. Uma aplicação com 50 segredos no Secrets Manager paga US$ 20/mês apenas em armazenamento, antes de qualquer chamada de API. Multiplicado por 10 ambientes (dev, staging, produção, etc.), são US$ 200/mês em armazenamento de credenciais que poderiam estar no Parameter Store Advanced por uma fração disso.
A conta de API do Secrets Manager também merece atenção. Lambda functions que fazem GetSecretValue a cada invocação sem cache local podem gerar milhares de chamadas por minuto. A boa prática é implementar cache com o AWS Secrets Manager caching client ou usar o Lambda Extension do Secrets Manager, que mantém o segredo em memória e só busca no serviço quando a versão muda.
3. Integração com Lambda e ECS: Onde Cada Um Brilha
Lambda:
O Lambda Extension do Secrets Manager é a integração mais eficiente para funções que precisam de segredos. Ele carrega o segredo uma vez no bootstrap da execução e serve das chamadas subsequentes do cache local, eliminando a latência de chamadas extras ao serviço.
# Variável de ambiente para habilitar o cache via extension
PARAMETERS_SECRETS_EXTENSION_CACHE_ENABLED=true
PARAMETERS_SECRETS_EXTENSION_HTTP_PORT=2773Para o Parameter Store com Lambda, o mesmo Extension funciona, sendo uma alternativa gratuita para segredos que não precisam de rotação automática.
ECS (Fargate e EC2):
O ECS suporta injeção nativa de segredos em variáveis de ambiente ou arquivos de configuração via secrets na task definition, referenciando tanto o Secrets Manager quanto o Parameter Store diretamente. O segredo é resolvido no momento do start do container,m não a cada requisição.
json
"secrets": [
{
"name": "DB_PASSWORD",
"valueFrom": "arn:aws:secretsmanager:us-east-1:123456789:secret:prod/db/password"
},
{
"name": "APP_CONFIG",
"valueFrom": "arn:aws:ssm:us-east-1:123456789:parameter/prod/app/config"
}
]A diferença crítica: se você usa rotação automática no Secrets Manager e um container já está rodando com a versão antiga da senha, ele não vai buscar a nova versão automaticamente. É preciso planejar a janela de rotação em conjunto com o ciclo de reimplantação das tasks ou implementar lógica de retry na aplicação.
Conclusão
A escolha entre Secrets Manager e Parameter Store não é técnica — é sobre o ciclo de vida do dado que você está armazenando. Se o segredo tem uma senha que precisa trocar periodicamente, é uma credencial de banco de dados em produção, ou precisa ser auditada com controle de versão e rotação automática: use o Secrets Manager. O custo de US$ 0,40 por segredo por mês é irrelevante comparado ao custo de um incidente causado por credencial comprometida e não rotacionada.
Para todo o resto — configurações, parâmetros de ambiente, flags, URLs — o Parameter Store é mais econômico, já está integrado ao SSM e não precisa de nenhuma funcionalidade que o Secrets Manager oferece.
O problema não é usar um ou outro. É usar o Parameter Store para esconder credenciais de banco de dados em produção porque “parece mais simples”, e descobrir seis meses depois que aquela credencial nunca foi rotacionada.
