• 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).
# Gerenciar nós em ambientes híbridos e multinuvem com o Systems Manager
Você pode usar o AWS Systems Manager para gerenciar instâncias do Amazon Elastic Compute Cloud (EC2) e vários tipos de máquinas que não são do EC2. Esta seção descreve as tarefas de configuração que os administradores de sistema e de conta executam para gerenciar máquinas que não são do EC2 usando o Systems Manager em um *ambiente [híbrido e multinuvem](operating-systems-and-machine-types.md#supported-machine-types)*. Depois que essas etapas forem concluídas, os usuários que tiveram permissões concedidas pelo administrador da Conta da AWS poderão usar o Systems Manager para configurar e gerenciar as máquinas da organização que não são do EC2.
Qualquer máquina configurada para uso com o Systems Manager é chamada de *nó gerenciado*.
**nota**
É possível registrar dispositivos de borda como nós gerenciados usando as mesmas etapas de ativação híbrida usadas para outras máquinas que não são do EC2. Esses tipos de dispositivos de borda incluem dispositivos do AWS IoT e dispositivos que não são dispositivos do AWS IoT. Use o processo descrito nesta seção para configurar esses tipos de dispositivos de borda.
O Systems Manager também oferece suporte a dispositivos de borda que usam o software AWS IoT Greengrass Core. O processo de configuração e os requisitos dos dispositivos AWS IoT Greengrass principais são diferentes daqueles para dispositivos de AWS IoT de borda que não sejam dispositivos de borda da AWS. Para obter informações sobre o registro de dispositivos AWS IoT Greengrass para uso com o Systems Manager, consulte [Gerenciar dispositivos de borda com o Systems Manager](systems-manager-setting-up-edge-devices.md).
Máquinas do macOS que não sejam do EC2 não são compatíveis com ambientes híbridos e multinuvem do Systems Manager.
Se você planeja usar o Systems Manager para gerenciar instâncias do Amazon Elastic Compute Cloud (Amazon EC2) ou usar instâncias do Amazon EC2 e máquinas que não são do EC2 em um ambiente híbrido e multinuvem, siga primeiro as etapas descritas em [Gerenciar instâncias do EC2 com o Systems Manager](systems-manager-setting-up-ec2.md).
Após configurar o ambiente híbrido e multinuvem para o Systems Manager, é possível fazer o seguinte:
+ Crie uma forma consistente e segura de gerenciar remotamente suas workloads híbridas e multinuvem com base em um local usando as mesmas ferramentas ou scripts.
+ Centralize o controle de acesso para as ações que podem ser realizadas nas máquinas, usando o AWS Identity and Access Management (IAM).
+ Centralize a auditoria das operações realizadas em suas máquinas visualizando a atividade da API registrada no AWS CloudTrail.
Para obter informações sobre como usar o CloudTrail para monitorar ações do Systems Manager, consulte [Registrar em log chamadas de API do AWS Systems Manager com o AWS CloudTrail](monitoring-cloudtrail-logs.md).
+ Centralize o monitoramento configurando o Amazon EventBridge e o Amazon Simple Notification Service (Amazon SNS) para enviarem notificações sobre o êxito da execução do serviço.
Para obter informações sobre como usar o EventBridge para monitorar eventos do Systems Manager, consulte [Monitorar eventos do Systems Manager com o Amazon EventBridge](monitoring-eventbridge-events.md).
**Sobre nós gerenciados**
Depois de concluir a configuração de máquinas que não são do EC2 para o Systems Manager, conforme descrito nesta seção, as máquinas ativadas para ambiente híbrido serão listadas no Console de gerenciamento da AWS e descritas como *nós gerenciados*. No console, os IDs dos nós gerenciados ativados para ambiente híbrido são diferenciados das instâncias do Amazon EC2 com o prefixo “mi-”. Os IDs das instâncias do Amazon EC2 usam o prefixo “i-”.
Um nó gerenciado é qualquer máquina configurada para o Systems Manager. Anteriormente, todos os nós gerenciados eram chamados de instâncias gerenciadas. O termo *instância* agora se refere somente às instâncias do EC2. O comando [deregister-managed-instance](https://docs.aws.amazon.com/cli/latest/reference/ssm/deregister-managed-instance.html) foi nomeado antes da mudança de terminologia.
Para obter mais informações, consulte [Trabalhar com nós gerenciados](fleet-manager-managed-nodes.md).
**Importante**
É altamente recomendável que você evite usar versões do sistema operacional que tenham atingido o fim da vida útil (EOL). Os fornecedores de sistemas operacionais, inclusive a AWS, normalmente não fornecem patches de segurança ou outras atualizações para versões que atingiram o EOL. Continuar usando um sistema EOL aumenta muito o risco de não conseguir aplicar atualizações, incluindo correções de segurança e outros problemas operacionais. A AWS não testa a funcionalidade do Systems Manager em versões do sistema operacional que atingiram o EOL.
**Sobre níveis de instância**
O Systems Manager oferece um nível de instâncias padrão e um nível de instâncias avançadas para nós gerenciados que não são do EC2 em seu ambiente híbrido e multinuvem. O nível de instâncias padrão permite registrar no máximo mil máquinas ativadas para ambiente híbrido por Conta da AWS e por Região da AWS. Se precisar registrar mais de mil máquinas que não são do EC2 em uma única conta e região, use o nível de instâncias avançadas. Instâncias avançadas também permitem que você se conecte às suas máquinas que não são do EC2 usando o Session Manager do AWS Systems Manager. O Session Manager fornece acesso via shell interativo aos nós gerenciados.
Para obter mais informações, consulte [Configurar níveis de instâncias](fleet-manager-configure-instance-tiers.md).
**Topics**
+ [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)
+ [Criar uma ativação híbrida para registrar nós no Systems Manager](hybrid-activation-managed-nodes.md)
+ [Instalar o SSM Agent em nós híbridos do Linux](hybrid-multicloud-ssm-agent-install-linux.md)
+ [Instalar o SSM Agent em nós híbridos do Windows Server](hybrid-multicloud-ssm-agent-install-windows.md)
# Criar o perfil de serviço do IAM obrigatório para o Systems Manager em ambientes híbridos e multinuvem
Máquinas que não são do Amazon Elastic Compute Cloud (EC2) em um ambiente [híbrido e multinuvem](operating-systems-and-machine-types.md#supported-machine-types) exigem um perfil de serviço do AWS Identity and Access Management (IAM) para se comunicarem com o serviço do AWS Systems Manager. A atribuição de função do AWS Security Token Service (AWS STS) [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) confiança para o serviço Systems Manager. Só é necessário criar um perfil de serviço para um ambiente híbrido e multinuvem uma vez para cada Conta da AWS. No entanto, você poderá optar por criar vários perfis de serviço para diferentes ativações híbridas se as máquinas em seu ambiente híbrido e multinuvem exigirem permissões diferentes.
Os procedimentos a seguir descrevem como criar a função de serviço necessária usando o console do Systems Manager ou sua ferramenta de linha de comando preferida.
## Usar o Console de gerenciamento da AWS para criar um perfil de serviço do IAM para ativações híbridas do Systems Manager
Use o procedimento a seguir para criar um perfil de serviço para a ativação híbrida. Este procedimento usa a política `AmazonSSMManagedInstanceCore` para a funcionalidade principal do Systems Manager. Dependendo do seu caso de uso, talvez seja necessário adicionar políticas à sua função de serviço em máquinas on-premises para poder acessar outras ferramentas do Systems Manager ou Serviços da AWS. Por exemplo, sem acesso aos buckets necessários do Amazon Simple Storage Service (Amazon S3), gerenciados pela AWS, as operações de aplicação de patches do Patch Manager falham.
**Como criar uma função de serviço do (console)**
1. Abra o console do IAM em [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. No painel de navegação, escolha **Roles** e **Create role**.
1. Em **Select trusted entity** (Selecionar entidade confiável), faça as seguintes escolhas:
1. Em **Tipo de entidade confiável**, escolha **AWS service (Serviço da AWS)**.
1. Em **Casos de uso para outros Serviços da AWS**, escolha **Systems Manager**.
1. Escolha **Systems Manager**.
A imagem a seguir destaca a localização da opção Systems Manager.
![\[O Systems Manager é uma das opções para o Caso de uso.\]](http://docs.aws.amazon.com/pt_br/systems-manager/latest/userguide/images/iam_use_cases_for_MWs.png)
1. Escolha **Próximo**.
1. Na página **Adicionar permissões**, faça o seguinte:
+ Use o campo **Search** (Pesquisar) para localizar **AmazonSSMManagedInstanceCore**. Marque a caixa de seleção próximo a seu nome, conforme mostrado na ilustração a seguir.
![\[A caixa de seleção é marcada na linha AmazonSSMManagedInstanceCore.\]](http://docs.aws.amazon.com/pt_br/systems-manager/latest/userguide/images/setup-instance-profile-2.png)
**nota**
O console reterá sua seleção mesmo que você pesquise outras políticas.
+ Se você tiver criado uma política de bucket do S3 personalizada no procedimento anterior, [(Opcional) Criação de uma política personalizada para acesso ao bucket do S3](setup-instance-permissions.md#instance-profile-custom-s3-policy), procure-a e marque a caixa de seleção ao lado de seu nome.
+ Se você planejar ingressar máquinas que não são do EC2 em um Active Directory gerenciado pelo Directory Service, pesquise por **AmazonSSMDirectoryServiceAccess** e marque a caixa de seleção ao lado do nome.
+ Se você pretende usar o EventBridge ou o CloudWatch Logs para gerenciar ou monitorar seu nó gerenciado, pesquise por **CloudWatchAgentServerPolicy** e marque a caixa de seleção ao lado do nome.
1. Escolha **Próximo**.
1. Em **Nome do perfil**, insira um nome para o novo perfil de servidor do IAM, como **SSMServerRole**.
**nota**
Anote o nome da função. Você escolherá esse perfil ao registrar novas máquinas que deseja gerenciar usando o Systems Manager.
1. (Opcional) Em **Descrição**, atualize a descrição deste perfil de servidor do IAM.
1. (Opcional) em **Tags**, adicione um ou mais pares de valores tag-chave para organizar, monitorar ou controlar acesso para essa função.
1. Selecione **Create role** (Criar função). O sistema faz com que você retorne para a página **Roles**.
## Usar o AWS CLI para criar um perfil de serviço do IAM para ativações híbridas do Systems Manager
Use o procedimento a seguir para criar um perfil de serviço para a ativação híbrida. Este procedimento usa a política `AmazonSSMManagedInstanceCore` para a funcionalidade principal do Systems Manager. Dependendo do caso de uso, talvez seja necessário adicionar outras políticas ao perfil de serviço em máquinas não EC2 em um ambiente [híbrido e multinuvem](operating-systems-and-machine-types.md#supported-machine-types) para poder acessar outras ferramentas ou Serviços da AWS.
**Requisito de política do bucket do S3**
Se qualquer um dos seguintes casos for verdadeiro, crie uma política de permissões personalizada do IAM e para os buckets do Amazon Simple Storage Service (Amazon S3) antes de concluir este procedimento:
+ **Caso 1**: você está usando um endpoint da VPC para conectar de forma privada sua VPC aos Serviços da AWS compatíveis e aos serviços do endpoint da VPC com a tecnologia AWS PrivateLink.
+ **Caso 2**: você planeja usar um bucket do Amazon S3 criado como parte das operações do Systems Manager, por exemplo, para armazenar a saída para comandos do Run Command ou as sessões do Session Manager em um bucket do S3. Antes de continuar, siga as etapas em [Create a custom S3 bucket policy for an instance profile](setup-instance-permissions.md#instance-profile-custom-s3-policy) (Criar uma política personalizada de bucket do S3 para um perfil de instância). As informações sobre políticas de bucket do S3 neste tópico também se aplicam à sua função de serviço.
------
#### [ AWS CLI ]
**Para criar um perfil de serviço do IAM para um ambiente híbrido e multinuvem (AWS CLI)**
1. Instale e configure a AWS Command Line Interface (AWS CLI), caso ainda não o tenha feito.
Para obter informações, consulte [Instalar ou atualizar a versão mais recente da AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).
1. Em sua máquina local, crie um arquivo de texto com um nome como `SSMService-Trust.json` com a política de confiança a seguir. Certifique-se de salvar o arquivo com a extensão de arquivo `.json`. Especifique a Conta da AWS e a Região da AWS no ARN onde você criou a ativação híbrida. Substitua os *valores dos espaços reservados* para ID da conta e região por suas próprias informações.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"",
"Effect":"Allow",
"Principal":{
"Service":"ssm.amazonaws.com"
},
"Action":"sts:AssumeRole",
"Condition":{
"StringEquals":{
"aws:SourceAccount":"123456789012"
},
"ArnEquals":{
"aws:SourceArn":"arn:aws:ssm:us-east-1:111122223333:*"
}
}
}
]
}
```
------
1. Abra a AWS CLI e, no diretório em que você criou o arquivo JSON, execute o [create-role](https://docs.aws.amazon.com/cli/latest/reference/iam/create-role.html) para criar a função de serviço. Este exemplo cria uma função chamada `SSMServiceRole`. É possível escolher outro nome, se você preferir.
------
#### [ Linux & macOS ]
```
aws iam create-role \
--role-name SSMServiceRole \
--assume-role-policy-document file://SSMService-Trust.json
```
------
#### [ Windows ]
```
aws iam create-role ^
--role-name SSMServiceRole ^
--assume-role-policy-document file://SSMService-Trust.json
```
------
1. Execute o comando [attach-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/attach-role-policy.html) da maneira a seguir para permitir que a função de serviço recém-criada crie um token de sessão. O token de sessão concede ao seu nó gerenciado permissão para executar comandos usando o Systems Manager.
**nota**
As políticas que você adicionar para um perfil de serviço para nós gerenciados em um ambiente híbrido e multinuvem serão as mesmas políticas usadas para criar um perfil de instância para instâncias do Amazon Elastic Compute Cloud (Amazon EC2). Para obter mais informações sobre as políticas da AWS usadas nos comandos a seguir, consulte [Configurar permissões de instância obrigatórias para o Systems Manager](setup-instance-permissions.md).
(Obrigatório) Execute o comando a seguir para permitir que um nó gerenciado use a funcionalidade básica do serviço do AWS Systems Manager.
------
#### [ Linux & macOS ]
```
aws iam attach-role-policy \
--role-name SSMServiceRole \
--policy-arn arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
```
------
#### [ Windows ]
```
aws iam attach-role-policy ^
--role-name SSMServiceRole ^
--policy-arn arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
```
------
Se você tiver criado uma política de bucket do S3 personalizada para sua função de serviço, execute o comando a seguir para permitir que o AWS Systems Manager Agent (SSM Agent) acesse os buckets que você especificou na política. Substitua *account-id* e *amzn-s3-demo-bucket* pelo ID da Conta da AWS e o nome do bucket.
------
#### [ Linux & macOS ]
```
aws iam attach-role-policy \
--role-name SSMServiceRole \
--policy-arn arn:aws:iam::account-id:policy/amzn-s3-demo-bucket
```
------
#### [ Windows ]
```
aws iam attach-role-policy ^
--role-name SSMServiceRole ^
--policy-arn arn:aws:iam::account-id:policy/amzn-s3-demo-bucket
```
------
(Opcional) Execute o comando a seguir para permitir que o SSM Agent acesse o Directory Service em seu nome para solicitações para ingressar no domínio pelo nó gerenciado. Seu perfil de serviço precisará dessa política somente se você integrar seus nós a um diretório do Microsoft AD.
------
#### [ Linux & macOS ]
```
aws iam attach-role-policy \
--role-name SSMServiceRole \
--policy-arn arn:aws:iam::aws:policy/AmazonSSMDirectoryServiceAccess
```
------
#### [ Windows ]
```
aws iam attach-role-policy ^
--role-name SSMServiceRole ^
--policy-arn arn:aws:iam::aws:policy/AmazonSSMDirectoryServiceAccess
```
------
(Opcional) Execute o comando a seguir para permitir que o agente do CloudWatch seja executado nos seus nós gerenciados. Este comando permite ler informações em um nó e gravá-las no CloudWatch. Seu perfil de serviço precisará dessa política somente se você pretende usar serviços como o Amazon EventBridge ou Amazon CloudWatch Logs.
```
aws iam attach-role-policy \
--role-name SSMServiceRole \
--policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy
```
------
#### [ Tools for PowerShell ]
**Para criar um perfil de serviço do IAM para um ambiente híbrido e multinuvem (AWS Tools for Windows PowerShell)**
1. Instale e configure o Ferramentas da AWS para PowerShell (Ferramentas para Windows PowerShell), caso ainda não o tenha feito.
Para obter informações, consulte [Instalar o Ferramentas da AWS para PowerShell](https://docs.aws.amazon.com/powershell/latest/userguide/pstools-getting-set-up.html).
1. Em sua máquina local, crie um arquivo de texto com um nome como `SSMService-Trust.json` com a política de confiança a seguir. Certifique-se de salvar o arquivo com a extensão de arquivo `.json`. Especifique a Conta da AWS e a Região da AWS no ARN onde você criou a ativação híbrida.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": "ssm.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "123456789012"
},
"ArnEquals": {
"aws:SourceArn": "arn:aws:ssm:us-east-1:123456789012:*"
}
}
}
]
}
```
------
1. Abra o PowerShell no modo administrativo e no diretório em que você criou o arquivo JSON, execute o[New-IAMRole](https://docs.aws.amazon.com//powershell/latest/reference/items/Register-IAMRolePolicy.html)da seguinte maneira para criar uma função de serviço. Este exemplo cria uma função chamada `SSMServiceRole`. É possível escolher outro nome, se você preferir.
```
New-IAMRole `
-RoleName SSMServiceRole `
-AssumeRolePolicyDocument (Get-Content -raw SSMService-Trust.json)
```
1. Use [Register-IAMRolePolicy](https://docs.aws.amazon.com/powershell/latest/reference/items/Register-IAMRolePolicy.html) conforme a seguir para permitir a função de serviço que você criou para criar um token de sessão. O token de sessão concede ao seu nó gerenciado permissão para executar comandos usando o Systems Manager.
**nota**
As políticas que você adicionar para um perfil de serviço para nós gerenciados em um ambiente híbrido e multinuvem serão as mesmas políticas usadas para criar um perfil de instância para instâncias do EC2. Para obter mais informações sobre as políticas da AWS usadas nos comandos a seguir, consulte [Configurar permissões de instância obrigatórias para o Systems Manager](setup-instance-permissions.md).
(Obrigatório) Execute o comando a seguir para permitir que um nó gerenciado use a funcionalidade básica do serviço do AWS Systems Manager.
```
Register-IAMRolePolicy `
-RoleName SSMServiceRole `
-PolicyArn arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
```
Se você tiver criado uma política de bucket do S3 personalizada para sua função de serviço, execute o comando a seguir para permitir que o SSM Agent acesse os buckets que você especificou na política. Substitua *account-id* e *my-bucket-policy-name* pelo ID da Conta da AWS e o nome do bucket.
```
Register-IAMRolePolicy `
-RoleName SSMServiceRole `
-PolicyArn arn:aws:iam::account-id:policy/my-bucket-policy-name
```
(Opcional) Execute o comando a seguir para permitir que o SSM Agent acesse o Directory Service em seu nome para solicitações para ingressar no domínio pelo nó gerenciado. Seu perfil de servidor precisará dessa política somente se você integrar seus nós a um diretório do Microsoft AD.
```
Register-IAMRolePolicy `
-RoleName SSMServiceRole `
-PolicyArn arn:aws:iam::aws:policy/AmazonSSMDirectoryServiceAccess
```
(Opcional) Execute o comando a seguir para permitir que o agente do CloudWatch seja executado nos seus nós gerenciados. Este comando permite ler informações em um nó e gravá-las no CloudWatch. Seu perfil de serviço precisará dessa política somente se você pretende usar serviços como o Amazon EventBridge ou Amazon CloudWatch Logs.
```
Register-IAMRolePolicy `
-RoleName SSMServiceRole `
-PolicyArn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy
```
------
Avance para [Criar uma ativação híbrida para registrar nós no Systems Manager](hybrid-activation-managed-nodes.md).
# Criar uma ativação híbrida para registrar nós no Systems Manager
Para configurar máquinas que não sejam instâncias do Amazon Elastic Compute Cloud (EC2) como nós gerenciados para um [ambiente híbrido e multinuvem](operating-systems-and-machine-types.md#supported-machine-types), crie e aplique uma *ativação híbrida*. Após concluir a ativação com êxito, você receberá *imediatamente* um código de ativação e um ID de ativação na parte de cima da página do console. Especifique essa combinação de código e ID ao instalar o AWS Systems Manager SSM Agent em máquinas que não são do EC2 em seu ambiente híbrido e multinuvem. O código e o ID fornecem acesso seguro ao serviço do Systems Manager a partir dos seus nós gerenciados.
**Importante**
O Systems Manager retorna imediatamente o ID e o código de ativação para o console ou a janela de comando, dependendo de como você criou a ativação. Copie essas informações e armazene-as em um local seguro. Se você sair do console ou fechar a janela de comando, poderá perder essas informações. Se perdê-las, será necessário criar outra ativação.
**Sobre expirações de ativação**
Uma *expiração de ativação* é uma janela de tempo em que você pode registrar máquinas on-premises no Systems Manager. Uma ativação expirada não tem impacto sobre seus servidores ou VMs registradas anteriormente no Systems Manager. Se uma ativação expirar, você não poderá registrar mais servidores ou VMs no Systems Manager usando essa ativação específica. Você simplesmente precisa criar uma nova.
Cada VM e servidor on-premises registrado anteriormente permanecerá registrado como um nó gerenciado do Systems Manager até que você cancele o registro deles explicitamente. Você pode cancelar o registro de um nó gerenciado não EC2 das seguintes formas:
+ Use a guia **Nós gerenciados** no Fleet Manager no console do Systems Manager
+ Use o comando [https://docs.aws.amazon.com/cli/latest/reference/ssm/deregister-managed-instance.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/deregister-managed-instance.html) da AWS CLI
+ Use a ação da API [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DeregisterManagedInstance.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DeregisterManagedInstance.html).
Para obter mais informações, consulte os tópicos a seguir
+ [Cancele o registro e registre um nó gerenciado novamente (Linux)](hybrid-multicloud-ssm-agent-install-linux.md#systems-manager-install-managed-linux-deregister-reregister)
+ [Cancelar o registro e registrar um nó gerenciado novamente (Windows Server)](hybrid-multicloud-ssm-agent-install-windows.md#systems-manager-install-managed-win-deregister-reregister)
**Sobre nós gerenciados**
Um nó gerenciado é qualquer máquina configurada para o AWS Systems Manager. O AWS Systems Manager oferece suporte a instâncias, dispositivos de borda, servidores on-premises ou VMs do Amazon Elastic Compute Cloud (Amazon EC2), incluindo VMs em outros ambientes de nuvem. Anteriormente, todos os nós gerenciados eram chamados de instâncias gerenciadas. O termo *instância* agora se refere somente às instâncias do EC2. O comando [deregister-managed-instance](https://docs.aws.amazon.com/cli/latest/reference/ssm/deregister-managed-instance.html) foi nomeado antes da mudança de terminologia.
**Sobre tags de ativação**
Se você criar uma ativação usando a AWS Command Line Interface (AWS CLI) ou o AWS Tools for Windows PowerShell, poderá especificar tags. Tags são metadados opcionais que você atribui a um recurso. As tags permitem categorizar um recurso de diferentes formas, como por finalidade, proprietário ou ambiente. Veja a seguir um comando de exemplo da AWS CLI a ser executado na região Leste dos EUA (Ohio) em uma máquina Linux local que inclui tags opcionais.
```
aws ssm create-activation \
--default-instance-name MyWebServers \
--description "Activation for Finance department webservers" \
--iam-role service-role/AmazonEC2RunCommandRoleForManagedInstances \
--registration-limit 10 \
--region us-east-2 \
--tags "Key=Department,Value=Finance"
```
Se você especificar tags ao criar uma ativação, essas tags serão atribuídas automaticamente aos seus nós gerenciados quando você ativá-los.
Você não pode adicionar ou excluir tags de uma ativação existente. Se você não quiser atribuir tags automaticamente aos servidores e VMs on-premises usando uma ativação, poderá adicionar tags a eles posteriormente. Mais especificamente, você poderá marcar os servidores on-premises e VMs depois que eles se conectarem ao Systems Manager pela primeira vez. Depois de se conectarem, eles receberão um ID de nó gerenciado e serão listados no console do Systems Manager com um ID prefixado com "mi-".
**nota**
Não é possível atribuir tags a uma ativação se você criá-la usando o console do Systems Manager. Você deve criá-la usando a AWS CLI ou Tools for Windows PowerShell.
Se não quiser mais gerenciar um servidor on-premises ou uma máquina virtual (VM) usando o Systems Manager, você poderá cancelar o registro. Para mais informações, consulte [Cancelar o registro de nós gerenciados em um ambiente híbrido e multinuvem](fleet-manager-deregister-hybrid-nodes.md).
**Topics**
+ [Usar o Console de gerenciamento da AWS para criar uma ativação para registrar nós gerenciados com o Systems Manager](#create-managed-node-activation-console)
+ [Usar a linha de comando para criar uma ativação para registrar nós gerenciados com o Systems Manager](#create-managed-node-activation-command-line)
## Usar o Console de gerenciamento da AWS para criar uma ativação para registrar nós gerenciados com o Systems Manager
**Para criar uma ativação de nó gerenciado**
1. Abra o console AWS Systems Manager em [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. No painel de navegação, selecione **Ativações híbridas do**.
1. Escolha **Create activation**.
- ou -
Se estiver acessando **Hibrid Activations** (Ativações híbridas) pela primeira vez na Região da AWS atual, escolha **Create an Activation** (Criar uma ativação).
1. (Opcional) Em **Activation description** (Descrição da ativação), insira uma descrição para essa ativação. Recomendamos inserir uma descrição caso pretenda ativar um grande número de servidores e VMs.
1. Em **Instance limit** (Limite da instância), especifique o número total de nós que deseja registrar com a AWS como parte dessa ativação. O valor padrão é uma instância.
1. Em **IAM role** (Perfil do IAM), escolha uma opção de perfil de serviço que permita que seus servidores e VMs comuniquem-se com o AWS Systems Manager na nuvem:
+ **Opção 1**: escolha **Use the default role created by the system** (Usar o perfil padrão criado pelo sistema) para usar um perfil e uma política gerenciada fornecida pela AWS.
+ **Opção 2**: escolha **Select an existing custom IAM role that has the required permissions** (Selecionar um perfil do IAM personalizado existente que tenha as permissões necessárias) para usar o perfil personalizado opcional que você criou anteriormente. Essa função deve ter uma política de relação de confiança que especifique o `"Service": "ssm.amazonaws.com"`. Se sua função do IAM não especificar esse princípio em uma política de relacionamento de confiança, você receberá o seguinte erro:
```
An error occurred (ValidationException) when calling the CreateActivation
operation: Not existing role: arn:aws:iam:::role/SSMRole
```
Para obter mais informações sobre a criação do perfil, 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).
1. Em **Activation expiry date** (Data de expiração da ativação), especifique uma data de expiração para a ativação. A data de validade deve ser no futuro, e não mais de 30 dias no futuro. O valor padrão é 24 horas.
**nota**
Se você quiser registrar nós gerenciados adicionais após a data de expiração, deverá criar uma nova ativação. A data de expiração não tem impacto sobre nós registrados e em execução.
1. (Opcional) No campo **Default instance name** (Nome da instância padrão), especifique um valor de nome de identificação a ser exibido para todos os nós gerenciados associados a essa ativação.
1. Escolha **Create activation**. O Systems Manager retorna imediatamente o código de ativação e o ID para o console.
## Usar a linha de comando para criar uma ativação para registrar nós gerenciados com o Systems Manager
O procedimento a seguir descreve como usar a AWS Command Line Interface (AWS CLI) (no Linux ou no Windows Server) ou o Ferramentas da AWS para PowerShell para criar uma ativação de nó gerenciado.
**Para criar uma ativação**
1. Instale e configure a AWS CLI ou o Ferramentas da AWS para PowerShell, caso ainda não o tenha feito.
Para obter informações, consulte [Instalar ou atualizar a versão mais recente da AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) e [Instalar o Ferramentas da AWS para PowerShell](https://docs.aws.amazon.com/powershell/latest/userguide/pstools-getting-set-up.html).
1. Execute o seguinte comando para criar uma ativação.
**nota**
No comando a seguir, substitua *region* por suas próprias informações. Para ver uma lista dos valores de *região* com suporte, consulte a coluna **Region** em [Systems Manager service endpoints](https://docs.aws.amazon.com/general/latest/gr/ssm.html#ssm_region) no *Referência geral da Amazon Web Services*.
A função que você especifica para o*IAM role*O parâmetro do precisa ter uma política de relação de confiança que especifique o`"Service": "ssm.amazonaws.com"`. Se suas receitas AWS Identity and Access Management (IAM) não especificar esse princípio em uma política de relacionamento de confiança, você recebe o seguinte erro:
```
An error occurred (ValidationException) when calling the CreateActivation
operation: Not existing role: arn:aws:iam:::role/SSMRole
```
Para obter mais informações sobre a criação do perfil, 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 `--expiration-date`, forneça uma data no formato de carimbo de data/hora, como `"2021-07-07T00:00:00"`, para quando o código de ativação expirar. Você pode especificar uma data com até 30 dias de antecedência. Se você não fornecer uma data de expiração, o código de ativação expira em 24 horas.
------
#### [ Linux & macOS ]
```
aws ssm create-activation \
--default-instance-name name \
--iam-role iam-service-role-name \
--registration-limit number-of-managed-instances \
--region region \
--expiration-date "timestamp" \\
--tags "Key=key-name-1,Value=key-value-1" "Key=key-name-2,Value=key-value-2"
```
------
#### [ Windows ]
```
aws ssm create-activation ^
--default-instance-name name ^
--iam-role iam-service-role-name ^
--registration-limit number-of-managed-instances ^
--region region ^
--expiration-date "timestamp" ^
--tags "Key=key-name-1,Value=key-value-1" "Key=key-name-2,Value=key-value-2"
```
------
#### [ PowerShell ]
```
New-SSMActivation -DefaultInstanceName name `
-IamRole iam-service-role-name `
-RegistrationLimit number-of-managed-instances `
–Region region `
-ExpirationDate "timestamp" `
-Tag @{"Key"="key-name-1";"Value"="key-value-1"},@{"Key"="key-name-2";"Value"="key-value-2"}
```
------
Aqui está um exemplo.
------
#### [ Linux & macOS ]
```
aws ssm create-activation \
--default-instance-name MyWebServers \
--iam-role service-role/AmazonEC2RunCommandRoleForManagedInstances \
--registration-limit 10 \
--region us-east-2 \
--expiration-date "2021-07-07T00:00:00" \
--tags "Key=Environment,Value=Production" "Key=Department,Value=Finance"
```
------
#### [ Windows ]
```
aws ssm create-activation ^
--default-instance-name MyWebServers ^
--iam-role service-role/AmazonEC2RunCommandRoleForManagedInstances ^
--registration-limit 10 ^
--region us-east-2 ^
--expiration-date "2021-07-07T00:00:00" ^
--tags "Key=Environment,Value=Production" "Key=Department,Value=Finance"
```
------
#### [ PowerShell ]
```
New-SSMActivation -DefaultInstanceName MyWebServers `
-IamRole service-role/AmazonEC2RunCommandRoleForManagedInstances `
-RegistrationLimit 10 `
–Region us-east-2 `
-ExpirationDate "2021-07-07T00:00:00" `
-Tag @{"Key"="Environment";"Value"="Production"},@{"Key"="Department";"Value"="Finance"}
```
------
Se a ativação for criada com êxito, o sistema retornará imediatamente um ID e código de ativação.
# Instalar o SSM Agent em nós híbridos do Linux
Este tópico descreve como instalar o SSM Agent do AWS Systems Manager em máquinas Linux que não são do (EC2) Amazon Elastic Compute Cloud em um ambiente [híbrido e multinuvem](operating-systems-and-machine-types.md#supported-machine-types). Para obter informações sobre como instalar o SSM Agent em instâncias do EC2 para , consulte [Instalar e desinstalar o SSM Agent manualmente em instâncias do EC2 para Linux](manually-install-ssm-agent-linux.md).
Antes de começar, localize o Código de Ativação e o ID de Ativação que foram gerados durante o processo de ativação híbrida, conforme descrito em [Criar uma ativação híbrida para registrar nós no Systems Manager](hybrid-activation-managed-nodes.md). Você especifica o código e o ID no procedimento a seguir.
**Para instalar o SSM Agent em máquinas que não sejam do EC2 em um ambiente híbrido e multinuvem**
1. Faça logon em um servidor ou VM no seu ambiente híbrido ou multinuvem.
1. Se você usar um proxy HTTP ou HTTPS, defina o `http_proxy` ou as variáveis de ambiente `https_proxy` na sessão do shell atual. Se você não estiver usando um proxy, ignore esta etapa.
Para um servidor proxy HTTP, insira os seguintes comandos na linha de comando:
```
export http_proxy=http://hostname:port
export https_proxy=http://hostname:port
```
Para um servidor proxy HTTPS, insira os seguintes comandos na linha de comando:
```
export http_proxy=http://hostname:port
export https_proxy=https://hostname:port
```
1. Copie e cole um dos seguintes blocos de comandos no SSH. Substitua os valores de espaços reservados pelo Código de Ativação e o ID de Ativação gerados durante o processo de ativação híbrido e com o identificador da Região da AWS da qual deseja baixar o SSM Agent, e em seguida pressione `Enter`.
**Importante**
Observe os seguintes detalhes importantes:
O uso de `ssm-setup-cli` para instalações não EC2 maximiza a segurança da instalação e configuração do Systems Manager.
`sudo`O não é necessário se você for um usuário root.
Faça o download `ssm-setup-cli` da mesma Região da AWS em que sua ativação híbrida foi criada.
`ssm-setup-cli` aceita uma opção `manifest-url` que determina a origem da qual o agente é baixado. Não especifique um valor para a opção, a menos que isso seja exigido pela sua organização.
Ao registrar instâncias, somente use o link de download fornecido para `ssm-setup-cli`. `ssm-setup-cli` não deve ser armazenado separadamente para uso futuro.
É possível usar o script fornecido [aqui](https://github.com/aws/amazon-ssm-agent/blob/mainline/Tools/src/setupcli_data_integrity_linux.sh) para validar a assinatura de `ssm-setup-cli`.
A *região* representa o identificador da região para uma região da Região da AWS compatível com o AWS Systems Manager, como `us-east-2` para a região Leste dos EUA (Ohio). Para ver uma lista dos valores de *região* com suporte, consulte a coluna **Region** em [Systems Manager service endpoints](https://docs.aws.amazon.com/general/latest/gr/ssm.html#ssm_region) no *Referência geral da Amazon Web Services*.
Além disso, `ssm-setup-cli` inclui as opções a seguir:
+ `version`: os valores válidos são `latest` e `stable`.
+ `downgrade`: permite que o SSM Agent seja atualizado para uma versão anterior. Especifique `true` para instalar uma versão anterior do agente.
+ `skip-signature-validation`: ignora a validação da assinatura durante o download e a instalação do agente.
## Amazon Linux 2, RHEL 7.x e Oracle Linux
```
mkdir /tmp/ssm
curl https://amazon-ssm-region.s3.region.amazonaws.com/latest/linux_amd64/ssm-setup-cli -o /tmp/ssm/ssm-setup-cli
sudo chmod +x /tmp/ssm/ssm-setup-cli
sudo /tmp/ssm/ssm-setup-cli -register -activation-code "activation-code" -activation-id "activation-id" -region "region"
```
## RHEL 8.x
```
mkdir /tmp/ssm
curl https://amazon-ssm-region.s3.region.amazonaws.com/latest/linux_amd64/ssm-setup-cli -o /tmp/ssm/ssm-setup-cli
sudo chmod +x /tmp/ssm/ssm-setup-cli
sudo /tmp/ssm/ssm-setup-cli -register -activation-code "activation-code" -activation-id "activation-id" -region "region"
```
## Debian Server
```
mkdir /tmp/ssm
curl https://amazon-ssm-region.s3.region.amazonaws.com/latest/debian_amd64/ssm-setup-cli -o /tmp/ssm/ssm-setup-cli
sudo chmod +x /tmp/ssm/ssm-setup-cli
sudo /tmp/ssm/ssm-setup-cli -register -activation-code "activation-code" -activation-id "activation-id" -region "region"
```
## Ubuntu Server
+ **Usar pacotes .deb**
```
mkdir /tmp/ssm
curl https://amazon-ssm-region.s3.region.amazonaws.com/latest/debian_amd64/ssm-setup-cli -o /tmp/ssm/ssm-setup-cli
sudo chmod +x /tmp/ssm/ssm-setup-cli
sudo /tmp/ssm/ssm-setup-cli -register -activation-code "activation-code" -activation-id "activation-id" -region "region"
```
+ **Usar pacotes de Snap**
Você não precisa especificar um URL para download porque o comando `snap` faz download automático do agente da [loja de aplicativos Snap](https://snapcraft.io/amazon-ssm-agent) em [https://snapcraft.io](https://snapcraft.io).
No Ubuntu Server 20.04, 18.04 e 16.04 LTS, os arquivos do instalador do SSM Agent, incluindo arquivos binários do atendente e arquivos de configuração, são armazenados no seguinte diretório: `/snap/amazon-ssm-agent/current/`. Se você fizer alterações em qualquer arquivo de configuração nesse diretório, copie esses arquivos do diretório `/snap` para o `/etc/amazon/ssm/`. Os arquivos de log e biblioteca não foram alterados (`/var/lib/amazon/ssm`, `/var/log/amazon/ssm`).
```
sudo snap install amazon-ssm-agent --classic
sudo systemctl stop snap.amazon-ssm-agent.amazon-ssm-agent.service
sudo /snap/amazon-ssm-agent/current/amazon-ssm-agent -register -code "activation-code" -id "activation-id" -region "region"
sudo systemctl start snap.amazon-ssm-agent.amazon-ssm-agent.service
```
**Importante**
O*candidato*na loja Snap contém a versão mais recente doSSM Agent; não o canal estável. Se você quiser acompanhar as informações de versão do SSM Agent no canal candidato, execute o comando a seguir em seus nós gerenciados do Ubuntu Server 18.04 e 16.04 LTS de 64 bits.
```
sudo snap switch --channel=candidate amazon-ssm-agent
```
O comando baixa e instala o SSM Agent na máquina ativada para ambiente híbrido em seu ambiente híbrido e multinuvem. O comando interrompe o SSM Agent e registra a máquina no serviço do Systems Manager. A máquina agora é um nó gerenciado. As instâncias do Amazon EC2 configuradas para o Systems Manager também são nós gerenciados. Porém, no console do Systems Manager, seus nós ativados para ambientes híbridos são diferenciados das instâncias do Amazon EC2 com o prefixo “mi-”.
Avance para [Instalar o SSM Agent em nós híbridos do Windows Server](hybrid-multicloud-ssm-agent-install-windows.md).
## Configurando a rotação automática da chave privada
Para fortalecer seu procedimento de segurança, você pode configurar o AWS Systems Manager Agent (SSM Agent) para alternar automaticamente a chave privada de seu ambiente híbrido e multinuvem. Você pode acessar esse recurso usando o SSM Agent versão 3.0.1031.0 ou posterior. Ative esse recurso usando procedimento a seguir.
**Para configurar o SSM Agent para alternar a chave privada em um ambiente híbrido e multinuvem**
1. Navegue até `/etc/amazon/ssm/` em uma máquina Linux ou `C:\Program Files\Amazon\SSM` em uma máquina Windows.
1. Copie o conteúdo do `amazon-ssm-agent.json.template` em um arquivo chamado `amazon-ssm-agent.json`. Salve o `amazon-ssm-agent.json` no mesmo diretório em que `amazon-ssm-agent.json.template` está localizado.
1. Localizar `Profile`, `KeyAutoRotateDays`. Insira o número de dias que você deseja entre as rotações automáticas de chave privada.
1. Reinicie o SSM Agent.
Toda vez que você alterar a configuração, reinicie o SSM Agent.
Você pode personalizar outros recursos do SSM Agent usando o mesmo procedimento. Para obter uma lista atualizada das propriedades de configuração disponíveis e seus valores padrão, consulte [Config Property Definitions](https://github.com/aws/amazon-ssm-agent#config-property-definitions) (Definições de Propriedades do Config).
## Cancele o registro e registre um nó gerenciado novamente (Linux)
É possível cancelar o registro de um nó gerenciado ativado para ambiente híbrido chamando a operação da API [DeregisterManagedInstance](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DeregisterManagedInstance.html) na AWS CLI ou em ferramentas para Windows PowerShell. Veja um exemplo de comando da CLI:
`aws ssm deregister-managed-instance --instance-id "mi-1234567890"`
Para remover as informações de registro restantes do agente, remova a chave `IdentityConsumptionOrder` no arquivo `amazon-ssm-agent.json`. Em seguida, dependendo do tipo de instalação, execute um dos comandos a seguir.
Nos nós Ubuntu Server em que o SSM Agent foi instalado usando pacotes Snap:
```
sudo /snap/amazon-ssm-agent/current/amazon-ssm-agent -register -clear
```
Em todas as outras instalações Linux:
```
amazon-ssm-agent -register -clear
```
**nota**
Você pode registrar novamente um servidor on-premises, um dispositivo de borda ou uma máquina virtual (VM) usando o mesmo código de ativação e o mesmo ID, desde que não tenha atingido o limite de instância para o código de ativação e o ID designados. Você pode verificar o limite de instâncias para um código de ativação e um ID chamando a API [describe-activations](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-activations.html) usando o AWS CLI. Depois de executar o comando, verifique se o valor de `RegistrationCount` não excede `RegistrationLimit`. Se isso acontecer, você deverá usar um código de ativação e um ID diferentes.
**Para registrar novamente um nó gerenciado em uma máquina Linux que não é do EC2**
1. Conectar-se à máquina.
1. Execute o comando a seguir. Substitua os valores dos espaços reservados pelo código de ativação e ID de ativação gerados ao criar uma ativação de nó gerenciado e pelo identificador da região da qual você quer baixar o SSM Agent.
```
echo "yes" | sudo /tmp/ssm/ssm-setup-cli -register -activation-code "activation-code" -activation-id "activation-id" -region "region
```
## Solução de problemas de instalação do SSM Agent em máquinas Linux que não são do EC2
Use as informações a seguir para ajudar você a solucionar problemas de instalação do SSM Agent em máquinas Linux ativadas para ambiente híbrido em um ambiente [híbrido e multinuvem](operating-systems-and-machine-types.md#supported-machine-types).
### Você recebe o erro DeliveryTimedOut
**Problema**: ao configurar uma máquina em um Conta da AWS como um nó gerenciado para uma Conta da AWS separada, você receberá `DeliveryTimedOut` depois de executar os comandos para instalar o SSM Agent na máquina de destino.
**Solução**:`DeliveryTimedOut`é o código de resposta esperado para este cenário. O comando para instalar o SSM Agent no nó de destino altera o ID do nó do nó de origem. Como o ID do nó foi alterado, o nó de origem não é capaz de responder ao nó de destino que o comando falhou, foi concluído ou expirou durante a execução.
### Não foi possível carregar associações de nós
**Problema**: Depois de executar os comandos de instalação, você verá o seguinte erro na seçãoSSM AgentLogs de erros:
`Unable to load instance associations, unable to retrieve associations unable to retrieve associations error occurred in RequestManagedInstanceRoleToken: MachineFingerprintDoesNotMatch: Fingerprint doesn't match`
Esse erro é exibido quando o ID da máquina não persiste após uma reinicialização.
**Solução**: para corrigir esse problema, execute o comando a seguir. Esse comando força o ID da máquina a persistir após uma reinicialização.
```
umount /etc/machine-id
systemd-machine-id-setup
```
# Instalar o SSM Agent em nós híbridos do Windows Server
Este tópico descreve como instalar o SSM Agent do AWS Systems Manager em máquinas do Windows Server em um ambiente [híbrido e multinuvem](operating-systems-and-machine-types.md#supported-machine-types). Para obter informações sobre como instalar o SSM Agent em instâncias do EC2 para Windows Server, consulte [Instalar e desinstalar o SSM Agent manualmente em instâncias do EC2 para Windows Server](manually-install-ssm-agent-windows.md).
Antes de começar, localize o Código de Ativação e o ID de Ativação que foram gerados durante o processo de ativação híbrida, conforme descrito em [Criar uma ativação híbrida para registrar nós no Systems Manager](hybrid-activation-managed-nodes.md). Você especifica o código e o ID no procedimento a seguir.
**Para instalar o SSM Agent em máquinas Windows Server que não sejam do EC2 em um ambiente híbrido e multinuvem**
1. Faça logon em um servidor ou VM no seu ambiente híbrido ou multinuvem.
1. Se você usar um proxy HTTP ou HTTPS, defina o `http_proxy` ou as variáveis de ambiente `https_proxy` na sessão do shell atual. Se você não estiver usando um proxy, ignore esta etapa.
Para um servidor proxy HTTP, defina esta variável:
```
http_proxy=http://hostname:port
https_proxy=http://hostname:port
```
Para um servidor proxy HTTPS, defina esta variável:
```
http_proxy=http://hostname:port
https_proxy=https://hostname:port
```
Para o PowerShell, defina as configurações do proxy WinInet:
```
[System.Net.WebRequest]::DefaultWebProxy
$proxyServer = "http://hostname:port"
$proxyBypass = "169.254.169.254"
$WebProxy = New-Object System.Net.WebProxy($proxyServer,$true,$proxyBypass)
[System.Net.WebRequest]::DefaultWebProxy = $WebProxy
```
**nota**
A configuração do proxy WinInet é necessária para operações do PowerShell. Para obter mais informações, consulte [SSM AgentAs configurações de proxy do e serviços do Systems Manager](configure-proxy-ssm-agent-windows.md#ssm-agent-proxy-services).
1. Abra o Windows PowerShell no modo elevado (administrativo).
1. Copie e cole um o bloco de comandos a seguir no Windows PowerShell. Substitua cada *espaço reservado para recurso de exemplo* por suas próprias informações. Por exemplo, o código de ativação e ID de ativação gerados ao criar uma ativação híbrida e pelo identificador da Região da AWS em que você deseja baixar o SSM Agent.
**Importante**
Observe os seguintes detalhes importantes:
O uso de `ssm-setup-cli` para instalações não EC2 maximiza a segurança da instalação e configuração do Systems Manager.
`ssm-setup-cli` aceita uma opção `manifest-url` que determina a origem da qual o agente é baixado. Não especifique um valor para a opção, a menos que isso seja exigido pela sua organização.
É possível usar o script fornecido [aqui](https://github.com/aws/amazon-ssm-agent/blob/mainline/Tools/src/setupcli_data_integrity_windows.ps1) para validar a assinatura de `ssm-setup-cli`.
Ao registrar instâncias, somente use o link de download fornecido para `ssm-setup-cli`. `ssm-setup-cli` não deve ser armazenado separadamente para uso futuro.
A *região* representa o identificador da região para uma região da Região da AWS compatível com o AWS Systems Manager, como `us-east-2` para a região Leste dos EUA (Ohio). Para ver uma lista dos valores de *região* com suporte, consulte a coluna **Region** em [Systems Manager service endpoints](https://docs.aws.amazon.com/general/latest/gr/ssm.html#ssm_region) no *Referência geral da Amazon Web Services*.
Além disso, `ssm-setup-cli` inclui as opções a seguir:
+ `version`: os valores válidos são `latest` e `stable`.
+ `downgrade`: reverte o agente para uma versão anterior.
+ `skip-signature-validation`: ignora a validação da assinatura durante o download e a instalação do agente.
------
#### [ 64-bit ]
```
[System.Net.ServicePointManager]::SecurityProtocol = 'TLS12'
$code = "activation-code"
$id = "activation-id"
$region = "us-east-1"
$dir = $env:TEMP + "\ssm"
New-Item -ItemType directory -Path $dir -Force
cd $dir
(New-Object System.Net.WebClient).DownloadFile("https://amazon-ssm-$region.s3.$region.amazonaws.com/latest/windows_amd64/ssm-setup-cli.exe", $dir + "\ssm-setup-cli.exe")
./ssm-setup-cli.exe -register -activation-code="$code" -activation-id="$id" -region="$region"
Get-Content ($env:ProgramData + "\Amazon\SSM\InstanceData\registration")
Get-Service -Name "AmazonSSMAgent"
```
------
1. Pressione `Enter`.
**nota**
Se o comando falhar, verifique se você está executando a versão mais recente do Ferramentas da AWS para PowerShell.
O comando faz o seguinte:
+ Baixa e instala o SSM Agent na máquina.
+ Registra a máquina no serviço Systems Manager.
+ Retorna uma resposta à solicitação semelhante à seguinte:
```
Directory: C:\Users\ADMINI~1\AppData\Local\Temp\2
Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 07/07/2018 8:07 PM ssm
{"ManagedInstanceID":"mi-008d36be46EXAMPLE","Region":"us-east-2"}
Status : Running
Name : AmazonSSMAgent
DisplayName : Amazon SSM Agent
```
A máquina agora é um *nó gerenciado*. Esses nós gerenciados agora são identificados com o prefixo "mi-". Você pode visualizar os nós gerenciados na página **Nós gerenciados** no Fleet Manager, usando o comando da AWS CLI [https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-instance-information.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-instance-information.html) ou usando o comando da API [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeInstanceInformation.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeInstanceInformation.html).
## Configurando a rotação automática da chave privada
Para fortalecer seu procedimento de segurança, você pode configurar o AWS Systems Manager Agent (SSM Agent) para alternar automaticamente a chave privada de um ambiente híbrido e multinuvem. Você pode acessar esse recurso usando o SSM Agent versão 3.0.1031.0 ou posterior. Ative esse recurso usando procedimento a seguir.
**Para configurar o SSM Agent para alternar a chave privada em um ambiente híbrido e multinuvem**
1. Navegue até `/etc/amazon/ssm/` em uma máquina Linux ou `C:\Program Files\Amazon\SSM` em uma máquina Windows Server.
1. Copie o conteúdo do `amazon-ssm-agent.json.template` em um arquivo chamado `amazon-ssm-agent.json`. Salve o `amazon-ssm-agent.json` no mesmo diretório em que `amazon-ssm-agent.json.template` está localizado.
1. Localizar `Profile`, `KeyAutoRotateDays`. Insira o número de dias que você deseja entre as rotações automáticas de chave privada.
1. Reinicie o SSM Agent.
Toda vez que você alterar a configuração, reinicie o SSM Agent.
Você pode personalizar outros recursos do SSM Agent usando o mesmo procedimento. Para obter uma lista atualizada das propriedades de configuração disponíveis e seus valores padrão, consulte [Config Property Definitions](https://github.com/aws/amazon-ssm-agent#config-property-definitions) (Definições de Propriedades do Config).
## Cancelar o registro e registrar um nó gerenciado novamente (Windows Server)
É possível cancelar o registro de um nó gerenciado chamando a operação da API [DeregisterManagedInstance](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DeregisterManagedInstance.html) na AWS CLI ou no Tools for Windows PowerShell. Veja um exemplo de comando da CLI:
`aws ssm deregister-managed-instance --instance-id "mi-1234567890"`
Para remover as informações de registro restantes do agente, remova a chave `IdentityConsumptionOrder` no arquivo `amazon-ssm-agent.json`. Em seguida, execute o seguinte comando:
`amazon-ssm-agent -register -clear`
**nota**
Você pode registrar novamente um servidor on-premises, um dispositivo de borda ou uma máquina virtual (VM) usando o mesmo código de ativação e o mesmo ID, desde que não tenha atingido o limite de instância para o código de ativação e o ID designados. Você pode verificar o limite de instâncias para um código de ativação e um ID chamando a API [describe-activations](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-activations.html) usando o AWS CLI. Depois de executar o comando, verifique se o valor de `RegistrationCount` não excede `RegistrationLimit`. Se isso acontecer, você deverá usar um código de ativação e um ID diferentes.
**Para registrar novamente um nó gerenciado em uma máquina híbrida Windows Server**
1. Conectar-se à máquina.
1. Execute o comando a seguir. Substitua os valores dos espaços reservados pelo código de ativação e ID de ativação gerados ao criar uma ativação híbrida e pelo identificador da região da qual você quer baixar o SSM Agent.
```
$dir = $env:TEMP + "\ssm"
cd $dir
Start-Process ./ssm-setup-cli.exe -ArgumentList @(
"-register",
"-activation-code=$code",
"-activation-id=$id",
"-region=$region"
) -Wait -NoNewWindow
```