Solução de problemas de erros de RFC no AMS - Guia do usuário avançado do AMS
Erros de RFC de “gerenciamento”Erros de RFC de “implantação”Validação de RFC versus erros de execuçãoMensagens de erro de RFCComo obter ajuda com um RFC

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á.

Solução de problemas de erros de RFC no AMS

Muitas falhas de RFC de provisionamento do AMS podem ser investigadas por meio da documentação. CloudFormation Consulte Solução de problemas da AWS CloudFormation: Solução de problemas de erros

Sugestões adicionais de solução de problemas são fornecidas nas seções a seguir.

Erros de RFC de “gerenciamento” no AMS

Os tipos de alteração de categoria (CTs) de “Gerenciamento” do AMS permitem que você solicite acesso aos recursos, bem como gerencie os recursos existentes. Esta seção descreve alguns problemas comuns.

Erros de acesso ao RFC

  • Verifique se o nome de usuário e o FQDN especificados na RFC estão corretos e existem no domínio. Para obter ajuda para encontrar seu FQDN, consulte Encontrando seu FQDN.

  • Certifique-se de que a ID da pilha que você especificou para acesso seja uma pilha EC2 relacionada. Pilhas como ELB e Amazon Simple Storage Service (S3) não são candidatas ao acesso. Em vez disso, use sua função de RFCs acesso somente de leitura para acessar esses recursos de pilhas. Para obter ajuda para encontrar uma ID de pilha, consulte Como encontrar uma pilha IDs

  • Verifique se o ID da pilha que você forneceu está correto e pertence à conta relevante.

Para obter ajuda com outras falhas de RFC de acesso, consulte Gerenciamento de acesso.

YouTube Vídeo: Como faço para gerar uma Solicitação de Mudança (RFC) adequadamente para evitar rejeições e falhas?

Erros de agendamento de RFC (manual) CT

A maioria dos tipos de alteração são ExecutionMode =Automatizados, mas alguns são ExecutionMode =Manual e isso afeta como você deve programá-los para evitar falhas no RFC.

Programado RFCs com ExecutionMode =Manual, deve ser configurado para ser executado pelo menos 24 horas no futuro se você estiver usando o console AMS para criar o RFC. Essa ressalva não se aplica à API/CLI do AMS, mas ainda é importante agendar o Manual com RFCs pelo menos 8 horas de antecedência.

O AMS visa responder a uma tomografia computadorizada manual em quatro horas e corresponderá o mais rápido possível, mas pode levar muito mais tempo para que a RFC seja realmente executada.

Usando RFCs com atualização manual CTs

Gerenciamento de rejeição de operações do AMS | Outros | Outros RFCs para atualizações em pilhas, quando há um tipo de alteração de atualização para o tipo de pilha que você deseja atualizar.

Erros de exclusão de pilha de RFC

Falhas de exclusão de pilha por RFC: se você usar o Gerenciamento | Pilhas padrão | Pilha | Excluir CT, verá os eventos detalhados no CloudFormation console da pilha com o nome da pilha AMS. Você pode identificar sua pilha comparando-a com o nome que ela tem no console do AMS. O CloudFormation console fornece mais detalhes sobre as causas da falha.

Antes de excluir uma pilha, você deve considerar como a pilha foi criada. Se você criou a pilha usando um AMS CT e não adicionou nem editou os recursos da pilha, pode esperar excluí-la sem problemas. No entanto, é uma boa ideia remover todos os recursos adicionados manualmente de uma pilha antes de enviar uma RFC de exclusão de pilha contra ela. Por exemplo, se você criar uma pilha usando a pilha completa CT (HA Two Tier), ela incluirá um grupo de segurança -. SG1 Se você então usar o AMS para criar outro grupo de segurança - SG2 e referenciar o novo SG2 no grupo SG1 criado como parte da pilha completa e, em seguida, usar a pilha de exclusão CT para excluir a pilha, ele não SG1 será excluído, pois é referenciado por. SG2

Importante

A exclusão de pilhas pode ter consequências indesejadas e imprevistas. O AMS prefere *não* excluir pilhas ou recursos em nome dos clientes por esse motivo. Observe que o AMS excluirá somente recursos em seu nome (por meio de um tipo de alteração enviado em Gerenciamento | Outro | Outro | Atualizar) que não possam ser excluídos usando o tipo de alteração apropriado e automatizado para excluir. Considerações adicionais:

  • Se os recursos estiverem habilitados para “proteção contra exclusão”, o AMS poderá ajudar a desbloqueá-los se você enviar um tipo de alteração Gerenciamento | Outros | Outros | Atualizar e, depois que a proteção contra exclusão for removida, você poderá usar a CT automatizada para excluir esse recurso.

  • Se houver vários recursos em uma pilha e você quiser excluir somente um subconjunto dos recursos da pilha, use o tipo de alteração CloudFormation Atualizar (consulte Pilha de CloudFormation ingestão: atualização). Você também pode enviar um tipo de alteração de Gerenciamento | Outros | Outros | Atualizar e os engenheiros da AMS podem ajudá-lo a criar o conjunto de alterações, se necessário.

  • Se houver problemas ao usar o CloudFormation Update CT devido a desvios, o AMS pode ajudar se você enviar uma atualização de Gerenciamento | Outro | Outro | Outro | para resolver o desvio (desde que suportado pelo CloudFormation Serviço da AWS) e forneça uma ChangeSet que você possa validar e executar usando a CT, o Management/Custom Stack/Stack From CloudFormation Template/Approve Changeset e o Update automatizados.

O AMS mantém as restrições acima para ajudar a garantir que não haja exclusões inesperadas ou imprevistas de recursos.

Para obter mais informações, consulte Solução de problemas da AWS CloudFormation: falhas na exclusão da pilha.

Erros de DNS de atualização de RFC

Várias atualizações RFCs de uma zona hospedada por DNS podem falhar, algumas sem motivo. Criar várias RFCs ao mesmo tempo para atualizar as zonas hospedadas do DNS (privadas ou públicas) pode fazer RFCs com que algumas falhem porque estão tentando atualizar a mesma pilha ao mesmo tempo. O gerenciamento de alterações do AMS rejeita ou falha os RFCs que não conseguem atualizar uma pilha porque a pilha já está sendo atualizada por outro RFC. O AMS recomenda que você crie uma RFC por vez e espere que a RFC seja bem-sucedida antes de criar uma nova para a mesma pilha.

Erros de entidades do RFC IAM

O AMS provisiona várias funções e perfis padrão do IAM em contas do AMS, projetados para atender às suas necessidades. No entanto, talvez seja necessário solicitar recursos adicionais do IAM ocasionalmente.

O processo de envio da RFCs solicitação de recursos personalizados do IAM segue o fluxo de trabalho padrão do manual RFCs, mas o processo de aprovação também inclui uma análise de segurança para garantir que os controles de segurança apropriados estejam em vigor. Portanto, o processo normalmente leva mais tempo do que outros manuais RFCs. Para reduzir o tempo de ciclo deles RFCs, siga as diretrizes a seguir.

Para obter informações sobre o que queremos dizer com uma revisão do IAM e como ela se relaciona com nossos padrões técnicos e processo de aceitação de riscos, consulteEntenda as análises de segurança da RFC.

Solicitações comuns de recursos do IAM:

  • Se você estiver solicitando uma política referente a um grande aplicativo compatível com a nuvem, como CloudEndure, consulte a CloudEndure política IAM pré-aprovada pelo AMS: Descompacte o arquivo de exemplo do WIGs Cloud Endure Landing Zone e abra o customer_cloud_endure_policy.json

    nota

    Se você quiser uma política mais permissiva, discuta suas necessidades com você CloudArchitect/CSDM e obtenha, se necessário, uma revisão e aprovação de segurança do AMS antes de enviar uma RFC implementando a política.

  • Se você quiser modificar um recurso implantado pelo AMS em sua conta por padrão, recomendamos que você solicite uma cópia modificada desse recurso em vez de alterações na existente.

  • Se você estiver solicitando permissões para um usuário humano (em vez de anexar as permissões ao usuário), anexe as permissões a uma função e, em seguida, conceda ao usuário permissão para assumir essa função. Para obter detalhes sobre como fazer isso, consulte Acesso temporário ao console AMS Advanced.

  • Se você precisar de permissões excepcionais para uma migração temporária ou fluxo de trabalho, forneça uma data de término para essas permissões em sua solicitação.

  • Se você já discutiu o assunto de sua solicitação com sua equipe de segurança, forneça evidências de sua aprovação ao CSDM com o máximo de detalhes possível.

Se o AMS rejeitar uma RFC do IAM, fornecemos um motivo claro para a rejeição. Por exemplo, podemos rejeitar uma solicitação de criação de política do IAM e explicar o que a política é inadequada. Nesse caso, você pode fazer as alterações identificadas e reenviar a solicitação. Se for necessária mais clareza sobre o status de uma solicitação, envie uma solicitação de serviço ou entre em contato com seu CSDM.

A lista a seguir descreve os riscos típicos que o AMS tenta mitigar ao analisarmos seu IAM RFCs. Se sua RFC do IAM tiver algum desses riscos, isso poderá resultar na rejeição da RFC. Nos casos em que você precisa de uma exceção, o AMS solicita a aprovação da sua equipe de segurança. Para buscar essa exceção, coordene com seu CSDM.

nota

O AMS pode, por qualquer motivo, recusar qualquer alteração nos recursos do IAM dentro de uma conta. Em caso de dúvidas sobre qualquer rejeição de RFC, entre em contato com a AMS Operations por meio de uma solicitação de serviço ou entre em contato com seu CSDM.

  • Escalonamento de privilégios, como permissões que permitem que você modifique suas próprias permissões ou modifique as permissões de outros recursos dentro da conta. Exemplos:

    • O uso de iam:PassRole com outro papel mais privilegiado.

    • Permissão para políticas do attach/detach IAM de uma função ou usuário.

    • A modificação das políticas do IAM na conta.

    • A capacidade de fazer chamadas de API no contexto da infraestrutura de gerenciamento.

  • Permissões para modificar recursos ou aplicativos necessários para fornecer serviços de AMS a você. Exemplos:

    • Modificação da infraestrutura do AMS, como bastiões, host de gerenciamento ou infraestrutura EPS.

    • Exclusão do gerenciamento de registros, funções ou fluxos de log do AWS Lambda.

    • A exclusão ou modificação do aplicativo de CloudTrail monitoramento padrão.

    • A modificação do Active Directory (AD) dos Serviços de Diretório.

    • Alarmes de desativação CloudWatch (CW).

    • A modificação dos princípios, políticas e namespaces implantados na conta como parte da landing zone.

  • Implantação de infraestrutura fora das melhores práticas, como permissões que permitem a criação de infraestrutura em um estado que coloca em risco a segurança das informações. Exemplos:

    • A criação de buckets S3 públicos ou não criptografados ou o compartilhamento público de volumes do EBS.

    • O provisionamento de endereços IP públicos.

    • A modificação dos grupos de segurança para permitir amplo acesso.

  • Permissões excessivamente amplas capazes de causar impacto nos aplicativos, como permissões que podem resultar em perda de dados, perda de integridade, configuração inadequada ou interrupções no serviço de sua infraestrutura e dos aplicativos dentro da conta. Exemplos:

    • Desabilitar ou redirecionar o tráfego de rede por meio APIs de like ou. ModifyNetworkInterfaceAttribute UpdateRouteTable

    • A desativação da infraestrutura gerenciada por meio da separação de volumes dos hosts gerenciados.

  • Permissões para serviços que não fazem parte da descrição do serviço do AMS e não são suportadas pelo AMS.

    Os serviços não listados na descrição do serviço AMS não podem ser usados nas contas do AMS. Para solicitar suporte para um recurso ou serviço, entre em contato com seu CSDM.

  • Permissões que não atendem à meta declarada, pois são muito generosas ou muito conservadoras ou são aplicadas aos recursos errados. Exemplos:

    • Uma solicitação de s3:PutObject permissões para um bucket do S3 que tem criptografia KMS obrigatória, sem KMS:Encrypt permissões para a chave relevante.

    • Permissões que dizem respeito a recursos que não existem na conta.

    • IAM RFCs em que a descrição da RFC parece não corresponder à solicitação.

Erros de RFC de “implantação”

Os tipos de alteração de categoria “Implantação” do AMS (CTs) permitem que você solicite que vários recursos suportados pelo AMS sejam adicionados à sua conta.

A maioria dos AMS CTs que criam um recurso é baseada em CloudFormation modelos. Como cliente, você tem acesso somente de leitura a todos os serviços da AWS CloudFormation, inclusive, você pode identificar rapidamente a CloudFormation pilha que representa sua pilha com base na descrição da pilha usando o console. CloudFormation A pilha com falha provavelmente estará em um estado de DELETE_COMPLETE. Depois de identificar a CloudFormation pilha, os eventos mostrarão o recurso específico que falhou na criação e por quê.

Usando a CloudFormation documentação para solucionar problemas

A maioria dos aprovisionamentos do AMS RFCs usa um CloudFormation modelo e essa documentação pode ser útil para solucionar problemas. Veja a documentação desse CloudFormation modelo:

RFC criando erros AMIs

Uma imagem de máquina da Amazon (AMI) é um modelo que contém uma configuração de software (por exemplo, sistema operacional, servidor de aplicação e aplicações). Em uma AMI, você executa uma instância, que é uma cópia da AMI em execução como um servidor virtual na nuvem. AMIs são muito úteis e necessários para criar EC2 instâncias ou grupos de Auto Scaling; no entanto, você deve observar alguns requisitos:

  • A instância que você especifica Ec2InstanceId deve estar em um estado interrompido para que a RFC seja bem-sucedida. Não use instâncias do grupo Auto Scaling (ASG) para esse parâmetro porque o ASG encerrará uma instância parada.

  • Para criar uma Amazon Machine Image (AMI) do AMS, você deve começar com uma instância do AMS. Antes de usar a instância para criar a AMI, você deve prepará-la garantindo que ela seja interrompida e separada de seu domínio. Para obter detalhes, consulte Criar uma imagem de máquina padrão da Amazon usando o Sysprep

  • O nome que você especificar para a nova AMI deve ser exclusivo na conta ou o RFC falhará. Como fazer isso está descrito em AMI | Create e, para obter mais detalhes, consulte AWS AMI Design.

nota

Para obter informações adicionais sobre como se preparar para a criação de AMI, consulte AMI | Create.

RFCs criação EC2s ou ASGs erros

Para EC2 falhas do ASG com tempos limite, o AMS recomenda que você confirme se a AMI usada é personalizada. Se estiver, consulte as etapas de criação da AMI incluídas neste guia (consulte AMI | Criar) para garantir que a AMI tenha sido criada corretamente. Um erro comum ao criar uma AMI personalizada é não seguir as etapas do guia para renomear ou invocar o Sysprep.

RFCs criando erros de RDS

As falhas do Amazon Relational Database Service (RDS) podem ocorrer por vários motivos diferentes, pois você pode usar vários mecanismos diferentes ao criar o RDS, e cada mecanismo tem seus próprios requisitos e limitações. Antes de tentar criar uma pilha do AMS RDS, analise cuidadosamente os valores dos parâmetros do AWS RDS, consulte Criar. DBInstance

Para saber mais sobre o Amazon RDS em geral, incluindo recomendações de tamanho, consulte a documentação do Amazon Relational Database Service.

RFCs criando erros do Amazon S3s

Um erro comum ao criar um bucket de armazenamento S3 é não usar um nome exclusivo para o bucket. Se você enviasse um bucket do S3 Create CT com o mesmo nome de outro enviado anteriormente, ele falharia porque já existiria um bucket do S3 com ele. BucketName Isso seria detalhado no CloudFormation console, onde você verá que o evento stack mostra que o nome do bucket já está em uso.

Validação de RFC versus erros de execução

As falhas de RFC e as mensagens relacionadas diferem nas mensagens de saída na página de detalhes da RFC do console AMS para uma RFC selecionada:

  • Os motivos das falhas de validação estão disponíveis somente no campo Status

  • Os motivos das falhas de execução estão disponíveis nos campos Saída de execução e Status.

Request for change details showing rejected status due to no domain trust found.

Mensagens de erro de RFC

Ao se deparar com o seguinte erro para os tipos de alteração listados (CTs), você pode usar essas soluções para ajudá-lo a encontrar a origem dos problemas e corrigi-los.

{"errorMessage":"An error has occurred during RFC execution. We are investigating the issue.","errorType":"InternalError"}

Se você precisar de mais assistência após consultar as seguintes opções de solução de problemas, entre em contato com o AMS por meio de correspondência RFC ou crie uma solicitação de serviço. Consulte Correspondência e anexo RFC (console) e Criação de uma solicitação de serviço no AMS para obter mais detalhes.

Erros de ingestão de carga de trabalho (WIGS)

nota

As ferramentas de validação para Windows e Linux podem ser baixadas e executadas diretamente em seus servidores locais, bem como em EC2 instâncias na AWS. Eles podem ser encontrados no Guia do Desenvolvedor de Aplicativos Avançados do AMS Migração de cargas de trabalho: Validação de pré-ingestão do Linux e Migração de cargas de trabalho: validação de pré-ingestão do Windows.

  • Verifique se a EC2 instância existe na conta AMS de destino. Por exemplo, se você compartilhou sua AMI de uma conta que não é da AMS com uma conta do AMS, precisará criar uma EC2 instância na sua conta do AMS com a AMI compartilhada antes de enviar uma RFC de ingestão de carga de trabalho.

  • Verifique se os grupos de segurança vinculados à instância têm tráfego de saída permitido. O agente SSM precisa ser capaz de se conectar ao seu endpoint público.

  • Verifique se a instância tem as permissões corretas para se conectar ao agente SSM. Essas permissões vêm com ocustomer-mc-ec2-instance-profile, você pode verificar isso no EC2 console:

    EC2 instance details showing IAM role set to customer-mc-ec2-instance-profile.

EC2 erros de parada de pilha de instâncias

  • Verifique se a instância já está em um estado interrompido ou encerrado.

  • Se a EC2 instância estiver on-line e você ver o InternalError erro, envie uma solicitação de serviço para que o AMS investigue.

  • Observe que você não pode usar o tipo de alteração Management | Advanced stack components | EC2 instance stack | Stop ct-3mvvt2zkyveqj para interromper uma instância de grupo do Auto Scaling (ASG). Se você precisar interromper uma instância do ASG, envie uma solicitação de serviço.

EC2 erros de criação da pilha de instâncias

A InternalError mensagem é de CloudFormation; um motivo do status CREATION_FAILED. Você pode encontrar detalhes sobre a falha da pilha nos eventos da CloudWatch pilha seguindo estas etapas:

  • No console de gerenciamento da AWS, você pode ver uma lista de eventos da pilha enquanto sua pilha está sendo criada, atualizada ou excluída. Nessa lista, encontre o evento de falha e, em seguida, visualize o motivo do status desse evento.

    O motivo do status pode conter uma mensagem de erro da AWS CloudFormation ou de um serviço específico que pode ajudar você a entender o problema.

  • Para obter mais informações sobre a visualização de eventos da pilha, consulte Visualização de dados e recursos do AWS CloudFormation Stack no AWS Management Console.

EC2 erros de restauração do volume da instância

O AMS cria um RFC interno para solução de problemas quando a restauração do volume da EC2 instância falha. Isso é feito porque a restauração do volume da EC2 instância é uma parte importante da recuperação de desastres (DR) e o AMS cria automaticamente essa RFC interna de solução de problemas para você.

Quando a RFC de solução de problemas interna é criada, um banner é exibido fornecendo links para a RFC. Essa RFC interna de solução de problemas fornece mais visibilidade das falhas de RFC e, em vez de enviar uma nova tentativa que RFCs leva aos mesmos erros ou fazer com que você entre em contato manualmente com o AMS em caso de falha, você pode acompanhar suas alterações e saber que a falha está sendo corrigida pelo AMS. Isso também reduz a métrica time-to-recovery (TTR) de sua alteração, pois os operadores do AMS trabalham proativamente na falha de RFC em vez de aguardar sua solicitação.

Como obter ajuda com um RFC

Você pode entrar em contato com a AMS para identificar a causa raiz de sua falha. O horário comercial do AMS é 24 horas por dia, 7 dias por semana, 365 dias por ano.

O AMS oferece vários meios para você pedir ajuda ou fazer solicitações de serviço.

  • Para solicitar informações ou conselhos, acessar um serviço de TI gerenciado pelo AMS ou solicitar um serviço adicional do AMS, use o console do AMS e envie uma solicitação de serviço. Para obter detalhes, consulte Criação de uma solicitação de serviço. Para obter informações gerais sobre solicitações de serviço do AMS, consulte Gerenciamento de solicitações de serviço.

  • Para relatar um problema de desempenho do serviço da AWS ou do AMS que afeta seu ambiente gerenciado, use o console do AMS e envie um relatório de incidentes. Para obter detalhes, consulte Relatar um incidente. Para obter informações gerais sobre o gerenciamento de incidentes do AMS, consulte Resposta a incidentes.

  • Para perguntas específicas sobre como você ou seus recursos ou aplicativos estão trabalhando com o AMS, ou para escalar um incidente, envie um e-mail para um ou mais dos seguintes:

    1. Primeiro, se você não estiver satisfeito com a solicitação de serviço ou com a resposta do relatório de incidentes, envie um e-mail para seu CSDM: ams-csdm@amazon.com

    2. Em seguida, se o escalonamento for necessário, você pode enviar um e-mail para o gerente de operações do AMS (mas seu CSDM provavelmente fará isso): ams-opsmanager@amazon.com

    3. Uma escalada adicional seria para o diretor da AMS: ams-director@amazon.com

    4. Finalmente, você sempre pode entrar em contato com o vice-presidente do AMS: ams-vp@amazon.com