• 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).
# Configurar nós gerenciados para o AWS Systems Manager
Conclua as tarefas nesta seção para configurar e configurar perfis, contas de usuário, permissões e recursos iniciais para usar ferramentas do AWS Systems Manager. As tarefas descritas nesta seção são normalmente executadas pela Conta da AWS e pelos administradores de sistemas. Quando essas etapas forem concluídas, os usuários na organização poderão usar o Systems Manager para configurar, gerenciar e acessar os *nós gerenciados*. Um nó gerenciado é qualquer máquina configurada para uso com o Systems Manager em um ambiente [híbrido e multinuvem](operating-systems-and-machine-types.md#supported-machine-types).
**nota**
Se você planeja usar as instâncias do Amazon EC2 *e* seus próprios recursos de computação em um ambiente [híbrido e multinuvem](operating-systems-and-machine-types.md#supported-machine-types), siga primeiro as etapas em [Gerenciar instâncias do EC2 com o Systems Manager](systems-manager-setting-up-ec2.md). Esse tópico apresenta as etapas na melhor ordem para concluir a configuração do Systems Manager para instâncias do EC2 e máquinas que não são do EC2.
Se você já usa outros Serviços da AWS, já concluiu algumas dessas etapas. No entanto, outras etapas são específicas ao Systems Manager. Portanto, recomendamos analisar toda esta seção para garantir que você está pronto para usar todas as ferramentas do Systems Manager.
**Topics**
+ [Gerenciar instâncias do EC2 com o Systems Manager](systems-manager-setting-up-ec2.md)
+ [Gerenciar nós em ambientes híbridos e multinuvem com o Systems Manager](systems-manager-hybrid-multicloud.md)
+ [Gerenciar dispositivos de borda com o Systems Manager](systems-manager-setting-up-edge-devices.md)
+ [Criar um administrador delegado do AWS Organizations para o Systems Manager](setting_up_delegated_admin.md)
+ [Configuração geral para AWS Systems Manager](#setting_up_prerequisites)
# Gerenciar instâncias do EC2 com o Systems Manager
Conclua as tarefas desta seção para definir e configurar perfis, permissões e recursos iniciais para o AWS Systems Manager. As tarefas descritas nesta seção são normalmente executadas pela Conta da AWS e pelos administradores de sistemas. Quando essas etapas forem concluídas, os usuários na organização poderão usar o Systems Manager para configurar, gerenciar e acessar as instâncias do Amazon Elastic Compute Cloud (Amazon EC2).
**nota**
Se você planeja usar o Systems Manager para gerenciar e configurar máquinas on-premises, siga as etapas de configuração em [Gerenciar nós em ambientes híbridos e multinuvem com o Systems Manager](systems-manager-hybrid-multicloud.md). Para usar as instâncias do Amazon EC2 *e* máquinas que não são do EC2 em um ambiente [híbrido e multinuvem](operating-systems-and-machine-types.md#supported-machine-types), siga estas etapas primeiro. Esta seção apresenta etapas na ordem recomendada para configurar as funções, usuários, permissões e recursos iniciais para uso nas suas operações do Systems Manager.
Se você já usa outros Serviços da AWS, já concluiu algumas dessas etapas. No entanto, outras etapas são específicas ao Systems Manager. Portanto, recomendamos analisar toda esta seção para garantir que você está pronto para usar todas as ferramentas do Systems Manager.
**Topics**
+ [Configurar permissões de instância obrigatórias para o Systems Manager](setup-instance-permissions.md)
+ [Melhorar a segurança das instâncias do EC2 usando endpoints da VPC para o Systems Manager](setup-create-vpc.md)
# Configurar permissões de instância obrigatórias para o Systems Manager
Por padrão, o AWS Systems Manager não tem permissão para executar ações em suas instâncias. É possível fornecer permissões de instância no nível da conta usando um perfil do AWS Identity and Access Management (IAM) ou no nível da instância usando um perfil de instância. Se o seu caso de uso permitir, recomendamos conceder acesso no nível da conta usando a configuração de gerenciamento de host padrão.
**nota**
Você pode pular essa etapa e permitir que o Systems Manager aplique as permissões necessárias às suas instâncias para você ao configurar o console unificado. Para obter mais informações, consulte [Configurar o AWS Systems Manager](systems-manager-setting-up-console.md).
## Configuração recomendada para permissões de instâncias do EC2
A configuração de gerenciamento de host padrão permite que o Systems Manager gerencie as instâncias do Amazon EC2 automaticamente. Após ativar essa configuração, todas as instâncias que usam a versão 2 do serviço de metadados da instância (IMDSv2) na Região da AWS e na Conta da AWS com a versão 3.2.582.0 ou posterior do SSM Agent instalada automaticamente, tornam-se instâncias gerenciadas. A configuração de gerenciamento de host padrão não oferece suporte à versão 1 do serviço de metadados da instância. Para obter informações sobre como fazer a transição para IMDSv2, consulte [Transição para usar o Serviço de metadados da instância versão 2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-transition-to-version-2.html) no *Guia do usuário do Amazon EC2*. Para obter informações sobre como verificar a versão do SSM Agent instalada em sua instância, consulte [Verificar o número de versão do SSM Agent](ssm-agent-get-version.md). Para obter informações sobre como atualizar o SSM Agent, consulte [Atualizar automaticamente o SSM Agent](ssm-agent-automatic-updates.md#ssm-agent-automatic-updates-console). Os benefícios das instâncias gerenciadas incluem o seguinte:
+ Conectar-se às suas instâncias com segurança usando o Session Manager.
+ Realizar verificações de patches automatizadas usando o Patch Manager.
+ Visualizar informações detalhadas sobre suas instâncias usando o Inventário do Systems Manager.
+ Acompanhar e gerenciar instâncias usando o Fleet Manager.
+ Manter o SSM Agent atualizado automaticamente.
Fleet Manager, Inventory, Patch Manager, e Session Manager são ferramentas do AWS Systems Manager.
A configuração de gerenciamento de host padrão permite o gerenciamento de instância sem o uso de perfis de instância e garante que o Systems Manager tenha permissões para gerenciar todas as instâncias na região e na conta. Se as permissões fornecidas não forem suficientes para seu caso de uso, também é possível adicionar políticas ao perfil do IAM padrão criado pela configuração de gerenciamento de host padrão. Como alternativa, se você não precisar de permissões para todas as funcionalidades fornecidas pelo perfil do IAM padrão, poderá criar seu próprio perfil e as políticas personalizadas. Quaisquer alterações realizadas no perfil do IAM que você escolher para a configuração de gerenciamento de host padrão se aplicarão a todas as instâncias do Amazon EC2 gerenciadas na região e na conta. Para obter mais informações sobre a política usada pela configuração de gerenciamento de host padrão, consulte [Política gerenciada pela AWS: AmazonSSMManagedEC2InstanceDefaultPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonSSMManagedEC2InstanceDefaultPolicy). Para obter mais informações sobre a configuração de gerenciamento do host padrão, consulte [Gerenciar instâncias do EC2 automaticamente com a Configuração de gerenciamento de hosts padrão](fleet-manager-default-host-management-configuration.md).
**Importante**
As instâncias registradas usando a Configuração Padrão de Gerenciamento de Host armazenam informações de registro localmente nos diretórios `/lib/amazon/ssm` ou `C:\ProgramData\Amazon`. A remoção desses diretórios ou de seus arquivos impedirá que a instância adquira as credenciais necessárias para se conectar ao Systems Manager usando a Configuração Padrão de Gerenciamento de Host. Nesses casos, você deve usar um perfil de instância para fornecer as permissões necessárias à sua instância, ou então recriar a instância.
**nota**
Esse procedimento deve ser executado somente por administradores. Implemente acesso com privilégio mínimo ao permitir que indivíduos configurem ou modifiquem a configuração de gerenciamento de host padrão. É necessário ativar a configuração de gerenciamento de host padrão em cada Região da AWS que deseja gerenciar automaticamente as instâncias do Amazon EC2.
**Como ativar a definição de configuração de gerenciamento de host padrão**
É possível ativar a configuração de gerenciamento de host padrão no console do Fleet Manager. Para concluir este procedimento com êxito usando o Console de gerenciamento da AWS ou sua ferramenta de linha de comando preferida, você deve ter permissões para as operações de API [GetServiceSetting](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetServiceSetting.html), [ResetServiceSetting](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_ResetServiceSetting.html) e [UpdateServiceSetting](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_UpdateServiceSetting.html). Além disso, você deve ter permissões para a permissão `iam:PassRole` para o perfil do IAM `AWSSystemsManagerDefaultEC2InstanceManagementRole`. Veja abaixo um exemplo de política. Substitua cada *espaço reservado para recurso de exemplo* por suas próprias informações.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:GetServiceSetting",
"ssm:ResetServiceSetting",
"ssm:UpdateServiceSetting"
],
"Resource": "arn:aws:ssm:us-east-1:111122223333:servicesetting/ssm/managed-instance/default-ec2-instance-management-role"
},
{
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": "arn:aws:iam::111122223333:role/service-role/AWSSystemsManagerDefaultEC2InstanceManagementRole",
"Condition": {
"StringEquals": {
"iam:PassedToService": [
"ssm.amazonaws.com"
]
}
}
}
]
}
```
------
Antes de começar, se você tiver perfis de instância anexados às suas instâncias do Amazon EC2, remova todas as permissões que permitem a operação `ssm:UpdateInstanceInformation`. O SSM Agent tenta usar as permissões de perfil de instância antes de usar as permissões de configuração de gerenciamento de host padrão. Se você permitir a operação `ssm:UpdateInstanceInformation` em seus perfis de instância, a instância não usará as permissões de configuração de gerenciamento de host padrão.
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, escolha **Fleet Manager**.
1. Escolha **Definir Configuração de gerenciamento de host padrão** no menu suspenso **Gerenciamento de contas**.
1. Ative **Habilitar a configuração de gerenciamento de host padrão**.
1. Escolha o perfil do IAM usado para habilitar as ferramentas do Systems Manager para suas instâncias. Recomendamos usar o perfil padrão fornecido pela configuração de gerenciamento de host padrão. Ele contém o conjunto mínimo de permissões necessárias para gerenciar as instâncias do Amazon EC2 usando o Systems Manager. Se você preferir usar um perfil personalizado, a política de confiança do perfil deve permitir que o Systems Manager seja uma entidade confiável.
1. Escolha **Configurar** para concluir a configuração.
Após ativar a configuração de gerenciamento de host padrão, pode demorar até 30 minutos para que as instâncias usem as credenciais do perfil escolhido. É necessário ativar a configuração de gerenciamento de host padrão em cada região que deseja gerenciar automaticamente as instâncias do Amazon EC2.
## Configuração alternativa para permissões de instâncias do EC2
É possível conceder acesso no nível da instância individual usando um perfil de instância do AWS Identity and Access Management (IAM). Um perfil de instância é um contêiner que transmite as informações da função do IAM para uma instância do Amazon Elastic Compute Cloud (Amazon EC2) na inicialização. Você pode criar um perfil de instância para o Systems Manager anexando uma ou mais políticas do IAM que definem as permissões necessárias para uma nova função ou uma função que você já tnha criado.
**nota**
Você pode usar o Quick Setup, uma ferramenta do AWS Systems Manager, para configurar rapidamente um perfil de instância em todas as instâncias em seu Conta da AWS. O Quick Setup também cria um perfil de serviço do IAM (ou perfil *assume*), o que permite que o Systems Manager execute com segurança comandos em seu nome em suas instâncias. Com o uso do Quick Setup, pode-se ignorar esta etapa (Etapa 3) e a Etapa 4. Para obter mais informações, consulte [AWS Systems Manager Quick Setup](systems-manager-quick-setup.md).
Observe os seguintes detalhes sobre a criação de um perfil da instância do IAM:
+ Se estiver configurando máquinas que não são do EC2 em um ambiente [híbrido e multinuvem](operating-systems-and-machine-types.md#supported-machine-types) para o Systems Manager, não é necessário criar um perfil de instância para elas. Em vez disso, configure seus servidores e VMs para usar uma função de serviço do IAM. 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).
+ Se você alterar o perfil da instância do IAM, poderá levar algum tempo até as credenciais da instância serem atualizadas. O SSM Agent não processará solicitações até que isso aconteça. Para acelerar o processo de atualização, reinicie o SSM Agent ou a instância.
Se você estiver criando uma nova função para o perfil da instância ou adicionando as permissões necessárias a uma função existente, use um dos procedimentos a seguir.
**Para criar um perfil de instância para instâncias gerenciadas do Systems Manager (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 **Trusted entity type** (Tipo da entidade confiável), escolha **AWS service (Serviço da AWS)**.
1. Diretamente sob **Use case** (Caso de uso), escolha **EC2** e **Next** (Avançar).
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)
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](#instance-profile-custom-s3-policy), marque a caixa de seleção ao lado do nome dela.
+ Se você planejar ingressar instâncias em um Active Directory gerenciado pelo Directory Service, pesquise por **AmazonSSMDirectoryServiceAccess** e marque a caixa de seleção ao lado do nome.
+ Se você planejar usar o EventBridge ou o CloudWatch Logs para gerenciar ou monitorar sua instância, pesquise por **CloudWatchAgentServerPolicy** e marque a caixa de seleção ao lado do nome.
1. Escolha **Próximo**.
1. Em **Role name** (Nome da função), insira um nome para seu novo perfil da instância, como **SSMInstanceProfile**.
**nota**
Anote o nome da função. Você escolherá essa função ao criar novas instâncias que deseja gerenciar usando o Systems Manager.
1. (Opcional) Em **Description** (Descrição), atualize a descrição deste perfil de instância.
1. (Opcional) Em **Tags** (Etiquetas), adicione um ou mais pares de valores etiqueta-chave para organizar, monitorar ou controlar o acesso para esse perfil e, em seguida, escolha **Create role** (Criar perfil). O sistema faz com que você retorne para a página **Roles**.
**Para adicionar permissões de perfil de instância para o Systems Manager a uma função existente (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, selecione **Roles** (Funções) e, em seguida, escolha a função existente que você deseja associar a um perfil de instância para operações do Systems Manager.
1. Na guia **Permissions** (Permissões), escolha **Add permissions, Attach policies** (Adicionar permissões, anexar políticas).
1. Na página **Attach Policy** (Anexar política), faça o seguinte:
+ Use o campo **Search** (Pesquisar) para localizar **AmazonSSMManagedInstanceCore**. Marque a caixa de seleção ao lado do nome.
+ Se você tiver criado uma política de bucket do S3 personalizada, procure-a e marque a caixa de seleção ao lado do nome dela. Para obter informações sobre políticas de bucket do S3 personalizadas para um perfil de instância, consulte [(Opcional) Criação de uma política personalizada para acesso ao bucket do S3](#instance-profile-custom-s3-policy).
+ Se você planejar ingressar instâncias em um Active Directory gerenciado pelo Directory Service, pesquise por **AmazonSSMDirectoryServiceAccess** e marque a caixa de seleção ao lado do nome.
+ Se você planejar usar o EventBridge ou o CloudWatch Logs para gerenciar ou monitorar sua instância, pesquise por **CloudWatchAgentServerPolicy** e marque a caixa de seleção ao lado do nome.
1. Escolha **Anexar políticas**.
Para obter mais informações sobre como atualizar uma função para incluir uma entidade confiável ou restringir ainda mais o acesso, consulte [Modificar uma função](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage_modify.html) no *Guia do usuário do IAM*.
## (Opcional) Criação de uma política personalizada para acesso ao bucket do S3
A criação de uma política personalizada para acesso ao Amazon S3 é necessária se você usa um endpoint da VPC ou um bucket do S3 próprio nas suas operações do Systems Manager. É possível anexar essa política ao perfil do IAM padrão criado pela configuração de gerenciamento de host padrão ou a um perfil de instância criado no procedimento anterior.
Para obter informações sobre os buckets do S3 gerenciados pela AWS aos quais você fornece acesso na política a seguir, consulte [SSM Agent Comunicações do AWS com os buckets do S3 gerenciados pela](ssm-agent-technical-details.md#ssm-agent-minimum-s3-permissions).
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 **Políticas** e, em seguida, **Criar política**.
1. Escolha a guia **JSON** e substitua o texto padrão conforme a seguir.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": [
"arn:aws:s3:::aws-ssm-us-east-2/*",
"arn:aws:s3:::aws-windows-downloads-us-east-2/*",
"arn:aws:s3:::amazon-ssm-us-east-2/*",
"arn:aws:s3:::amazon-ssm-packages-us-east-2/*",
"arn:aws:s3:::us-east-2-birdwatcher-prod/*",
"arn:aws:s3:::aws-ssm-distributor-file-us-east-2/*",
"arn:aws:s3:::aws-ssm-document-attachments-us-east-2/*",
"arn:aws:s3:::patch-baseline-snapshot-us-east-2/*"
]
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:PutObjectAcl",
"s3:GetEncryptionConfiguration"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket/*",
"arn:aws:s3:::amzn-s3-demo-bucket"
]
}
]
}
```
------
**nota**
O primeiro elemento `Statement` será necessário somente se você estiver usando um endpoint da VPC.
O segundo elemento `Statement` será necessário somente se você estiver usando um bucket do S3 que você criou para usar em suas operações do Systems Manager.
A permissão da lista de controle de acesso de `PutObjectAcl` será necessária somente se você planeja oferecer suporte ao acesso entre contas para buckets do S3 em outras contas.
O elemento `GetEncryptionConfiguration` será necessário se o bucket do S3 estiver configurado para usar criptografia.
Se o bucket do S3 estiver configurado para usar criptografia, a raiz do bucket do S3 (por exemplo, `arn:aws:s3:::amzn-s3-demo-bucket`) deverá estar listada na seção **Recurso**. Seu usuário, grupo ou perfil deve ser configurado com acesso ao bucket raiz.
1. Se você estiver usando um endpoint da VPC em suas operações, faça o seguinte:
No primeiro elemento `Statement`, substitua cada espaço reservado *região* pelo identificador da Região da AWS na qual essa política será usada. Por exemplo, use `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*.
**Importante**
Recomendamos que você evite usar caracteres curinga (\$1) no lugar das regiões específicas nessa política. Por exemplo, use `arn:aws:s3:::aws-ssm-us-east-2/*` e não use `arn:aws:s3:::aws-ssm-*/*`. O uso de curingas pode fornecer acesso a buckets do S3 aos quais você não pretende conceder acesso. Se você quiser usar o perfil de instância para mais de uma região, recomendamos repetir o primeiro elemento `Statement` para cada região.
- ou -
Se não estiver usando um endpoint da VPC em suas operações, você poderá excluir o primeiro elemento `Statement`.
1. Se você estiver usando um bucket do S3 de sua propriedade em suas operações do Systems Manager, faça o seguinte:
No segundo elemento `Statement`, substitua *amzn-s3-demo-bucket* pelo nome de um bucket do S3 em sua conta. Você usará esse bucket para suas operações do Systems Manager. Ele fornecerá permissão para objetos no bucket, usando `"arn:aws:s3:::my-bucket-name/*"` como o recurso. Para obter mais informações sobre como fornecer permissões para buckets ou objetos em buckets, consulte o tópico [Ações do Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/dev/using-with-s3-actions.html) no *Guia do usuário do Amazon Simple Storage Service* e a postagem do blog da AWS [IAM Policies and Bucket Policies and ACLs\$1 (Políticas de buckets e do IAM e ACLs\$1). Nossa\$1 (Controlar o acesso aos recursos do S)](https://aws.amazon.com/blogs/security/iam-policies-and-bucket-policies-and-acls-oh-my-controlling-access-to-s3-resources/).
**nota**
Se você usar mais de um bucket, forneça o ARN de cada um. Veja o exemplo a seguir sobre permissões em buckets.
```
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket1/*",
"arn:aws:s3:::amzn-s3-demo-bucket2/*"
]
```
- ou -
Se não estiver usando um bucket do S3 de sua propriedade em suas operações do Systems Manager, você poderá excluir o segundo elemento `Statement`.
1. Escolha **Próximo: tags**.
1. (Opcional) Adicione tags escolhendo **Add tag** (Adicionar tag) e inserindo as tags preferenciais para a política.
1. Escolha **Próximo: revisar**.
1. Em **Name** (Nome), insira um nome para identificar essa política, como **SSMInstanceProfileS3Policy**.
1. Escolha **Criar política**.
## Considerações de política adicionais para instâncias gerenciadas
Esta seção descreve algumas das políticas que você pode adicionar ao perfil do IAM padrão criado pela configuração de gerenciamento de host padrão ou seus perfis de instância para o AWS Systems Manager. Para fornecer permissões para a comunicação entre instâncias e a API do Systems Manager, recomendamos criar políticas personalizadas que reflitam as necessidades do sistema e os requisitos de segurança. Dependendo do seu plano de operações, você pode precisar de permissões representadas em uma ou mais das outras políticas.
**Política: `AmazonSSMDirectoryServiceAccess`**
Obrigatória somente se você planejar incluir instâncias do Amazon EC2 para Windows Server em um diretório do Microsoft AD.
Essa política gerenciada da AWS permite que o SSM Agent acesse o AWS Directory Service em seu nome para solicitações para ingressar no domínio pela instância gerenciada. Para obter mais informações, consulte [Integrar-se facilmente a uma instância do Windows EC2](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/launching_instance.html) no *Guia de administração do AWS Directory Service*.
**Política: `CloudWatchAgentServerPolicy`**
Exigido apenas se você planeja instalar e executar o agente CloudWatch em suas instâncias para ler dados métricos e de logs em uma instância e gravá-los no Amazon CloudWatch. Eles ajudam você a monitorar, analisar e responder rapidamente a problemas ou alterações em seus recursos da AWS.
Seu perfil do IAM padrão criado pela configuração de gerenciamento de host padrão ou o perfil de instância precisa dessa política somente se você pretende usar recursos como o Amazon EventBridge ou o Amazon CloudWatch Logs. (Você também pode criar uma política mais restritiva que, por exemplo, limita o acesso à gravação a um determinado fluxo de logs do CloudWatch Logs.)
O uso dos recursos do EventBridge e do CloudWatch Logs é opcional. Contudo, recomendamos configurá-los no início do seu processo de configuração do Systems Manager caso tenha decidido usá-los. Para obter mais informações, consulte o *[Guia do usuário do Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/)* e o *[Guia do usuário do Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/)*.
Para criar políticas do IAM com permissões para ferramentas adicionais do Systems Manager, consulte os recursos a seguir:
+ [Restringir o acesso a parâmetros do Parameter Store usando políticas do IAM](sysman-paramstore-access.md)
+ [Configurar a automação](automation-setup.md)
+ [Etapa 2: verificar ou adicionar permissões de instância para o Session Manager](session-manager-getting-started-instance-profile.md)
## Anexe o perfil de instância do Systems Manager a uma instância (console)
O procedimento a seguir descreve como anexar um perfil de instância do IAM a uma instância do Amazon EC2 usando o console do Amazon EC2.
1. Faça login no Console de gerenciamento da AWS e 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, em **Instâncias**, escolha **Instâncias**.
1. Navegue até a lista e escolha a instância do EC2 na lista.
1. No menu **Actions** (Açõeescolha s), **Security** (Segurança), **Modify IAM role** (Modificar função do IAM).
1. Em **IAM role (Função do IAM)**, selecione o perfil da instância que você criou usando o procedimento em [Configuração alternativa para permissões de instâncias do EC2](#instance-profile-add-permissions).
1. Escolha **Update **IAM role**** (Atualizar perfil do IAM).
Para obter mais informações sobre como anexar funções do IAM a instâncias, escolha uma das seguintes opções, dependendo do tipo de sistema operacional selecionado:
+ [Anexar um perfil do IAM a uma instância](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html#attach-iam-role) no *Guia do usuário do Amazon EC2*
+ [Anexar um perfil do IAM a uma instância](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/iam-roles-for-amazon-ec2.html#attach-iam-role) no *Guia do usuário do Amazon EC2*
Avance para [Melhorar a segurança das instâncias do EC2 usando endpoints da VPC para o Systems Manager](setup-create-vpc.md).
# Melhorar a segurança das instâncias do EC2 usando endpoints da VPC para o Systems Manager
Você pode melhorar o procedimento de segurança de seus nós gerenciados (inclusive máquinas que não são do EC2 em um ambiente [híbrido e multinuvem](operating-systems-and-machine-types.md#supported-machine-types)) configurando o AWS Systems Manager para usar um endpoint da VPC de interface na Amazon Virtual Private Cloud (Amazon VPC). Por meio de um endpoint da VPC de interface (endpoint de interface), você pode se conecter a serviços com a tecnologia AWS PrivateLink. AWS PrivateLink é uma tecnologia que permite acessar de forma privada APIs da Amazon Elastic Compute Cloud (Amazon EC2) e do Systems Manager usando endereços IP privados.
AWS PrivateLinkO limita todo o tráfego de rede entre as instâncias gerenciadas, o Systems Manager, o Amazon EC2 e a rede da Amazon. Isso significa que suas instâncias gerenciadas não precisam ter acesso à Internet. Se você usa o AWS PrivateLink, não precisa de um gateway da Internet, de um dispositivo NAT ou de um gateway privado virtual.
Não é necessário configurar o AWS PrivateLink, mas é recomendável. Para obter mais informações sobre o AWS PrivateLink e os endpoints da VPC, consulte [AWS PrivateLink e endpoints da VPC](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-services-overview.html).
**nota**
A alternativa ao uso de um endpoint da VPC é permitir o acesso à Internet de saída em suas instâncias gerenciadas. Nesse caso, as instâncias gerenciadas também devem permitir tráfego de saída HTTPS (porta 443) para os seguintes endpoints:
`ssm.region.amazonaws.com`
`ssmmessages.region.amazonaws.com`
`ec2messages.region.amazonaws.com`
SSM AgentO inicia todas as conexões com o serviço Systems Manager na nuvem. Por essa razão, você não precisa configurar o firewall para permitir o tráfego de entrada nas instâncias para o Systems Manager.
Para obter mais informações sobre chamadas para esses endpoints, consulte [Referência: ec2messages, ssmmessages e outras operações da API](systems-manager-setting-up-messageAPIs.md).
Se você estiver usando o Systems Manager em um ambiente que suporta *somente* IPv6, você também deve permitir o tráfego de saída para os seguintes endpoints:
`ssm.region.api.aws`
`ssmmessages.region.api.aws`
`ec2messages.region.api.aws`
Para ter mais informações sobre endpoints de serviço de pilha dupla, consulte [Endpoints de pilha dupla](https://docs.aws.amazon.com/general/latest/gr/rande.html#dual-stack-endpoints) no *Guia de referência geral da AWS*.
Você também deve garantir que os buckets de operação de patch possam ser acessados a partir de seus nós, conforme descrito em [Referência: buckets do Amazon S3 para operações de aplicação de patches](https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-operations-s3-buckets.html).
**Sobre a Amazon VPC**
O Amazon Virtual Private Cloud (Amazon VPC) permite definir uma rede virtual em sua própria área isolada logicamente na Nuvem AWS, conhecida como uma *nuvem privada virtual (VPC)*. Você pode iniciar os recursos da AWS, como as instâncias, na VPC. Sua VPC assemelha-se a uma rede tradicional que você poderia operar no seu próprio data center, com os benefícios de usar a infraestrutura escalável da AWS. É possível configurar seu VPC, selecionar o intervalo de endereços IP dele, criar sub-redes e definir tabelas de rotas, gateways de rede e configurações de segurança. Você pode se conectar às suas instâncias na VPC. É possível conectar a VPC a seu próprio data center corporativo, tornando a Nuvem AWS uma extensão do seu data center. Para proteger os recursos em cada sub-rede, você pode usar várias camadas de segurança, incluindo grupos de segurança e listas de controle de acesso de rede. Para obter mais informações, consulte [Guia do usuário da Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/).
**Topics**
+ [Restrições e limitações do VPC endpoint](#vpc-requirements-and-limitations)
+ [Criar endpoints da VPC para o Systems Manager](#create-vpc-endpoints)
+ [Criar uma política de VPC endpoint de interface](#create-vpc-interface-endpoint-policies)
## Restrições e limitações do VPC endpoint
Antes de configurar endpoints da VPC para o Systems Manager, fique atento às restrições e limitações a seguir.
**Conexões de emparelhamento de VPC**
Os endpoints da interface da VPC podem ser acessados por meio de conexões de emparelhamento de VPC *dentro da região* e *entre regiões*. Para obter mais informações sobre solicitações de conexão de emparelhamento de VPC para endpoints de interface da VPC, consulte [Conexões de emparelhamento da VPC (Cotas)](https://docs.aws.amazon.com/vpc/latest/userguide/amazon-vpc-limits.html#vpc-limits-peering) no *Guia do usuário da Amazon Virtual Private Cloud*.
Não é possível estender conexões de endpoint de gateway de VPC para fora de uma VPC. Os recursos do outro lado de uma conexão de emparelhamento de VPC em sua VPC não podem usar o endpoint de gateway para se comunicar com recursos no serviço de endpoint de gateway. Para obter mais informações sobre solicitações de conexão de emparelhamento de VPC para endpoints do gateway da VPC, consulte [Endpoints da VPC (Cotas)](https://docs.aws.amazon.com/vpc/latest/userguide/amazon-vpc-limits.html#vpc-limits-endpoints) no *Guia do usuário da Amazon Virtual Private Cloud*.
**Conexões de entrada**
O grupo de segurança anexado ao VPC endpoint deve permitir conexões de entrada na porta 443 na sub-rede privada da instância gerenciada. Se conexões de entrada não são permitidas, a instância gerenciada não pode se conectar ao SSM e endpoints do EC2.
**Resolução do DNS**
Para usar um servidor DNS personalizado, você deve adicionar um encaminhador condicional para qualquer consulta ao domínio `amazonaws.com` para o servidor Amazon DNS de sua VPC.
**Buckets do S3**
Sua política de endpoint da VPC deve permitir acesso ao menos aos buckets do Amazon S3 listados em [SSM Agent Comunicações do AWS com os buckets do S3 gerenciados pela](ssm-agent-technical-details.md#ssm-agent-minimum-s3-permissions).
**nota**
Se você usar um firewall on-premises e planeja usar o Patch Manager, esse firewall também deverá permitir o acesso ao endpoint da lista de referência de patches apropriado.
**Amazon CloudWatch Logs**
Se você não permitir que suas instâncias acessem a Internet, crie um endpoint da VPC para que o CloudWatch Logs use recursos que enviem logs para o CloudWatch Logs. Para obter mais informações sobre como criar um endpoint para o CloudWatch Logs, consulte [Criar um endpoint da VPC para o CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/cloudwatch-logs-and-interface-VPC.html#create-VPC-endpoint-for-CloudWatchLogs) no *Manual do usuário do Amazon CloudWatch Logs*.
**DNS em ambiente híbrido e multinuvem**
Para obter informações sobre como configurar o DNS para trabalhar com endpoints do AWS PrivateLink em ambientes [híbridos e multinuvem](operating-systems-and-machine-types.md#supported-machine-types), consulte [Private DNS for interface endpoints](https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-interface.html#vpce-private-dns) no *Guia do usuário da Amazon VPC*. Se quiser usar seu próprio DNS, poderá usar o resolvedor do Route 53. Para obter mais informações, consulte [Resolver consultas de DNS entre VPCs e sua rede ](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver.html) no *Guia do desenvolvedor do Amazon Route 53*.
## Criar endpoints da VPC para o Systems Manager
Use as informações a seguir para criar endpoints de interface da VPC para o AWS Systems Manager. Este tópico contém links para procedimentos no*Manual do usuário da Amazon VPC*.
**nota**
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*.
Siga as etapas em [Create an interface endpoint](https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-interface.html#create-interface-endpoint) (Criar um endpoint de interface) para criar os seguintes endpoints de interface:
+ **`com.amazonaws.region.ssm`** – o endpoint para o serviço Systems Manager.
+ **`com.amazonaws.region.ec2messages`**: o Systems Manager usa esse endpoint para fazer chamadas do SSM Agent para o serviço do Systems Manager. A partir da versão 3.3.40.0 do SSM Agent, o Systems Manager começou a usar o endpoint `ssmmessages:*` (Amazon Message Gateway Service) sempre que disponível, em vez do endpoint `ec2messages:*` (Amazon Message Delivery Service).
+ **`com.amazonaws.region.ec2`** – se você estiver usando o Systems Manager para criar snapshots habilitados para VSS, será necessário ter um endpoint para o serviço EC2. Sem o endpoint do EC2 definido, a chamada para enumerar os volumes anexados do Amazon EBS falha, o que faz com que o comando do Systems Manager falhe.
+ **`com.amazonaws.region.s3`** – o Systems Manager usa esse endpoint para atualizar SSM Agent. O Systems Manager também usará esse endpoint se, opcionalmente, você optar por recuperar scripts ou outros arquivos armazenados em buckets ou fazer upload dos logs de saída para buckets. Se o grupo de segurança associado a suas instâncias restringir o tráfego de saída, será preciso adicionar uma regra para permitir o tráfego para a lista de prefixos do Amazon S3. Para obter mais informações, consulte [Modificar seu grupo de segurança](https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-gateway.html#vpc-endpoints-security) no *Guia do AWS PrivateLink*.
+ **`com.amazonaws.region.ssmmessages`** — Este endpoint será necessário para que o SSM Agent se comunique com o serviço Systems Manager, para Run Command, e se você estiver se conectando às suas instâncias por meio de um canal de dados seguro usando o Session Manager. Para obter mais informações, consulte [AWS Systems Manager Session Manager](session-manager.md) e [Referência: ec2messages, ssmmessages e outras operações da API](systems-manager-setting-up-messageAPIs.md).
+ (Opcional) **`com.amazonaws.region.kms`**: crie esse endpoint se você quiser usar a criptografia AWS Key Management Service (AWS KMS) para os parâmetros do Session Manager ou do Parameter Store.
+ (Opcional) **`com.amazonaws.region.logs`**: crie este endpoint se você deseja usar o Amazon CloudWatch Logs (CloudWatch Logs) para logs do Session Manager, Run Command ou SSM Agent.
Para obter informações sobre os buckets do S3 gerenciados pela AWS que o SSM Agent deve ser capaz de acessar, consulte [SSM Agent Comunicações do AWS com os buckets do S3 gerenciados pela](ssm-agent-technical-details.md#ssm-agent-minimum-s3-permissions). Se você estiver usando um endpoint da nuvem privada virtual (VPC) nas operações do Systems Manager, deverá fornecer permissão explícita em um perfil de instância do EC2 para o Systems Manager ou em um perfil de serviço para nós gerenciados que não são do EC2 em um ambiente [híbrido e multinuvem](operating-systems-and-machine-types.md#supported-machine-types).
## Criar uma política de VPC endpoint de interface
Você pode criar políticas de endpoints de interface da VPC para o AWS Systems Manager nas quais é possível especificar:
+ A entidade principal que pode executar ações
+ As ações que podem ser executadas
+ Os recursos que podem ter ações executadas neles
Para obter mais informações, consulte [Controlar o acesso a serviços com endpoints da VPCs](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html) no *Guia do usuário da Amazon VPC*.
# 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
```
# Gerenciar dispositivos de borda com o Systems Manager
Esta seção descreve as tarefas de configuração que os administradores de sistema e da conta executam para habilitar a configuração e o gerenciamento dos dispositivos principais do AWS IoT Greengrass. Depois de concluir essas tarefas, os usuários que receberam permissões pelo administrador da Conta da AWS poderão usar o AWS Systems Manager para configurar e gerenciar os dispositivos principais do AWS IoT Greengrass na organização.
**nota**
O SSM Agent para AWS IoT Greengrass não é compatível com macOS e Windows 10. Não é possível usar ferramentas do Systems Manager para gerenciar e configurar dispositivos de borda que usam esses sistemas operacionais.
O Systems Manager também oferece suporte a dispositivos de borda que não estejam configurados como dispositivos principais do AWS IoT Greengrass. Para usar o Systems Manager para gerenciar os dispositivos principais do AWS IoT e dispositivos de borda que não são da AWS, você deve configurá-los usando uma ativação para ambientes híbridos. Para obter mais informações, consulte [Gerenciar nós em ambientes híbridos e multinuvem com o Systems Manager](systems-manager-hybrid-multicloud.md).
Para usar o Session Manager e patches em aplicações da Microsoft com seus dispositivos de borda, você deve habilitar o nível de instâncias avançadas. Para obter mais informações, consulte [Ativar o nível de instâncias avançadas](fleet-manager-enable-advanced-instances-tier.md).
**Antes de começar**
Verifique se os dispositivos de borda atendem aos requisitos a seguir.
+ Seus dispositivos de borda devem atender aos requisitos para serem configurados como dispositivos principais do AWS IoT Greengrass. Para obter mais informações, consulte [Configurar dispositivos principais do AWS IoT Greengrass](https://docs.aws.amazon.com/greengrass/v2/developerguide/setting-up.html) no *Guia do desenvolvedor do AWS IoT Greengrass Version 2*.
+ Seus dispositivos de borda devem ser compatíveis com o Atendente do AWS Systems Manager (SSM Agent). Para obter mais informações, consulte [Sistemas operacionais compatíveis com o Systems Manager](operating-systems-and-machine-types.md#prereqs-operating-systems).
+ Seus dispositivos de borda devem conseguir se comunicar com o serviço do Systems Manager na nuvem. O Systems Manager não oferece suporte a dispositivos de borda desconectados.
**Sobre a configuração de dispositivos de borda**
Configurar dispositivos AWS IoT Greengrass para o Systems Manager envolve os processos a seguir.
**nota**
Para obter informações sobre a desinstalação do SSM Agent de um dispositivo de borda, consulte [Desinstalar o atendente do AWS Systems Manager](https://docs.aws.amazon.com/greengrass/v2/developerguide/uninstall-systems-manager-agent.html) no *Guia do desenvolvedor do AWS IoT Greengrass Version 2*.
## Criar um perfil de serviço do IAM para seus dispositivos de borda
Os dispositivos principais do AWS IoT Greengrass requerem uma função de serviço do AWS Identity and Access Management (IAM) para se comunicar com o 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. Você só precisa criar a função de serviço uma vez para cada Conta da AWS. Você especificará essa função para o parâmetro `RegistrationRole` quando configurar e implantar o componente SSM Agent dos dispositivos AWS IoT Greengrass. Caso já tenha criado esse perfil ao configurar nós que não são do EC2 para um ambiente [híbrido e multinuvem](operating-systems-and-machine-types.md#supported-machine-types), você poderá ignorar esta etapa.
**nota**
Usuários na sua empresa ou organização que usarão o Systems Manager em seus dispositivos de borda deverão receber permissão no IAM para chamar a API do Systems Manager.
**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 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.
**nota**
Se seus dispositivos estiverem protegidos por um firewall e você planeja usar o Patch Manager, o firewall deve permitir o acesso ao endpoint da lista de referência de patches `arn:aws:s3:::patch-baseline-snapshot-region/*`.
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*.
------
#### [ AWS CLI ]
**Para criar uma função de serviço do IAM para um ambiente AWS IoT Greengrass (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`.
**nota**
Anote o nome. Você o especificará ao implantar o SSM Agent para seus dispositivos principais do AWS IoT Greengrass.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Principal": {
"Service": "ssm.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
}
```
------
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. Substitua cada *espaço reservado para recurso de exemplo* por suas próprias informações.
**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 aos dispositivos de borda permissão para executar comandos usando o Systems Manager.
**nota**
As políticas que você adicionar a um perfil de serviço para dispositivos de borda são as mesmas políticas usadas para criar um perfil da instância para instâncias do Amazon Elastic Compute Cloud (Amazon EC2). Para obter mais informações sobre as políticas do IAM usadas nos comandos a seguir, consulte [Configurar permissões de instância necessárias para o Systems Manager](setup-instance-permissions.md).
(Obrigatório) Execute o comando a seguir para permitir que um dispositivo de borda 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\$1ID* e *my\$1bucket\$1policy\$1name* 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/my_bucket_policy_name
```
**Windows**
```
aws iam attach-role-policy ^
--role-name SSMServiceRole ^
--policy-arn 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 que as solicitações ingressem no domínio dos dispositivos de borda. A função de serviço precisará dessa política somente se você integrar os dispositivos de borda 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 atendente do CloudWatch seja executado nos dispositivos de borda. Esse comando permite ler informações em um dispositivo e gravá-las no CloudWatch. Sua função 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 uma função de serviço do IAM para um ambiente AWS IoT Greengrass (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`.
**nota**
Anote o nome. Você o especificará ao implantar o SSM Agent para seus dispositivos principais do AWS IoT Greengrass.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Principal": {
"Service": "ssm.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
}
```
------
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.
```
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 aos dispositivos de borda permissão para executar comandos usando o Systems Manager.
**nota**
As políticas que você adicionar em uma função de serviço para dispositivos de borda em um ambiente AWS IoT Greengrass são as mesmas políticas usadas para criar um perfil 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 necessárias para o Systems Manager](setup-instance-permissions.md).
(Obrigatório) Execute o comando a seguir para permitir que um dispositivo de borda 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\$1ID* e *my\$1bucket\$1policy\$1name* 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 que as solicitações ingressem no domínio dos dispositivos de borda. A função de serviço precisará dessa política somente se você integrar os dispositivos de borda 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 atendente do CloudWatch seja executado nos dispositivos de borda. Esse comando permite ler informações em um dispositivo e gravá-las no CloudWatch. Sua função 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
```
------
## Configure seus dispositivos de borda para AWS IoT Greengrass
Configure seus dispositivos de borda como dispositivos principais do AWS IoT Greengrass. O processo de configuração envolve a verificação de sistemas operacionais e requisitos do sistema compatíveis, bem como a instalação e configuração do software principal do AWS IoT Greengrass em seus dispositivos. Para obter mais informações, consulte [Configurar dispositivos principais do AWS IoT Greengrass](https://docs.aws.amazon.com/greengrass/v2/developerguide/setting-up.html) no *Guia do desenvolvedor do AWS IoT Greengrass Version 2*.
## Atualizar o perfil de troca de token do AWS IoT Greengrass e instalar o SSM Agent em seus dispositivos de borda
A etapa final para preparar e configurar seus dispositivos principais AWS IoT Greengrass para o Systems Manager exige que você atualize o perfil de serviço do dispositivo AWS IoT Greengrass AWS Identity and Access Management (IAM), também chamado de *função de troca de token* e implante o Atendente do AWS Systems Manager (SSM Agent) em seus dispositivos AWS IoT Greengrass. Para obter informações sobre esses processos, consulte [Instalar o AWS Systems ManagerAtendente](https://docs.aws.amazon.com/greengrass/v2/developerguide/install-systems-manager-agent.html) no *Guia do desenvolvedor do AWS IoT Greengrass Version 2*.
Depois de implantar o SSM Agent em seus dispositivos, o AWS IoT Greengrass registra automaticamente os dispositivos com o Systems Manager. Nenhum registro adicional é necessário. Você pode começar a usar as ferramentas do Systems Manager para acessar, gerenciar e configurar seus dispositivos do AWS IoT Greengrass.
**nota**
Seus dispositivos de borda devem conseguir se comunicar com o serviço do Systems Manager na nuvem. O Systems Manager não oferece suporte a dispositivos de borda desconectados.
# Criar um administrador delegado do AWS Organizations para o Systems Manager
**Mudança de disponibilidade do Change Manager**
O AWS Systems Manager Change Manager não estará mais disponível para novos clientes a partir de 7 de novembro de 2025. Se quiser usar o Change Manager, inscreva-se antes dessa data. Os clientes atuais podem continuar usando o serviço normalmente. Para obter mais informações, consulte [mudança de disponibilidade do AWS Systems Manager Change Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/change-manager-availability-change.html).
Ao configurar uma organização no AWS Organizations, você atribui uma conta de gerenciamento para realizar todas as tarefas administrativas para todos os Serviços da AWS. O usuário da conta gerencial pode atribuir uma *conta de administrador delegado* somente para que o Systems Manager execute tarefas administrativas para o Change Manager, o Explorer e o OpsCenter. O AWS Organizations é um serviço de gerenciamento de contas que pode ser usado para criar uma organização e atribuir Contas da AWS para gerenciar essas contas de maneira centralizada. Para obter informações sobre AWS Organizations, consulte [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html) no *Guia do usuário do AWS Organizations*.
O Change Manager, o Explorer e o OpsCenter, todos ferramentas do AWS Systems Manager, trabalham com o AWS Organizations para realizar tarefas em todas as contas de membro da organização. É possível atribuir somente um administrador delegado a todas as ferramentas do Systems Manager. A conta de administrador delegado deve ser um membro da organização à qual ela está atribuída.
**Topics**
+ [Usar um administrador delegado com o Change Manager](#setting_up_delegated_administrator_change_manager)
+ [Usar um administrador delegado com o Explorer](#setting_up_delegated_administrator_explorer)
+ [Usar um administrador delegado com o OpsCenter](#setting_up_delegated_administrator_opscenter)
+ [Usar um administrador delegado com o Quick Setup](#setting_up_delegated_administrator_quick_setup)
## Usar um administrador delegado com o Change Manager
Change ManagerO é um framework empresarial de gerenciamento de alterações para solicitar, aprovar, implementar e emitir relatórios sobre alterações operacionais em sua configuração e infraestrutura de aplicações.
Se você usa o Change Manager em uma organização, atribua uma conta de administrador delegado para gerenciar modelos, aprovações e relatórios de alteração para todas as contas de membro. Com a Quick Setup, você pode configurar o Change Manager para usar com uma organização e selecionar a conta de administrador delegado. Se você usar o Change Manager apenas com uma única Conta da AWS, a conta de administrador delegado não será necessária.
Por padrão, o Change Manager exibe todas as tarefas relacionadas a alterações na conta do administrador delegado. Para obter instruções sobre como configurar um administrador delegado ao configurar o Change Manager para uma organização, consulte [Configure o Change Manager para uma organização (conta de gerenciamento)](change-manager-organization-setup.md).
**Importante**
Se você usar o Change Manager em uma organização, recomendamos sempre fazer as alterações na conta de administrador delegado. Embora seja possível fazer alterações de outras contas na organização, essas alterações não serão relatadas ou visíveis na conta do administrador delegado.
## Usar um administrador delegado com o Explorer
O Explorer é um painel de operações personalizável que exibe uma visualização agregada dos dados de operações (OpsData) para as Contas da AWS em todas as Regiões da AWS.
Você pode configurar uma conta de administrador delegado para o Systems Manager agregar dados do Explorer de várias regiões e contas usando a sincronização de dados de recursos com o AWS Organizations. O administrador delegado pode pesquisar, filtrar e agregar dados do Explorer usando o Console de gerenciamento da AWS, a AWS Command Line Interface (AWS CLI) ou o AWS Tools for Windows PowerShell.
Ao usar uma conta de administrador delegado para o Explorer, você limita o número de administradores que podem criar ou excluir sincronizações de dados de recurso de várias contas e regiões a apenas uma Conta da AWS individual.
Você pode sincronizar dados de operações em todas as Contas da AWS da organização usando o Explorer. Para obter informações sobre como atribuir um administrador delegado pelo Explorer, consulte [Configuração de um administrador delegado para Explorer](Explorer-setup-delegated-administrator.md).
## Usar um administrador delegado com o OpsCenter
O OpsCenter fornece um local central em que engenheiros de operações e profissionais de TI podem gerenciar itens de trabalho operacionais (OpsItems) relacionados a recursos da AWS. Se você quiser usar o OpsCenter para gerenciar o OpsItems de maneira centralizada entre contas, é necessário configurar a organização no AWS Organizations.
Com a Quick Setup para o OpsCenter, você pode atribuir uma conta de administrador delegado e configurar o OpsCenter para gerenciar OpsItems de maneira centralizada. Para obter mais informações, consulte [(Opcional) Configurar o OpsCenter para gerenciar OpsItems entre contas usando a Quick Setup](OpsCenter-quick-setup-cross-account.md).
## Usar um administrador delegado com o Quick Setup
O Quick Setup é uma ferramenta do Systems Manager que ajuda configurar rapidamente serviços e recursos da AWS usados frequentemente de acordo com as práticas recomendadas. É possível configurar uma conta de administrador delegado da Quick Setup para implantar e gerenciar configurações em contas e regiões usando o AWS Organizations. Um administrador delegado da Quick Setup pode criar, atualizar, visualizar e excluir recursos do gerenciador de configurações em sua organização. O Systems Manager registra um administrador delegado para a Quick Setup como parte do processo de configuração da experiência do console integrado. Para obter mais informações, consulte [Configurar o console unificado do Systems Manager para uma organização](systems-manager-setting-up-organizations.md).
## Configuração geral para AWS Systems Manager
Se você ainda não fez isso, conecte–se em uma Conta da AWS e crie um usuário administrativo.
### Inscrever-se para uma Conta da AWS
Se você ainda não tem uma Conta da AWS, siga as etapas abaixo para criar uma.
**Como cadastrar uma Conta da AWS**
1. Abra [https://portal.aws.amazon.com/billing/signup](https://portal.aws.amazon.com/billing/signup).
1. Siga as instruções online.
Parte do procedimento de inscrição envolve receber uma chamada telefônica ou uma mensagem de texto e inserir um código de verificação pelo teclado do telefone.
Quando você se inscreve para uma Conta da AWS, um *Usuário raiz da conta da AWS* é criado. O usuário-raiz tem acesso a todos os Serviços da AWS e recursos na conta. Como prática recomendada de segurança, atribua o acesso administrativo a um usuário e use somente o usuário-raiz para executar [tarefas que exigem acesso de usuário-raiz](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks).
A AWS envia um e-mail de confirmação depois que o processo de inscrição é concluído. A qualquer momento, é possível exibir as atividades da conta atual e gerenciar sua conta acessando [https://aws.amazon.com/](https://aws.amazon.com/) e selecionando **Minha conta**.
### Criar um usuário com acesso administrativo
Depois de se cadastrar em uma Conta da AWS, proteja seu Usuário raiz da conta da AWS, habilite o Centro de Identidade do AWS IAM e crie um usuário administrativo para não usar o usuário-raiz em tarefas cotidianas.
**Proteger o Usuário raiz da conta da AWS**
1. Faça login no [Console de gerenciamento da AWS](https://console.aws.amazon.com/) como o proprietário da conta ao escolher a opção **Usuário-raiz** e inserir o endereço de e-mail da Conta da AWS. Na próxima página, insira a senha.
Para obter ajuda ao fazer login usando o usuário-raiz, consulte [Fazer login como usuário-raiz](https://docs.aws.amazon.com/signin/latest/userguide/console-sign-in-tutorials.html#introduction-to-root-user-sign-in-tutorial) no *Guia do usuário do Início de Sessão da AWS*.
1. Habilite a autenticação multifator (MFA) para o usuário-raiz.
Para obter instruções, consulte [Habilitar um dispositivo MFA virtual para sua Conta da AWS de usuário-raiz (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/enable-virt-mfa-for-root.html) no *Guia do usuário do IAM*.
**Criar um usuário com acesso administrativo**
1. Habilita o Centro de Identidade do IAM.
Para obter instruções, consulte [Habilitar o Centro de Identidade do AWS IAM](https://docs.aws.amazon.com//singlesignon/latest/userguide/get-set-up-for-idc.html) no *Guia do usuário do Centro de Identidade do AWS IAM*.
1. No Centro de Identidade do IAM, conceda o acesso administrativo a um usuário.
Para obter um tutorial sobre como usar o Diretório do Centro de Identidade do IAM como a fonte de identidade, consulte [Configurar o acesso dos usuários com o Diretório do Centro de Identidade do IAM padrão](https://docs.aws.amazon.com//singlesignon/latest/userguide/quick-start-default-idc.html) no *Guia do usuário do Centro de Identidade do AWS IAM*.
**Iniciar sessão como o usuário com acesso administrativo**
+ Para fazer login com o seu usuário do Centro de Identidade do IAM, use o URL de login enviado ao seu endereço de e-mail quando o usuário do Centro de Identidade do IAM foi criado.
Para obter ajuda para fazer login usando um usuário do Centro de Identidade do IAM, consulte [Fazer login no portal de acesso da AWS](https://docs.aws.amazon.com/signin/latest/userguide/iam-id-center-sign-in-tutorial.html), no *Guia do usuário do Início de Sessão da AWS*.
**Atribuir acesso a usuários adicionais**
1. No Centro de Identidade do IAM, crie um conjunto de permissões que siga as práticas recomendadas de aplicação de permissões com privilégio mínimo.
Para obter instruções, consulte [Criar um conjunto de permissões](https://docs.aws.amazon.com//singlesignon/latest/userguide/get-started-create-a-permission-set.html) no *Guia do usuário do Centro de Identidade do AWS IAM*.
1. Atribua usuários a um grupo e, em seguida, atribua o acesso de logon único ao grupo.
Para obter instruções, consulte [Adicionar grupos](https://docs.aws.amazon.com//singlesignon/latest/userguide/addgroups.html) no *Guia do usuário do Centro de Identidade do AWS IAM*.