As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Migrando seus AWS OpsWorks Stacks aplicativos para o AWS Systems Manager Application Manager
**Importante**
O AWS OpsWorks Stacks serviço chegou ao fim da vida útil em 26 de maio de 2024 e foi desativado para clientes novos e existentes. É altamente recomendável que os clientes migrem suas cargas de trabalho para outras soluções o mais rápido possível.
Agora você pode migrar seus AWS OpsWorks Stacks aplicativos para o [Application Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/application-manager.html), um recurso de AWS Systems Manager, usando um script de migração. A migração de seus aplicativos Stacks para o Systems Manager Application Manager permite que você use AWS recursos que não estão disponíveis no AWS OpsWorks Stacks, como novos tipos de EC2 instância da Amazon, como Graviton, novos volumes do Amazon Elastic Block Store (EBS), como gp3, novos sistemas operacionais, integrações com grupos do Auto Scaling e balanceadores de carga de aplicativos.
Com esta versão, agora você pode monitorar e executar operações em suas instâncias migradas usando uma nova guia **Instâncias** disponível no Systems Manager Application Manager. Você pode usar a guia **Instâncias** para visualizar várias AWS instâncias em um só lugar. Usando essa guia, você pode ver informações sobre a integridade da instância e solucionar problemas. Para obter mais informações sobre como trabalhar com a guia **Instâncias**, consulte [Como trabalhar com as instâncias do seu aplicativo](https://docs.aws.amazon.com/systems-manager/latest/userguide/application-manager-working-instances.html) no *Guia do usuário AWS Systems Manager *.
**Topics**
+ [Como o script funciona](#migrating-to-systems-manager-script)
+ [Pré-requisitos](migrating-to-systems-manager-prerequisites.md)
+ [Limitações](migrating-to-systems-manager-limitations.md)
+ [Introdução](migrating-to-systems-manager-getting-started.md)
+ [Perguntas frequentes](migrating-to-systems-manager-faqs.md)
+ [Solução de problemas](migrating-to-systems-manager-troubleshooting.md)
## Como o script funciona
OpsWorks fornece um script que você pode executar para migrar seus AWS OpsWorks Stacks aplicativos para o Systems Manager Application Manager usando um CloudFormation modelo. O script obtém informações sobre uma OpsWorks camada existente e, dependendo do valor do `--provision-application` parâmetro do script, provisiona um clone do seu aplicativo ou fornece um CloudFormation modelo inicial que você pode modificar usando. CloudFormation
# Pré-requisitos
+ Certifique-se de que o AWS CLI esteja instalado e configurado. Para obter mais informações sobre a instalação do AWS CLI, consulte [Instalando ou atualizando a versão mais recente do AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) no *Guia AWS Command Line Interface do Usuário*.
**nota**
Se você não quiser configurar o AWS CLI, você também pode executar comandos usando AWS CloudShell o. Para obter mais informações sobre como trabalhar com CloudShell, consulte [Trabalhando com AWS CloudShell](https://docs.aws.amazon.com/cloudshell/latest/userguide/working-with-cloudshell.html) no *Guia AWS CloudShell do Usuário*.
+ Garanta que o Python versão 3.6 ou mais recente esteja instalado ou venha com a Imagem de máquina da Amazon (AMI).
+ Garanta que seu sistema operacional seja compatível. Você pode baixar e executar o script de migração nos seguintes sistemas operacionais.
+ Amazon Linux e Amazon Linux 2
+ Ubuntu 18.04 LTS, 20.04 LTS, 22.04 LTS
+ Red Hat Enterprise Linux 8
+ Windows Server 2019, Windows 10 Enterprise
**nota**
O Windows Server 2022 não é compatível.
# Limitações
A nova OpsWorks arquitetura é diferente da arquitetura para AWS OpsWorks Stacks. Esta seção descreve as limitações conhecidas dessa arquitetura.
Os itens a seguir não são compatíveis com a nova OpsWorks arquitetura.
+ Executando receitas do Chef em instâncias do Windows e CentOS
+ Chef 11 camadas e Berkshelf integrados
+ Atributos e pacotes de dados do Chef
+ Instâncias on-premises
+ Instâncias importadas de EC2
+ Não há suporte para instalar uma lista especificada pelo usuário de pacotes do sistema operacional
+ Os aplicativos não são compatíveis nem migrados
Estes a seguir são compatíveis, mas com limitações:
+ O script de migração clona as informações do volume do EBS, mas exclui os pontos de montagem e os dados reais contidos nos volumes.
+ As instâncias escalonadas com base no tempo e na carga são migradas, mas as regras de escalabilidade associadas a essas instâncias não são migradas. Você pode modificar o grupo do Auto Scaling para obter resultados semelhantes.
+ As entidades do IAM definidas na página de **permissões** da pilha no OpsWorks console não são criadas nem geradas.
+ O script de migração só é capaz de provisionar aplicativos de camada única no Systems Manager. Por exemplo, se você executar o script duas vezes para duas camadas na mesma pilha, obterá dois aplicativos diferentes no Systems Manager.
# Introdução
O script de migração,`stack_exporter.py`, é um script Python que você pode executar localmente ou em uma EC2 instância. Antes de executar o script, verifique se todos os pré-requisitos foram atendidos. Para mais sobre os pré-requisitos, consulte [Pré-requisitos](migrating-to-systems-manager-prerequisites.md).
As etapas nas seções a seguir mostram como migrar suas OpsWorks pilhas para o Systems Manager Application Manager.
**Topics**
+ [Etapa 1: preparar o ambiente para executar o script](w2ab1c14c43c17b9.md)
+ [Etapa 2: fazer download do script de migração](migrating-to-systems-manager-download-script.md)
+ [Etapa 3: configurar o ambiente para executar o script](migrating-to-systems-manager-script-parameters.md)
+ [Etapa 4: executar o script](migrating-to-systems-manager-run-script.md)
+ [Etapa 5: provisionar uma CloudFormation pilha](migrating-to-systems-manager-provision-stack.md)
+ [Etapa 6: revisar os recursos provisionados](migrating-to-systems-manager-provision-resources.md)
+ [Etapa 7: iniciar uma instância](migrating-to-systems-manager-start-instance.md)
+ [Etapa 8: revisar a instância](migrating-to-systems-manager-review-instance.md)
+ [Etapa 9: monitore e execute operações em suas instâncias usando o Systems Manager Application Manager](migrating-to-systems-manager-monitor.md)
# Etapa 1: preparar o ambiente para executar o script
Preparar o ambiente executando os comandos apropriados para o sistema operacional.
**Topics**
+ [Amazon Linux 2](#w2ab1c14c43c17b9b7)
+ [Amazon Linux](#w2ab1c14c43c17b9b9)
+ [Ubuntu 18.04, 20.04, 22.04](#w2ab1c14c43c17b9c11)
+ [Red Hat Enterprise Linux 8](#w2ab1c14c43c17b9c13)
+ [Windows Server 2019, Windows 10 Enterprise](#w2ab1c14c43c17b9c15)
## Amazon Linux 2
```
sudo su
python3 -m pip install pipenv
PATH="$PATH:/usr/local/bin"
yum update
yum install git
```
## Amazon Linux
```
sudo su
PATH="$PATH:/usr/local/bin"
export LC_ALL=en_US.utf-8
export LANG=en_US.utf-8
yum update
yum list | grep python3
yum install python36 // Any python version
yum install git
```
Para o Python versão 3.6, execute também:
```
python3 -m pip install pipenv==2022.4.8
```
Para Python versão 3.7 e versões mais recentes, execute também:
```
python3 -m pip install pipenv
```
## Ubuntu 18.04, 20.04, 22.04
```
sudo su
export PATH="${HOME}/.local/bin:$PATH"
apt-get update
apt install python3-pip
apt-get install git // if git is not installed
python3 -m pip install --user pipenv==2022.4.8
```
## Red Hat Enterprise Linux 8
```
sudo su
sudo dnf install python3
PATH="$PATH:/usr/local/bin"
yum update
yum install git
python3 -m pip install pipenv==2022.4.8
```
## Windows Server 2019, Windows 10 Enterprise
**nota**
Para o Windows Server 2019, instale o Python versão 3.6.1 ou mais recente.
```
pip install pipenv
```
Se o Git ainda não estiver instalado, baixe e instale o [Git](https://git-scm.com/download/win).
Se você usa o Git como fonte do livro de receitas, adicione seu servidor Git a um arquivo `known_hosts` antes de executar o script no Windows. Você pode usar PowerShell para criar a seguinte função.
```
function add_to_known_hosts($server){
$new_host=$(ssh-keyscan $server 2> $null)
$existing_hosts=''
if (!(test-path "$env:userprofile\.ssh")) {
md "$env:userprofile\.ssh"
}
if ((test-path "$env:userprofile\.ssh\known_hosts")) {
$existing_hosts=Get-Content "$env:userprofile\.ssh\known_hosts"
}
$host_added=0
foreach ($line in $new_host) {
if (!($existing_hosts -contains $line)) {
Add-Content -Path "$env:userprofile\.ssh\known_hosts" -Value $line
$host_added=1
}
}
if ($host_added) {
echo "$server has been added to known_hosts."
} else {
echo "$server already exists in known_hosts."
}
}
```
Em seguida, você pode fornecer seu servidor Git (por exemplo, github.com, git-codecommit). *repository\$1region*.amazonaws.com) quando você executa a função.
```
add_to_known_hosts "myGitServer"
```
# Etapa 2: fazer download do script de migração
Faça o download do arquivo zip contendo o script de migração e todos os arquivos relevantes executando o comando a seguir.
```
aws s3api get-object \
--bucket export-opsworks-stacks-bucket-prod-us-east-1 \
--key export_opsworks_stacks_script.zip export_opsworks_stacks_script.zip
```
Se você estiver usando Linux, instale o utilitário de descompactação usando os seguintes comandos.
```
sudo apt-get install unzip
sudo yum install unzip
```
Descompacte os arquivos usando o comando apropriado para seu sistema operacional.
**No Linux**, use o comando a seguir:
```
unzip export_opsworks_stacks_script.zip
```
**Para Windows**, use o `Expand-Archive` comando em PowerShell.
```
Expand-Archive -LiteralPath PathToZipFile -DestinationPath PathToDestination
```
Depois que o arquivo for descompactado, os seguintes diretórios e arquivos estarão disponíveis.
+ README.md
+ LICENSE
+ NOTICE
+ requirements.txt
+ templates/
+ OpsWorksCFNTemplate.yaml
+ Monte EBSVolumes .yaml
+ opsworks/
+ cloudformation/
+ instances\$1tab/
+ cfn\$1stack\$1deployer.py
+ s3.py
+ stack\$1exporter\$1context.py
+ stack\$1exporter.py
# Etapa 3: configurar o ambiente para executar o script
Configure seu ambiente para executar o script usando o comando a seguir.
```
pipenv install -r requirements.txt
pipenv shell
```
**nota**
Atualmente, o script só pode provisionar aplicativos de camada única no Application Manager. Por exemplo, se você executar o script duas vezes para duas camadas na mesma pilha, o script cria dois aplicativos diferentes no Application Manager.
Depois de configurar seu ambiente, revise os parâmetros do script. Você pode ver as opções disponíveis para o script de migração executando o comando `python3 stack_exporter.py --help`.
****
| Parâmetro | Description | Obrigatório | Tipo | Valor padrão |
| --- | --- | --- | --- | --- |
| --layer-id | Exporta um CloudFormation modelo para essa ID OpsWorks de camada. | Sim | string | |
| --region | A AWS região da OpsWorks pilha. Se a região da OpsWorks pilha e a região do endpoint da API forem diferentes, use a região da pilha. Essa é a mesma região que os outros recursos que fazem parte da sua OpsWorks pilha (por exemplo, EC2 instâncias e sub-redes). | Não | string | us-east-1 |
| --provision-application | Por padrão, o script provisiona o aplicativo exportado pelo CloudFormation modelo. Passe esse parâmetro para o script com o valor FALSE para ignorar o provisionamento do modelo. CloudFormation | Não | Booleano | TRUE |
| --launch-template | Esse parâmetro define se vai usar um modelo de inicialização existente ou criar um novo modelo de inicialização. Você pode criar um novo modelo de execução que use as propriedades de instância recomendadas ou que use propriedades de instância que correspondam a uma instância on-line. Os valores válidos são: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/opsworks/latest/userguide/migrating-to-systems-manager-script-parameters.html) | Não | string | RECOMMENDED |
| --system-updates | Define se vai atualizar o kernel e o pacote vai atualizar quando a instância é inicializada. Os valores válidos são: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/opsworks/latest/userguide/migrating-to-systems-manager-script-parameters.html) | Não | string | ALL\$1UPDATES |
| --http-username | O nome do parâmetro SecureString do Systems Manager que armazena o nome de usuário usado para autenticação no arquivo HTTP que contém os livros de receitas personalizados. | Não | string | |
| --http-password | O nome do parâmetro SecureString do Systems Manager que armazena a senha usada para autenticação no arquivo HTTP que contém os livros de receitas personalizados. | Não | string | |
| --repo-private-key | O nome do parâmetro SecureString do Systems Manager que armazena a chave SSH usada para autenticação no repositório que contém os livros de receitas personalizados. Se o repositório estiver ativado GitHub, você deverá gerar uma nova chave Ed25519 SSH. Se você não gerar uma nova chave Ed25519 SSH, a conexão com o GitHub repositório falhará. | Não | string | |
| --lb-type | O tipo de balanceador de carga, se houver, a ser criado ao migrar seu balanceador de carga existente. Os valores válidos são: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/opsworks/latest/userguide/migrating-to-systems-manager-script-parameters.html) | Não | string | ALB |
| --lb-access-logs-path | O caminho para um bucket S3 existente e o prefixo para armazenar os registros de acesso do balanceador de carga. O bucket e o balanceador de carga devem estar na mesma Região. Se você não fornecer um valor e o valor do parâmetro --lb-type for definido como None, o script criará um novo bucket e prefixo do S3. Verifique se há uma política de bucket apropriada para esse prefixo. | Não | string | |
| --enable-instance-protection | Se definido comoTRUE, o script cria uma política de encerramento personalizada (função Lambda) para seu grupo de Auto Scaling. EC2instâncias com uma protected\$1instance tag são protegidas de eventos de expansão. Adicione uma protected\$1instance tag a cada EC2 instância que você deseja proteger de eventos de escalabilidade. | Não | Booleano | FALSE |
| --command-logs-bucket | O nome de um bucket do S3 existente para armazenar os logs AWS ApplyChefRecipe e MountEBSVolumes. Se você não fornecer um valor, o script criará um novo bucket do S3. | Não | string | aws-opsworks-application-manager-logs-account-id |
| --custom-json-bucket | O nome de um bucket do S3 existente para armazenar JSON personalizado. Se você não fornecer um valor, o script criará um novo bucket do S3. | Não | string | aws-apply-chef-application-manager-transition-data-account-id |
**Observações:**
+ Se você usar um GitHub repositório privado, deverá criar uma nova chave de `Ed25519` host para SSH. Isso ocorre porque GitHub alterou quais chaves são suportadas no SSH e removeu o protocolo Git não criptografado. Para obter mais informações sobre a chave do `Ed25519` host, consulte a postagem do GitHub blog [Melhorando a segurança do protocolo Git](https://github.blog/2021-09-01-improving-git-protocol-security-github/) em. GitHub Depois de gerar uma nova chave de host `Ed25519`, crie um parâmetro `SecureString` do Systems Manager para a chave SSH e use o nome do parâmetro `SecureString` como o valor do parâmetro `--repo-private-key`. Para obter mais informações sobre como criar um `SecureString` parâmetro do Systems Manager, consulte [Create a SecureString parameter (AWS CLI)](https://docs.aws.amazon.com/systems-manager/latest/userguide/param-create-cli.html#param-create-cli-securestring) ou [Create a Systems Manager parameter (console)](https://docs.aws.amazon.com/systems-manager/latest/userguide/parameter-create-console.html) no *Guia do AWS Systems Manager Usuário*.
+ Os parâmetros `--http-username`, `--http-password` e `--repo-private-key` referem-se ao nome do parâmetro `SecureString` do Systems Manager. O script de migração usa esses parâmetros quando você executa o documento `AWS-ApplyChefRecipes`.
+ O parâmetro `--http-username` exige que você também especifique um valor para o `--http-password` parâmetro.
+ O parâmetro `--http-password` exige que você também especifique um valor para o `--http-username` parâmetro.
+ Não defina valores para `--http-password` e `--repo-private-key`. Forneça um nome de parâmetro `SecureString` do Systems Manager de uma chave SSH (`--repo-private-key`) ou um nome de usuário (`--http-username`) e senha (`--http-password`) do repositório.
# Etapa 4: executar o script
Ao executar `python3 stack_exporter.py`, você pode provisionar o aplicativo ou criar um modelo inicial definindo o valor do parâmetro `--provision-application` como `FALSE`.
**Exemplo 1: provisionar um aplicativo Systems Manager Application Manager**
O comando a seguir obtém informações sobre uma OpsWorks camada existente e provisiona um aplicativo usando a OpsWorks arquitetura mais recente, que obtém um resultado semelhante à versão do Chef configurada para a pilha. O script provisiona todos os recursos necessários, como grupos de Auto Scaling usando e CloudFormation, em seguida, registra o aplicativo no Systems Manager Application Manager.
Substitua *stack-region* e *layer-id* pelos valores de sua OpsWorks pilha e camada.
```
python3 stack_exporter.py \
--layer-id layer-id \
--region stack-region
```
**Exemplo 2: gerar um modelo**
O comando a seguir obtém informações sobre uma OpsWorks camada existente e gera um CloudFormation modelo. O modelo, se provisionado, obtém um resultado semelhante ao uso do Chef 14. Neste exemplo, nenhum recurso é provisionado, porque o `--provision-application` parâmetro está definido como. `FALSE`
Substitua *stack-region* e *layer-id* pelos valores de sua OpsWorks pilha e camada.
```
python3 stack_exporter.py \
--layer-id layer-id \
--region stack-region \
--provision-application FALSE
```
Depois de executar o comando, você pode revisar o modelo na biblioteca de modelos do Application Manager no Systems Manager e também pode provisionar o modelo. Para obter mais informações sobre como visualizar a biblioteca de modelos, consulte Como [trabalhar com a biblioteca de modelos](https://docs.aws.amazon.com/systems-manager/latest/userguide/application-manager-working-templates-overview.html#application-manager-working-stacks-template-library-working) no *Guia do usuário AWS Systems Manager *.
# Etapa 5: provisionar uma CloudFormation pilha
**nota**
Você só precisará concluir esta etapa se definir o parâmetro `--provision-application` do script como `FALSE`.
Quando você especifica o `--provision-application` parâmetro com um valor de`FALSE`, a saída do script fornece o nome e a URL do CloudFormation modelo. Esse modelo representa uma proposta de substituição para sua OpsWorks pilha e camada existentes.
Você pode provisionar o modelo usando a biblioteca de modelos do Application Manager (recomendado) ou usando CloudFormation. Para obter mais informações sobre como trabalhar com a biblioteca de modelos, consulte [Como trabalhar com a biblioteca de modelos](https://docs.aws.amazon.com/systems-manager/latest/userguide/application-manager-working-templates-overview.html#application-manager-working-stacks-template-library-working) no *Guia do usuário AWS Systems Manager *.
# Etapa 6: revisar os recursos provisionados
Agora, você está pronto para revisar os recursos provisionados.
1. Analise os recursos da pilha provisionada usando o console. CloudFormation
1. **Abra o CloudFormation console em [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/) e escolha Stacks.**
1. Na página **Pilhas**, escolha a pilha, e depois escolha a guia **Recursos**.
1. Na guia **Recursos**, revise os recursos listados para sua pilha. A lista de recursos inclui um grupo de EC2 Auto Scaling, que você pode analisar no console do Auto Scaling, ou. AWS CLI
1. Analise os recursos do aplicativo usando o Systems Manager Application Manager.
1. Abra o console do Systems Manager em [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. No painel de navegação, escolha **Application Manager**.
1. Na seção **Aplicações**, escolha a aplicação personalizada. O Application Manager abre a guia **Visão geral**.
1. Escolha a guia **Recursos**. A guia **Recursos** mostra todos os recursos que foram migrados para sua OpsWorks pilha e camada. O nome do aplicativo inclui o nome da OpsWorks pilha e é formatado como *app* - *stack-name* -, *suffix* onde *suffix* representa os primeiros seis caracteres do ID da pilha. Para obter mais informações sobre a visualização de recursos no Application Manager, consulte [Visualização de recursos do aplicativo](https://docs.aws.amazon.com/systems-manager/latest/userguide/application-manager-working-viewing-resources.html) no *Guia do usuário AWS Systems Manager *.
# Etapa 7: iniciar uma instância
Depois de provisionar uma instância, você estará pronto para testar a instância. Neste momento, não há instâncias em execução.
Para colocar suas instâncias on-line, ajuste os valores `Min`, `Max`, e `Desired capacity` do grupo do Auto Scaling para um número que faça sentido para seu aplicativo. Inicialmente, talvez você queira definir esses valores como 1, para colocar uma única instância on-line e verificar se a instância executa todas as ações esperadas, incluindo a execução de suas receitas personalizadas do Chef.
# Etapa 8: revisar a instância
Depois de iniciar uma instância, verifique se ela é executada conforme o esperado.
1. Revise os logs `startup` e `terminate` do Chef, localizados no bucket do S3 especificado pelo parâmetro `--command-logs-bucket` do script. Por padrão, os registros são armazenados em um bucket com o nome `aws-opsworks-application-manager-logs-account-id`.
1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon S3 em. [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)
1. Escolha o bucket que contém seus logs.
1. Navegue até o `ApplyChefRecipes` prefixo para ver seus registros.
1. Verifique a conectividade e a integridade do Application Load Balancer.
Siga as seguintes etapas para visualizar os logs de acesso do seu balanceador de carga. É possível especificar o bucket do S3 no qual deseja armazenar os logs de acesso do balanceador de carga usando o parâmetro `--lb-access-logs-path` do script.
1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon S3 em. [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)
1. Escolha seu bucket do S3 e, em seguida, navegue até o prefixo que contém seus registros.
1. Verifique se a instância é aprovada em todas as verificações de integridade do ajuste de escala automático e do Application Load Balancer (se você tiver configurado alguma).
Você pode ver informações sobre a integridade do ajuste de escala automático na nova guia **Instâncias**.
1. Abra o console do Systems Manager em [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. No painel de navegação, escolha **Application Manager**.
1. Na seção **Aplicativos**, escolha **Aplicativos personalizados**.
1. Selecione o aplicativo na lista. O Application Manager abre a guia **Visão geral**.
1. Escolha a guia **Instâncias** para ver informações sobre a integridade do ajuste de escala automático.
Depois de verificar se as receitas do Chef são executadas com êxito, você pode diminuir a capacidade do grupo do Auto Scaling para encerrar a instância. Se você tiver alguma receita de terminação personalizada, verifique se as receitas funcionam conforme o esperado.
# Etapa 9: monitore e execute operações em suas instâncias usando o Systems Manager Application Manager
Agora você pode monitorar e executar operações em suas instâncias usando uma nova guia **Instâncias** na página do Application Manager. Para obter mais informações sobre como trabalhar com a guia **Instâncias**, consulte [Como trabalhar com as instâncias do seu aplicativo](https://docs.aws.amazon.com/systems-manager/latest/userguide/application-manager-working-instances.html) no *Guia do usuário AWS Systems Manager *.
Você pode usar a guia **Instâncias** para visualizar várias AWS instâncias em um só lugar. Usando essa guia, você pode ver informações sobre a integridade da instância e solucionar problemas.
![\[Application dashboard showing instance status with running, healthy, and OK indicators at 100%.\]](http://docs.aws.amazon.com/pt_br/opsworks/latest/userguide/images/instances-tab.png)
Siga as etapas a seguir para ver a guia **Instâncias**.
1. Abra o console do Systems Manager em [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. No painel de navegação, escolha **Application Manager**.
1. Na seção **Aplicativos**, escolha **Aplicativos personalizados**.
1. Selecione o aplicativo na lista. O Application Manager abre a guia **Visão geral**.
1. Escolha a guia **Instâncias** para ver informações sobre o status e a EC2 integridade da sua instância.
# Perguntas frequentes
Veja a seguir FAQs respostas para algumas perguntas comuns.
**Topics**
+ [Quais AWS OpsWorks Stacks versões posso migrar?](#w2ab1c14c43c19b7)
+ [Quais versões do Chef minhas instâncias migradas podem usar?](#w2ab1c14c43c19b9)
+ [Quais tipos de repositório posso migrar?](#w2ab1c14c43c19c11)
+ [Posso continuar usando um repositório Git privado?](#w2ab1c14c43c19c13)
+ [Quais chaves SSH posso usar para acessar minhas instâncias?](#w2ab1c14c43c19c15)
+ [Por que minhas instâncias estão aumentando e diminuindo automaticamente?](#w2ab1c14c43c19c17)
+ [Posso desativar o ajuste de escala automático?](#w2ab1c14c43c19c19)
+ [Posso realizar atualizações de kernel e pacote em EC2 instâncias lançadas?](#w2ab1c14c43c19c21)
+ [Por que os volumes do EBS em minhas instâncias não contêm dados?](#w2ab1c14c43c19c23)
+ [Por que os volumes do EBS descritos no meu modelo de lançamento não estão montados?](#w2ab1c14c43c19c25)
+ [Onde posso encontrar receitas do Chef e registros de volume do Mount EBS?](#w2ab1c14c43c19c27)
+ [Onde posso encontrar o log de depuração do script de migração?](#w2ab1c14c43c19c29)
+ [O script de migração oferece suporte ao controle CloudFormation de versão do modelo?](#w2ab1c14c43c19c31)
+ [Posso migrar várias camadas?](#w2ab1c14c43c19c33)
+ [Como crio um parâmetro `SecureString`?](#w2ab1c14c43c19c35)
+ [Como posso proteger as instâncias do novo grupo do Auto Scaling contra eventos de encerramento?](#w2ab1c14c43c19c37)
+ [Quais balanceadores de carga estão disponíveis com o script de migração?](#w2ab1c14c43c19c39)
+ [As receitas de configuração do livro de receitas personalizado foram migradas?](#w2ab1c14c43c19c41)
+ [Posso executar receitas de implantação e desimplantação em minhas instâncias recém-criadas?](#w2ab1c14c43c19c43)
+ [Posso alterar quais sub-redes meu grupo do Auto Scaling abrange?](#w2ab1c14c43c19c45)
## Quais AWS OpsWorks Stacks versões posso migrar?
Você só pode migrar pilhas do Chef 11.10 e do Chef 12, do Amazon Linux, do Amazon Linux 2, do Ubuntu e do Red Hat Enterprise Linux 7.
## Quais versões do Chef minhas instâncias migradas podem usar?
As instâncias migradas podem usar as versões 11 a 14 do Chef.
**nota**
Não há suporte para migração de pilhas do Windows.
## Quais tipos de repositório posso migrar?
Você pode migrar os tipos de repositório S3, Git e HTTP.
## Posso continuar usando um repositório Git privado?
Sim, você pode continuar usando um repositório Git privado.
Se você usar um GitHub repositório privado, deverá criar uma nova chave de `Ed25519` host para SSH. Isso ocorre porque GitHub alterou quais chaves são suportadas no SSH e removeu o protocolo Git não criptografado. Para obter mais informações sobre a chave do `Ed25519` host, consulte a postagem do GitHub blog [Melhorando a segurança do protocolo Git](https://github.blog/2021-09-01-improving-git-protocol-security-github/) em. GitHub Depois de gerar uma nova chave de host `Ed25519`, crie um parâmetro `SecureString` do Systems Manager para essa chave SSH e use o nome do parâmetro como o valor do parâmetro `--repo-private-key`. Para obter mais informações sobre como criar um `SecureString` parâmetro do Systems Manager, consulte [Create a SecureString parameter (AWS CLI)](https://docs.aws.amazon.com/systems-manager/latest/userguide/param-create-cli.html#param-create-cli-securestring) no *Guia AWS Systems Manager do usuário*.
Para qualquer outro tipo de repositório Git, crie um parâmetro `SecureString` do Systems Manager para essa chave SSH e use o nome do parâmetro como o valor do parâmetro `--repo-private-key` do script.
## Quais chaves SSH posso usar para acessar minhas instâncias?
Quando você executa o script, o script migra as chaves SSH e as instâncias configuradas na pilha. Você pode usar as chaves SSH para acessar sua instância. Se as chaves SSH forem fornecidas para a pilha e a instância, o script usará as chaves da pilha. Se você não tiver certeza de quais chaves SSH usar, visualize as instâncias no EC2 console ([https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)). A página **Detalhes** no EC2 console mostra as chaves SSH da sua instância.
## Por que minhas instâncias estão aumentando e diminuindo automaticamente?
O ajuste de escala automático dimensiona as instâncias com base nas regras de escalabilidade do grupo do Auto Scaling. Você pode definir os valores de **capacidade **mínima**, **máxima** e desejada** para seu grupo. O grupo do Auto Scaling dimensiona automaticamente sua capacidade de acordo com a atualização desses valores.
## Posso desativar o ajuste de escala automático?
Você pode desativar o ajuste de escala automático definindo os valores de capacidade **mínima**, **máxima** e **desejada** do grupo do Auto Scaling para o mesmo número. Por exemplo, se você quiser sempre ter dez instâncias, defina os valores de capacidade **mínima**, **máxima** e **desejada** como dez.
## Posso realizar atualizações de kernel e pacote em EC2 instâncias lançadas?
Por padrão, as atualizações do kernel e dos pacotes ocorrem quando a EC2 instância é inicializada. Use as etapas a seguir para realizar atualizações de kernel ou pacote em uma EC2 instância iniciada. Por exemplo, talvez você queira aplicar atualizações após executar o deploy ou o configure recipes.
1. Conecte-se à sua EC2 instância.
1. Crie a função `perform_upgrade` a seguir e execute-a na sua instância.
```
perform_upgrade() {
#!/bin/bash
if [ -e '/etc/system-release' ] || [ -e '/etc/redhat-release' ]; then
sudo yum -y update
elif [ -e '/etc/debian_version' ]; then
sudo apt-get update
sudo apt-get dist-upgrade -y
fi
}
perform_upgrade
```
1. Depois das atualizações do kernel e do pacote, talvez seja necessário reinicializar sua EC2 instância. Para verificar se é necessário reinicializar, crie a `reboot_if_required` função a seguir e execute-a na sua EC2 instância.
```
reboot_if_required () {
#!/bin/bash
if [ -e '/etc/debian_version' ]; then
if [ -f /var/run/reboot-required ]; then
echo "reboot is required"
else
echo "reboot is not required"
fi
elif [ -e '/etc/system-release' ] || [ -e '/etc/redhat-release' ]; then
export LC_CTYPE=en_US.UTF-8
export LC_ALL=en_US.UTF-8
LATEST_INSTALLED_KERNEL=`rpm -q --last kernel | perl -X -pe 's/^kernel-(\S+).*/$1/' | head -1`
CURRENTLY_USED_KERNEL=`uname -r`
if [ "${LATEST_INSTALLED_KERNEL}" != "${CURRENTLY_USED_KERNEL}" ];then
echo "reboot is required"
else
echo "reboot is not required"
fi
fi
}
reboot_if_required
```
1. Se estiver executando os `reboot_if_required` resultados em uma `reboot is required` mensagem, reinicie a EC2 instância. Se você receber uma `reboot is not required` mensagem, não precisará reinicializar a EC2 instância.
## Por que os volumes do EBS em minhas instâncias não contêm dados?
Quando você executa o script, o script migra a configuração dos volumes do EBS, criando uma arquitetura substituta para sua OpsWorks pilha e sua camada. O script não migra instâncias reais nem os dados contidos nas instâncias. O script migra somente a configuração dos volumes do EBS no nível da camada e anexa os volumes vazios do EBS às instâncias iniciadas. EC2
Siga as etapas a seguir para extrair dados dos volumes do EBS de suas instâncias anteriores.
1. Crie um snapshot dos volumes do EBS de instâncias anteriores. Para obter mais informações sobre a criação de um snapshot, consulte [Criar um snapshot do Amazon EBS no Guia](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-creating-snapshot.html) do usuário da *Amazon EC2 *.
1. Criar um volume a partir de um snapshot. Para obter mais informações sobre a criação de um volume a partir de um snapshot, consulte [Criar um volume a partir de um snapshot no Guia EC2 ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-creating-volume.html#ebs-create-volume-from-snapshot) *do usuário da Amazon*.
1. Anexe o volume que você criou à instância. Para obter mais informações sobre anexar volumes, consulte [Anexar um volume do Amazon EBS a uma instância no Guia EC2 ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-attaching-volume.html) *do usuário da Amazon*.
## Por que os volumes do EBS descritos no meu modelo de lançamento não estão montados?
Se você fornecer uma ID de modelo de execução para o parâmetro `--launch-template` com volumes do EBS, o script anexará os volumes do EBS, mas não montará os volumes. Você pode montar os volumes do EBS anexados executando o `MountEBSVolumes` RunCommand documento que o script criou para a EC2 instância iniciada.
Se você não definir o `--launch-template` parâmetro, o script cria um modelo e, quando o grupo Auto Scaling inicia uma nova EC2 instância, o grupo Auto Scaling anexa automaticamente os volumes do EBS e, em seguida, executa `SetupAutomation` o comando para montar os volumes anexados nos pontos de montagem definidos nas configurações da camada.
## Onde posso encontrar receitas do Chef e registros de volume do Mount EBS?
OpsWorks entrega os registros em um bucket do S3 que você pode especificar fornecendo um valor para o `--command-logs-bucket` parâmetro. O nome padrão do bucket do S3 tem o formato: `aws-opsworks-stacks-application-manager-logs-account-id`. Os registros de receitas do Chef são armazenados no prefixo `ApplyChefRecipes`. Os registros de volume do Mount EBS são armazenados no prefixo `MountEBSVolumes`. Todas as camadas que são migradas de uma pilha entregam registros para o mesmo bucket do S3.
**nota**
A configuração do ciclo de vida do bucket S3 inclui uma regra para excluir os registros após 30 dias. Se quiser manter os registros por mais de 30 dias, você deve atualizar a regra na configuração do ciclo de vida do bucket S3.
Atualmente, registra OpsWorks apenas o Chef `setup` e `terminate` as receitas.
## Onde posso encontrar o log de depuração do script de migração?
O script coloca os logs de depuração em um bucket chamado `aws-opsworks-stacks-transition-logs-account-id`. Você pode encontrar os logs de depuração pasta `migration_script` do bucket do S3 em pastas que correspondem ao nome da camada que você migrou.
## O script de migração oferece suporte ao controle CloudFormation de versão do modelo?
O script gera documentos do tipo Systems Manager CloudFormation que criam uma substituição para a camada ou pilha que você deseja migrar. Executar o script novamente, mesmo com os mesmos parâmetros, exporta uma nova versão do modelo de camada exportado anteriormente. As versões do modelo são armazenadas no mesmo bucket do S3 que os logs do script.
## Posso migrar várias camadas?
O parâmetro `--layer-id` do script passa em uma única camada. Para migrar várias camadas, execute novamente o script e passe uma diferente `--layer-id`.
As camadas que fazem parte da mesma OpsWorks pilha são listadas sob o mesmo aplicativo no Application Manager.
1. Abra o console do Systems Manager em [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. No painel de navegação, escolha **Application Manager**.
1. Na seção **Aplicativos**, escolha **Aplicativos personalizados**.
1. Escolha o aplicativo. O nome do aplicativo começa com `app-stack-name-first-six-characters-stack-id`.
1. O elemento de nível superior, começando com app, mostra todos os componentes que correspondem à sua OpsWorks pilha. Isso inclui componentes correspondentes à sua OpsWorks camada.
1. Escolha o componente correspondente à camada para visualizar os recursos da camada. Os componentes que representam OpsWorks camadas também são visíveis na seção **Aplicativos personalizados** como aplicativos individuais.
## Como crio um parâmetro `SecureString`?
Você pode usar o Systems Manager para criar um parâmetro `SecureString`. Para obter mais informações sobre como criar um `SecureString` parâmetro do Systems Manager, consulte [Create a SecureString parameter (AWS CLI)](https://docs.aws.amazon.com/systems-manager/latest/userguide/param-create-cli.html#param-create-cli-securestring) ou [Create a Systems Manager parameter (console)](https://docs.aws.amazon.com/systems-manager/latest/userguide/parameter-create-console.html) no *Guia do AWS Systems Manager Usuário*.
Você deve fornecer um parâmetro `SecureString` como valor para os parâmetros `--http-username`, `--http-password`, ou `--repo-private-key`.
## Como posso proteger as instâncias do novo grupo do Auto Scaling contra eventos de encerramento?
Você pode proteger as instâncias definindo o `--enable-instance-protection` parâmetro `TRUE` e adicionando uma chave de `protected_instance` tag a cada EC2 instância que você deseja proteger contra eventos de encerramento. Quando você define o parâmetro `--enable-instance-protection` para `TRUE` e adiciona uma chave de tag `protected_instance`, o script adiciona uma política de encerramento personalizada ao seu novo grupo do Auto Scaling e suspende o processo `ReplaceUnhealthy`. As instâncias com a chave de tag `protected_instance` são protegidas dos seguintes eventos de encerramento:
+ Eventos de redução de escala horizontalmente
+ Atualização de instância
+ Rebalanceamento
+ Vida útil máxima da instância
+ Permitir o término de instâncias
+ Rescisão e substituição de instâncias não íntegras
**nota**
Você deve definir a chave da tag `protected_instance` nas instâncias que deseja proteger. Observe que a chave da tag faz distinção entre maiúsculas e minúsculas. Qualquer instância com essa chave de tag é protegida, independentemente do valor da tag.
Para reduzir o tempo de execução da política de encerramento personalizada, você pode aumentar o número padrão de instâncias que a função do Lambda usa para filtrar instâncias protegidas atualizando o valor da variável de código da função `default_sample_size`. O valor padrão é 15. Se você aumentar o `default_sample_size`, talvez seja necessário aumentar a memória alocada para a função do Lambda, o que aumentaria o custo da sua função do Lambda. Para obter mais informações sobre a definição de preço do AWS Lambda , consulte [Definição de preço do AWS Lambda](https://aws.amazon.com/).
## Quais balanceadores de carga estão disponíveis com o script de migração?
O script fornece três opções de balanceador de carga.
+ (Recomendado) Crie um novo Application Load Balancer. Por padrão, o script cria um novo Application Load Balancer. Também é possível definir o parâmetro `--lb-type` para `ALB`. Para obter mais informações sobre os Application Load Balancers, consulte [O que é Application Load Balancer?](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html) no guia do usuário do *Elastic Load Balancing*
+ Se um Application Load Balancer não for uma opção, crie um Classic Load Balancer definindo o parâmetro `--lb-type` para `Classic`. Se você selecionar essa opção, seu Classic Load Balancer existente anexado à sua OpsWorks camada será mantido separado do seu aplicativo. Para obter mais informações sobre Application Load Balancers, consulte [O que é um balanceador de carga clássico?](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/introduction.html) no *guia do usuário do Elastic Load Balancing: Classic Load Balancers*.
+ Você pode conectar um balanceador de carga existente definindo o parâmetro `--lb-type` para `None`.
**Importante**
Recomendamos criar novos balanceadores de carga do Elastic Load Balancing para suas camadas do AWS OpsWorks Stacks. Se escolher usar um balanceador de carga do Elastic Load Balancing existente, você deve primeiro confirmar que não está sendo usado para outros fins e não tem instâncias anexadas. Depois que o balanceador de carga é anexado à camada, OpsWorks remove todas as instâncias existentes e configura o balanceador de carga para lidar somente com as instâncias da camada. Apesar de ser tecnicamente possível usar o console do Elastic Load Balancing ou API para modificar a configuração do balanceador de carga após anexá-lo a camada, você não deve fazê-lo; as mudanças não serão permanentes.
**Para anexar seu balanceador OpsWorks de carga de camada existente ao seu grupo de Auto Scaling**
1. Execute o script de migração com o parâmetro `--lb-type` definido como `None`. Quando o valor é definido como `None`, o script não clona nem cria um balanceador de carga.
1. Depois que o script implantar a CloudFormation pilha, atualize os `Min` `Max` grupos `Desired capacity` e valores do Auto Scaling e teste seu aplicativo.
1. Escolha `Link to the template` mostrada na saída do script. Se você fechou seu terminal, siga estas etapas para acessar o modelo.
1. Abra o console do Systems Manager em [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. No painel de navegação, escolha **Application Manager**.
1. Escolha **CloudFormation pilhas** e, em seguida, escolha **Biblioteca de modelos**.
1. Escolha **Minha propriedade** e localize seu modelo.
1. No CloudFormation modelo, escolha **Editar** no menu **Ações**.
1. Atualize a `LabelBalancerNames` propriedade na seção de `ApplicationAsg` recursos do CloudFormation modelo.
```
ApplicationAsg:
DependsOn: CustomTerminationLambdaPermission
Properties:
#(other properties in ApplicationAsg to remain unchanged)
LoadBalancerNames:
- load-balancer-name
HealthCheckType: ELB
```
1. Se você quiser que sua verificação de integridade de instâncias de grupo do Auto Scaling também use a verificação de integridade do balanceador de carga, remova a seção `HealthCheckType` abaixo e insira `ELB`. Se você precisar apenas de verificações de EC2 saúde, não precisará alterar o modelo.
1. Salve as alterações. Salvar cria uma nova versão padrão do modelo. Se esta é a primeira vez que você executa o script para a camada e a primeira vez que você salva as alterações no console, a versão mais recente é 2.
1. Em **Ações**, escolha **Provisionar pilha**.
1. Confirme que você deseja usar a versão padrão do modelo. Certifique-se de que a **opção Selecionar uma pilha existente** esteja selecionada e escolha a CloudFormation pilha a ser atualizada.
1. Escolha **Próximo** para cada uma das páginas subsequentes até ver a página **Revisar e provisionar**. Na página **Revisar e provisionar**, escolha **Eu reconheço que AWS CloudFormation pode criar recursos do IAM com nomes personalizados** e **entendo que alterações no modelo selecionado podem AWS CloudFormation fazer com que os AWS recursos existentes sejam atualizados ou removidos.**
1. Selecione **Provision stack** (Provisionar pilha).
Se você precisar reverter as atualizações, siga as seguintes etapas:
1. Escolha **Ações** e depois escolha **Provisionar pilha**.
1. Selecione **Escolher uma das versões existentes** e, em seguida, escolha a versão anterior do modelo.
1. Escolha **Selecionar uma pilha existente** e, em seguida, escolha a CloudFormation pilha a ser atualizada.
## As receitas de configuração do livro de receitas personalizado foram migradas?
Não há suporte para execução de livros de receitas personalizados durante um evento de configuração. O script migra o livro de receitas personalizado, configura receitas e cria um runbook do Systems Manager Automation para você. No entanto, você deverá executar as receitas manualmente.
Siga as seguintes etapas para executar suas receitas de configuração.
1. Abra o console do Systems Manager em [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. No painel de navegação, escolha **Application Manager**.
1. Na seção **Aplicativos**, escolha **Aplicativos personalizados**.
1. Escolha o aplicativo. O nome do aplicativo começa com `app-stack-name`.
1. Escolha **Recursos** e, em seguida, escolha o runbook de configuração.****
1. Escolha **Executar automação**.
1. Escolha a instância IDs para a qual você deseja executar as receitas de configuração e, em seguida, escolha **Executar**.
## Posso executar receitas de implantação e desimplantação em minhas instâncias recém-criadas?
O script pode criar três possíveis runbooks de automação, dependendo da configuração da sua camada.
+ Configuração
+ Configurar
+ Encerrar
O script também pode criar os seguintes parâmetros do Systems Manager que contêm valores de entrada para o documento `AWS-ApplyChefRecipes Run Command`.
+ Configuração
+ Implantar
+ Configurar
+ Desfazer a Implementação
+ Encerrar
Quando ocorre um evento de expansão, o runbook de automação de configuração é executado automaticamente. Isso inclui a configuração e a implantação de receitas personalizadas de livros de receitas a partir de sua OpsWorks camada original. Quando um evento de aumento da escala na vertical acontece, o runbook de automação de término é executado automaticamente. O runbook terminate Automation contém as receitas de desligamento da sua camada original. OpsWorks
Se você deseja executar, desimplantar ou configurar receitas manualmente, siga as seguintes etapas.
1. Abra o console do Systems Manager em [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. No painel de navegação, escolha **Application Manager**.
1. Na seção **Aplicativos**, escolha **Aplicativos personalizados**.
1. Escolha o aplicativo. O nome do aplicativo começa com `app-stack-name-first-six-characters-stack-id`. O Application Manager abre a guia **Visão geral**.
1. Escolha **Recursos** e, em seguida, escolha o runbook de configuração de automação.
1. Escolha **Executar automação**.
1. Para o parâmetro de entrada do Automation runbook `applyChefRecipesPropertiesParameter`, consulte o parâmetro correto do Systems Manager. O nome do parâmetro Systems Manager segue o formato`/ApplyChefRecipes-Preset/OpsWorks-stack-name-OpsWorks-layer-name-first-six-characters-stack-id/event`, onde o valor para *event* está `Configure``Deploy`, ou `Undeploy` dependendo das receitas que você deseja executar.
1. Escolha a instância IDs em que você deseja executar as receitas e escolha **Executar**.
## Posso alterar quais sub-redes meu grupo do Auto Scaling abrange?
Por padrão, o grupo Auto Scaling abrange todas as sub-redes em sua VPC de pilha. OpsWorks Para atualizar as sub-redes a serem abrangidas, siga as seguintes etapas:
1. Escolha `Link to the template` mostrada na saída do script. Se você fechou seu terminal, siga estas etapas para acessar o modelo.
1. Abra o console do Systems Manager em [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. No painel de navegação, escolha **Application Manager**.
1. Escolha **CloudFormation pilhas** e, em seguida, escolha **Biblioteca de modelos**.
1. Escolha **Minha propriedade** e localize seu modelo.
1. Em **Ações**, escolha **Provisionar pilha**.
1. Confirme que você deseja usar o modelo padrão. Escolha **Selecionar uma pilha existente** e, em seguida, escolha a CloudFormation pilha a ser atualizada.
**nota**
Se você executou o script com o `--provision-application` parâmetro definido como`FALSE`, deverá criar uma nova CloudFormation pilha.
1. Para o `SubnetIDs` parâmetro, forneça uma lista separada por vírgulas da sub-rede IDs que você deseja que seu grupo de Auto Scaling abranja.
1. Escolha **Avançar** até ver a página **Revisar e provisionar**.
1. Na página **Revisar e provisionar**, escolha **Eu reconheço que CloudFormation pode criar recursos do IAM com nomes personalizados** e **entendo que alterações no modelo selecionado podem CloudFormation fazer com que os AWS recursos existentes sejam atualizados ou removidos**.
1. Selecione **Provision stack** (Provisionar pilha).
# Solução de problemas
Esta seção contém alguns problemas comuns, e soluções sugeridas para esses problemas.
**Topics**
+ [A entidade principal fornecida não é valida](#w2ab1c14c43c21b7)
+ [Não é possível excluir a CloudFormation pilha quando as instâncias protegidas por grupos do Auto Scaling estão habilitadas](#w2ab1c14c43c21b9)
+ [Erro de acesso negado ao fornecer bucket e prefixo S3 existentes](#w2ab1c14c43c21c11)
## A entidade principal fornecida não é valida
**Problema:** você recebe uma mensagem de erro informando que a entidade principal fornecida não é válida.
**Causa:** isso ocorre porque o grupo do Auto Scaling não tem um perfil de serviço.
**Solução:** crie um grupo do Auto Scaling na região em que o erro ocorreu. Criar um grupo do Auto Scaling cria o perfil vinculado ao serviço necessário para sua política de rescisão personalizada.
## Não é possível excluir a CloudFormation pilha quando as instâncias protegidas por grupos do Auto Scaling estão habilitadas
**Problema:** o `--enable-instance-protection` parâmetro está definido como `TRUE` e algumas das EC2 instâncias do seu grupo do Auto Scaling são protegidas com a chave de `protected_instance` tag, o que impede que sua CloudFormation pilha seja completamente excluída.
**Causa:** as EC2 instâncias têm uma chave de `protected_instance` tag que as protege de eventos de encerramento.
**Solução:** remova a chave de `protected_instance` tag das EC2 instâncias. Isso permite que o grupo do Auto Scaling reduza a escala verticalmente. Depois que o grupo Auto Scaling for reduzido, você poderá excluir a CloudFormation pilha.
## Erro de acesso negado ao fornecer bucket e prefixo S3 existentes
**Problema:** você recebe um erro `AccessDenied` ao fornecer um bucket e um prefixo do S3 existentes.
**Causa:** a política de bucket do S3 não fornece as permissões necessárias para entregar os logs do balanceador de carga ao bucket.
**Solução:** atualize a política de bucket do S3 para permitir que o script entregue os registros de acesso do balanceador de carga ao bucket. Para obter mais informações sobre como atualizar a política de bucket, consulte [Habilitar registros de acesso para seu Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/enable-access-logging.html) no *guia do usuário do Elastic Load Balancing: Application Load Balancers*.