Conceitos da centralização de dados Configurando a centralização de logs Monitoramento e solução de problemas de centralização

Cross-account Centralização de registros entre regiões

A centralização de dados do Amazon CloudWatch Logs funciona com AWS Organizations a coleta de dados de log de várias contas de membros em um repositório de dados usando regras de centralização entre contas e regiões. Você define as regras que replicam automaticamente os dados de logs de várias contas e Regiões da AWS em uma conta centralizada em sua organização. Esse recurso simplifica a consolidação de registros para melhorar o monitoramento, a análise e a conformidade centralizados em toda a AWS sua infraestrutura.

CloudWatch A centralização de dados de registros oferece flexibilidade de configuração para atender aos requisitos operacionais e de segurança, como a capacidade de configurar uma região de backup durante a configuração da regra na conta de destino para garantir maior resiliência. Além disso, você tem controle total sobre o comportamento de criptografia de grupos de registros copiados das contas de origem para lidar com dados originalmente criptografados com chaves KMS gerenciadas pelo cliente.

nota

O recurso de centralização de CloudWatch registros processa somente novos dados de registro que chegam às contas de origem após a criação da regra de centralização. Os dados históricos de log (logs que existiam antes da criação da regra) não são centralizados.

Conceitos da centralização de dados

Antes de começar a usar a centralização de dados do CloudWatch Logs, familiarize-se com os seguintes conceitos:

Regra de centralização

Uma configuração que define como os dados de log das contas e regiões de origem são replicados em uma conta e região de destino. As regras especificam os critérios de origem e as configurações de destino.

Conta de origem

A AWS conta na qual os dados de registro se originam. Os eventos de logs das contas de origem são replicados para a conta de destino com base nas regras de centralização que você define.

Conta de destino

A AWS conta de destino na qual os dados de registro replicados são armazenados. Essa conta serve como local centralizado para análise e monitoramento de logs.

Região de backup

Uma região secundária opcional na conta de destino na qual os dados de log podem ser replicados para obter maior resiliência e no caso de recuperação de desastres.

Propagação de tags

Um recurso opcional que propaga tags de recursos dos grupos de registros de origem para os grupos de registros de destino correspondentes. A propagação de tags usa uma função do IAM gerenciada pelo cliente na conta de destino para adicionar, atualizar e remover tags nos grupos de registros de destino. Você configura a propagação de tags adicionando um TagPropagationConfiguration bloco à configuração de destino da regra de centralização.

Criptografia em CloudWatch registros

Os dados do grupo de registros são sempre criptografados em CloudWatch Registros. Por padrão, o CloudWatch Logs usa criptografia do lado do servidor com o Galois/Counter Modo Padrão de Criptografia Avançada de 256 bits (AES-GCM) para criptografar dados de log em repouso. Como alternativa, você pode usar o Serviço de Gerenciamento de AWS Chaves para essa criptografia. Para obter mais informações, consulte a documentação sobre criptografia de CloudWatch registros.

Como a criptografia funciona durante a centralização: a centralização de CloudWatch registros copia ativamente os dados de registro no momento da ingestão das contas de origem para as contas de destino. Durante esse processo, seus dados permanecem criptografados em trânsito usando uma chave AWS de serviço própria. Os dados em repouso nos grupos de log de origem e de destino são criptografados usando o método de criptografia escolhido (chaves KMS gerenciadas ou de AWS propriedade do cliente). Se você estiver usando a chave KMS gerenciada pelo cliente em seus grupos de registros de destino, adicione a tag LogsManaged = true à chave kms para que o serviço de centralização possa acessá-la.
Quando as permissões do KMS são necessárias:
- Se você estiver usando chaves KMS gerenciadas pelo cliente em suas contas de origem, o CloudWatch Logs exigirá permissões de KMS nos seguintes cenários de exemplo:
  - Gerenciamento de taxa de transferência: quando os limites de taxa de transferência de centralização são atingidos, os dados de registro são temporariamente armazenados criptografados com sua chave KMS gerenciada pelo cliente até que a largura de banda fique disponível.
  - Proteção e redação de dados: quando os grupos de registros de origem têm políticas de proteção de dados ativadas, CloudWatch os registros exigem permissões de descriptografia para acessar dados de registro brutos e centralizá-los.

Importante

As regras de centralização são gerenciadas pela conta de gerenciamento da AWS organização ou pelo administrador delegado. Para excluir da centralização grupos de KMS-encrypted registros gerenciados pelo cliente, defina as configurações da regra como “Não centralizar grupos de registros criptografados com chave AWS KMS”.

Configurando a centralização de logs

Para configurar a centralização de CloudWatch registros, você precisa configurar regras de centralização que definam como os dados de registro fluem dos grupos de registro nas contas de origem para os grupos de registro na sua conta de destino.

Depois que a regra de centralização estiver ativada e os eventos de log estiverem sendo replicados na conta de destino, você poderá criar filtros de métrica, de assinatura e de conta em grupos de logs centralizados com recursos aprimorados de filtragem. Esses filtros podem direcionar eventos de logs de contas e regiões de origem específicas e podem emitir informações da conta de origem e da região como dimensões métricas. Para obter mais informações, consulte Criar métricas de eventos de log usando filtros.

Pré-requisitos

AWS Organizations devem ser configuradas e as contas de origem e de destino devem pertencer à organização.
O acesso confiável deve estar habilitado para CloudWatch a conta de gerenciamento e a conta de destino, portanto, forneça acesso aos dados de registro.

nota
É recomendável habilitar o acesso confiável pelo console, o que cria automaticamente o perfil vinculado a serviços (SLR). Se o acesso confiável for habilitado por meio de outros métodos, a função vinculada ao serviço precisará ser criada separadamente.

Pré-requisitos de propagação de tags

Para ativar a propagação de tags, você deve concluir a seguinte configuração adicional:

Crie uma função do IAM gerenciada pelo cliente

Você deve criar uma função do IAM gerenciada pelo cliente na conta de destino com a seguinte configuração:

Política de confiança

A política de confiança da função deve permitir que a função vinculada ao serviço de centralização a assuma. O exemplo de política de confiança a seguir concede à função AWSServiceRoleForObservabilityAdmin_LogsCentralization vinculada ao serviço permissão para assumir a função de destino. <destination-account-id>Substitua pelo ID da sua conta de destino e <organization-id> pelo seu AWS Organizations ID.


{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "AWS": "arn:aws:iam::<destination-account-id>:role/aws-service-role/logs-centralization.observabilityadmin.amazonaws.com/AWSServiceRoleForObservabilityAdmin_LogsCentralization"
    },
    "Action": "sts:AssumeRole",
    "Condition": {
      "StringEquals": {
        "sts:ExternalId": "<organization-id>"
      }
    }
  }]
}

Política de permissões

A política de permissões da função deve conceder operações de tag nos grupos de registros de destino. O exemplo a seguir concede as permissões mínimas necessárias. <destination-account-id>Substitua pelo seu valor. Você pode Resource ampliar o escopo para padrões específicos de ARN de grupos de registros.


{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": [
      "logs:ListTagsForResource",
      "logs:TagResource",
      "logs:UntagResource"
    ],
    "Resource": "arn:aws:logs:*:<destination-account-id>:log-group:*"
  }]
}

Conceder a iam: PassRole permissão

Você deve ter iam:PassRole permissão na função de destino, com escopo definido para o serviço de centralização por meio da chave de iam:PassedToService condição. O exemplo a seguir concede permissão para passar a função. Substitua <destination-account-id> e <your-tag-role-name> pelos seus valores.

nota

Essa declaração se aplica à sua política de identidade (a chamada principal CreateCentralizationRuleForOrganization ouUpdateCentralizationRuleForOrganization), não à função de destino em si.


{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "iam:PassRole",
    "Resource": "arn:aws:iam::<destination-account-id>:role/<your-tag-role-name>",
    "Condition": {
      "StringEquals": {
        "iam:PassedToService": "logs-centralization.observabilityadmin.amazonaws.com"
      }
    }
  }]
}

Personalizando nomes de grupos de registros de destino

Ao criar uma regra de centralização, você pode personalizar como os nomes dos grupos de registros de destino são estruturados usando atributos. Esses atributos são automaticamente substituídos por valores reais quando grupos de registros são criados, permitindo que você organize os registros hierarquicamente na sua conta de destino. Por padrão, somente o ${source.logGroup} atributo é usado, que mescla todos os grupos de registros com o mesmo nome na conta de destino. Se uma variável não puder ser resolvida, ela herdará o valor de sua variável principal na hierarquia.

Atributos disponíveis

Você pode usar os seguintes atributos em seu padrão de nome de grupo de registros de destino:

Atributos do nome do grupo de registros de destino
Atributo	Description
`${source.accountId}`	O ID da AWS conta em que o registro se originou.
`${source.region}`	O Região da AWS local de origem do registro.
`${source.logGroup}`	O nome original do grupo de registros da conta de origem.
`${source.org.id}`	Seu AWS Organizations ID da conta de origem.
`${source.org.ouId}`	O ID da unidade organizacional da conta de origem
`${source.org.rootId}`	O ID raiz da organização
`${source.org.path}`	O caminho organizacional completo da conta até a raiz

Exemplos

Preserve a estrutura original do grupo de registros

Padrão: /centralized/${source.accountId}${source.logGroup}

Result: /centralized/123456789012/aws/lambda/my-function

Organize por conta e região

Padrão: /centralized/${source.accountId}/${source.region}

Result: /centralized/123456789012/us-east-1

Organizar por estrutura organizacional

Padrão: /logs/${source.org.id}/${source.org.ouId}/${source.accountId}

Result: /logs/o-abc123/ou-xyz-12345678/123456789012

Estrutura plana simples

Padrão: /centralized-logs

Result: /centralized-logs

Práticas recomendadas

Inclua o ID da conta de origem para identificar facilmente de quais registros da conta vieram.
Inclua a região de origem se você estiver centralizando em várias regiões.
Estruture os nomes dos grupos de registros de destino com menos de 512 caracteres. CloudWatch Os registros impõem um tamanho máximo de nome de grupo de registros de 512 caracteres.
Se você habilitar a propagação de tags, o padrão deverá conter todos os três atributos: ${source.logGroup}${source.accountId}, e. ${source.region} Isso garante que cada grupo de registros de origem seja mapeado para um grupo de registros de destino exclusivo.

Criação de uma regra de centralização

Use o procedimento a seguir para criar uma regra de centralização que replica os dados de log das contas de origem para sua conta de destino.

Para criar uma regra de centralização

Navegue até o CloudWatch console na conta de gerenciamento ou administrador delegado da organização.
Escolha Configurações.
Acesse a guia Organização.
Escolha Configurar regra.
Especifique os detalhes da fonte definindo os seguintes campos e, em seguida, escolha Avançar:
1. Nome da regra de centralização: insira um nome exclusivo para a regra de centralização.
2. Contas de origem: defina os critérios de seleção da origem para escolher contas a partir das quais os dados de telemetria serão centralizados. Os critérios de seleção podem incluir:
  - Uma ista das contas de membros da organização
  - Uma lista de unidades organizacionais na organização
  - Toda a organização
  Você pode fornecer os critérios de seleção de dois modos:
  - Builder: uma experiência baseada em cliques para gerar os critérios de seleção da origem
  - Editor: uma caixa de texto de formato livre para fornecer os critérios de seleção da origem
  Sintaxe suportada para critérios de seleção de origem:
  - Teclas suportadas: OrganizationId | OrganizationUnitId | AccountId | *
  - Operadores compatíveis: = | IN | OR
3. Regiões de origem: selecione uma lista de regiões onde procurar os dados de telemetria a serem centralizados.
Especifique os detalhes do destino definindo os seguintes campos e, em seguida, escolha Avançar:
1. Conta de destino: selecione uma conta na organização que atue como destino central para os dados de telemetria.
2. Região de destino: selecione uma região primária que armazene uma cópia dos dados de telemetria centralizada.
3. Região de backup: opcionalmente, selecione uma região que armazenará uma segunda cópia dos dados de telemetria centralizados.
Especifique os dados de telemetria definindo os seguintes campos e, em seguida, escolha Avançar:
1. Grupos de logs: escolha uma das seguintes opções:
  - Todos os grupos de logs: centralize os logs de todos os grupos de logs nas contas de origem.
  - Grupo de registros de filtros: centralize os registros de um subconjunto de grupos de registros nas contas de origem, atendendo aos critérios de seleção. Você pode fornecer os critérios de seleção de dois modos:
    Builder: uma experiência baseada em escolhas para gerar os critérios de seleção
    
    Editor: uma caixa de texto de formato livre para fornecer os critérios de seleção
    Há dois critérios de seleção que você pode usar para filtrar registros:
    Critérios de seleção de grupos de registros: os critérios de seleção que especificam quais grupos de registros de origem devem ser centralizados.
    
    Teclas suportadas: LogGroupName | *
    
    Operadores compatíveis: = | != | IN | NOT IN | AND | OR | LIKE | NOT LIKE
    
    Critérios de seleção da fonte de dados: os critérios de seleção que especificam quais fontes de dados devem ser centralizadas.
    
    Teclas suportadas: DataSourceName | DataSourceType
    
    Operadores compatíveis: = | != | IN | NOT IN | AND | OR | LIKE | NOT LIKE
    Quando os critérios de seleção do grupo de registros e os critérios de seleção da fonte de dados são especificados, um evento de log deve corresponder aos dois critérios para ser centralizado.
2. Grupo de logs criptografados do KMS
  
  Importante
  CloudWatch as regras de centralização não entregarão os registros da conta de origem aos grupos de registros de destino se a chave KMS fornecida na regra de centralização não permitir que CloudWatch os registros a usem. Se você estiver usando a chave KMS gerenciada pelo cliente em seus grupos de registros de destino, adicione a tag LogsManaged = true à chave kms. Para obter mais informações, consulte Etapa 2: definir permissões na chave do KMS.
  
  Escolha uma das seguintes opções:
  - Centralize grupos de registros de origem criptografados com chaves KMS gerenciadas pelo cliente usando uma chave KMS gerenciada pelo cliente específica de destino: centralize os eventos de registro dos grupos de registro de origem criptografados com chaves KMS gerenciadas pelo cliente em grupos de registro de destino criptografados com uma chave KMS gerenciada pelo cliente na conta de destino.
    
    Quando esta configuração é selecionada, você também deve definir o seguinte:
    ARN da chave de criptografia de destino: ARN da chave KMS gerenciada pelo cliente na conta de destino e na região de destino principal, a ser associada aos grupos de registros de destino recém-criados.
    
    ARN da chave de criptografia de destino do backup (se a região de backup estiver selecionada): ARN da chave KMS gerenciada pelo cliente na conta de destino e na região de destino do backup, a ser associada aos grupos de registros de destino recém-criados.
    
    Pule a centralização para grupos de registros de destino não criptografados (opcional): se um grupo de registros já existir sem uma chave KMS gerenciada pelo cliente, CloudWatch não é possível atualizar sua criptografia. Escolha essa opção para ignorar a centralização de eventos de log de grupos de log de origem criptografados com chaves KMS gerenciadas pelo cliente para grupos de log de destino que não estão associados a uma chave KMS gerenciada pelo cliente.
  - Centralize grupos de log criptografados com chaves KMS gerenciadas pelo cliente na conta de destino com chave KMS AWS própria: centralize eventos de log de grupos de log de origem criptografados com chaves KMS gerenciadas pelo cliente em grupos de log de destino recém-criados criptografados usando uma chave KMS própria. AWS
  - Não centralize grupos de log criptografados com chaves KMS gerenciadas pelo cliente: ignore a centralização de eventos de log de grupos de log de origem criptografados com chaves KMS gerenciadas pelo cliente.
Revise a regra de centralização, opcionalmente, faça edições de última hora e escolha Criar política de centralização.

Modificando uma regra de centralização

Use o procedimento a seguir para modificar uma regra de centralização existente.

Para modificar uma regra de centralização

Navegue até o CloudWatch console na conta de gerenciamento ou administrador delegado da organização.
Escolha Configurações.
Acesse a guia Organização.
Escolha Gerenciar regras.
Selecione a regra a ser atualizada e escolha Editar.
Atualize a configuração da regra conforme necessário, escolhendo Avançar para prosseguir com cada etapa.
Na Etapa 4, Revisar e configurar, escolha Atualizar política de centralização.

Visualizar uma regra de centralização

Use o procedimento a seguir para exibir detalhes de uma regra de centralização existente.

Para visualizar uma regra de centralização

Navegue até o CloudWatch console na conta de gerenciamento ou administrador delegado da organização.
Escolha Configurações.
Acesse a guia Organização.
Escolha Gerenciar regras.
Veja uma lista de todas as regras de centralização existentes e escolha um nome de regra específico para ver seus detalhes.

Excluindo uma regra de centralização

Use o procedimento a seguir para excluir uma regra de centralização existente.

Para excluir uma regra de centralização

Navegue até o CloudWatch console na conta de gerenciamento ou administrador delegado da organização.
Escolha Configurações.
Acesse a guia Organização.
Escolha Gerenciar regras.
Selecione a regra para excluir e escolha Excluir.
Confirme a exclusão e escolha Excluir.

Monitoramento e solução de problemas de centralização

Você pode monitorar o status e o desempenho de suas regras de centralização usando CloudWatch métricas, o console do CloudWatch Logs e AWS CloudTrail os registros. Isso ajuda você a garantir que os dados de log sejam replicados com sucesso e a identificar quaisquer problemas com sua configuração de centralização.

CloudWatch O Logs fornece:

Integridade da regra por regra de centralização
1. Escolha Configurações.
2. Acesse a guia Organização.
3. Escolha Gerenciar regras.
Registra chamadas de API com AWS CloudTrail
CloudWatch também publica métricas para centralização, incluindo eventos de log replicados, erros e limitação. Para obter mais informações sobre essas métricas e suas dimensões, consulteMétricas e dimensões de centralização.

Status de integridade da regra de centralização

Cada regra de centralização tem um status de integridade que indica se ela está operando corretamente. Você pode verificar a integridade das regras por meio do console ou programaticamente com a API.

Os status de integridade das regras incluem:

HEALTHY: a regra está operando normalmente e replicando os dados de log conforme configurado
UNHEALTHY: a regra encontrou problemas e pode não estar replicando os dados corretamente
PROVISIONING: a centralização da organização está em processo de configuração.

Quando uma regra é marcada como NÃO ÍNTEGRA, o campo FailureReason fornece detalhes sobre o problema específico que precisa ser resolvido.

Status de integridade da propagação de tags

A propagação de tags tem seu próprio status de integridade (TagPropagationStatus) que é independente do geral RuleHealth para entrega de registros. Se você configurar incorretamente a função de destino, a integridade geral da regra não será afetada — somente a propagação de tags será exibida como insalubre.

Healthy: A tentativa mais recente de propagação de tags foi bem-sucedida.
Unhealthy: A tentativa mais recente de propagação de tags falhou. Verifique o TagPropagationFailureReason campo para obter detalhes. Consulte a seção de solução de problemas abaixo para ver as etapas de correção.

Monitoramento de chamadas de API de centralização com AWS CloudTrail

AWS CloudTrail registra chamadas de API feitas para o serviço de centralização, permitindo que você acompanhe alterações de configuração e solucione problemas em contas que são membros da sua. AWS Organizations

CloudTrail Os principais eventos para centralização incluem:

CreateCentralizationRuleForOrganization: quando uma nova regra de centralização é criada
UpdateCentralizationRuleForOrganization: quando uma regra existente é modificada
DeleteCentralizationRuleForOrganization: quando uma regra é excluída
GetCentralizationRuleForOrganization: quando os detalhes da regra são recuperados
ListCentralizationRulesForOrganization: quando as regras são listadas

Você pode usar CloudTrail registros para auditar alterações na configuração de centralização e correlacioná-las com problemas de desempenho ou falhas de replicação.

Recomendações de monitoramento

Para garantir que a centralização esteja funcionando corretamente, recomendamos configurar CloudWatch alarmes nas principais métricas de centralização que vendemos à Metrics. CloudWatch Esse monitoramento proativo ajuda você a detectar problemas precocemente e a manter uma centralização confiável de registros em toda a organização.

As principais métricas a serem monitoradas incluem:

IncomingCopiedBytes: monitore o volume de dados de registro que estão sendo replicados com sucesso em sua conta de destino. Uma queda repentina ou a ausência dessa métrica pode indicar problemas de centralização.
CentralizationError: configure alarmes para qualquer erro no processo de centralização para identificar e resolver problemas rapidamente.
CentralizationThrottled: monitore os eventos de limitação que podem afetar o desempenho da replicação de registros.

Para obter uma lista completa das métricas de centralização disponíveis e suas dimensões, consulteMétricas e dimensões de centralização.

Se os registros não estiverem sendo centralizados conforme o esperado, analise os seguintes cenários comuns que podem impedir a centralização de registros.

Dados históricos de registro

Permissões da chave KMS

As regras de centralização não entregarão os registros da conta de origem aos grupos de registros de destino se a chave KMS fornecida na regra de centralização não permitir que CloudWatch os registros a usem. Certifique-se de que a política de chaves do KMS conceda as permissões necessárias aos CloudWatch registros. Para obter mais informações, consulte Etapa 2: definir permissões na chave do KMS.

Configuração de chave KMS gerenciada pelo cliente

Se você selecionou Não centralizar grupos de log criptografados com a chave KMS gerenciada pelo cliente durante a criação da regra, os eventos de log dos grupos de log de origem criptografados com a chave KMS gerenciada pelo cliente serão ignorados e não centralizados.

Incompatibilidade de criptografia de destino

Se o grupo de registros de destino já existir com uma configuração de criptografia KMS diferente da especificada pela regra de centralização e a resolução de conflitos estiver definida como SKIP, os registros serão descartados e um DestinationEncryptionMismatch erro será emitido. Por exemplo, isso ocorre quando o destino tem criptografia padrão, mas a regra especifica uma chave KMS gerenciada pelo cliente.

Acesso confiável não ativado

O acesso confiável deve estar ativado para CloudWatch que a conta de gerenciamento e a conta de destino forneçam acesso aos dados de registro. AWS Organizations

Critérios de seleção da fonte

Verifique se os critérios de seleção de origem da regra de centralização estão configurados corretamente:

Contas e regiões: certifique-se de que as contas de origem e as regiões de origem dos registros estejam incluídas na regra. Grupos de registros de contas ou regiões não especificadas na regra não serão centralizados.
Filtros de grupos de registros: se você configurou filtros de grupos de registros, somente grupos de registros que correspondam aos critérios especificados serão centralizados. Verifique se seus critérios de seleção de grupos de registros incluem os grupos de registros que você espera centralizar.
Associação à organização: as contas de origem e de destino devem pertencer à mesma AWS Organizations organização. Contas fora da organização não podem participar da centralização.

Limite de cota do grupo de registros atingido

Se a conta de destino atingir o limite de cota do grupo de registros, novos grupos de registros não poderão ser criados para centralização. Verifique se a conta de destino tem cota suficiente para acomodar grupos de registros centralizados de todas as contas de origem. É possível solicitar um aumento de cota, se necessário.

Limite de tamanho do nome do fluxo de log excedido

Os nomes dos fluxos de log têm restrições de tamanho máximo. Quando a centralização replica fluxos de log para a conta de destino, um sufixo é adicionado ao nome do stream de log. Se o nome do fluxo de registros resultante exceder o tamanho máximo permitido, os registros serão descartados e um InvalidLogStream erro será emitido na conta do cliente.

Estado de saúde da regra

Verifique o status de integridade da regra de centralização no console ou usando a GetCentralizationRuleForOrganization API. Se a regra estiver marcada como NÃO SAUDÁVEL, revise o FailureReason campo para obter detalhes específicos sobre o problema.

Status de integridade da propagação de tags

Se TagPropagationStatus aparecerUnhealthy, verifique o TagPropagationFailureReason campo:

RoleNotAssumable: o serviço não pode assumir a função de destino. Verifique se a política de confiança da função permite que a função vinculada ao serviço de centralização a assuma e se ela sts:ExternalId corresponde à ID da sua organização.
RoleLacksPermissions: A função foi assumida, mas a chamada da API de tags foi negada. Garanta que a política de permissões da função conceda logs:ListTagsForResourcelogs:TagResource, e logs:UntagResource nos grupos de registros de destino.

Para diagnosticar problemas de centralização, revise o status de integridade da regra de centralização no console, verifique as CloudWatch métricas em busca de erros e limitação e examine os AWS CloudTrail registros de falhas nas chamadas de API. Para obter mais informações sobre métricas de centralização, consulteMétricas e dimensões de centralização.

Atenção O Javascript está desativado ou não está disponível no seu navegador.

Para usar a documentação da AWS, o Javascript deve estar ativado. Consulte as páginas de Ajuda do navegador para obter instruções.

Convenções do documento

Solução de problemas com o CloudWatch Logs Live Tail

Trabalhar com grupos de logs e fluxos de logs