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á.
AWS Config Regras personalizadas
AWS Config Regras personalizadas são regras que você cria do zero. Há duas maneiras de criar regras AWS Config personalizadas: com as funções Lambda (Guia do AWS Lambda desenvolvedor) e com o Guard (Guard GitHub Repository
AWS Config as regras personalizadas criadas com o Lambda são chamadas de Regras AWS Config Lambda AWS Config Personalizadas e as regras personalizadas criadas com o Guard são chamadas AWS Config de Regras de Política Personalizadas.
AWS Config Regras de política personalizadas
As regras escritas usando o Guard podem ser criadas no AWS Config console ou usando as APIs de AWS Config regras. AWS Config As regras de políticas personalizadas permitem que você crie regras AWS Config personalizadas sem precisar usar Java ou Python para desenvolver funções do Lambda e gerenciar suas regras personalizadas. AWS Config As regras de política personalizada são iniciadas por alterações de configuração. Para obter mais informações sobre o Guard, consulte o GitHubRepositório do Guard
AWS Config Regras personalizadas do Lambda
As regras personalizadas do Lambda oferecem a opção de usar Java ou Python para criar uma função do Lambda para uma regra personalizada. AWS Config Uma função Lambda é um código personalizado para o qual você faz o AWS Lambda upload e é invocado por eventos que são publicados nela por uma fonte de eventos. Se a função Lambda estiver associada a uma AWS Config regra, ela será AWS Config invocada quando a regra for iniciada. Em seguida, a função Lambda avalia as informações de configuração enviadas por AWS Config e retorna os resultados da avaliação. Para mais informações sobre as funções do Lambda, consulte Origens de eventos e funções no Guia do desenvolvedor do AWS Lambda .
Considerações sobre custos
Para obter detalhes sobre os custos associados ao registro de recursos, consulte AWS Config preços
Recomendação: adicione lógica para lidar com a avaliação de recursos excluídos para regras lambda personalizadas
Ao criar regras lambda AWS Config personalizadas, é altamente recomendável que você adicione lógica para lidar com a avaliação dos recursos excluídos.
Quando os resultados da avaliação forem marcados como NOT_APPLICABLE, eles serão marcados para exclusão e limpos. Se NÃO estiverem marcados como NOT_APPLICABLE, os resultados da avaliação permanecerão inalterados até que a regra seja excluída, o que pode causar um aumento inesperado na criação de itens de configuração (CIs) para o AWS::Config::ResourceCompliance após a exclusão da regra.
Para obter informações sobre como definir regras lambda AWS Config personalizadas para retornar NOT_APPLICABLE para recursos excluídos, consulte Gerenciamento de recursos excluídos com regras lambda AWS Config personalizadas.
Recomendação: forneça os recursos no escopo das regras lambda personalizadas
AWS Config As regras personalizadas do Lambda podem causar um grande número de invocações de funções do Lambda se a regra não tiver como escopo um ou mais tipos de recursos. Para evitar o aumento da atividade associada à sua conta, é altamente recomendável fornecer recursos no escopo de suas regras personalizadas do Lambda. Se nenhum tipo de recurso for selecionado, a regra invocará a função do Lambda para todos os recursos na conta.
Recomendação: pare de registrar a conformidade dos recursos antes de excluir as regras
É altamente recomendável que você interrompa a gravação do tipo de AWS::Config::ResourceCompliance recurso antes de excluir as regras da sua conta. A exclusão de regras cria CIs AWS::Config::ResourceCompliance e pode afetar os custos do gravador AWS Config de configuração. Se você estiver excluindo regras que avaliam um grande número de tipos de recursos, isso pode levar a um aumento no número de ICs registrados.
Prática recomendada:
Pare de gravar
AWS::Config::ResourceComplianceExcluir regra (s)
Ativar a gravação para
AWS::Config::ResourceCompliance
Tipos de trigger
Depois de adicionar uma regra à sua conta, AWS Config compara seus recursos com as condições da regra. Após essa avaliação inicial, AWS Config continua executando avaliações cada vez que uma é acionada. Os gatilhos de avaliação são definidos como parte da regra e podem incluir os seguintes tipos.
| Tipo de gatilho | Descrição |
|---|---|
| Alterações de configuração | AWS Config executa avaliações para a regra quando há um recurso que corresponde ao escopo da regra e há uma alteração na configuração do recurso. A avaliação é executada após o AWS Config envio de uma notificação de alteração do item de configuração. Você escolhe quais recursos acionam a avaliação, definindo o escopo da regra. O escopo pode incluir o seguinte:
AWS Config executa a avaliação quando detecta uma alteração em um recurso que corresponda ao escopo da regra. Você pode usar o escopo para restringir quais recursos iniciam as avaliações. |
| Periódico | AWS Config executa avaliações para a regra na frequência que você escolher; por exemplo, a cada 24 horas. |
| Híbrida | Algumas regras têm alterações na configuração e gatilhos periódicos. Para essas regras, AWS Config avalia seus recursos quando detecta uma alteração na configuração e também na frequência que você especifica. |
Modos de avaliação
Há dois modos de avaliação das AWS Config regras.
| Modo de avaliação | Descrição |
|---|---|
| Proativo | Use a avaliação proativa para avaliar os recursos antes de serem implantados. Isso permite avaliar se um conjunto de propriedades de recursos, se usado para definir um AWS recurso, seria COMPATÍVEL ou NÃO COMPATÍVEL, considerando o conjunto de regras proativas que você tem em sua conta na sua região. Para obter mais informações, consulte Modos de avaliação. Para obter uma lista de regras gerenciadas que oferecem suporte à avaliação proativa, consulte Lista de regras AWS Config gerenciadas por modo de avaliação. |
| Detecção | Use a avaliação de detecção para avaliar os recursos que já foram implantados. Isso permite avaliar as definições de configuração de seus recursos existentes. |
nota
As regras proativas não corrigem os recursos marcados como NON_COMPLIANT nem impedem que eles sejam implantados.
Tópicos
