

• O AWS Systems Manager CloudWatch Dashboard não estará mais disponível a partir de 30 de abril de 2026. Os clientes podem continuar usando o console do Amazon CloudWatch para visualizar, criar e gerenciar os painéis do Amazon CloudWatch exatamente como fazem hoje. Para obter mais informações, consulte a [documentação do Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html). 

# Solução de problemas de disponibilidade do nó gerenciado
<a name="fleet-manager-troubleshooting-managed-nodes"></a>

Para várias ferramentas do AWS Systems Manager como Run Command, Distributor e Session Manager, você pode optar por selecionar manualmente os nós gerenciados nos quais deseja executar uma operação. Em casos como esses, depois de especificar que você deseja escolher os nós manualmente, o sistema exibirá uma lista de nós gerenciados nos quais você poderá executar a operação.

Este tópico fornece informações para ajudar você a identificar por que um nó gerenciado, *confirmadamente em execução*, não está incluído em suas listas de nós gerenciados no Systems Manager. 

Para que um nó seja gerenciado pelo Systems Manager e disponível nas listas de nós gerenciados, ele deverá atender a três requisitos principais:
+ SSM AgentO deve ser instalado e executado em um nó com um sistema operacional compatível.
**nota**  
Algumas Amazon Machine Images (AMIs) gerenciadas pela AWS estão configuradas para iniciar instâncias com o [SSM Agent](ssm-agent.md) pré-instalado. (Você também pode configurar uma AMI para pré-instalar o SSM Agent.) Para obter mais informações, consulte [Encontrar AMIs com o SSM Agent pré-instalado](ami-preinstalled-agent.md).
+ Para instâncias do Amazon Elastic Compute Cloud (Amazon EC2), você deve anexar um perfil do AWS Identity and Access Management (IAM) para a instância. O perfil da instância permite que ela se comunique com o serviço do Systems Manager. Se você não atribuir um perfil de instância à instância, registre-a usando uma [ativação híbrida](activations.md), o que não é uma situação comum.
+ SSM AgentO deve ser capaz de se conectar a um endpoint do Systems Manager para se registrar no serviço. Posteriormente, o nó gerenciado deve estar disponível para o serviço e, para confirmar isso, o serviço envia um sinal a cada cinco minutos para verificar a integridade da instância. 
+ Depois que o status de um nó gerenciado `Connection Lost` durar pelo menos 30 dias, talvez o nó não esteja mais listado no Fleet Manager console. Para restaurá-lo na lista, o problema que causou a perda da conexão deve ser resolvido.

Depois de verificar se um nó gerenciado está em execução, será possível usar o comando a seguir para verificar se o SSM Agent foi registrado com êxito no serviço Systems Manager. Este comando não retorna resultados até que um registro bem-sucedido tenha ocorrido.

------
#### [ Linux & macOS ]

```
aws ssm describe-instance-associations-status \
    --instance-id {{instance-id}}
```

------
#### [ Windows ]

```
aws ssm describe-instance-associations-status ^
    --instance-id {{instance-id}}
```

------
#### [ PowerShell ]

```
Get-SSMInstanceAssociationsStatus `
    -InstanceId {{instance-id}}
```

------

Se o registro foi bem-sucedido e o nó gerenciado estiver agora disponível para operações do Systems Manager, o comando retornará resultados semelhantes aos mostrados a seguir.

```
{
    "InstanceAssociationStatusInfos": [
        {
            "AssociationId": "fa262de1-6150-4a90-8f53-d7eb5EXAMPLE",
            "Name": "AWS-GatherSoftwareInventory",
            "DocumentVersion": "1",
            "AssociationVersion": "1",
            "InstanceId": "i-02573cafcfEXAMPLE",
            "Status": "Pending",
            "DetailedStatus": "Associated"
        },
        {
            "AssociationId": "f9ec7a0f-6104-4273-8975-82e34EXAMPLE",
            "Name": "AWS-RunPatchBaseline",
            "DocumentVersion": "1",
            "AssociationVersion": "1",
            "InstanceId": "i-02573cafcfEXAMPLE",
            "Status": "Queued",
            "AssociationName": "SystemAssociationForScanningPatches"
        }
    ]
}
```

Se o registro ainda não foi concluído ou não foi bem-sucedido, o comando retornará resultados semelhantes aos seguintes:

```
{
    "InstanceAssociationStatusInfos": []
}
```

Se o comando não retornar resultados depois de mais ou menos 5 minutos, use as informações a seguir para ajudar você a solucionar problemas com os nós gerenciados.

**Topics**
+ [Solução 1: verifique se o SSM Agent está instalado e executando em seus nós gerenciados.](#instances-missing-solution-1)
+ [Solução 2: verifique se um perfil da instância do IAM foi especificado para a instância (somente instâncias do EC2)](#instances-missing-solution-2)
+ [Solução 3: Verifique a conectividade dos endpoints do serviço](#instances-missing-solution-3)
+ [Solução 4: Verifique o suporte do sistema operacional de destino](#instances-missing-solution-4)
+ [Solução 5: verifique se você está trabalhando na mesma Região da AWS da instância do Amazon EC2](#instances-missing-solution-5)
+ [Solução 6: verifique a configuração de proxy aplicada ao SSM Agent em seu nó gerenciado](#instances-missing-solution-6)
+ [Solução 7: instale um certificado TLS em instâncias gerenciadas](#hybrid-tls-certificate)
+ [Solucionar problemas de disponibilidade do nó gerenciado usando a `ssm-cli`](troubleshooting-managed-nodes-using-ssm-cli.md)

## Solução 1: verifique se o SSM Agent está instalado e executando em seus nós gerenciados.
<a name="instances-missing-solution-1"></a>

Verifique se a versão mais recente do SSM Agent está instalada em seu nó gerenciado.

Para determinar se o SSM Agent está instalado e em execução em um nó gerenciado, consulte [Verificar o status do SSM Agent e iniciar o agente](ssm-agent-status-and-restart.md).

Para instalar ou reinstalar o SSM Agent em um nó gerenciado, consulte os seguintes tópicos:
+ [Instalar e desinstalar o SSM Agent manualmente em instâncias do EC2 para Linux](manually-install-ssm-agent-linux.md)
+ [Como instalar o SSM Agent em nós híbridos do Linux](hybrid-multicloud-ssm-agent-install-linux.md)
+ [Instalar e desinstalar o SSM Agent manualmente em instâncias do EC2 para Windows Server](manually-install-ssm-agent-windows.md)
+ [Como instalar o SSM Agent em nós híbridos do Windows](hybrid-multicloud-ssm-agent-install-windows.md)

## Solução 2: verifique se um perfil da instância do IAM foi especificado para a instância (somente instâncias do EC2)
<a name="instances-missing-solution-2"></a>

Para instâncias do Amazon Elastic Compute Cloud (Amazon EC2), verifique se a instância está configurada com um perfil da instância do AWS Identity and Access Management (IAM) que permite que a ela se comunique com a API do Systems Manager. Verifique também se o usuário tem uma política de confiança do IAM que permite que o usuário se comunique com a API do Systems Manager.

**nota**  
Os servidores on-premises, dispositivos de borda e máquinas virtuais (VMs) usam uma função de serviço do IAM em vez de um perfil da instância. Para obter mais informações, consulte [Criar o perfil de serviço do IAM obrigatório para o Systems Manager em ambientes híbridos e multinuvem](hybrid-multicloud-service-role.md).

**Para determinar se um perfil da instância com as permissões necessárias está anexado a uma instância do EC2**

1. Abra o console do Amazon EC2 em [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).

1. No painel de navegação, escolha **Instances (Instâncias)**.

1. Selecione a instância na qual verificar um perfil de instância.

1. Na guia **Description** (Descrição) do painel inferior, localize **IAM role** (Função do IAM) e escolha o nome da função.

1. Na página **Summary** (Resumo) da função para o perfil da instância, na guia **Permissions** (Permissões), verifique se `AmazonSSMManagedInstanceCore` está listado em **Permissions policies** (Políticas de permissões).

   Se uma política personalizada for usada, verifique se ela fornece as mesmas permissões que o `AmazonSSMManagedInstanceCore`.

   [Abra `AmazonSSMManagedInstanceCore` no console](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore$jsonEditor).

   Para obter informações sobre outras políticas que podem ser anexadas a um perfil de instância para o Systems Manager, consulte [Configurar permissões de instância obrigatórias para o Systems Manager](setup-instance-permissions.md).

## Solução 3: Verifique a conectividade dos endpoints do serviço
<a name="instances-missing-solution-3"></a>

Verifique se a instância tem conectividade com os endpoints de serviço do Systems Manager. Essa conectividade é fornecida com a criação e configuração de endpoints da VPC para o Systems Manager ou com a permissão do tráfego de saída HTTPS (porta 443) para os endpoints de serviço.

Para instâncias do Amazon EC2, o endpoint de serviço do Systems Manager para a Região da AWS é usado para registrar a instância se sua configuração de nuvem privada virtual (VPC) permitir o tráfego de saída. No entanto, se a configuração da VPC na qual a instância foi executada não permitir tráfego de saída e você não puder alterar essa configuração para permitir conectividade com os endpoints de serviço público, configure endpoints de interface para sua VPC.

Para obter mais informações, consulte [Melhorar a segurança das instâncias do EC2 usando endpoints da VPC para o Systems Manager](setup-create-vpc.md).

## Solução 4: Verifique o suporte do sistema operacional de destino
<a name="instances-missing-solution-4"></a>

Verifique se a operação escolhida pode ser executada no tipo de nó gerenciado que você espera ver listado. Algumas operações do Systems Manager podem visar somente instâncias do Windows ou somente instâncias do Linux. Por exemplo, os documentos do Systems Manager (SSM) `AWS-InstallPowerShellModule` e `AWS-ConfigureCloudWatch` podem ser executados somente em instâncias do Windows. Na página **Run a command** (Executar um comando), se você escolher um desses documentos e selecionar **Choose instances manually**, (Escolher instâncias manualmente), somente as instâncias do Windows serão listadas e disponibilizadas para seleção.

## Solução 5: verifique se você está trabalhando na mesma Região da AWS da instância do Amazon EC2
<a name="instances-missing-solution-5"></a>

Instâncias do Amazon EC2 são criadas e disponibilizadas nas Regiões da AWS específicas, como a Região Leste dos EUA (Ohio) (us-east-2) ou Europa (Irlanda) (eu-west-1). Verifique se você está trabalhando na mesma Região da AWS da instância do Amazon EC2 com a qual você deseja trabalhar. Para obter mais informações, consulte [Selecionar uma região](https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/getting-started.html#select-region), em *Conceitos básicos do Console de gerenciamento da AWS*.

## Solução 6: verifique a configuração de proxy aplicada ao SSM Agent em seu nó gerenciado
<a name="instances-missing-solution-6"></a>

Verifique se a configuração de proxy aplicada ao SSM Agent em seu nó gerenciado está correta. Se a configuração de proxy estiver incorreta, o nó não poderá se conectar aos endpoints de serviço necessários ou o Systems Manager poderá identificar incorretamente o sistema operacional do nó gerenciado. Para obter mais informações, consulte [Configurar o SSM Agent para usar um proxy em nós do Linux](configure-proxy-ssm-agent.md) e [Configurar o SSM Agent para usar um proxy para instâncias do Windows Server](configure-proxy-ssm-agent-windows.md).

## Solução 7: instale um certificado TLS em instâncias gerenciadas
<a name="hybrid-tls-certificate"></a>

Um certificado Transport Layer Security (TLS - Segurança de camada de transporte) deve ser instalado em cada instância gerenciada que você usa com o AWS Systems Manager. Os Serviços da AWS usam esses certificados para criptografar chamadas para outros Serviços da AWS.

Por padrão, um certificado TLS já está instalado em cada instância do Amazon EC2 criada em qualquer Amazon Machine Image (AMI). A maioria dos sistemas operacionais modernos inclui o certificado TLS necessário das autoridades de certificação do Amazon Trust Services em seu armazenamento confiável.

Para verificar se o certificado necessário está instalado na instância, execute o seguinte comando com base no sistema operacional da instância. Substitua a parte referente à {{região}} do URL por Região da AWS onde o nó gerenciado estiver localizado.

------
#### [ Linux & macOS ]

```
curl -L https://ssm.{{region}}.amazonaws.com
```

------
#### [ Windows ]

```
Invoke-WebRequest -Uri https://ssm.{{region}}.amazonaws.com
```

------

O comando deve retornar um erro `UnknownOperationException`. Se você receber uma mensagem de erro SSL/TLS, o certificado necessário talvez não esteja instalado.

Se você achar que os certificados CA necessários do Amazon Trust Services não estão instalados nos sistemas operacionais de base, em instâncias criadas de AMIs que não são fornecidas pela Amazon ou em seus próprios servidores on-premises e VMs, será necessário instalar e habilitar um certificado do [Amazon Trust Services](https://www.amazontrust.com/repository/) ou usar o AWS Certificate Manager (ACM) para criar e gerenciar certificados para um serviço integrado compatível.

Cada instância gerenciada deve ter um dos seguintes certificados Transport Layer Security (TLS) instalado.
+ Amazon Root CA 1
+ Starfield Services Root Certificate Authority – G2
+ Starfield Class 2 Certificate Authority

Para obter informações sobre o ACM, consulte o *[Guia do usuário do AWS Certificate Manager](https://docs.aws.amazon.com/acm/latest/userguide/)*.

Se os certificados em seu ambiente de computação forem gerenciados por um Group Policy Object (GPO - Objeto de política de grupo), poderá ser necessário configurar a política de grupo para incluir um desses certificados.

Para obter mais informações sobre os certificados Amazon Root e Starfield, consulte a publicação do blog [How to Prepare for AWS’s Move to Its Own Certificate Authority](https://aws.amazon.com/blogs/security/how-to-prepare-for-aws-move-to-its-own-certificate-authority/).