Toda instância EC2 exposta à internet com a porta 22 aberta é uma aposta: a aposta de que ninguém vai escanear aquele IP antes que o time de segurança feche o acesso. O AWS Systems Manager nasceu para tirar essa aposta da mesa — ele centraliza o acesso, o patch e a configuração de instâncias EC2, servidores on-premises e VMs híbridas em um único plano de controle, sem exigir uma porta de entrada aberta para cada máquina. Neste guia, você vai entender como o Systems Manager resolve o problema de acesso remoto exposto, como automatizar patch e configuração em escala com Patch Manager e State Manager, como centralizar segredos e parâmetros, e como decidir quais componentes faz sentido adotar primeiro dependendo do tamanho do seu parque de instâncias.
O Problema que o AWS Systems Manager Resolve
Antes de existir uma alternativa madura, gerenciar um parque de instâncias EC2 significava aceitar um conjunto de riscos operacionais que a maioria das empresas conhece bem: portas SSH (22) e RDP (3389) abertas para permitir acesso administrativo, um bastion host (também chamado de jump box) como ponto único de falha e de ataque, chaves SSH espalhadas entre desenvolvedores e raramente rotacionadas, patch de segurança aplicado manualmente — ou não aplicado — e nenhum inventário confiável de que software está instalado em qual máquina.
Cada um desses pontos é, isoladamente, um vetor de ataque conhecido e um item recorrente em auditoria de segurança. O Systems Manager ataca os cinco ao mesmo tempo porque todos compartilham a mesma causa raiz: falta de um plano de controle central que enxergue e atue sobre a frota inteira de instâncias, em vez de tratar cada máquina como um caso isolado. É esse ponto que diferencia o Systems Manager de scripts avulsos ou de disciplina manual — ele estrutura como governança, não como boa vontade da equipe.
Session Manager: Acesso Remoto sem Porta SSH ou RDP Exposta
O Session Manager é o componente do Systems Manager que resolve diretamente o problema de acesso remoto. Ele estabelece uma sessão segura, autenticada por política do IAM, entre o usuário e a instância — via console, CLI ou navegador — sem abrir nenhuma porta de entrada na instância e sem exigir bastion host, chave SSH ou VPN dedicada. A instância só precisa do SSM Agent instalado (já vem pré-instalado nas AMIs Amazon Linux e Windows Server mais recentes) e de uma IAM role com a permissão necessária.
Do lado da segurança, a mudança é estrutural: fechar as portas 22 e 3389 elimina a superfície de ataque mais escaneada da internet, e o controle de quem acessa qual instância passa a ser feito inteiramente por política do IAM, revogável em um único lugar — sem precisar caçar quem ainda tem a chave SSH de uma máquina que devia ter sido desativada há meses. Esse modelo de controle de acesso centralizado por identidade, em vez de credencial compartilhada, é o mesmo princípio que orienta uma estratégia de Zero Trust e IAM avançado na AWS — o Session Manager é, na prática, uma aplicação concreta desse princípio ao acesso operacional a servidores.
Toda sessão pode ser registrada — comandos executados, duração, usuário — com log enviado para o Amazon S3 ou para o CloudWatch Logs, e eventos de início e fim de sessão podem disparar notificação via EventBridge. Para setores regulados ou empresas que precisam comprovar trilha de auditoria de acesso administrativo, essa é a diferença entre "confiar que ninguém abusou do acesso" e ter o registro para provar.
Patch Manager: Compliance de Patch sem Depender de Memória Humana
Patch manual funciona até não funcionar — até a instância que ninguém lembrava de atualizar virar a porta de entrada de um incidente. O Patch Manager automatiza esse processo definindo o que a empresa considera "compliance de patch" através de uma patch baseline: uma configuração que define quais patches são aprovados, por qual critério (classificação, severidade, tempo desde o lançamento) e para qual sistema operacional.
Uma operação de patch pode rodar em modo Scan, que só reporta o que está faltando, ou Scan and install, que aplica automaticamente. Isso pode ser disparado por uma maintenance window (uma janela de tempo definida para minimizar impacto em produção), por uma patch policy configurada via Quick Setup — que aplica a mesma política a toda uma organização multi-conta de uma vez — ou sob demanda, com a opção "Patch now" para quando um CVE crítico não pode esperar o próximo ciclo.
O Patch Manager cobre Windows Server, diversas distribuições Linux e macOS, suporta hooks de lifecycle para rodar scripts antes e depois da aplicação de patch, e gera relatórios de compliance em CSV — inclusive integrando com o AWS Security Hub CSPM para consolidar esse dado junto com o restante da postura de segurança da conta. Vale um detalhe importante: ser "compliant" com uma patch baseline significa que os patches aprovados foram instalados — não é sinônimo automático de "seguro". A definição do que constitui compliance é responsabilidade de quem configura a baseline, não algo que a AWS determina por padrão.
Run Command e State Manager: Automação Pontual vs. Estado Desejado
É comum confundir Run Command com State Manager porque os dois executam comandos em escala numa frota de instâncias — mas resolvem problemas diferentes, e a diferença importa na hora de escolher qual usar.
Run Command executa uma ação pontual: rodar um script, reiniciar um serviço, coletar um diagnóstico, aplicar uma mudança de configuração agora, numa ou em milhares de instâncias simultaneamente, sem precisar abrir uma sessão interativa em cada uma. É a ferramenta certa para "preciso fazer isso agora, uma vez, em todas as instâncias com essa tag".
State Manager garante um estado desejado de forma recorrente, através de associations — uma configuração que especifica, por exemplo, que o antivírus precisa estar instalado e em execução em toda instância com determinada tag, verificado diariamente. Se o software não estiver instalado, a associação instrui a instalação; se estiver instalado mas parado, instrui o reinício do serviço. É a ferramenta certa para combater configuration drift — o desvio gradual entre a configuração que a instância deveria ter e a que ela realmente tem, que se acumula silenciosamente em qualquer ambiente que cresce sem disciplina.
Na prática, as duas ferramentas se complementam: Run Command para a ação imediata, State Manager para garantir que essa ação continue verdadeira amanhã, na próxima semana e depois que a instância for recriada por um Auto Scaling Group.
Inventory, Parameter Store e a Diferença para o Secrets Manager
Duas perguntas recorrentes em qualquer auditoria de infraestrutura são "o que está instalado em cada máquina?" e "onde estão os segredos e configurações que as aplicações usam?". O Systems Manager tem uma resposta para cada uma.
O Inventory coleta metadados de software, configuração de aplicações, atualizações do sistema operacional e informações de rede de cada instância gerenciada, de forma agendada — a base para responder, sem depender de planilha desatualizada, perguntas como "quais instâncias ainda rodam essa versão vulnerável de uma biblioteca" antes mesmo de abrir um chamado de segurança. É o tipo de dado que sustenta uma prática séria de gestão de ativos de TI, agora estendida à infraestrutura em nuvem.
O Parameter Store é um repositório centralizado de dados de configuração — variáveis de ambiente, IDs de AMI aprovadas, endpoints, listas — em três tipos: String, StringList e SecureString (este último criptografado via AWS KMS). Ele tem dois tiers: o standard, gratuito, com até 10.000 parâmetros por conta/região e valores de até 4 KB; e o advanced, cobrado por parâmetro e por 10.000 interações de API, que sobe o limite para 100.000 parâmetros, valores de até 8 KB e suporta políticas de expiração e compartilhamento entre contas.
O ponto que gera mais confusão é quando usar Parameter Store e quando usar o AWS Secrets Manager. A própria documentação da AWS é direta nessa distinção: Parameter Store é adequado para dados de configuração estática — sem necessidade de rotação automática — enquanto o Secrets Manager foi desenhado especificamente para credenciais (senha de banco de dados, chave de API, token) que precisam de rotação automática, integração nativa com bancos gerenciados e auditoria fina por segredo. Usar Parameter Store para armazenar uma senha de produção que nunca é rotacionada é um padrão comum, mas não é a ferramenta certa para esse caso — o Secrets Manager existe exatamente para eliminar esse risco.
Componentes do Systems Manager: o que Cada Um Resolve
| Componente | O que faz | Quando usar |
|---|---|---|
| Session Manager | Acesso remoto interativo sem SSH/RDP exposto, com log de sessão | Substituir bastion host e chave SSH pelo controle de acesso via IAM |
| Patch Manager | Aplica e audita patches de SO/aplicação por baseline, com relatório de compliance | Padronizar e automatizar a janela de manutenção de patch |
| Run Command | Executa comandos ou scripts pontuais em uma ou milhares de instâncias | Ação imediata em escala, sem sessão interativa |
| State Manager | Garante configuração/estado desejado de forma recorrente, corrige drift | Manter agente, antivírus ou configuração de rede sempre no estado certo |
| Inventory | Coleta metadados de software, SO e rede de cada instância | Base de dados para auditoria e gestão de ativos de TI |
| Parameter Store | Armazena configuração e segredos simples, com criptografia opcional | Configuração de aplicação, AMI aprovada, endpoint — não credencial rotativa |
| Automation | Executa runbooks (SSM documents) para orquestrar tarefas operacionais multi-etapa | Automatizar um processo operacional inteiro, não só um comando |
| Fleet Manager | Interface visual centralizada da frota de instâncias gerenciadas | Visibilidade operacional do parque inteiro num só painel |
Segurança e Custo: o que É Gratuito e o que Não É
Um ponto que costuma surpreender times avaliando o Systems Manager pela primeira vez: a maior parte da plataforma não tem custo adicional. Session Manager, Run Command, State Manager, Patch Manager (para instâncias EC2), Inventory, Fleet Manager e Compliance são gratuitos — o cliente paga apenas pela infraestrutura EC2 subjacente, como já pagaria de qualquer forma.
O custo aparece em componentes específicos de maior escala ou funcionalidade avançada: parâmetros advanced no Parameter Store (cobrados por parâmetro/mês e por volume de chamadas de API), execução de steps no Automation, o OpsCenter (cobrado por OpsItem criado) e o gerenciamento de nós híbridos/multicloud fora da AWS. Para uma operação típica de EC2 usando Session Manager, Patch Manager e State Manager no tier padrão, o custo incremental sobre a fatura AWS tende a ser próximo de zero — o que muda o cálculo de decisão de "vale o investimento" para "por que ainda não estamos usando".
Do lado da segurança, vale reforçar: o Systems Manager reduz superfície de ataque e centraliza controle, mas depende de IAM policies bem desenhadas para não virar, ele mesmo, um vetor de acesso amplo demais — uma role com permissão de Session Manager para toda a frota, dada sem critério, recria o mesmo problema que o serviço deveria resolver. Esse é exatamente o tipo de questão que uma revisão pelo pilar de Segurança do AWS Well-Architected Framework deveria capturar antes que vire incidente.
Casos de Uso por Porte de Empresa
Não existe uma adoção "completa" certa para toda empresa — o ponto de entrada certo depende de quantas instâncias existem e de quão madura é a operação:
PME com um punhado de instâncias (10-30 EC2). O ganho imediato e de menor esforço é o Session Manager: eliminar o bastion host, fechar a porta 22 e centralizar o acesso via IAM já resolve o risco mais comum de auditoria, sem exigir reestruturação de processo.
Empresa em crescimento com dezenas a poucas centenas de instâncias. Session Manager já consolidado, o próximo passo natural é Patch Manager com uma maintenance window recorrente e Parameter Store para parar de hardcodar configuração em código — o par que elimina a maior parte do trabalho manual repetitivo de operação.
Parque de centenas de instâncias, múltiplas contas. Aqui o valor está em Patch Manager operado via patch policy no nível de AWS Organizations (uma política, todas as contas), State Manager para garantir configuração consistente independente de quem provisionou a instância, e Inventory alimentando um processo real de gestão de ativos — o ponto em que a governança deixa de depender de disciplina individual e passa a ser estrutural. Empresas nessa fase que não têm profundidade interna para desenhar as patch baselines e as IAM policies certas desde o início costumam se beneficiar de uma consultoria AWS especializada para estruturar a governança antes de escalar o parque, em vez de corrigir depois.
Tendências: para Onde o Systems Manager Está Indo
A direção clara do Systems Manager nos últimos ciclos é reduzir ainda mais a configuração manual necessária para chegar a um bom padrão de governança — as patch policies via Quick Setup, que aplicam uma configuração a uma organização inteira em vez de conta por conta, são exemplo direto disso. A integração mais próxima com AWS Security Hub CSPM também sinaliza uma consolidação: compliance de patch deixando de ser um painel isolado do Systems Manager para virar mais um sinal dentro da postura de segurança única da conta, ao lado de achados de outros serviços.
Vale observar também que a AWS vem ajustando a fronteira entre "gratuito" e "pago" em serviços auxiliares do Systems Manager — o CloudWatch Dashboard nativo do serviço, por exemplo, está sendo descontinuado em favor do CloudWatch tradicional, e cobranças novas estão surgindo para acesso a nós híbridos e multicloud. Para empresas com operação puramente EC2, o núcleo gratuito do serviço segue estável; vale checar a página oficial de preços antes de expandir para nós fora da AWS.
Perguntas Frequentes sobre AWS Systems Manager
O AWS Systems Manager é realmente gratuito?
Os componentes mais usados — Session Manager, Run Command, State Manager, Patch Manager para EC2, Inventory e Fleet Manager — não têm cobrança adicional; o custo é só o da infraestrutura EC2 já existente. Cobrança aparece em recursos específicos, como parâmetros advanced no Parameter Store, execução de steps no Automation, OpsCenter e gestão de nós híbridos/multicloud.
O Systems Manager substitui o AWS Secrets Manager?
Não. Parameter Store (parte do Systems Manager) é indicado para configuração estática, sem necessidade de rotação; Secrets Manager é o serviço correto para credenciais que precisam de rotação automática, como senha de banco de dados ou chave de API. Usar Parameter Store para esse tipo de segredo é possível, mas não é a prática recomendada pela própria AWS.
Preciso instalar algo na instância para usar o Systems Manager?
Sim, o SSM Agent precisa estar presente e em execução na instância, além de uma IAM role com a permissão adequada anexada a ela. As AMIs Amazon Linux e Windows Server mais recentes já vêm com o agente pré-instalado; para AMIs customizadas ou sistemas mais antigos, a instalação é um passo manual único.
Qual a diferença entre Run Command e Automation?
Run Command executa um comando ou script pontual em uma ou várias instâncias. Automation orquestra um runbook — uma sequência de múltiplas etapas, potencialmente envolvendo vários serviços AWS além do EC2, como criar snapshot, validar, depois aplicar mudança. Use Run Command para uma ação simples; Automation quando o processo tem várias etapas encadeadas.
O Session Manager registra tudo o que é digitado durante a sessão?
Pode ser configurado para isso: o log de sessão pode ser enviado para Amazon S3 ou CloudWatch Logs, com opção de criptografia via KMS. Uma exceção importante: sessões que usam port forwarding ou túnel SSH não são logadas no conteúdo, porque o tráfego é criptografado ponta a ponta entre o cliente e a instância — o Systems Manager funciona só como túnel nesse caso.
O Patch Manager consegue fazer upgrade de versão major do sistema operacional?
Não. O Patch Manager aplica patches e atualizações dentro da mesma versão principal do sistema operacional — por exemplo, atualizações dentro do Windows Server 2019 ou dentro do RHEL 8 — mas não faz upgrade de Windows Server 2016 para 2019, nem de RHEL 7 para RHEL 8. Esse tipo de mudança exige um processo de migração à parte.
Dá para usar o Systems Manager em servidores fora da AWS?
Sim. O Systems Manager suporta nós híbridos e multicloud — servidores on-premises e VMs em outros provedores — desde que o SSM Agent esteja instalado e configurado com as credenciais adequadas. Vale checar a página de preços atualizada, porque cobranças específicas para gestão de nós fora da AWS têm mudado.
Governança de EC2 Deixa de Ser Trabalho Manual com o Systems Manager
O AWS Systems Manager não é um serviço opcional para quem já opera EC2 em escala — é a diferença entre tratar acesso, patch e configuração como disciplina individual de cada administrador ou como processo estruturado e auditável da empresa inteira. A maior parte do valor está disponível sem custo adicional, o que torna a decisão de adoção menos sobre orçamento e mais sobre priorização: por onde começar, dado o tamanho e a maturidade do parque atual.
Empresas que tratam o Systems Manager como parte da linha de base de segurança — não como ferramenta avançada para depois — são as que chegam à próxima auditoria com respostas prontas, em vez de trabalho emergencial para reconstruir um inventário e uma política de acesso que deveriam ter existido desde o primeiro dia.
Artigos Relacionados
Para aprofundar em temas conectados à governança e automação de infraestrutura AWS:
- Amazon EC2 para Pequenas Empresas: Guia Completo de Computação em Nuvem — a base de instâncias que o Systems Manager gerencia; entenda os fundamentos antes de automatizar.
- Zero Trust e IAM Avançado na AWS — o mesmo princípio de controle de acesso por identidade que sustenta o modelo do Session Manager.
- AWS Well-Architected Framework: o Guia Avançado — o pilar de Segurança traz as perguntas certas para avaliar se o Systems Manager está configurado com o mínimo privilégio necessário.
- Gestão de Ativos de TI: O Guia Completo — o Inventory do Systems Manager como fonte de dado confiável para esse processo, estendido à infraestrutura em nuvem.
