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á.
# Automatizar backups com o Amazon Data Lifecycle Manager
Você pode usar o Amazon Data Lifecycle Manager para automatizar a criação, retenção e exclusão de snapshots do EBS e com suporte do EBS. AMIs Quando você automatiza o gerenciamento de snapshot e AMI, isso ajuda a:
+ Proteger dados valiosos impondo uma programação regular de backup.
+ Crie modelos padronizados AMIs que possam ser atualizados em intervalos regulares.
+ Reter os backups conforme exigido por auditores ou pelas regras de conformidade interna.
+ Reduzir os custos de armazenamento ao excluir backup obsoletos.
+ Criar políticas de backup de recuperação de desastres que fazem backup de dados em regiões ou contas isoladas.
Quando combinado com os recursos de monitoramento da Amazon EventBridge e do Amazon Data Lifecycle Manager AWS CloudTrail, o Amazon Data Lifecycle Manager fornece uma solução de backup completa para instâncias do Amazon EC2 e volumes individuais do EBS sem custo adicional.
**Importante**
O Amazon Data Lifecycle Manager não pode gerenciar snapshots nem AMIs criar por qualquer outro meio.
O Amazon Data Lifecycle Manager não pode automatizar a criação, retenção e exclusão de instâncias armazenadas. AMIs
O Amazon Data Lifecycle Manager é avaliado como uma capacidade de serviço do do Amazon Elastic Block Store (Amazon EBS). Quaisquer [serviços da AWS no escopo de programas de conformidade](https://aws.amazon.com/compliance/services-in-scope/) (FedRAMP, HIPAA BAA, SOC etc.) que listem o Amazon EBS também se aplicam ao Amazon Data Lifecycle Manager.
**Topics**
+ [Cotas](#dlm-quotas)
+ [Como funciona](dlm-elements.md)
+ [Políticas padrão comparadas com políticas personalizadas](policy-differences.md)
+ [Criar políticas padrão](default-policies.md)
+ [Criar política personalizada para snapshots](snapshot-ami-policy.md)
+ [Crie uma política personalizada para AMIs](ami-policy.md)
+ [Automatizar cópias de snapshots entre contas](event-policy.md)
+ [Modificar políticas](modify.md)
+ [Excluir políticas](delete.md)
+ [Controlar o acesso do](dlm-prerequisites.md)
+ [Monitorar políticas](dlm-monitor-lifecycle.md)
+ [Service endpoints](dlm-service-endpoints.md)
+ [Endpoints da VPC de interface](dlm-vpc-endpoints.md)
+ [Solução de problemas](dlm-troubleshooting.md)
## Cotas
Sua AWS conta tem as seguintes cotas relacionadas ao Amazon Data Lifecycle Manager:
| Description | Quota |
| --- | --- |
| Políticas personalizadas de ciclo de vida por região | 100 |
| Políticas padrão para snapshots do EBS por região | 1 |
| Políticas padrão para empresas apoiadas pelo EBS por região AMIs | 1 |
| Tags por recurso | 45 |
# Como o Amazon Data Lifecycle Manager funciona
Veja a seguir os elementos de chaves do Amazon Data Lifecycle Manager.
**Topics**
+ [Políticas](#dlm-policies)
+ [Programações de política](#dlm-lifecycle-schedule)
+ [Tags de recurso de destino](#dlm-tagging-volumes)
+ [Snapshots](#dlm-ebs-snapshots)
+ [Apoiado pelo EBS AMIs](#dlm-ebs-amis)
+ [Tags do Amazon Data Lifecycle Manager](#dlm-tagging-snapshots)
## Políticas
Com o Amazon Data Lifecycle Manager, você cria políticas para definir os requisitos de criação e retenção de backup. Essas políticas geralmente especificam o seguinte:
+ **Tipo de política** — Define o tipo de recursos de backup que a política gerencia (instantâneos ou baseados em EBS AMIs).
+ **Recursos-alvo**: define o tipo dos recursos que são alvo da política (instâncias ou volumes do EBS).
+ **Frequência de criação** — Define com que frequência a política é executada e cria instantâneos ou AMIs.
+ **Limite de retenção** — define por quanto tempo a política retém os instantâneos ou AMIs após a criação.
+ **Ações adicionais**: define as ações adicionais que a política deve realizar, como cópia entre regiões, arquivamento ou marcação de recursos.
O Amazon Data Lifecycle Manager oferece políticas padrão e políticas personalizadas.
**Políticas padrão**
As políticas padrão fazem backup de todos os volumes e instâncias em uma região que não têm backups recentes. Opcionalmente, você pode excluir volumes e instâncias especificando parâmetros de exclusão.
O Amazon Data Lifecycle Manager é compatível com as seguintes políticas padrão:
+ Política padrão para snapshots do EBS: tem como alvo os volumes e automatiza a criação, a retenção e a exclusão de snapshots.
+ Política padrão para instâncias apoiadas pelo EBS AMIs — visa instâncias e automatiza a criação, retenção e cancelamento do registro de instâncias apoiadas pelo EBS. AMIs
Você só pode ter uma política padrão por tipo de recurso em cada conta e região da AWS .
**Políticas personalizadas**
As políticas personalizadas têm como alvo recursos específicos com base nas tags atribuídas a eles e são compatíveis com atributos avançados, como restauração rápida de snapshots, arquivamento de snapshots, cópia entre contas e scripts prévios e posteriores. Uma política personalizada pode incluir até quatro agendas, e cada agenda pode ter sua própria frequência de criação, limite de retenção e configuração avançada de atributos.
O Amazon Data Lifecycle Manager é compatível com as seguintes políticas personalizadas:
+ Política de snapshots do EBS: tem como alvo os volumes ou as instâncias, e automatiza a criação, a retenção e a exclusão dos snapshots do EBS.
+ Política de AMI baseada em EBS — visa instâncias e automatiza a criação, retenção e cancelamento de registro de sistemas baseados em EBS. AMIs
+ Política de evento de cópia entre contas: automatiza ações de cópia entre regiões para os snapshots que são compartilhados com você.
Para obter mais informações, consulte [As políticas padrão comparadas com as políticas personalizadas do Amazon Data Lifecycle Manager](policy-differences.md).
## Agendas da política (*somente políticas personalizadas*)
Os cronogramas de políticas definem quando os instantâneos AMIs são criados pela política. As políticas podem ter até quatro programações — uma obrigatória e até três opcionais.
Adicionar vários agendamentos a uma única política permite criar instantâneos ou AMIs em frequências diferentes usando a mesma política. Por exemplo, é possível criar uma única política que cria snapshots diários, semanais, mensais e anuais. Isso elimina a necessidade de gerenciar várias políticas.
Para cada programação, é possível definir a frequência, configurações de restauração rápida de snapshots (somente políticas de ciclo de vida do snapshot), regras de cópia entre regiões e tags. As tags atribuídas a uma agenda são automaticamente atribuídas aos instantâneos ou AMIs criadas quando a agenda é iniciada. Além disso, o Amazon Data Lifecycle Manager atribui automaticamente uma tag gerada pelo sistema com base na frequência da programação a cada snapshot ou AMI.
Cada agendamento é acionado individualmente com base na frequência. Se vários agendamentos forem iniciados ao mesmo tempo, o Amazon Data Lifecycle Manager criará apenas um snapshot ou uma AMI e aplicará as configurações de retenção do agendamento que tem o período de retenção mais alto. As etiquetas de todos os agendamentos iniciados são aplicadas ao snapshot ou à AMI.
+ (Somente políticas de ciclo de vida de snapshot) Se mais de um dos agendamentos iniciados estiver habilitado para restauração rápida de snapshots, o snapshot será habilitado para restauração rápida de snapshots em todas as zonas de disponibilidade especificadas em todos os agendamentos iniciados. As configurações de retenção mais altas dos agendamentos iniciados são usadas para cada zona de disponibilidade.
+ Se mais de um dos agendamentos iniciados estiver habilitado para cópia entre regiões, o snapshot ou a AMI serão copiados para todas as regiões especificadas em todos os agendamentos iniciados. O período de retenção mais alta dos agendamentos iniciados é aplicado.
## Tags do recurso-alvo (*somente políticas personalizadas*)
As políticas personalizadas do Amazon Data Lifecycle usam tags de recurso para identificar os recursos para backup. Ao criar um snapshot ou uma política de AMI baseada no EBS, você pode especificar várias tags de recursos de destino. Todos os recursos do tipo especificado (instância ou volume) que tenham pelo menos uma das tags de recursos de destino especificadas serão visados pela política. Por exemplo, se você criar uma política de snapshot direcionada a volumes e especificar `purpose=prod`, `costcenter=prod`, e `environment=live` como tags de recurso de destino, a política visará todos os volumes que tenham qualquer um desses pares de valores de chave de tag.
Se você quiser executar várias políticas em um recurso, poderá atribuir várias tags ao recurso de destino e, em seguida, criar políticas separadas para cada uma direcionar uma tag de recurso específica.
Não é possível usar os caracteres `\` ou `=` em uma chave de etiquetas. Tags de recursos de destino diferenciam letras maiúsculas de minúsculas. Para obter mais informações, consulte [Marcar seus recursos](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html).
## Snapshots
Os snapshots são o principal meio de fazer backup de dados de volumes do EBS. Para economizar custos de armazenamento, os snapshots sucessivos são incrementais, contendo apenas os dados do volume que mudaram desde o snapshot anterior. Quando você exclui um snapshot de uma série de snapshots de um volume, somente os dados exclusivos daquele snapshot são removidos. Os dados restantes do histórico capturado do volume são preservados. Para obter mais informações, consulte [Snapshots do Amazon EBS](ebs-snapshots.md).
## Apoiado pelo EBS AMIs
Uma Imagem de máquina da Amazon (AMI) fornece as informações necessárias para iniciar uma instância. É possível executar várias instâncias em uma única AMI quando precisa de várias instâncias com a mesma configuração. O Amazon Data Lifecycle Manager oferece suporte somente com suporte do EBS. AMIs O suporte do EBS AMIs inclui um snapshot para cada volume do EBS anexado à instância de origem. Para obter mais informações, consulte [Imagens de máquina da Amazon (AMIs)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html).
## Tags do Amazon Data Lifecycle Manager
O Amazon Data Lifecycle Manager aplica as seguintes tags de sistema a todos os snapshots e são AMIs criados por uma política, para diferenciá-los dos snapshots criados por qualquer outro meio: AMIs
+ `aws:dlm:lifecycle-policy-id`
+ `aws:dlm:lifecycle-schedule-name`
+ `aws:dlm:expirationTime`: para snapshots criados por uma programação baseada em idade. Indica quando o snapshot deve ser excluído do nível padrão.
+ `dlm:managed`
+ `aws:dlm:archived`: para snapshots que foram arquivados de acordo com uma programação.
+ `aws:dlm:pre-script`: para snapshots criados com scripts prévios.
+ `aws:dlm:post-script`: para snapshots criados com scripts posteriores.
Você também pode especificar tags personalizadas a serem aplicadas aos instantâneos e AMIs na criação. Não é possível usar os caracteres `\` ou `=` em uma chave de etiquetas.
As tags de destino que o Amazon Data Lifecycle Manager usa para associar os volumes à política podem ser aplicadas opcionalmente aos snapshots criados pela política. Da mesma forma, as tags de destino usadas para associar instâncias a uma política de AMI podem, opcionalmente, ser aplicadas às AMIs criadas pela política.
# As políticas padrão comparadas com as políticas personalizadas do Amazon Data Lifecycle Manager
Esta seção compara as políticas padrão e as políticas personalizadas, e destaca suas semelhanças e diferenças.
**Topics**
+ [Comparação de políticas de snapshots do EBS](#snapshot-policy-diffs)
+ [Comparação das políticas de AMI baseadas no EBS](#ami-policy-diffs)
## Comparação de políticas de snapshots do EBS
A tabela a seguir destaca as diferenças entre a política padrão para snapshots do EBS e as políticas personalizadas de snapshot do EBS.
| Recurso | Política padrão para snapshots do EBS | Política personalizada de snapshots do EBS |
| --- | --- | --- |
| Recurso de backup gerenciado | Snapshot do EBS | Snapshot do EBS |
| Tipos de recursos-alvo | Volumes | Volumes ou instâncias |
| Seleção de recursos-alvo | Tem como alvo todos os volumes da região que não têm snapshots recentes. Você pode especificar parâmetros de exclusão para excluir volumes específicos. | Tem como alvo somente os volumes ou as instâncias que têm tags específicas. |
| Parâmetros de exclusão | Sim, pode excluir volumes de inicialização, tipos de volume específicos e volumes com tags específicas. | Sim, pode excluir volumes de inicialização e volumes com tags específicas quando tem como alvo as instâncias. |
| Suporte AWS Outposts | Não | Sim |
| Compatibilidade com várias agendas | Não | Sim, até quatro agendas por política |
| Tipos de retenção compatíveis | Retenção baseada em tempo apenas | Retenção com base em tempo e quantidade |
| Frequência de criação de snapshots | A cada 1 a 7 dias. | Frequência diária, semanal, mensal, anual ou personalizada usando uma expressão cron. |
| Retenção de snapshots | 2 a 14 dias. | Até 1.000 snapshots (baseado em quantidade) ou até 100 anos (baseado em tempo). |
| Compatibilidade com snapshots consistentes com a aplicação | Não | Sim, usando scripts prévios e posteriores |
| Compatibilidade com arquivamento de snapshots | Não | Sim |
| Compatibilidade com restauração rápida de snapshots | Não | Sim |
| Compatibilidade com cópia entre regiões | Sim, com as configurações padrão 1 | Sim, com configurações personalizadas |
| Compatibilidade com compartilhamento entre contas | Não | Sim |
| Compatibilidade com exclusão estendida 2 | Sim | Não |
1 Para políticas padrão:
+ Você não pode copiar tags em cópias entre regiões.
+ As cópias usam o mesmo período de retenção que o snapshot original.
+ Os snapshots recebem o mesmo status de criptografia que o volume original. Se a região de destino estiver habilitada para criptografia por padrão, as cópias sempre serão criptografadas, mesmo que os snapshots originais estejam descriptografados. As cópias são sempre criptografadas com a chave do KMS padrão para a região de destino.
2 Para políticas padrão e personalizadas:
+ Se uma instância ou volume-alvo for excluído, o Amazon Data Lifecycle Manager continuará excluindo snapshots até restar apenas o último com base no período de retenção. Para as políticas padrão, você pode estender a exclusão para incluir o último snapshot.
+ Se uma política for excluída ou entrar em estado de erro ou de desabilitada, o Amazon Data Lifecycle Manager interromperá a exclusão dos snapshots. Para as políticas padrão, você pode estender a exclusão para continuar a excluir os snapshots, inclusive o último.
## Comparação das políticas de AMI baseadas no EBS
A tabela a seguir destaca as diferenças entre a política padrão para políticas de AMI baseadas no EBS AMIs e as personalizadas baseadas no EBS.
| Recurso | Política padrão para suporte do EBS AMIs | Política personalizada de AMI baseada no EBS |
| --- | --- | --- |
| Recurso de backup gerenciado | Apoiado pelo EBS AMIs | Apoiado pelo EBS AMIs |
| Tipos de recursos-alvo | Instâncias | Instâncias |
| Seleção de recursos-alvo | Tem como alvo todas as instâncias na região que não têm instâncias recentes AMIs. Você pode especificar parâmetros de exclusão para excluir instâncias específicas. | Tem como alvo somente as instâncias que têm tags específicas. |
| Reinicializar instâncias antes da criação da AMI | Não | Sim |
| Parâmetros de exclusão | Sim, pode excluir instâncias com tags específicas. | Não |
| Compatibilidade com várias agendas | Não | Sim, até quatro agendas por política. |
| Frequência de criação de AMI | A cada 1 a 7 dias. | Frequência diária, semanal, mensal, anual ou personalizada usando uma expressão cron. |
| Tipos de retenção compatíveis | Retenção baseada em tempo apenas. | Retenção baseada em tempo e quantidade. |
| AMIs retenção | 2 a 14 dias. | Até 1000 AMIs (com base na contagem) ou até 100 anos (com base na idade). |
| Compatibilidade com descontinuação de AMIs | Não | Sim |
| Compatibilidade com cópia entre regiões | Sim, com as configurações padrão 1 | Sim, com configurações personalizadas |
| Compatibilidade com exclusão estendida 2 | Sim | Não |
1 Para políticas padrão:
+ Você não pode copiar tags em cópias entre regiões.
+ As cópias usam o mesmo período de retenção que a AMI original.
+ Os snapshots recebem o mesmo status de criptografia que a AMI original. Se a região de destino estiver habilitada para criptografia por padrão, as cópias sempre serão criptografadas, mesmo que a origem não AMIs esteja criptografada. As cópias são sempre criptografadas com a chave do KMS padrão para a região de destino.
2 Para políticas padrão e personalizadas:
+ Se uma instância alvo for encerrada, o Amazon Data Lifecycle Manager continuará cancelando o AMIs registro até o último, mas sem incluir, o último, com base no período de retenção. Para políticas padrão, você pode estender o cancelamento de registro para incluir a última AMI.
+ Se uma política for excluída ou entrar no estado de erro ou desativada, o Amazon Data Lifecycle Manager interromperá o cancelamento do registro. AMIs Para políticas padrão, você pode estender a exclusão para continuar cancelando o registro AMIs, incluindo o último.
# Criar políticas padrão do Amazon Data Lifecycle Manager
Para criar instâncias periódicas apoiadas pelo EBS AMIs , use a política padrão para o EBS. AMIs Para criar snapshots de todos os volumes, qualquer que seja seu estado de anexação, ou se você quiser excluir volumes específicos, use a política padrão para snapshots do EBS.
Esta seção explica como criar políticas padrão.
**Topics**
+ [Considerações sobre as políticas padrão](#default-policy-considerations)
+ [Criar política padrão para snapshots do Amazon EBS](#default-snapshot-policy)
+ [Crie uma política padrão para o suporte do EBS AMIs](#default-ami-policy)
+ [Habilitar políticas padrão em várias contas e regiões](dlm-stacksets.md)
## Considerações sobre as políticas padrão
Ao trabalhar com políticas padrão, tenha em mente o seguinte:
+ As políticas padrão não fazem backup de recursos de destino (instâncias ou volumes) que tenham backups recentes (instantâneos ou AMIs). A frequência de criação determina de quais recursos são feitos backups. O backup de um volume ou instância é feito somente se seu último snapshot ou AMI for mais antigo que a frequência de criação da política. Por exemplo, se você especificar uma frequência de criação de três dias, a política padrão para snapshots do EBS só criará um snapshot de um volume se o último snapshot tiver sido feito há mais de 3 dias.
+ Por padrão, as políticas padrão têm como alvo todas as instâncias ou volumes na região, a menos que parâmetros de exclusão sejam especificados.
+ As políticas padrão criarão um conjunto mínimo de snapshots exclusivos. Por exemplo, se você habilitar a política de AMI baseada no EBS e a política de snapshot do EBS, a política de snapshot não duplicará os snapshots dos volumes que já foram copiados para backup pela política de AMI baseada no EBS.
+ As políticas padrão só começarão a ter como alvo os recursos criados há pelo menos 24 horas.
+ Se você excluir um volume ou encerrar uma instância visada por uma política padrão, o Amazon Data Lifecycle Manager continuará excluindo os backups (snapshots AMIs ou) criados anteriormente de acordo com o período de retenção até, mas não incluindo, o último backup. Você deve excluir esse backup manualmente se ele não for necessário.
Se você quiser que o Amazon Data Lifecycle Manager exclua o último backup, você poderá habilitar a *exclusão estendida*.
+ Se uma política padrão for excluída ou entrar no estado de erro ou desativada, o Amazon Data Lifecycle Manager interrompe a exclusão dos backups criados anteriormente (snapshots ou). AMIs Se você quiser que o Amazon Data Lifecycle Manager continue excluindo os backups, inclusive o último, deverá habilitar a *exclusão estendida* antes de excluir a política ou antes que o estado da política mude para desabilitada ou excluída.
+ Quando você cria e habilita uma política padrão, o Amazon Data Lifecycle Manager atribui aleatoriamente aos recursos-alvo uma janela de quatro horas. Os recursos-alvo são copiados durante a janela que foi atribuída a eles na frequência de criação especificada. Por exemplo, se uma política tiver uma frequência de criação de 3 dias e se a um recurso-alvo for atribuída a janela das 12h às 16h, o backup desse recurso será feito entre 12h e 16h a cada 3 dias.
## Criar política padrão para snapshots do Amazon EBS
O procedimento a seguir mostra como criar uma política padrão para snapshots do EBS.
------
#### [ Console ]
**Para criar uma política padrão para snapshots do EBS**
1. Abra o console do Amazon EC2 em [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. No painel de navegação, escolha **Lifecycle Manager** e depois **Criar política de ciclo de vida**.
1. Para **Tipo de política**, escolha **Política padrão** e depois **Política de snapshot do EBS**.
1. Para **Description** (Descrição), insira uma breve descrição da rota.
1. Para **Perfil do IAM**, escolha o perfil do IAM que tem permissões para gerenciar snapshots.
Recomendamos que você escolha **Padrão** para usar o perfil do IAM padrão fornecido pelo Amazon Data Lifecycle Manager. Porém, também é possível usar um perfil do IAM personalizado que você criou anteriormente.
1. Em **Frequência de criação**, especifique com que frequência você deseja que a política seja executada e crie snapshots dos seus volumes.
A frequência especificada também determina de quais volumes será feito backup. A política só fará backup dos volumes cujo backup não foi feito por nenhum outro meio dentro da frequência especificada. Por exemplo, se você especificar uma frequência de criação de três dias, a política só criará snapshots dos volumes cujo backup não foi feito nos últimos três dias.
1. Para **Período de retenção**, especifique por quanto tempo você deseja que a política retenha os snapshots que ela criar. Quando um snapshot atinge o limite de retenção, ele é automaticamente excluído. O período de retenção deve ser maior ou igual ao intervalo de criação.
1. (*Opcional*) Configure os **parâmetros de exclusão** para excluir volumes específicos dos backups agendados. Os volumes excluídos não serão copiados quando a política for executada.
1. Para excluir os volumes de inicialização, selecione **Excluir volumes de inicialização**. Se você excluir os volumes de inicialização, somente os volumes de dados (não de inicialização) serão copiados pela política. Em outras palavras, ela não criará snapshots de volumes anexados às instâncias como volumes de inicialização.
1. Para excluir tipos de volume específicos, escolha **Excluir tipos de volume específicos** e selecione os tipos de volume a serem excluídos. A política só fará backup de volumes de outros tipos.
1. Para excluir volumes que têm tags específicas, escolha **Adicionar tag** e depois especifique as chaves e os valores de tag. A política não criará snapshots de volumes que contêm alguma das tags especificadas.
1. (*Opcional*) Para **Configurações avançadas**, especifique as ações adicionais que a política deve realizar.
1. (Opcional) Para copiar automaticamente as tags atribuídas do volume original para os snapshots, selecione **Copiar tags dos volumes**.
1. Com a **exclusão estendida** desabilitada:
+ Se o volume original for excluído, o Amazon Data Lifecycle Manager continuará excluindo snapshots criados anteriormente até restar apenas o último com base no período de retenção. **Se você quiser que o Amazon Data Lifecycle Manager exclua todos os snapshots, inclusive o último, selecione Estender exclusão**.
+ Se uma política for excluída ou entrar em estado de `error`ou de `disabled`, o Amazon Data Lifecycle Manager interromperá a exclusão dos snapshots. Se você quiser que o Amazon Data Lifecycle Manager continue a excluir os snapshots, inclusive o último, selecione **Estender exclusão**.
**nota**
Se você habilitar a exclusão estendida, substituirá ambos os comportamentos descritos acima simultaneamente.
1. Para copiar os snapshots criados pela política para outras regiões, selecione **Criar cópia entre regiões** e depois selecione até três regiões de destino.
+ Se o snapshot original estiver criptografado ou se a criptografia estiver habilitada por padrão para a região de destino, os snapshots copiados serão criptografados usando a chave do KMS padrão para criptografia do EBS na região de destino.
+ Se o snapshot original não estiver criptografado e a criptografia estiver desabilitada por padrão para a região de destino, os snapshots copiados serão descriptografados.
1. (*Opcional*) Para adicionar uma tag à política, escolha **Adicionar tag** e especifique o par chave-valor da tag.
1. Escolha **Criar política padrão**.
**nota**
Se receber um erro `Role with name AWSDataLifecycleManagerDefaultRole already exists`, consulte [Solucionar problemas do Amazon Data Lifecycle Manager](dlm-troubleshooting.md) para obter mais informações.
------
#### [ AWS CLI ]
**Para criar uma política padrão para snapshots do EBS**
Use o comando [ da create-lifecycle-policy](https://docs.aws.amazon.com/cli/latest/reference/dlm/create-lifecycle-policy.html). Você pode especificar os parâmetros de solicitação com um de dois métodos, dependendo do seu caso de uso ou de suas preferências:
+ **Método 1**
```
$ aws dlm create-lifecycle-policy \
--state ENABLED | DISABLED \
--description "policy_description" \
--execution-role-arn role_arn \
--default-policy VOLUME \
--create-interval creation_frequency_in_days (1-7) \
--retain-interval retention_period_in_days (2-14) \
--copy-tags | --no-copy-tags \
--extend-deletion | --no-extend-deletion \
--cross-region-copy-targets TargetRegion=destination_region_code \
--exclusions ExcludeBootVolumes=true | false, ExcludeTags=[{Key=tag_key,Value=tag_value}], ExcludeVolumeTypes="standard | gp2 | gp3 | io1 | io2 | st1 | sc1"
```
Por exemplo, para criar uma política padrão para snapshots do EBS que tenha como alvo todos os volumes na região, use o perfil do IAM padrão, seja executada diariamente (padrão) e retenha snapshots por 7 dias (padrão), você precisa especificar os seguintes parâmetros:
```
$ aws dlm create-lifecycle-policy \
--state ENABLED \
--description "Daily default snapshot policy" \
--execution-role-arn arn:aws:iam::account_id:role/AWSDataLifecycleManagerDefaultRole \
--default-policy VOLUME
```
+ **Método 2**
```
$ aws dlm create-lifecycle-policy \
--state ENABLED | DISABLED \
--description "policy_description" \
--execution-role-arn role_arn \
--default-policy VOLUME \
--policy-details file://policyDetails.json
```
Em que `policyDetails.json` inclui o seguinte:
```
{
"PolicyLanguage": "SIMPLIFIED",
"PolicyType": "EBS_SNAPSHOT_MANAGEMENT",
"ResourceType": "VOLUME",
"CopyTags": true | false,
"CreateInterval": creation_frequency_in_days (1-7),
"RetainInterval": retention_period_in_days (2-14),
"ExtendDeletion": true | false,
"CrossRegionCopyTargets": [{"TargetRegion":"destination_region_code"}],
"Exclusions": {
"ExcludeBootVolume": true | false,
"ExcludeVolumeTypes": ["standard | gp2 | gp3 | io1 | io2 | st1 | sc1"],
"ExcludeTags": [{
"Key": "exclusion_tag_key",
"Value": "exclusion_tag_value"
}]
}
}
```
------
## Crie uma política padrão para o suporte do EBS AMIs
O procedimento a seguir mostra como criar uma política padrão para o suporte do EBS AMIs.
------
#### [ Console ]
**Para criar uma política padrão para o suporte do EBS AMIs**
1. Abra o console do Amazon EC2 em [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. No painel de navegação, escolha **Lifecycle Manager** e depois **Criar política de ciclo de vida**.
1. Para **Tipo de política**, escolha **Política padrão** e depois **Política de AMI baseada no EBS**.
1. Para **Description** (Descrição), insira uma breve descrição da rota.
1. Para a **função do IAM**, escolha a função do IAM que tem permissões para gerenciar AMIs.
Recomendamos que você escolha **Padrão** para usar o perfil do IAM padrão fornecido pelo Amazon Data Lifecycle Manager. Porém, também é possível usar um perfil do IAM personalizado que você criou anteriormente.
1. Em **Frequência de criação**, especifique com que frequência você deseja que a política seja executada e criada a AMIs partir de suas instâncias.
A frequência especificada também determina de quais instâncias será feito backup. A política só fará backup das instâncias cujo backup não foi feito por nenhum outro meio dentro da frequência especificada. Por exemplo, se você especificar uma frequência de criação de 3 dias, a política só será criada AMIs a partir de instâncias que não tenham sido copiadas nos últimos 3 dias.
1. Em **Período de retenção**, especifique por quanto tempo você deseja que a política retenha o AMIs que ela cria. Quando uma AMI atinge o limite de retenção, seu registro é automaticamente cancelado e os snapshots a ela associados são excluídos. O período de retenção deve ser maior ou igual ao intervalo de criação.
1. (*Opcional*) Configure os **Parâmetros de exclusão** para excluir instâncias específicas dos backups agendados. O backup das instâncias excluídas não será feito quando a política for executada.
1. Para excluir volumes que tenham tags específicas, escolha **Adicionar tag** e depois especifique as chaves e os valores da tag. A política não será criada AMIs a partir de instâncias que tenham nenhuma das tags especificadas.
1. (*Opcional*) Para **Configurações avançadas**, especifique as ações adicionais que a política deve realizar.
1. Para copiar as tags atribuídas das instâncias de origem para suas AMIs, selecione **Copiar tags das instâncias**.
1. Com a **exclusão estendida** desabilitada:
+ Se uma instância de origem for encerrada, o Amazon Data Lifecycle Manager continuará cancelando o registro AMIs criado anteriormente, até o último, mas sem incluir, o último, com base no período de retenção. **Se você quiser que o Amazon Data Lifecycle Manager cancele o registro de tudo AMIs, incluindo o último, selecione Estender exclusão.**
+ Se uma política for excluída ou entrar no `disabled` estado `error` ou, o Amazon Data Lifecycle Manager interromperá o cancelamento do registro. AMIs **Se você quiser que o Amazon Data Lifecycle Manager continue com o cancelamento do registro AMIs, incluindo o último, selecione Estender exclusão.**
**nota**
Se você habilitar a exclusão estendida, substituirá ambos os comportamentos descritos acima simultaneamente.
1. Para copiar a AMIs criação da política para outras regiões, selecione **Criar cópia entre regiões** e, em seguida, selecione até 3 regiões de destino.
+ Se a AMI de origem for criptografada ou se a criptografia por padrão estiver habilitada para a região de destino, as copiadas serão AMIs criptografadas usando a chave KMS padrão para criptografia do EBS na região de destino.
+ Se a AMI de origem não estiver criptografada e a criptografia, por padrão, estiver desativada para a região de destino, as copiadas não serão AMIs criptografadas.
1. (*Opcional*) Para adicionar uma tag à política, escolha **Adicionar tag** e especifique o par chave-valor da tag.
1. Escolha **Criar política padrão**.
**nota**
Se receber um erro `Role with name AWSDataLifecycleManagerDefaultRoleForAMIManagement already exists`, consulte [Solucionar problemas do Amazon Data Lifecycle Manager](dlm-troubleshooting.md) para obter mais informações.
------
#### [ AWS CLI ]
**Para criar uma política padrão para o suporte do EBS AMIs**
Use o comando [ da create-lifecycle-policy](https://docs.aws.amazon.com/cli/latest/reference/dlm/create-lifecycle-policy.html). Você pode especificar os parâmetros de solicitação com um de dois métodos, dependendo do seu caso de uso ou de suas preferências:
+ **Método 1**
```
$ aws dlm create-lifecycle-policy \
--state ENABLED | DISABLED \
--description "policy_description" \
--execution-role-arn role_arn \
--default-policy INSTANCE \
--create-interval creation_frequency_in_days (1-7) \
--retain-interval retention_period_in_days (2-14) \
--copy-tags | --no-copy-tags \
--extend-deletion | --no-extend-deletion \
--cross-region-copy-targets TargetRegion=destination_region_code \
--exclusions ExcludeTags=[{Key=tag_key,Value=tag_value}]
```
Por exemplo, para criar uma política padrão para o EBS AMIs que vise todas as instâncias na região, use a função padrão do IAM, seja executada diariamente (padrão) e retida AMIs por 7 dias (padrão), você precisa especificar os seguintes parâmetros:
```
$ aws dlm create-lifecycle-policy \
--state ENABLED \
--description "Daily default AMI policy" \
--execution-role-arn arn:aws:iam::account_id:role/AWSDataLifecycleManagerDefaultRoleForAMIManagement \
--default-policy INSTANCE
```
+ **Método 2**
```
$ aws dlm create-lifecycle-policy \
--state ENABLED | DISABLED \
--description "policy_description" \
--execution-role-arn role_arn \
--default-policy INSTANCE \
--policy-details file://policyDetails.json
```
Em que `policyDetails.json` inclui o seguinte:
```
{
"PolicyLanguage": "SIMPLIFIED",
"PolicyType": "IMAGE_MANAGEMENT",
"ResourceType": "INSTANCE",
"CopyTags": true | false,
"CreateInterval": creation_frequency_in_days (1-7),
"RetainInterval": retention_period_in_days (2-14),
"ExtendDeletion": true | false,
"CrossRegionCopyTargets": [{"TargetRegion":"destination_region_code"}],
"Exclusions": {
"ExcludeTags": [{
"Key": "exclusion_tag_key",
"Value": "exclusion_tag_value"
}]
}
}
```
------
# Habilitar as políticas padrão do Amazon Data Lifecycle Manager em várias contas e regiões
Usando CloudFormation StackSets, você pode habilitar as políticas padrão do Amazon Data Lifecycle Manager em várias contas e AWS regiões com uma única operação.
Você pode usar conjuntos de pilhas para habilitar políticas padrão de uma das seguintes maneiras:
+ **Em toda a AWS organização** — garante que as políticas padrão sejam habilitadas e configuradas de forma consistente em toda a AWS organização ou em unidades organizacionais específicas de uma organização. Isso é feito usando permissões *gerenciadas pelo serviço*. CloudFormation StackSets cria as funções necessárias do IAM em seu nome.
+ **Em AWS contas específicas** — Garante que as políticas padrão sejam ativadas e configuradas de forma consistente em contas específicas de destino. Isso requer *permissões autogerenciadas*. Você cria os perfis do IAM necessários para estabelecer a relação de confiança entre a conta do administrador do conjunto de pilhas e as contas de destino.
Para obter mais informações, consulte [Modelos de permissões para conjuntos de pilhas](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html#stacksets-concepts-stackset-permission-models) no *Guia do usuário do AWS CloudFormation *.
Use os procedimentos a seguir para habilitar as políticas padrão do Amazon Data Lifecycle Manager em toda a AWS organização, em contas específicas ou em OUs contas-alvo específicas.
**Pré-requisitos**
Dependendo de como você estiver habilitando as políticas padrão, faça uma das seguintes alternativas:
+ (Em todas AWS as organizações) Você deve [habilitar todos os recursos em sua organização](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_org_support-all-features.html) e [ativar o acesso confiável com AWS Organizations](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-orgs-activate-trusted-access.html). Você também deve usar a conta de gerenciamento da organização ou uma [conta de administrador delegado](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-orgs-delegated-admin.html).
+ (Em contas de destino específicas) Você deve [conceder permissões autogerenciadas](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-prereqs-self-managed.html) criando os perfis necessários para estabelecer uma relação de confiança entre a conta de administrador do conjunto de pilhas e as contas de destino.
------
#### [ Console ]
**Para habilitar políticas padrão em uma AWS organização ou em contas específicas**
1. Abra o CloudFormation console em [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/).
1. No painel de navegação, escolha e, em seguida **StackSets**, escolha **Criar StackSet**.
1. Em **Permissões**, dependendo de como você estiver habilitando as políticas padrão, faça uma das seguintes alternativas:
+ (Em toda a AWS organização) Escolha as permissões **gerenciadas pelo serviço**.
+ (Em contas de destino específicas) Escolha **Permissões de autoatendimento**. Em seguida, em **ARN do perfil de administrador do IAM**, selecione o perfil de serviço do IAM que você criou para a conta do administrador e, em **Nome do perfil de execução do IAM**, insira o nome do perfil de serviço do IAM que você criou nas contas de destino.
1. Em **Preparar modelo**, escolha **Usar um exemplo de modelo**.
1. Em **Exemplos de modelo**, faça uma das seguintes alternativas:
+ (Política padrão para snapshots do EBS) Selecione **Criar políticas padrão do Amazon Data Lifecycle Manager para snapshots do EBS**.
+ (Política padrão para sistemas baseados em EBS AMIs) Selecione **Criar políticas padrão do Amazon Data Lifecycle** Manager para sistemas baseados em EBS. AMIs
1. Escolha **Próximo**.
1. Para **StackSet nome** e **StackSet descrição**, insira um nome descritivo e uma breve descrição.
1. Na seção **Parâmetros**, defina as configurações de política padrão conforme necessário.
**nota**
Para cargas de trabalho críticas, recomendamos **CreateInterval = 1 dia** e **RetainInterval = 7 dias**.
1. Escolha **Próximo**.
1. (Opcional) Para **Tags**, especifique tags para ajudá-lo a identificar StackSet e empilhar recursos.
1. Em **Execução gerenciada**, escolha **Ativa**.
1. Escolha **Próximo**.
1. Em **Add stacks to stack set** (Adicionar pilhas ao conjunto de pilhas), escolha **Deploy new stacks** (Implantar novas pilhas).
1. Dependendo de como você estiver habilitando as políticas padrão, faça uma das seguintes alternativas:
+ (Em toda a AWS organização) Para **destinos de implantação**, escolha uma das seguintes opções:
+ Para implantar em toda a AWS organização, escolha **Implantar na organização**.
+ Para implantar em unidades organizacionais (UO) específicas, escolha **Implantar em unidades organizacionais** e em **ID da UO**, insira o ID da UO. Para adicionar maisOUs, escolha **Adicionar outra OU**.
+ (Para contas de destino específicas) Em **Contas**, faça uma das seguintes alternativas:
+ Para implantar em contas de destino específicas, escolha **Implantar pilhas em contas** e, em **Números da conta**, insira as contas IDs de destino.
+ Para implantar em todas as contas em uma UO específica, escolha **Implantar pilha em todas as contas de uma unidade organizacional** e, em **Números de organização**, insira o ID da UO de destino.
1. Em **Implantação automática**, escolha **Ativada**.
1. Em **Comportamento de remoção de conta**, escolha **Reter pilhas**.
1. Em **Especificar regiões**, selecione as regiões específicas nas quais habilitar as políticas padrão ou escolha **Adicionar todas as regiões** para habilitar as políticas padrão em todas as regiões.
1. Escolha **Próximo**.
1. Analise as configurações do conjunto de pilhas, selecione **Eu reconheço que CloudFormation pode criar recursos do IAM** e, em seguida, escolha **Enviar**.
------
#### [ AWS CLI ]
**Para habilitar políticas padrão em uma AWS organização**
1. Crie o conjunto de pilhas. Use o comando [ da create-stack-set](https://docs.aws.amazon.com/cli/latest/reference/cloudformation/create-stack-set.html).
Em `--permission-model`, especifique `SERVICE_MANAGED`.
Para`--template-url`, especifique um dos seguintes modelos URLs:
+ (Políticas padrão para suporte do EBS AMIs) `https://s3.amazonaws.com/cloudformation-stackset-sample-templates-us-east-1/DataLifecycleManagerAMIDefaultPolicy.yaml`
+ (Políticas padrão para snapshots do EBS) `https://s3.amazonaws.com/cloudformation-stackset-sample-templates-us-east-1/DataLifecycleManagerEBSSnapshotDefaultPolicy.yaml`
Em `--parameters`, especifique as configurações das políticas padrão. Para obter os parâmetros compatíveis, as descrições de parâmetros e os valores válidos, baixe o modelo usando o URL e depois visualize o modelo usando um editor de texto.
Em `--auto-deployment`, especifique `Enabled=true, RetainStacksOnAccountRemoval=true`.
```
$ aws cloudformation create-stack-set \
--stack-set-name stackset_name \
--permission-model SERVICE_MANAGED \
--template-url template_url \
--parameters "ParameterKey=param_name_1,ParameterValue=param_value_1" "ParameterKey=param_name_2,ParameterValue=param_value_2" \
--auto-deployment "Enabled=true, RetainStacksOnAccountRemoval=true"
```
1. Implante o conjunto de pilhas. Use o comando [ da create-stack-instances](https://docs.aws.amazon.com/cli/latest/reference/cloudformation/create-stack-instances.html).
Em `--stack-set-name`, especifique o nome do conjunto de pilhas que você criou na etapa anterior.
Para`--deployment-targets OrganizationalUnitIds`, especifique o ID da OU raiz a ser implantada em uma organização inteira ou da OU IDs a ser implantada OUs em uma área específica da organização.
Para`--regions`, especifique as AWS regiões nas quais habilitar as políticas padrão.
```
$ aws cloudformation create-stack-instances \
--stack-set-name stackset_name \
--deployment-targets OrganizationalUnitIds='["root_ou_id"]' | '["ou_id_1", "ou_id_2]' \
--regions '["region_1", "region_2"]'
```
**Para habilitar as políticas padrão em contas de destino específicas**
1. Crie o conjunto de pilhas. Use o comando [ da create-stack-set](https://docs.aws.amazon.com/cli/latest/reference/cloudformation/create-stack-set.html).
Para`--template-url`, especifique um dos seguintes modelos URLs:
+ (Políticas padrão para suporte do EBS AMIs) `https://s3.amazonaws.com/cloudformation-stackset-sample-templates-us-east-1/DataLifecycleManagerAMIDefaultPolicy.yaml`
+ (Políticas padrão para snapshots do EBS) `https://s3.amazonaws.com/cloudformation-stackset-sample-templates-us-east-1/DataLifecycleManagerEBSSnapshotDefaultPolicy.yaml`
Em `--administration-role-arn`, especifique o ARN do perfil de serviço do IAM que você criou anteriormente para o administrador do conjunto de pilhas.
Em `--execution-role-name`, especifique o nome do perfil de serviço do IAM que você criou nas contas de destino.
Em `--parameters`, especifique as configurações das políticas padrão. Para obter os parâmetros compatíveis, as descrições de parâmetros e os valores válidos, baixe o modelo usando o URL e depois visualize o modelo usando um editor de texto.
Em `--auto-deployment`, especifique `Enabled=true, RetainStacksOnAccountRemoval=true`.
```
$ aws cloudformation create-stack-set \
--stack-set-name stackset_name \
--template-url template_url \
--parameters "ParameterKey=param_name_1,ParameterValue=param_value_1" "ParameterKey=param_name_2,ParameterValue=param_value_2" \
--administration-role-arn administrator_role_arn \
--execution-role-name target_account_role \
--auto-deployment "Enabled=true, RetainStacksOnAccountRemoval=true"
```
1. Implante o conjunto de pilhas. Use o comando [ da create-stack-instances](https://docs.aws.amazon.com/cli/latest/reference/cloudformation/create-stack-instances.html).
Em `--stack-set-name`, especifique o nome do conjunto de pilhas que você criou na etapa anterior.
Para`--accounts`, especifique as AWS contas IDs de destino.
Para`--regions`, especifique as AWS regiões nas quais habilitar as políticas padrão.
```
$ aws cloudformation create-stack-instances \
--stack-set-name stackset_name \
--accounts '["account_ID_1","account_ID_2"]' \
--regions '["region_1", "region_2"]'
```
------
# Criar política padrão do Amazon Data Lifecycle Manager para snapshots
O procedimento a seguir mostra como usar o Amazon Data Lifecycle Manager para automatizar os ciclos de vida de snapshots do Amazon EBS.
**Topics**
+ [Criar uma política de ciclo de vida de snapshots](#create-snap-policy)
+ [Considerações sobre políticas de ciclo de vida de snapshots](#snapshot-considerations)
+ [Recursos adicionais do](#snapshot-additional-resources)
+ [Automatizar snapshots consistentes com a aplicação](automate-app-consistent-backups.md)
+ [Outros casos de uso para scripts prévios e posteriores](script-other-use-cases.md)
+ [Como funcionam os scripts prévios e posteriores](script-flow.md)
+ [Identificar snapshots criados com pré-scripts e pós-scripts](dlm-script-tags.md)
+ [Monitorar pré-scripts e pós-scripts](dlm-script-monitoring.md)
## Criar uma política de ciclo de vida de snapshots
Use um dos procedimentos a seguir para criar uma política de ciclo de vida de snapshots.
------
#### [ Console ]
**Para criar uma política de snapshot**
1. Abra o console do Amazon EC2 em [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. No painel de navegação, selecione **Elastic Block Store**, **Lifecycle Manager** ((Gerenciador de ciclo de vida) e **Create snapshot lifecycle policy** (Criar política de ciclo de vida de snapshot).
1. Na tela **Select policy type** (Selecionar tipo de política), escolha **EBS snapshot policy** (Política de snapshot do EBS) e depois **Next** (Próximo).
1. Na seção **Target resources** (Recursos de destino), faça o seguinte:
1. Em **Target resource types**, (Tipos de recurso de destino), escolha o tipo de recurso para backup. Escolha `Volume` (Volume) para criar snapshots de volumes individuais ou `Instance` (Instância) para criar snapshots multivolume dos volumes associados a uma instância.
1. (*Apenas para clientes do Outpost e zonas locais*) Especifique onde os recursos-alvo estão localizados.
Para **Local dos recursos-alvo**, especifique onde os recursos-alvo estão localizados.
+ Para direcionar recursos em uma região, escolha **Região da AWS **. O Amazon Data Lifecycle Manager fará backup de todos os recursos do tipo especificado que têm etiquetas de destino correspondentes somente na região atual. Os snapshots são criados na mesma região.
+ Para direcionar recursos em zonas locais, escolha **Zonas locais da AWS **. O Amazon Data Lifecycle Manager fará backup de todos os recursos do tipo especificado que têm etiquetas de destino correspondentes em todas as zonas locais apenas na região atual. Os snapshots podem ser criados na mesma zona local do recurso de origem ou em sua região principal.
+ Para direcionar recursos para um Outpost, selecione **AWS Outpost**. O Amazon Data Lifecycle Manager fará backup de todos os recursos do tipo especificado que tenham etiquetas de destino correspondentes em todos os Outposts em sua conta. Os snapshots podem ser criados no mesmo Outpost que o recurso de origem ou em sua região principal.
1. Em **Target with these tags** (Destino com essas etiquetas), escolha as etiquetas de recurso que identificam os volumes ou as instâncias dos quais fazer backup. A política só oferece suporte aos recursos com a chave de tag e os pares de valor especificados.
1. Para **Description** (Descrição), insira uma breve descrição da rota.
1. Em **IAM role** (Função do IAM), selecione a função do IAM que tem permissões para gerenciar snapshots e para descrever volumes e instâncias. Para usar a função padrão fornecida pelo Amazon Data Lifecycle Manager, escolha **Default role** (Função padrão). Se preferir, para usar uma função do IAM personalizada criada anteriormente, selecione **Choose another role** (Escolher outra função) e selecione a função a ser usada.
1. Em **Policy tags** (Etiquetas de políticas), adicione as etiquetas a serem aplicadas na política de ciclo de vida. É possível usar essas etiquetas para identificar e categorizar suas políticas.
1. Em **Policy status** (Status da política), selecione **Enable** (Habilitar) para iniciar as execuções da política no próximo horário agendado ou **Disable policy** (Desabilitar política) para impedir que a política seja executada. Se você não habilitar a política agora, ela não começará a criar snapshots até que você a ative manualmente após a criação.
1. (*Políticas que têm apenas instâncias como alvo*) Excluir volumes de conjuntos de snapshots de vários volumes.
Por padrão, o Amazon Data Lifecycle Manager criará snapshots de todos os volumes anexados às instâncias-alvo. Porém, você pode optar por criar snapshots de um subconjunto dos volumes anexados. Na seção **Parameters** (Parâmetros), faça o seguinte:
+ Se não quiser criar snapshots dos volumes raiz anexados às instâncias de destino, selecione **Exclude root volume** (Excluir volume raiz). Se você selecionar essa opção, apenas os volumes de dados (não raiz) anexados às instâncias de destino serão incluídos nos conjuntos de snapshots de vários volumes.
+ Para criar snapshots de um subconjunto dos volumes de dados (não raiz) anexados às instâncias de destino, selecione **Exclude specific data volumes** (Excluir volumes de dados específicos) e especifique as etiquetas a serem usadas para identificar os volumes de dados que não deverão ser capturados. O Amazon Data Lifecycle Manager não criará snapshots de volumes de dados que contenham qualquer uma das etiquetas especificadas. O Amazon Data Lifecycle Manager criará snapshots apenas de volumes de dados que não contenham qualquer uma das etiquetas especificadas.
1. Escolha **Próximo**.
1. Em **Configure schedule** (Configurar agendamento), configure os agendamentos de política. Uma política pode ter até quatro agendamentos. A Programação 1 é obrigatória. As Programações 2, 3 e 4 são opcionais. Para cada agendamento de política que você adicionar, faça o seguinte:
1. Na seção **Schedule details** (Detalhes do agendamento), faça o seguinte:
1. Em **Schedule name** (Nome do agendamento), especifique um nome descritivo para o agendamento.
1. Em **Frequency** (Frequência) e nos campos relacionados, configure o intervalo entre as execuções da política.
É possível configurar execuções de políticas com uma programação diária, semanal, mensal ou anual. Como opção, escolha **Custom cron expression** (Expressão cron personalizada) para especificar um intervalo de até 1 ano. Para obter mais informações, consulte [Cron e expressões de taxa](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-scheduled-rule-pattern.html) no *Guia do EventBridge usuário da Amazon*.
**nota**
Se precisar habilitar o **arquivamento de snapshots** para a programação, você deve selecionar a frequência **mensal** ou **anual**, ou especificar uma expressão cron com uma frequência de criação de pelo menos 28 dias.
Se você especificar uma frequência mensal que crie snapshots em um dia específico de uma semana específica (por exemplo, na segunda quinta-feira do mês), para uma programação baseada em contagem, a contagem de retenção para o nível de arquivamento deverá ser 4 ou mais.
1. Em **Starting at** (Iniciando às), especifique a hora em que as execuções da política estão programadas para iniciar. A primeira execução da política começa uma hora depois do horário agendado. A hora deve ser inserida no formato `hh:mm` UTC.
1. Em **Retention type** (Tipo de retenção), especifique a política de retenção para snapshots criados pelo agendamento.
É possível reter snapshots com base na contagem total ou na idade deles.
+ Retenção baseada em contagem
+ Com o arquivamento de snapshots desabilitado, o intervalo varia de `1` a `1000`. Quando o limite de retenção for atingido, o snapshot mais antigo será excluído permanentemente.
+ Com o arquivamento de snapshots habilitado, o intervalo varia de `0` (arquivamento imediatamente após a criação) a `1000`. Quando o limite de retenção for atingido, o snapshot mais antigo será convertido em um snapshot completo e movido para o nível de arquivamento.
+ Retenção com base em tempo
+ Com o arquivamento de snapshots desabilitado, o intervalo varia de `1` dia a `100` anos. Quando o limite de retenção for atingido, o snapshot mais antigo será excluído permanentemente.
+ Com o arquivamento de snapshots habilitado, o intervalo varia de `0` dias (arquivamento imediatamente após a criação) a `100` anos. Quando o limite de retenção for atingido, o snapshot mais antigo será convertido em um snapshot completo e movido para o nível de arquivamento.
**nota**
Todas as programações devem ter o mesmo tipo de retenção (baseado em idade ou contagem). É possível especificar o tipo de retenção somente para a Programação 1. As Programações 2, 3 e 4 herdam o tipo de retenção da Programação 1. Cada programação pode ter sua própria contagem ou período de retenção.
Se você habilitar a restauração rápida de snapshots, a cópia entre regiões ou o compartilhamento de snapshots, deverá especificar uma contagem de retenção de `1` ou mais, ou um período de retenção de `1` dia ou mais.
1. (*AWS Outposts e somente para clientes da Zona Local*) Especifique o destino do snapshot.
Para **Destino do snapshot**, especifique o destino dos snapshots criados pela política.
+ Se a política tem como alvo recursos em uma região, os instantâneos devem ser criados na mesma região. AWS A região está selecionada para você.
+ Se a política tiver como alvo recursos em uma zona local, você pode criar snapshots na mesma zona local que o recurso de origem ou em sua região principal.
+ Se a política tiver como alvo recursos em um Outpost, você pode criar snapshots no mesmo Outpost que o recurso de origem ou em sua região principal.
1. Configure a marcação para snapshots.
Na seção **Tagging** (Marcação), faça o seguinte:
1. Para copiar todas as etiquetas definidas por usuário do volume de origem para os snapshots criados pelo agendamento, selecione **Copy tags from source** (Copiar etiquetas da origem).
1. Para especificar etiquetas adicionais a serem atribuídas aos snapshots criados por esse agendamento, escolha **Add tags** (Adicionar etiquetas).
1. Configurar scripts prévios e posteriores para snapshots consistentes com a aplicação.
Para obter mais informações, consulte [Automatizar snapshots consistentes com a aplicação com o Data Lifecycle Manager](automate-app-consistent-backups.md).
1. (*Políticas que têm somente volumes como alvo*) Configurar o arquivamento dos snapshots.
Na seção **Arquivamento de snapshots**, faça o seguinte:
**nota**
Você só pode habilitar o arquivamento de snapshots para uma única programação em uma política.
1. Para habilitar o arquivamento de snapshots para a programação, selecione **Archive snapshots created by this schedule** (Arquivar os snapshots criados por essa programação).
**nota**
Você só pode habilitar o arquivamento de snapshots se a frequência de criação de snapshots for mensal ou anual, ou se especificar uma expressão cron com uma frequência de criação de pelo menos 28 dias.
1. Especifique a regra de retenção para snapshots no nível de arquivamento.
+ Para **programações baseadas em contagem**, especifique o número de snapshots a serem retidos no nível de arquivamento. Quando o limite de retenção for atingido, o snapshot mais antigo será excluído permanentemente do nível de arquivamento. Por exemplo, se você especificar 3, a programação reterá no máximo 3 snapshots no nível de arquivamento. Quando o quarto snapshot for arquivado, o mais antigo dos três snapshots existentes no nível de arquivamento será excluído.
+ Para **programações baseadas em idade**, especifique por quanto tempo os snapshots devem ser retidos no nível de arquivamento. Quando o limite de retenção for atingido, o snapshot mais antigo será excluído permanentemente do nível de arquivamento. Por exemplo, se você especificar 120 dias, a programação excluirá automaticamente os snapshots do nível de arquivamento quando eles atingirem essa idade.
**Importante**
O período de retenção mínimo para snapshots arquivados é de 90 dias. Você deve especificar uma regra de retenção para reter o snapshot por pelo menos 90 dias.
1. Habilitar a restauração rápida de snapshots.
Para habilitar a restauração rápida de snapshots para snapshots criados pelo agendamento, na seção **Fast snapshot restore** (Restauração rápida de snapshots), selecione **Enable fast snapshot restore** (Habilitar restauração rápida de snapshots). Se você habilitar a restauração rápida de snapshots, deverá escolher as zonas de disponibilidade nas quais serão habilitadas. Se o agendamento usar uma programação de retenção baseada em idade, será necessário especificar o período para o qual habilitar a restauração rápida de snapshots para cada snapshot. Se o agendamento usar retenção baseada em contagem, será necessário especificar o número máximo de snapshots para ativar a restauração rápida de snapshots.
Se o agendamento criar snapshots em um Outpost, você não poderá habilitar a restauração rápida de snapshots. A restauração rápida de snapshots não é compatível com snapshots locais armazenados em um Outpost.
**nota**
Você será cobrado por cada minuto em que a restauração rápida de snapshots estiver habilitada para um snapshot em uma determinada zona de disponibilidade. As cobranças são divididas com um mínimo de uma hora.
1. Configurar cópia entre regiões.
Para copiar snapshots criados pelo agendamento para um Outpost ou para uma região diferente, na seção **Cópia entre regiões**, selecione **Habilitar cópia entre regiões**.
Se o agendamento criar snapshots em uma região, será possível copiar os snapshots para até três regiões ou Outposts adicionais na sua conta. É preciso especificar uma regra de cópia entre regiões separada para cada Outpost ou região de destino.
Para cada região ou Outpost, é possível escolher diferentes políticas de retenção e se deseja copiar todas as etiquetas ou nenhuma etiqueta. Se o snapshot de origem estiver criptografado, ou se a criptografia estiver habilitada por padrão, os snapshots copiados serão criptografados. Se o snapshot de origem não estiver criptografado, será possível habilitar a criptografia. Se você não especificar uma chave do KMS, os snapshots serão criptografados usando a chave do KMS padrão de criptografia do EBS em cada região de destino. Se você especificar uma Chave do KMS para a região de destino, a função do IAM selecionada deverá ter acesso à Chave do KMS.
**nota**
É necessário garantir que o número de cópias de snapshots simultâneas não seja excedido por região.
Se a política criar snapshots em um Outpost, você não poderá copiá-los para uma região ou outro Outpost e as configurações de cópia entre regiões não estarão disponíveis.
1. Configurar compartilhamento entre contas.
No **compartilhamento entre contas**, configure a política para compartilhar automaticamente os instantâneos criados pela agenda com outras AWS contas. Faça o seguinte:
1. Para ativar o compartilhamento com outras AWS contas, selecione **Ativar compartilhamento entre contas**.
1. Para adicionar contas com as quais os snapshots serão compartilhados, escolha **Add account** (Adicionar conta), insira o ID de 12 dígitos da conta da AWS e escolha **Add** (Adicionar).
1. Para cancelar o compartilhamento de snapshots compartilhados automaticamente após um período específico, selecione **Unshare automatically** (Cancelar o compartilhamento automaticamente). Se você escolher cancelar automaticamente o compartilhamento de snapshots compartilhados, o período após o qual cancelar o compartilhamento automaticamente dos snapshots não poderá ser maior do que o período para o qual a política retém seus snapshots. Por exemplo, se a configuração de retenção da política retém snapshots por um período de cinco dias, é possível configurar a política para cancelar o compartilhamento automático de snapshots compartilhados após períodos de até quatro dias. Isso se aplica a políticas com configurações de retenção de snapshots baseadas em idade e em contagem.
Se você não habilitar o cancelamento automático de compartilhamento, o snapshot será compartilhado até ser excluído.
**nota**
Você só pode compartilhar snapshots não criptografados ou criptografados usando uma chave gerenciada pelo cliente gerenciada pelo cliente. Você não pode compartilhar snapshots criptografados com a Chave do KMS de criptografia padrão do EBS. Se você compartilhar snapshots criptografados, também deverá compartilhar a Chave do KMS usada para criptografar o volume de origem com as contas de destino. Para obter mais informações, consulte [Como permitir que usuários em outras contas usem uma chave do KMS](https://docs.aws.amazon.com//kms/latest/developerguide/key-policy-modifying-external-accounts.html) no *Guia do desenvolvedor do AWS Key Management Service *.
1. Para adicionar outros agendamentos, escolha **Add another schedule** (Adicionar outro agendamento), localizado na parte superior da tela. Para cada agendamento adicional, preencha os campos conforme descrito anteriormente neste tópico.
1. Depois de adicionar os agendamentos necessárias, escolha **Review policy** (Revisar política).
1. Revise o resumo da política e escolha **Create policy** (Criar política).
**nota**
Se receber um erro `Role with name AWSDataLifecycleManagerDefaultRole already exists`, consulte [Solucionar problemas do Amazon Data Lifecycle Manager](dlm-troubleshooting.md) para obter mais informações.
------
#### [ Command line ]
Use o [create-lifecycle-policy](https://docs.aws.amazon.com/cli/latest/reference/dlm/create-lifecycle-policy.html)comando para criar uma política de ciclo de vida de instantâneos. Para `PolicyType`, especifique `EBS_SNAPSHOT_MANAGEMENT`.
**nota**
Para simplificar a sintaxe, os exemplos a seguir usam um arquivo JSON `policyDetails.json`, que inclui os detalhes da política.
**Exemplo 1: política de ciclo de vida de snapshot com duas programações**
Este exemplo cria uma política de ciclo de vida de snapshot que cria snapshots de todos os volumes que têm uma chave de tag de `costcenter` com um valor de `115`. A política inclui duas programações. A primeira programação cria um snapshot todos os dias às 3h UTC. A segunda programação cria um snapshot semanal todas as sextas-feiras às 17h UTC.
```
aws dlm create-lifecycle-policy \
--description "My volume policy" \
--state ENABLED \
--execution-role-arn arn:aws:iam::12345678910:role/AWSDataLifecycleManagerDefaultRole \
--policy-details file://policyDetails.json
```
Este é um exemplo do arquivo `policyDetails.json`.
```
{
"PolicyType": "EBS_SNAPSHOT_MANAGEMENT",
"ResourceTypes": [
"VOLUME"
],
"TargetTags": [{
"Key": "costcenter",
"Value": "115"
}],
"Schedules": [{
"Name": "DailySnapshots",
"TagsToAdd": [{
"Key": "type",
"Value": "myDailySnapshot"
}],
"CreateRule": {
"Interval": 24,
"IntervalUnit": "HOURS",
"Times": [
"03:00"
]
},
"RetainRule": {
"Count": 5
},
"CopyTags": false
},
{
"Name": "WeeklySnapshots",
"TagsToAdd": [{
"Key": "type",
"Value": "myWeeklySnapshot"
}],
"CreateRule": {
"CronExpression": "cron(0 17 ? * FRI *)"
},
"RetainRule": {
"Count": 5
},
"CopyTags": false
}
]}
```
Se a solicitação for bem-sucedida, o comando retornará o ID da política recém-criada. O seguinte é um exemplo de saída.
```
{
"PolicyId": "policy-0123456789abcdef0"
}
```
**Exemplo 2: política de ciclo de vida de snapshot direcionada a instâncias que cria snapshots de um subconjunto de volumes de dados (não raiz)**
Este exemplo cria uma política de ciclo de vida de snapshots de vários volumes com base em instâncias marcadas com `code=production`. A política inclui um agendamento. O agendamento não cria snapshots dos volumes de dados com a etiqueta `code=temp`.
```
aws dlm create-lifecycle-policy \
--description "My volume policy" \
--state ENABLED \
--execution-role-arn arn:aws:iam::12345678910:role/AWSDataLifecycleManagerDefaultRole \
--policy-details file://policyDetails.json
```
Este é um exemplo do arquivo `policyDetails.json`.
```
{
"PolicyType": "EBS_SNAPSHOT_MANAGEMENT",
"ResourceTypes": [
"INSTANCE"
],
"TargetTags": [{
"Key": "code",
"Value": "production"
}],
"Parameters": {
"ExcludeDataVolumeTags": [{
"Key": "code",
"Value": "temp"
}]
},
"Schedules": [{
"Name": "DailySnapshots",
"TagsToAdd": [{
"Key": "type",
"Value": "myDailySnapshot"
}],
"CreateRule": {
"Interval": 24,
"IntervalUnit": "HOURS",
"Times": [
"03:00"
]
},
"RetainRule": {
"Count": 5
},
"CopyTags": false
}
]}
```
Se a solicitação for bem-sucedida, o comando retornará o ID da política recém-criada. O seguinte é um exemplo de saída.
```
{
"PolicyId": "policy-0123456789abcdef0"
}
```
**Exemplo 3: política de ciclo de vida de snapshots que automatiza snapshots locais de recursos do Outpost**
Este exemplo cria uma política de ciclo de vida de snapshots que cria snapshots de volumes marcados com `team=dev` em todos os seus Outposts. A política cria os snapshots nos mesmos Outposts que os volumes de origem. A política cria snapshots a cada `12` horas a partir das `00:00` UTC.
```
aws dlm create-lifecycle-policy \
--description "My local snapshot policy" \
--state ENABLED \
--execution-role-arn arn:aws:iam::12345678910:role/AWSDataLifecycleManagerDefaultRole \
--policy-details file://policyDetails.json
```
Este é um exemplo do arquivo `policyDetails.json`.
```
{
"PolicyType": "EBS_SNAPSHOT_MANAGEMENT",
"ResourceTypes": "VOLUME",
"ResourceLocations": "OUTPOST",
"TargetTags": [{
"Key": "team",
"Value": "dev"
}],
"Schedules": [{
"Name": "on-site backup",
"CreateRule": {
"Interval": 12,
"IntervalUnit": "HOURS",
"Times": [
"00:00"
],
"Location": [
"OUTPOST_LOCAL"
]
},
"RetainRule": {
"Count": 1
},
"CopyTags": false
}
]}
```
**Exemplo 4: política de ciclo de vida de snapshots que cria snapshots em uma região e os copia para um Outpost**
O exemplo de política a seguir cria snapshots de volumes com a tag `team=dev`. Os snapshots são criados na mesma região que o volume de origem. Os snapshots são criados a cada `12` horas a partir das `00:00` UTC e retêm, no máximo, `1` snapshot. A política também copia os snapshots para o Outpost `arn:aws:outposts:us-east-1:123456789012:outpost/op-1234567890abcdef0`, criptografa os snapshots copiados usando a chave do KMS de criptografia padrão e retém as cópias por `1` mês.
```
aws dlm create-lifecycle-policy \
--description "Copy snapshots to Outpost" \
--state ENABLED \
--execution-role-arn arn:aws:iam::12345678910:role/AWSDataLifecycleManagerDefaultRole \
--policy-details file://policyDetails.json
```
Este é um exemplo do arquivo `policyDetails.json`.
```
{
"PolicyType": "EBS_SNAPSHOT_MANAGEMENT",
"ResourceTypes": "VOLUME",
"ResourceLocations": "CLOUD",
"TargetTags": [{
"Key": "team",
"Value": "dev"
}],
"Schedules": [{
"Name": "on-site backup",
"CopyTags": false,
"CreateRule": {
"Interval": 12,
"IntervalUnit": "HOURS",
"Times": [
"00:00"
],
"Location": "CLOUD"
},
"RetainRule": {
"Count": 1
},
"CrossRegionCopyRules" : [
{
"Target": "arn:aws:outposts:us-east-1:123456789012:outpost/op-1234567890abcdef0",
"Encrypted": true,
"CopyTags": true,
"RetainRule": {
"Interval": 1,
"IntervalUnit": "MONTHS"
}
}]
}
]}
```
**Exemplo 5: política de ciclo de vida de snapshots com uma programação baseada em idade habilitada para arquivamento**
Este exemplo cria uma política de ciclo de vida de snapshots que visa volumes marcados com `Name=Prod`. A política tem uma programação baseada em idade que cria snapshots no primeiro dia de cada mês às 9h. A programação retém cada snapshot no nível padrão por um dia e depois o move para o nível de arquivamento. Os snapshots são armazenados no nível de arquivamento por 90 dias antes de serem excluídos.
```
aws dlm create-lifecycle-policy \
--description "Copy snapshots to Outpost" \
--state ENABLED \
--execution-role-arn arn:aws:iam::12345678910:role/AWSDataLifecycleManagerDefaultRole \
--policy-details file://policyDetails.json
```
Este é um exemplo do arquivo `policyDetails.json`.
```
{
"ResourceTypes": [ "VOLUME"],
"PolicyType": "EBS_SNAPSHOT_MANAGEMENT",
"Schedules" : [
{
"Name": "sched1",
"TagsToAdd": [
{"Key":"createdby","Value":"dlm"}
],
"CreateRule": {
"CronExpression": "cron(0 9 1 * ? *)"
},
"CopyTags": true,
"RetainRule":{
"Interval": 1,
"IntervalUnit": "DAYS"
},
"ArchiveRule": {
"RetainRule":{
"RetentionArchiveTier": {
"Interval": 90,
"IntervalUnit": "DAYS"
}
}
}
}
],
"TargetTags": [
{
"Key": "Name",
"Value": "Prod"
}
]
}
```
**Exemplo 6: política de ciclo de vida de snapshots com uma programação baseada em conta habilitada para arquivamento**
Este exemplo cria uma política de ciclo de vida de snapshots que visa volumes marcados com `Purpose=Test`. A política tem uma programação baseada em contagem que cria snapshots no primeiro dia de cada mês às 9h. A programação arquiva os snapshots imediatamente após a criação e retém no máximo três snapshots no nível de arquivamento.
```
aws dlm create-lifecycle-policy \
--description "Copy snapshots to Outpost" \
--state ENABLED \
--execution-role-arn arn:aws:iam::12345678910:role/AWSDataLifecycleManagerDefaultRole \
--policy-details file://policyDetails.json
```
Este é um exemplo do arquivo `policyDetails.json`.
```
{
"ResourceTypes": [ "VOLUME"],
"PolicyType": "EBS_SNAPSHOT_MANAGEMENT",
"Schedules" : [
{
"Name": "sched1",
"TagsToAdd": [
{"Key":"createdby","Value":"dlm"}
],
"CreateRule": {
"CronExpression": "cron(0 9 1 * ? *)"
},
"CopyTags": true,
"RetainRule":{
"Count": 0
},
"ArchiveRule": {
"RetainRule":{
"RetentionArchiveTier": {
"Count": 3
}
}
}
}
],
"TargetTags": [
{
"Key": "Purpose",
"Value": "Test"
}
]
}
```
------
## Considerações sobre políticas de ciclo de vida de snapshots
As seguintes **considerações gerais** se aplicam a políticas de ciclo de vida de snapshot:
+ As políticas de ciclo de vida do snapshot visam somente instâncias ou volumes que estão na mesma região que a política.
+ A primeira operação de criação de snapshot começa uma hora após o horário de início especificado. As operações subsequentes de criação de snapshot começam uma hora após o horário programado.
+ É possível criar várias políticas para fazer backup de um volume ou de uma instância. Por exemplo, se um volume tiver 2 etiquetas, com a etiqueta *A* como o destino da política *A* para criar um snapshot a cada 12 horas, e a etiqueta *B* como o destino da política *B* para criar um snapshot a cada 24 horas, o Amazon Data Lifecycle Manager cria snapshots de acordo com as programações de ambas as políticas. Como alternativa, é possível obter o mesmo resultado criando uma única política que tenha várias programações. Por exemplo, é possível criar uma única política voltada apenas para tag *A* e especificar duas programações: uma para cada 12 horas e uma para cada 24 horas.
+ Tags de recursos de destino diferenciam letras maiúsculas de minúsculas.
+ Se você remover as tags de destino de um recurso visado por uma política, o Amazon Data Lifecycle Manager não gerenciará mais os snapshots existentes no nível padrão e no nível de arquivamento; você deverá excluí-los manualmente se eles não forem mais necessários.
+ Se você criar uma política que segmente instâncias e novos volumes forem anexados à instância-alvo após a criação da política, os volumes recém-adicionados serão incluídos no backup na próxima execução da política. Todos os volumes associados à instância no momento da execução da política são incluídos.
+ Se você criar uma política com uma programação personalizada baseada em cron que esteja configurada para criar apenas um snapshot, a política não excluirá automaticamente esse snapshot quando o limite de retenção for atingido. Exclua manualmente o snapshot caso ele não seja mais necessário.
+ Se você criar uma política baseada na idade em que o período de retenção seja menor do que a frequência de criação, o Amazon Data Lifecycle Manager sempre reterá o último snapshot até que o próximo seja criado. Por exemplo, se uma política baseada na idade criar um snapshot por mês com um período de retenção de sete dias, o Amazon Data Lifecycle Manager reterá cada snapshot por um mês, mesmo que o período de retenção seja de sete dias.
As seguintes considerações se aplicam ao **[arquivamento de snapshots](snapshot-archive.md)**:
+ Você só pode habilitar o arquivamento de snapshots para políticas de snapshots que visem volumes.
+ Você só pode especificar uma regra de arquivamento para uma única programação para cada política.
+ Se você estiver usando o console, só poderá habilitar o arquivamento de snapshots se a programação tiver uma frequência de criação mensal ou anual, ou tiver uma expressão cron com uma frequência de criação de pelo menos 28 dias.
Se você estiver usando a AWS API ou o AWS CLI AWS SDK, poderá ativar o arquivamento de instantâneos somente se o cronograma tiver uma expressão cron com uma frequência de criação de pelo menos 28 dias.
+ O período mínimo de retenção no nível de arquivamento é de 90 dias.
+ Quando um snapshot está arquivado, ele é convertido em um snapshot completo quando é movido para o nível de arquivamento. Isso pode resultar em custos de armazenamento de snapshots mais altos. Para obter mais informações, consulte [Preços e faturamento para o arquivamento de snapshots do Amazon EBS](snapshot-archive-pricing.md).
+ A restauração rápida e o compartilhamento de snapshots são desabilitados para os snapshots quando eles são arquivados.
+ Se, no caso de um ano bissexto, a regra de retenção resultar em um período de retenção de arquivos de menos de 90 dias, o Amazon Data Lifecycle Manager garantirá que os snapshots sejam retidos pelo período mínimo de 90 dias.
+ Se você arquivar manualmente um snapshot criado pelo Amazon Data Lifecycle Manager e o snapshot ainda estiver arquivado quando o limite de retenção da programação for atingido, o Amazon Data Lifecycle Manager não gerenciará mais esse snapshot. Porém, se você restaurar o snapshot no nível padrão antes que o limite de retenção da programação seja atingido, a programação continuará gerenciando o snapshot de acordo com as regras de retenção.
+ Se você restaurar, permanente ou temporariamente, um snapshot arquivado pelo Amazon Data Lifecycle Manager no nível padrão e o snapshot ainda estiver arquivado quando o limite de retenção da programação for atingido, o Amazon Data Lifecycle Manager não gerenciará mais esse snapshot. Porém, se você rearquivar o snapshot antes que o limite de retenção da programação seja atingido, a programação excluirá o snapshot quando o limite de retenção for atingido.
+ Os snapshots arquivados pelo Amazon Data Lifecycle Manager contam para as cotas de `Archived snapshots per volume` e `In-progress snapshot archives per account`.
+ Se uma programação não conseguir arquivar um snapshot após repetidas tentativas durante 24 horas, o snapshot permanecerá no nível padrão e será programado para exclusão com base na hora em que seria excluído do nível de arquivamento. Por exemplo, se a programação arquivar snapshots por 120 dias, o snapshot permanecerá no nível padrão por 120 dias após a falha no arquivamento antes de ser excluído permanentemente. Para programações baseadas em contagem, o snapshot não conta para a contagem de retenção da programação.
+ Os snapshots devem ser arquivados na mesma região em que foram criados. Se você tiver habilitado a cópia e arquivamento de snapshot entre regiões, o Amazon Data Lifecycle Manager não arquivará a cópia do snapshot.
+ Os snapshots arquivados pelo Amazon Data Lifecycle Manager são marcados com a etiqueta `aws:dlm:archived=true` do sistema. Além disso, os snapshots criados por uma programação baseada em idade habilitada para arquivamento são marcados com a tag `aws:dlm:expirationTime` do sistema, que indica a data e a hora em que o snapshot está programado para ser arquivado.
Estas considerações se aplicam a **excluir volumes raiz e volumes de dados (não raiz)**:
+ Se você optar por excluir volumes de inicialização e especificar tags que, consequentemente, excluem todos os volumes de dados adicionais anexados a uma instância, o Amazon Data Lifecycle Manager não criará nenhum snapshot para a instância afetada e emitirá uma métrica. `SnapshotsCreateFailed` CloudWatch Para obter mais informações, consulte [Monitore políticas usando CloudWatch](monitor-dlm-cw-metrics.md).
Os seguintes fatores são aplicáveis à **exclusão de volumes ou ao encerramento de instâncias com direcionamento por políticas de ciclo de vida de snapshots**:
+ Se você excluir um volume ou encerrar uma instância visada por uma política com uma programação de retenção baseada em contagem, o Amazon Data Lifecycle Manager não gerenciará mais os snapshots no nível padrão e no nível de arquivamento que foram criados a partir do volume excluído ou da instância encerrada. Exclua manualmente esses snapshots mais antigos caso eles não sejam mais necessários.
+ Se você excluir um volume ou encerrar uma instância visada por uma política com uma programação de retenção baseada em idade, a política continuará excluir snapshots no nível padrão e no nível de arquivamento que foram criados a partir do volume ou da instância excluídos até restar apenas um snapshot. Exclua manualmente o último snapshot caso ele não seja mais necessário.
As seguintes considerações se aplicam às políticas de ciclo de vida de snapshots e à **[restauração rápida de snapshots](ebs-fast-snapshot-restore.md)**:
+ O Amazon Data Lifecycle Manager pode habilitar a restauração rápida de snapshots somente para snapshots com um tamanho de 16 TiB ou menos. Para obter mais informações, consulte [Restauração rápida de snapshots do Amazon EBS](ebs-fast-snapshot-restore.md).
+ Um snapshot habilitado para restauração rápida continua habilitado mesmo que você exclua ou desabilite a política, desabilite a restauração rápida de snapshots ou desabilite a restauração de snapshots para a zona de disponibilidade. É possível desabilitar a restauração rápida desses snapshots manualmente.
+ Se você habilitar a restauração rápida de snapshots para uma política e exceder o número máximo de snapshots que podem ser habilitados para restauração rápida de snapshots, o Amazon Data Lifecycle Manager criará snapshots, mas não os habilitará para restauração rápida. Depois que um snapshot que está habilitado para restauração rápida for excluído, o próximo snapshot que o Amazon Data Lifecycle Manager criar será habilitado para restauração rápida.
+ Quando a restauração rápida de um snapshot é habilitada, são necessários 60 minutos por TiB para otimizar o snapshot. Recomendamos configurar as programações de modo que cada snapshot seja totalmente otimizado antes que o Amazon Data Lifecycle Manager crie o próximo snapshot.
+ Se você habilitar a restauração rápida de snapshots para uma política que visa instâncias, o Amazon Data Lifecycle Manager habilitará a restauração rápida de snapshot para cada um dos snapshots de vários volumes, definidos individualmente. Se o Amazon Data Lifecycle Manager não habilitar a restauração rápida de snapshots para um dos snapshots no conjunto de snapshots de vários volumes, ele tentará habilitar a restauração rápida para os snapshots restantes no conjunto.
+ Você será cobrado por cada minuto em que a restauração rápida de snapshots estiver habilitada para um snapshot em uma determinada zona de disponibilidade. As cobranças são divididas com um mínimo de uma hora. Para obter mais informações, consulte [Definição de preço e faturamento](ebs-fast-snapshot-restore.md#fsr-pricing).
**nota**
Dependendo da configuração de suas políticas de ciclo de vida, é possível ter vários snapshots habilitados para restauração rápida de snapshots em várias zonas de disponibilidade, simultaneamente.
As considerações a seguir se aplicam às políticas de ciclo de vida de snapshots e aos **volumes habilitados para [multi-attach](ebs-volumes-multi.md)**:
+ Ao criar uma política de ciclo de vida voltada para instâncias que tenham o mesmo volume habilitado de Multi-Attach, o Amazon Data Lifecycle Manager inicia um snapshot do volume para cada instância anexada. Use a tag *timestamp* para identificar o conjunto de snapshots consistentes em relação ao tempo criados das instâncias anexadas.
As considerações a seguir se aplicam ao **compartilhamento de snapshots entre contas**:
+ Você só pode compartilhar snapshots não criptografados ou criptografados usando uma chave gerenciada pelo cliente gerenciada pelo cliente.
+ Você não pode compartilhar snapshots criptografados com a Chave do KMS de criptografia padrão do EBS.
+ Se você compartilhar snapshots criptografados, também deverá compartilhar a chave do KMS usada para criptografar o volume de origem com as contas de destino. Para obter mais informações, consulte [Permissão para usuários em outras contas usarem uma chave KMS](https://docs.aws.amazon.com//kms/latest/developerguide/key-policy-modifying-external-accounts.html) no *Guia de desenvolvedor do AWS Key Management Service *.
As considerações a seguir se aplicam às políticas de snapshots e ao **[arquivamento de snapshots](snapshot-archive.md)**:
+ Se você arquivar manualmente um snapshot criado por uma política e esse snapshot estiver no nível de arquivamento quando o limite de retenção da política for atingido, o Amazon Data Lifecycle Manager não excluirá o snapshot. O Amazon Data Lifecycle Manager não gerencia snapshots enquanto eles são armazenados no nível de arquivamento. Se não precisar mais dos snapshots que estão armazenados no nível de arquivamento, você deve excluí-los manualmente.
As seguintes considerações se aplicam às políticas de snapshots e à [Lixeira](recycle-bin.md):
+ Se o Amazon Data Lifecycle Manager excluir um snapshot e enviá-lo para a lixeira quando o limite de retenção da política for atingido e você restaurar manualmente o snapshot da lixeira, você deverá excluir manualmente esse snapshot quando ele não for mais necessário. O Amazon Data Lifecycle Manager não poderá mais gerenciar o snapshot.
+ Se você excluir manualmente um snapshot criado por uma política e esse snapshot estiver na lixeira quando o limite de retenção da política for atingido, o Amazon Data Lifecycle Manager não excluirá o snapshot. O Amazon Data Lifecycle Manager não gerencia snapshots enquanto eles estão armazenados no nível de arquivamento.
Se o snapshot for restaurado da lixeira antes que o limite de retenção da política seja atingido, o Amazon Data Lifecycle Manager excluirá o snapshot quando o limite de retenção da política for atingido.
Se o snapshot for restaurado da lixeira depois que o limite de retenção da política seja atingido, o Amazon Data Lifecycle Manager não excluirá mais o snapshot. Exclua manualmente o snapshot quando ele não for mais necessário.
As seguintes considerações se aplicam a políticas de ciclo de vida de snapshots que estão no estado **error**:
+ Para políticas com programações de retenção com base na idade, os snapshots configurados para expirar enquanto a política estiver no estado `error` serão retidos por tempo indeterminado. Será necessário excluir os snapshots manualmente. Quando você habilita a política novamente, o Amazon Data Lifecycle Manager retoma a exclusão de snapshots à medida que os períodos de retenção expiram.
+ Para políticas com programas de retenção com base em contagem, a política interrompe a criação e exclusão de snapshots enquanto está no estado `error`. Ao reabilitar a política, o Amazon Data Lifecycle Manager retoma a criação de snapshots e retoma a exclusão de snapshots quando o limite de retenção é atingido.
As seguintes considerações se aplicam às políticas de snapshot e **[bloqueio de snapshot](ebs-snapshot-lock.md)**:
+ Se você bloquear manualmente um snapshot criado pelo Amazon Data Lifecycle Manager e esse snapshot ainda estiver bloqueado quando seu limite de retenção for atingido, o Amazon Data Lifecycle Manager não gerenciará mais esse snapshot. Exclua manualmente o snapshot caso ele não seja mais necessário.
+ Se você bloquear manualmente um snapshot criado e habilitado para restauração rápida de snapshots pelo Amazon Data Lifecycle Manager e o snapshot ainda estiver arquivado quando seu limite de retenção for atingido, o Amazon Data Lifecycle Manager não desabilitará a restauração rápida de snapshots nem excluirá o snapshot. Você deve desabilitar manualmente a restauração rápida de snapshots e excluir o snapshot caso ele não seja mais necessário.
+ Se você registrar manualmente um snapshot criado por Amazon Data Lifecycle Manager com uma AMI e depois bloquear o snapshot e ele ainda estiver bloqueado e associado à AMI quando seu limite de retenção for atingido, o Amazon Data Lifecycle Manager continuará tentando excluir o snapshot. Quando o registro da AMI for cancelado e o snapshot for desbloqueado, o Amazon Data Lifecycle Manager excluirá automaticamente o snapshot.
## Recursos adicionais do
Para obter mais informações, consulte o blog [Automatizando o snapshot e o gerenciamento de AMI do Amazon EBS usando o Amazon AWS Data Lifecycle Manager](https://aws.amazon.com/blogs/storage/automating-amazon-ebs-snapshot-and-ami-management-using-amazon-dlm/).
# Automatizar snapshots consistentes com a aplicação com o Data Lifecycle Manager
Você pode automatizar snapshots consistentes com a aplicação com o Amazon Data Lifecycle Manager habilitando scripts prévios e posteriores nas políticas de ciclo de vida de snapshot que têm as instâncias como alvo.
O Amazon Data Lifecycle Manager se integra ao (Systems AWS Systems Manager Manager) para oferecer suporte a snapshots consistentes com aplicativos. O Amazon Data Lifecycle Manager usa documentos de comando do Systems Manager (SSM) que incluem scripts prévios e posteriores para automatizar as ações necessárias para fazer snapshots consistentes com a aplicação. Antes de o Amazon Data Lifecycle Manager iniciar a criação do snapshot, ele executa os comandos no pré-script para congelar e liberar. I/O. After Amazon Data Lifecycle Manager initiates snapshot creation, it runs the commands in the post script to thaw I/O
Usando o Amazon Data Lifecycle Manager, você pode automatizar os snapshots consistentes com a aplicação dos seguintes itens:
+ Aplicações do Windows que usam o Volume Shadow Copy Service (VSS)
+ SAP HANA usando um documento AWS SSDM gerenciado. Para obter mais informações, consulte [Amazon EBS snapshots for SAP HANA](https://docs.aws.amazon.com/sap/latest/sap-hana/ebs-sap-hana.html).
+ Bancos de dados autogerenciados, como MySQL, PostgreSQL ou IRIS, usando modelos de documentos SSM InterSystems
**Topics**
+ [Requisitos para o uso de scripts prévios e posteriores](#app-consistent-prereqs)
+ [Conceitos básicos dos snapshots consistentes com a aplicação](#app-consistent-get-started)
+ [Considerações sobre os backups do VSS com o Amazon Data Lifecycle Manager](#app-consistent-vss)
+ [Responsabilidade compartilhada pelos snapshots consistentes com a aplicação](#shared-responsibility)
## Requisitos para o uso de scripts prévios e posteriores
A tabela a seguir descreve os requisitos para o uso de scripts prévios e posteriores com o Amazon Data Lifecycle Manager.
| | Snapshots consistentes com aplicação | |
| --- |--- |--- |
| Requisito | Backup do VSS | Documento do SSM personalizado | Outros casos de uso |
| --- |--- |--- |--- |
| Agente SSM instalado e em execução nas instâncias de destino | ✓ | ✓ | ✓ |
| Requisitos do sistema VSS atendidos nas instâncias de destino | ✓ | | |
| Perfil de instância habilitado para VSS associado às instâncias de destino | ✓ | | |
| Componentes do VSS instalados nas instâncias de destino | ✓ | | |
| Prepare o documento SSM com comandos pré e pós-script | | ✓ | ✓ |
| Prepare a função IAM do Amazon Data Lifecycle Manager, execute scripts pré e pós | ✓ | ✓ | ✓ |
| Crie uma política de snapshot que vise instâncias e seja configurada para scripts anteriores e posteriores | ✓ | ✓ | ✓ |
## Conceitos básicos dos snapshots consistentes com a aplicação
Esta seção explica as etapas que você precisa seguir para automatizar snapshots consistentes com a aplicação usando o Amazon Data Lifecycle Manager.
### Etapa 1: preparar as instâncias-alvo
Você precisa preparar as instâncias-alvo para snapshots consistentes com a aplicação usando o Amazon Data Lifecycle Manager. Dependendo do caso de uso, faça um dos procedimentos a seguir.
------
#### [ Prepare for VSS Backups ]
**Para preparar as instâncias-alvo para backups do VSS**
1. Instale o SSM Agent nas instâncias-alvo, se ainda não estiver instalado. Se o SSM Agent já estiver instalado em suas instâncias-alvo, pule esta etapa.
Para obter mais informações, consulte [Trabalho com o SSM Agent em instâncias do EC2 para o Windows Server](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-windows.html).
1. Certifique-se de que o SSM Agent esteja em execução. Para obter mais informações, consulte [Verificar o status do SSM Agent e iniciar o agente](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-status-and-restart.html).
1. Configure o Systems Manager para instâncias do Amazon EC2. Para obter mais informações, consulte [Configuração do Systems Manager para instâncias Amazon EC2](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-setting-up-ec2.html) no *Guia do usuário do AWS Systems Manager *.
1. [Certifique-se de que os requisitos do sistema para backups do VSS sejam atendidos](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/application-consistent-snapshots-prereqs.html).
1. [ Anexe um perfil de instância habilitado para o VSS às instâncias-alvo.](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/vss-iam-reqs.html)
1. [Instale os componentes do VSS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/application-consistent-snapshots-getting-started.html).
------
#### [ Prepare for SAP HANA backups ]
**Para preparar as instâncias-alvo para backups do SAP HANA**
1. Prepare o ambiente do SAP HANA nas instâncias-alvo.
1. Configure a instância com o SAP HANA. Se você ainda não tiver um ambiente do SAP HANA, pode consultar [SAP HANA Environment Setup on AWS](https://docs.aws.amazon.com/sap/latest/sap-hana/std-sap-hana-environment-setup.html).
1. Faça login no SystemDB como um usuário administrador adequado.
1. Crie um usuário de backup de banco de dados para ser usado com o Amazon Data Lifecycle Manager.
```
CREATE USER username PASSWORD password NO FORCE_FIRST_PASSWORD_CHANGE;
```
Por exemplo, o comando a seguir criar um usuário denominado `dlm_user` com a senha `password`.
```
CREATE USER dlm_user PASSWORD password NO FORCE_FIRST_PASSWORD_CHANGE;
```
1. Atribua um perfil de `BACKUP OPERATOR` ao usuário de backup do banco de dados que você criou na etapa anterior.
```
GRANT BACKUP OPERATOR TO username
```
Por exemplo, o comando a seguir atribui o perfil a um usuário denominado `dlm_user`.
```
GRANT BACKUP OPERATOR TO dlm_user
```
1. Faça login no sistema operacional como administrador, por exemplo `sidadm`.
1. Crie uma entrada `hdbuserstore` para armazenar as informações de conexão para que o documento do SSM do SAP HANA possa se conectar ao SAP HANA sem que os usuários precisem inserir as informações.
```
hdbuserstore set DLM_HANADB_SNAPSHOT_USER localhost:3hana_instance_number13 username password
```
Por exemplo:
```
hdbuserstore set DLM_HANADB_SNAPSHOT_USER localhost:30013 dlm_user password
```
1. Teste a conexão.
```
hdbsql -U DLM_HANADB_SNAPSHOT_USER "select * from dummy"
```
1. Instale o SSM Agent nas instâncias-alvo, se ainda não estiver instalado. Se o SSM Agent já estiver instalado em suas instâncias-alvo, pule esta etapa.
Para obter mais informações, consulte [Instalar manualmente o SSM Agent em instâncias do EC2 para Linux](https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-linux.html).
1. Certifique-se de que o SSM Agent esteja em execução. Para obter mais informações, consulte [Verificar o status do SSM Agent e iniciar o agente](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-status-and-restart.html).
1. Configure o Systems Manager para instâncias do Amazon EC2. Para obter mais informações, consulte [Configuração do Systems Manager para instâncias Amazon EC2](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-setting-up-ec2.html) no *AWS Systems Manager Guia do usuário do *.
------
#### [ Prepare for custom SSM documents ]
**Para preparar os documentos do SSM personalizados das instâncias-alvo**
1. Instale o SSM Agent nas instâncias-alvo, se ainda não estiver instalado. Se o SSM Agent já estiver instalado em suas instâncias-alvo, pule esta etapa.
+ (Instâncias do Linux) [Instalar o SSM Agent manualmente em instâncias do EC2 para Linux](https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-linux.html)
+ (Instâncias do Windows) [Trabalhar com o SSM Agent em instâncias do EC2 para Windows Server](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-windows.html)
1. Certifique-se de que o SSM Agent esteja em execução. Para obter mais informações, consulte [Verificar o status do SSM Agent e iniciar o agente](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-status-and-restart.html).
1. Configure o Systems Manager para instâncias do Amazon EC2. Para obter mais informações, consulte [Configuração do Systems Manager para instâncias Amazon EC2](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-setting-up-ec2.html) no *AWS Systems Manager Guia do usuário do *.
------
### Etapa 2: preparar o documento do SSM
**nota**
Essa etapa só é necessária para documentos do SSM personalizados. Não é necessária para backup do VSS ou para o SAP HANA. Para backups do VSS e SAP HANA, o Amazon Data Lifecycle Manager AWS usa o documento SSM gerenciado.
Se você estiver automatizando instantâneos consistentes com aplicativos para um banco de dados autogerenciado, como MySQL, PostgreSQL InterSystems ou IRIS, deverá criar um documento de comando SSM que inclua um pré-script para congelar e I/O liberar antes do início da criação do instantâneo e um pós-script para descongelar após o início da criação do instantâneo. I/O
Se seu banco de dados MySQL, PostgreSQL ou InterSystems IRIS usa configurações padrão, você pode criar um documento de comando SSM usando o conteúdo de amostra do documento SSM abaixo. Se seu banco de dados MySQL, PostgreSQL ou InterSystems IRIS usa uma configuração não padrão, você pode usar o conteúdo de amostra abaixo como ponto de partida para seu documento de comando SSM e depois personalizá-lo para atender às suas necessidades. Ou então, se quiser criar um novo documento do SSM começando do zero, você pode usar o modelo de documento do SSM em branco abaixo e adicionar seus comandos prévios e posteriores nas seções apropriadas do documento.
**Observe o seguinte:**
É sua responsabilidade garantir que o documento do SSM realize as ações corretas e necessárias para a configuração do banco de dados.
Só haverá garantia de que os snapshots sejam consistentes com a aplicação se os scripts prévios e posteriores no documento do SSM puderem congelar, descarregar e descongelar a E/S com sucesso.
O documento do SSM deve incluir os campos obrigatórios para `allowedValues`, incluindo `pre-script`, `post-script` e `dry-run`. O Amazon Data Lifecycle Manager executará os comandos na instância com base no conteúdo dessas seções. Se o documento do SSM não tiver essas seções, o Amazon Data Lifecycle Manager o tratará como uma execução que falhou.
------
#### [ MySQL sample document content ]
```
###===============================================================================###
# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
# Permission is hereby granted, free of charge, to any person obtaining a copy of this
# software and associated documentation files (the "Software"), to deal in the Software
# without restriction, including without limitation the rights to use, copy, modify,
# merge, publish, distribute, sublicense, and/or sell copies of the Software, and to
# permit persons to whom the Software is furnished to do so.
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED,
# INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A
# PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
# HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
# OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
# SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
###===============================================================================###
schemaVersion: '2.2'
description: Amazon Data Lifecycle Manager Pre/Post script for MySQL databases
parameters:
executionId:
type: String
default: None
description: (Required) Specifies the unique identifier associated with a pre and/or post execution
allowedPattern: ^(None|[a-fA-F0-9]{8}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{12})$
command:
# Data Lifecycle Manager will trigger the pre-script and post-script actions during policy execution.
# 'dry-run' option is intended for validating the document execution without triggering any commands
# on the instance. The following allowedValues will allow Data Lifecycle Manager to successfully
# trigger pre and post script actions.
type: String
default: 'dry-run'
description: (Required) Specifies whether pre-script and/or post-script should be executed.
allowedValues:
- pre-script
- post-script
- dry-run
mainSteps:
- action: aws:runShellScript
description: Run MySQL Database freeze/thaw commands
name: run_pre_post_scripts
precondition:
StringEquals:
- platformType
- Linux
inputs:
runCommand:
- |
#!/bin/bash
###===============================================================================###
### Error Codes
###===============================================================================###
# The following Error codes will inform Data Lifecycle Manager of the type of error
# and help guide handling of the error.
# The Error code will also be emitted via AWS Eventbridge events in the 'cause' field.
# 1 Pre-script failed during execution - 201
# 2 Post-script failed during execution - 202
# 3 Auto thaw occurred before post-script was initiated - 203
# 4 Pre-script initiated while post-script was expected - 204
# 5 Post-script initiated while pre-script was expected - 205
# 6 Application not ready for pre or post-script initiation - 206
###=================================================================###
### Global variables
###=================================================================###
START=$(date +%s)
# For testing this script locally, replace the below with OPERATION=$1.
OPERATION={{ command }}
FS_ALREADY_FROZEN_ERROR='freeze failed: Device or resource busy'
FS_ALREADY_THAWED_ERROR='unfreeze failed: Invalid argument'
FS_BUSY_ERROR='mount point is busy'
# Auto thaw is a fail safe mechanism to automatically unfreeze the application after the
# duration specified in the global variable below. Choose the duration based on your
# database application's tolerance to freeze.
export AUTO_THAW_DURATION_SECS="60"
# Add all pre-script actions to be performed within the function below
execute_pre_script() {
echo "INFO: Start execution of pre-script"
# Check if filesystem is already frozen. No error code indicates that filesystem
# is not currently frozen and that the pre-script can proceed with freezing the filesystem.
check_fs_freeze
# Execute the DB commands to flush the DB in preparation for snapshot
snap_db
# Freeze the filesystem. No error code indicates that filesystem was succefully frozen
freeze_fs
echo "INFO: Schedule Auto Thaw to execute in ${AUTO_THAW_DURATION_SECS} seconds."
$(nohup bash -c execute_schedule_auto_thaw >/dev/null 2>&1 &)
}
# Add all post-script actions to be performed within the function below
execute_post_script() {
echo "INFO: Start execution of post-script"
# Unfreeze the filesystem. No error code indicates that filesystem was successfully unfrozen.
unfreeze_fs
thaw_db
}
# Execute Auto Thaw to automatically unfreeze the application after the duration configured
# in the AUTO_THAW_DURATION_SECS global variable.
execute_schedule_auto_thaw() {
sleep ${AUTO_THAW_DURATION_SECS}
execute_post_script
}
# Disable Auto Thaw if it is still enabled
execute_disable_auto_thaw() {
echo "INFO: Attempting to disable auto thaw if enabled"
auto_thaw_pgid=$(pgrep -f execute_schedule_auto_thaw | xargs -i ps -hp {} -o pgid)
if [ -n "${auto_thaw_pgid}" ]; then
echo "INFO: execute_schedule_auto_thaw process found with pgid ${auto_thaw_pgid}"
sudo pkill -g ${auto_thaw_pgid}
rc=$?
if [ ${rc} != 0 ]; then
echo "ERROR: Unable to kill execute_schedule_auto_thaw process. retval=${rc}"
else
echo "INFO: Auto Thaw has been disabled"
fi
fi
}
# Iterate over all the mountpoints and check if filesystem is already in freeze state.
# Return error code 204 if any of the mount points are already frozen.
check_fs_freeze() {
for target in $(lsblk -nlo MOUNTPOINTS)
do
# Freeze of the root and boot filesystems is dangerous and pre-script does not freeze these filesystems.
# Hence, we will skip the root and boot mountpoints while checking if filesystem is in freeze state.
if [ $target == '/' ]; then continue; fi
if [[ "$target" == *"/boot"* ]]; then continue; fi
error_message=$(sudo mount -o remount,noatime $target 2>&1)
# Remount will be a no-op without a error message if the filesystem is unfrozen.
# However, if filesystem is already frozen, remount will fail with busy error message.
if [ $? -ne 0 ];then
# If the filesystem is already in frozen, return error code 204
if [[ "$error_message" == *"$FS_BUSY_ERROR"* ]];then
echo "ERROR: Filesystem ${target} already frozen. Return Error Code: 204"
exit 204
fi
# If the check filesystem freeze failed due to any reason other than the filesystem already frozen, return 201
echo "ERROR: Failed to check_fs_freeze on mountpoint $target due to error - $errormessage"
exit 201
fi
done
}
# Iterate over all the mountpoints and freeze the filesystem.
freeze_fs() {
for target in $(lsblk -nlo MOUNTPOINTS)
do
# Freeze of the root and boot filesystems is dangerous. Hence, skip filesystem freeze
# operations for root and boot mountpoints.
if [ $target == '/' ]; then continue; fi
if [[ "$target" == *"/boot"* ]]; then continue; fi
echo "INFO: Freezing $target"
error_message=$(sudo fsfreeze -f $target 2>&1)
if [ $? -ne 0 ];then
# If the filesystem is already in frozen, return error code 204
if [[ "$error_message" == *"$FS_ALREADY_FROZEN_ERROR"* ]]; then
echo "ERROR: Filesystem ${target} already frozen. Return Error Code: 204"
sudo mysql -e 'UNLOCK TABLES;'
exit 204
fi
# If the filesystem freeze failed due to any reason other than the filesystem already frozen, return 201
echo "ERROR: Failed to freeze mountpoint $targetdue due to error - $errormessage"
thaw_db
exit 201
fi
echo "INFO: Freezing complete on $target"
done
}
# Iterate over all the mountpoints and unfreeze the filesystem.
unfreeze_fs() {
for target in $(lsblk -nlo MOUNTPOINTS)
do
# Freeze of the root and boot filesystems is dangerous and pre-script does not freeze these filesystems.
# Hence, will skip the root and boot mountpoints during unfreeze as well.
if [ $target == '/' ]; then continue; fi
if [[ "$target" == *"/boot"* ]]; then continue; fi
echo "INFO: Thawing $target"
error_message=$(sudo fsfreeze -u $target 2>&1)
# Check if filesystem is already unfrozen (thawed). Return error code 204 if filesystem is already unfrozen.
if [ $? -ne 0 ]; then
if [[ "$error_message" == *"$FS_ALREADY_THAWED_ERROR"* ]]; then
echo "ERROR: Filesystem ${target} is already in thaw state. Return Error Code: 205"
exit 205
fi
# If the filesystem unfreeze failed due to any reason other than the filesystem already unfrozen, return 202
echo "ERROR: Failed to unfreeze mountpoint $targetdue due to error - $errormessage"
exit 202
fi
echo "INFO: Thaw complete on $target"
done
}
snap_db() {
# Run the flush command only when MySQL DB service is up and running
sudo systemctl is-active --quiet mysqld.service
if [ $? -eq 0 ]; then
echo "INFO: Execute MySQL Flush and Lock command."
sudo mysql -e 'FLUSH TABLES WITH READ LOCK;'
# If the MySQL Flush and Lock command did not succeed, return error code 201 to indicate pre-script failure
if [ $? -ne 0 ]; then
echo "ERROR: MySQL FLUSH TABLES WITH READ LOCK command failed."
exit 201
fi
sync
else
echo "INFO: MySQL service is inactive. Skipping execution of MySQL Flush and Lock command."
fi
}
thaw_db() {
# Run the unlock command only when MySQL DB service is up and running
sudo systemctl is-active --quiet mysqld.service
if [ $? -eq 0 ]; then
echo "INFO: Execute MySQL Unlock"
sudo mysql -e 'UNLOCK TABLES;'
else
echo "INFO: MySQL service is inactive. Skipping execution of MySQL Unlock command."
fi
}
export -f execute_schedule_auto_thaw
export -f execute_post_script
export -f unfreeze_fs
export -f thaw_db
# Debug logging for parameters passed to the SSM document
echo "INFO: ${OPERATION} starting at $(date) with executionId: ${EXECUTION_ID}"
# Based on the command parameter value execute the function that supports
# pre-script/post-script operation
case ${OPERATION} in
pre-script)
execute_pre_script
;;
post-script)
execute_post_script
execute_disable_auto_thaw
;;
dry-run)
echo "INFO: dry-run option invoked - taking no action"
;;
*)
echo "ERROR: Invalid command parameter passed. Please use either pre-script, post-script, dry-run."
exit 1 # return failure
;;
esac
END=$(date +%s)
# Debug Log for profiling the script time
echo "INFO: ${OPERATION} completed at $(date). Total runtime: $((${END} - ${START})) seconds."
```
------
#### [ PostgreSQL sample document content ]
```
###===============================================================================###
# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
# Permission is hereby granted, free of charge, to any person obtaining a copy of this
# software and associated documentation files (the "Software"), to deal in the Software
# without restriction, including without limitation the rights to use, copy, modify,
# merge, publish, distribute, sublicense, and/or sell copies of the Software, and to
# permit persons to whom the Software is furnished to do so.
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED,
# INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A
# PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
# HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
# OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
# SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
###===============================================================================###
schemaVersion: '2.2'
description: Amazon Data Lifecycle Manager Pre/Post script for PostgreSQL databases
parameters:
executionId:
type: String
default: None
description: (Required) Specifies the unique identifier associated with a pre and/or post execution
allowedPattern: ^(None|[a-fA-F0-9]{8}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{12})$
command:
# Data Lifecycle Manager will trigger the pre-script and post-script actions during policy execution.
# 'dry-run' option is intended for validating the document execution without triggering any commands
# on the instance. The following allowedValues will allow Data Lifecycle Manager to successfully
# trigger pre and post script actions.
type: String
default: 'dry-run'
description: (Required) Specifies whether pre-script and/or post-script should be executed.
allowedValues:
- pre-script
- post-script
- dry-run
mainSteps:
- action: aws:runShellScript
description: Run PostgreSQL Database freeze/thaw commands
name: run_pre_post_scripts
precondition:
StringEquals:
- platformType
- Linux
inputs:
runCommand:
- |
#!/bin/bash
###===============================================================================###
### Error Codes
###===============================================================================###
# The following Error codes will inform Data Lifecycle Manager of the type of error
# and help guide handling of the error.
# The Error code will also be emitted via AWS Eventbridge events in the 'cause' field.
# 1 Pre-script failed during execution - 201
# 2 Post-script failed during execution - 202
# 3 Auto thaw occurred before post-script was initiated - 203
# 4 Pre-script initiated while post-script was expected - 204
# 5 Post-script initiated while pre-script was expected - 205
# 6 Application not ready for pre or post-script initiation - 206
###===============================================================================###
### Global variables
###===============================================================================###
START=$(date +%s)
OPERATION={{ command }}
FS_ALREADY_FROZEN_ERROR='freeze failed: Device or resource busy'
FS_ALREADY_THAWED_ERROR='unfreeze failed: Invalid argument'
FS_BUSY_ERROR='mount point is busy'
# Auto thaw is a fail safe mechanism to automatically unfreeze the application after the
# duration specified in the global variable below. Choose the duration based on your
# database application's tolerance to freeze.
export AUTO_THAW_DURATION_SECS="60"
# Add all pre-script actions to be performed within the function below
execute_pre_script() {
echo "INFO: Start execution of pre-script"
# Check if filesystem is already frozen. No error code indicates that filesystem
# is not currently frozen and that the pre-script can proceed with freezing the filesystem.
check_fs_freeze
# Execute the DB commands to flush the DB in preparation for snapshot
snap_db
# Freeze the filesystem. No error code indicates that filesystem was succefully frozen
freeze_fs
echo "INFO: Schedule Auto Thaw to execute in ${AUTO_THAW_DURATION_SECS} seconds."
$(nohup bash -c execute_schedule_auto_thaw >/dev/null 2>&1 &)
}
# Add all post-script actions to be performed within the function below
execute_post_script() {
echo "INFO: Start execution of post-script"
# Unfreeze the filesystem. No error code indicates that filesystem was successfully unfrozen
unfreeze_fs
}
# Execute Auto Thaw to automatically unfreeze the application after the duration configured
# in the AUTO_THAW_DURATION_SECS global variable.
execute_schedule_auto_thaw() {
sleep ${AUTO_THAW_DURATION_SECS}
execute_post_script
}
# Disable Auto Thaw if it is still enabled
execute_disable_auto_thaw() {
echo "INFO: Attempting to disable auto thaw if enabled"
auto_thaw_pgid=$(pgrep -f execute_schedule_auto_thaw | xargs -i ps -hp {} -o pgid)
if [ -n "${auto_thaw_pgid}" ]; then
echo "INFO: execute_schedule_auto_thaw process found with pgid ${auto_thaw_pgid}"
sudo pkill -g ${auto_thaw_pgid}
rc=$?
if [ ${rc} != 0 ]; then
echo "ERROR: Unable to kill execute_schedule_auto_thaw process. retval=${rc}"
else
echo "INFO: Auto Thaw has been disabled"
fi
fi
}
# Iterate over all the mountpoints and check if filesystem is already in freeze state.
# Return error code 204 if any of the mount points are already frozen.
check_fs_freeze() {
for target in $(lsblk -nlo MOUNTPOINTS)
do
# Freeze of the root and boot filesystems is dangerous and pre-script does not freeze these filesystems.
# Hence, we will skip the root and boot mountpoints while checking if filesystem is in freeze state.
if [ $target == '/' ]; then continue; fi
if [[ "$target" == *"/boot"* ]]; then continue; fi
error_message=$(sudo mount -o remount,noatime $target 2>&1)
# Remount will be a no-op without a error message if the filesystem is unfrozen.
# However, if filesystem is already frozen, remount will fail with busy error message.
if [ $? -ne 0 ];then
# If the filesystem is already in frozen, return error code 204
if [[ "$error_message" == *"$FS_BUSY_ERROR"* ]];then
echo "ERROR: Filesystem ${target} already frozen. Return Error Code: 204"
exit 204
fi
# If the check filesystem freeze failed due to any reason other than the filesystem already frozen, return 201
echo "ERROR: Failed to check_fs_freeze on mountpoint $target due to error - $errormessage"
exit 201
fi
done
}
# Iterate over all the mountpoints and freeze the filesystem.
freeze_fs() {
for target in $(lsblk -nlo MOUNTPOINTS)
do
# Freeze of the root and boot filesystems is dangerous. Hence, skip filesystem freeze
# operations for root and boot mountpoints.
if [ $target == '/' ]; then continue; fi
if [[ "$target" == *"/boot"* ]]; then continue; fi
echo "INFO: Freezing $target"
error_message=$(sudo fsfreeze -f $target 2>&1)
if [ $? -ne 0 ];then
# If the filesystem is already in frozen, return error code 204
if [[ "$error_message" == *"$FS_ALREADY_FROZEN_ERROR"* ]]; then
echo "ERROR: Filesystem ${target} already frozen. Return Error Code: 204"
exit 204
fi
# If the filesystem freeze failed due to any reason other than the filesystem already frozen, return 201
echo "ERROR: Failed to freeze mountpoint $targetdue due to error - $errormessage"
exit 201
fi
echo "INFO: Freezing complete on $target"
done
}
# Iterate over all the mountpoints and unfreeze the filesystem.
unfreeze_fs() {
for target in $(lsblk -nlo MOUNTPOINTS)
do
# Freeze of the root and boot filesystems is dangerous and pre-script does not freeze these filesystems.
# Hence, will skip the root and boot mountpoints during unfreeze as well.
if [ $target == '/' ]; then continue; fi
if [[ "$target" == *"/boot"* ]]; then continue; fi
echo "INFO: Thawing $target"
error_message=$(sudo fsfreeze -u $target 2>&1)
# Check if filesystem is already unfrozen (thawed). Return error code 204 if filesystem is already unfrozen.
if [ $? -ne 0 ]; then
if [[ "$error_message" == *"$FS_ALREADY_THAWED_ERROR"* ]]; then
echo "ERROR: Filesystem ${target} is already in thaw state. Return Error Code: 205"
exit 205
fi
# If the filesystem unfreeze failed due to any reason other than the filesystem already unfrozen, return 202
echo "ERROR: Failed to unfreeze mountpoint $targetdue due to error - $errormessage"
exit 202
fi
echo "INFO: Thaw complete on $target"
done
}
snap_db() {
# Run the flush command only when PostgreSQL DB service is up and running
sudo systemctl is-active --quiet postgresql
if [ $? -eq 0 ]; then
echo "INFO: Execute Postgres CHECKPOINT"
# PostgreSQL command to flush the transactions in memory to disk
sudo -u postgres psql -c 'CHECKPOINT;'
# If the PostgreSQL Command did not succeed, return error code 201 to indicate pre-script failure
if [ $? -ne 0 ]; then
echo "ERROR: Postgres CHECKPOINT command failed."
exit 201
fi
sync
else
echo "INFO: PostgreSQL service is inactive. Skipping execution of CHECKPOINT command."
fi
}
export -f execute_schedule_auto_thaw
export -f execute_post_script
export -f unfreeze_fs
# Debug logging for parameters passed to the SSM document
echo "INFO: ${OPERATION} starting at $(date) with executionId: ${EXECUTION_ID}"
# Based on the command parameter value execute the function that supports
# pre-script/post-script operation
case ${OPERATION} in
pre-script)
execute_pre_script
;;
post-script)
execute_post_script
execute_disable_auto_thaw
;;
dry-run)
echo "INFO: dry-run option invoked - taking no action"
;;
*)
echo "ERROR: Invalid command parameter passed. Please use either pre-script, post-script, dry-run."
exit 1 # return failure
;;
esac
END=$(date +%s)
# Debug Log for profiling the script time
echo "INFO: ${OPERATION} completed at $(date). Total runtime: $((${END} - ${START})) seconds."
```
------
#### [ InterSystems IRIS sample document content ]
```
###===============================================================================###
# MIT License
#
# Copyright (c) 2024 InterSystems
#
# Permission is hereby granted, free of charge, to any person obtaining a copy
# of this software and associated documentation files (the "Software"), to deal
# in the Software without restriction, including without limitation the rights
# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
# copies of the Software, and to permit persons to whom the Software is
# furnished to do so, subject to the following conditions:
#
# The above copyright notice and this permission notice shall be included in all
# copies or substantial portions of the Software.
#
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
# SOFTWARE.
###===============================================================================###
schemaVersion: '2.2'
description: SSM Document Template for Amazon Data Lifecycle Manager Pre/Post script feature for InterSystems IRIS.
parameters:
executionId:
type: String
default: None
description: Specifies the unique identifier associated with a pre and/or post execution
allowedPattern: ^(None|[a-fA-F0-9]{8}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{12})$
command:
type: String
# Data Lifecycle Manager will trigger the pre-script and post-script actions. You can also use this SSM document with 'dry-run' for manual testing purposes.
default: 'dry-run'
description: (Required) Specifies whether pre-script and/or post-script should be executed.
#The following allowedValues will allow Data Lifecycle Manager to successfully trigger pre and post script actions.
allowedValues:
- pre-script
- post-script
- dry-run
mainSteps:
- action: aws:runShellScript
description: Run InterSystems IRIS Database freeze/thaw commands
name: run_pre_post_scripts
precondition:
StringEquals:
- platformType
- Linux
inputs:
runCommand:
- |
#!/bin/bash
###===============================================================================###
### Global variables
###===============================================================================###
DOCKER_NAME=iris
LOGDIR=./
EXIT_CODE=0
OPERATION={{ command }}
START=$(date +%s)
# Check if Docker is installed
# By default if Docker is present, script assumes that InterSystems IRIS is running in Docker
# Leave only the else block DOCKER_EXEC line, if you run InterSystems IRIS non-containerised (and Docker is present).
# Script assumes irissys user has OS auth enabled, change the OS user or supply login/password depending on your configuration.
if command -v docker &> /dev/null
then
DOCKER_EXEC="docker exec $DOCKER_NAME"
else
DOCKER_EXEC="sudo -i -u irissys"
fi
# Add all pre-script actions to be performed within the function below
execute_pre_script() {
echo "INFO: Start execution of pre-script"
# find all iris running instances
iris_instances=$($DOCKER_EXEC iris qall 2>/dev/null | tail -n +3 | grep '^up' | cut -c5- | awk '{print $1}')
echo "`date`: Running iris instances $iris_instances"
# Only for running instances
for INST in $iris_instances; do
echo "`date`: Attempting to freeze $INST"
# Detailed instances specific log
LOGFILE=$LOGDIR/$INST-pre_post.log
#check Freeze status before starting
$DOCKER_EXEC irissession $INST -U '%SYS' "##Class(Backup.General).IsWDSuspendedExt()"
freeze_status=$?
if [ $freeze_status -eq 5 ]; then
echo "`date`: ERROR: $INST IS already FROZEN"
EXIT_CODE=204
else
echo "`date`: $INST is not frozen"
# Freeze
# Docs: https://docs.intersystems.com/irislatest/csp/documatic/%25CSP.Documatic.cls?LIBRARY=%25SYS&CLASSNAME=Backup.General#ExternalFreeze
$DOCKER_EXEC irissession $INST -U '%SYS' "##Class(Backup.General).ExternalFreeze(\"$LOGFILE\",,,,,,600,,,300)"
status=$?
case $status in
5) echo "`date`: $INST IS FROZEN"
;;
3) echo "`date`: $INST FREEZE FAILED"
EXIT_CODE=201
;;
*) echo "`date`: ERROR: Unknown status code: $status"
EXIT_CODE=201
;;
esac
echo "`date`: Completed freeze of $INST"
fi
done
echo "`date`: Pre freeze script finished"
}
# Add all post-script actions to be performed within the function below
execute_post_script() {
echo "INFO: Start execution of post-script"
# find all iris running instances
iris_instances=$($DOCKER_EXEC iris qall 2>/dev/null | tail -n +3 | grep '^up' | cut -c5- | awk '{print $1}')
echo "`date`: Running iris instances $iris_instances"
# Only for running instances
for INST in $iris_instances; do
echo "`date`: Attempting to thaw $INST"
# Detailed instances specific log
LOGFILE=$LOGDIR/$INST-pre_post.log
#check Freeze status befor starting
$DOCKER_EXEC irissession $INST -U '%SYS' "##Class(Backup.General).IsWDSuspendedExt()"
freeze_status=$?
if [ $freeze_status -eq 5 ]; then
echo "`date`: $INST is in frozen state"
# Thaw
# Docs: https://docs.intersystems.com/irislatest/csp/documatic/%25CSP.Documatic.cls?LIBRARY=%25SYS&CLASSNAME=Backup.General#ExternalFreeze
$DOCKER_EXEC irissession $INST -U%SYS "##Class(Backup.General).ExternalThaw(\"$LOGFILE\")"
status=$?
case $status in
5) echo "`date`: $INST IS THAWED"
$DOCKER_EXEC irissession $INST -U%SYS "##Class(Backup.General).ExternalSetHistory(\"$LOGFILE\")"
;;
3) echo "`date`: $INST THAW FAILED"
EXIT_CODE=202
;;
*) echo "`date`: ERROR: Unknown status code: $status"
EXIT_CODE=202
;;
esac
echo "`date`: Completed thaw of $INST"
else
echo "`date`: ERROR: $INST IS already THAWED"
EXIT_CODE=205
fi
done
echo "`date`: Post thaw script finished"
}
# Debug logging for parameters passed to the SSM document
echo "INFO: ${OPERATION} starting at $(date) with executionId: ${EXECUTION_ID}"
# Based on the command parameter value execute the function that supports
# pre-script/post-script operation
case ${OPERATION} in
pre-script)
execute_pre_script
;;
post-script)
execute_post_script
;;
dry-run)
echo "INFO: dry-run option invoked - taking no action"
;;
*)
echo "ERROR: Invalid command parameter passed. Please use either pre-script, post-script, dry-run."
# return failure
EXIT_CODE=1
;;
esac
END=$(date +%s)
# Debug Log for profiling the script time
echo "INFO: ${OPERATION} completed at $(date). Total runtime: $((${END} - ${START})) seconds."
exit $EXIT_CODE
```
Para obter mais informações, consulte o [GitHub repositório.](https://github.com/intersystems-community/aws/blob/master/README.md)
------
#### [ Empty document template ]
```
###===============================================================================###
# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
# Permission is hereby granted, free of charge, to any person obtaining a copy of this
# software and associated documentation files (the "Software"), to deal in the Software
# without restriction, including without limitation the rights to use, copy, modify,
# merge, publish, distribute, sublicense, and/or sell copies of the Software, and to
# permit persons to whom the Software is furnished to do so.
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED,
# INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A
# PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
# HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
# OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
# SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
###===============================================================================###
schemaVersion: '2.2'
description: SSM Document Template for Amazon Data Lifecycle Manager Pre/Post script feature
parameters:
executionId:
type: String
default: None
description: (Required) Specifies the unique identifier associated with a pre and/or post execution
allowedPattern: ^(None|[a-fA-F0-9]{8}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{12})$
command:
# Data Lifecycle Manager will trigger the pre-script and post-script actions during policy execution.
# 'dry-run' option is intended for validating the document execution without triggering any commands
# on the instance. The following allowedValues will allow Data Lifecycle Manager to successfully
# trigger pre and post script actions.
type: String
default: 'dry-run'
description: (Required) Specifies whether pre-script and/or post-script should be executed.
allowedValues:
- pre-script
- post-script
- dry-run
mainSteps:
- action: aws:runShellScript
description: Run Database freeze/thaw commands
name: run_pre_post_scripts
precondition:
StringEquals:
- platformType
- Linux
inputs:
runCommand:
- |
#!/bin/bash
###===============================================================================###
### Error Codes
###===============================================================================###
# The following Error codes will inform Data Lifecycle Manager of the type of error
# and help guide handling of the error.
# The Error code will also be emitted via AWS Eventbridge events in the 'cause' field.
# 1 Pre-script failed during execution - 201
# 2 Post-script failed during execution - 202
# 3 Auto thaw occurred before post-script was initiated - 203
# 4 Pre-script initiated while post-script was expected - 204
# 5 Post-script initiated while pre-script was expected - 205
# 6 Application not ready for pre or post-script initiation - 206
###===============================================================================###
### Global variables
###===============================================================================###
START=$(date +%s)
# For testing this script locally, replace the below with OPERATION=$1.
OPERATION={{ command }}
# Add all pre-script actions to be performed within the function below
execute_pre_script() {
echo "INFO: Start execution of pre-script"
}
# Add all post-script actions to be performed within the function below
execute_post_script() {
echo "INFO: Start execution of post-script"
}
# Debug logging for parameters passed to the SSM document
echo "INFO: ${OPERATION} starting at $(date) with executionId: ${EXECUTION_ID}"
# Based on the command parameter value execute the function that supports
# pre-script/post-script operation
case ${OPERATION} in
pre-script)
execute_pre_script
;;
post-script)
execute_post_script
;;
dry-run)
echo "INFO: dry-run option invoked - taking no action"
;;
*)
echo "ERROR: Invalid command parameter passed. Please use either pre-script, post-script, dry-run."
exit 1 # return failure
;;
esac
END=$(date +%s)
# Debug Log for profiling the script time
echo "INFO: ${OPERATION} completed at $(date). Total runtime: $((${END} - ${START})) seconds."
```
------
Quando tiver o conteúdo do documento do SSM, use um dos procedimentos a seguir para criar o documento do SSM personalizado.
------
#### [ Console ]
**Para criar um documento de comando do SSM**
1. Abra o AWS Systems Manager console em [https://console.aws.amazon.com//systems-manager/](https://console.aws.amazon.com//systems-manager/).
1. No painel de navegação, escolha **Documentos** e depois **Criar documento**, **Comando ou Sessão**.
1. Em **Name** (Nome), insira um nome descritivo para o documento.
1. Em **Tipo de destino**, selecione**/AWS::EC2::Instance**.
1. Para **Tipo de documento**, selecione **Comando**.
1. No campo **Conteúdo**, selecione **YAML** e cole o conteúdo do documento.
1. Na seção **Tags do documento**, adicione uma tag com uma chave de tag de `DLMScriptsAccess` e um valor de tag de `true`.
**Importante**
A `DLMScriptsAccess:true` tag é exigida pela política AWS gerenciada de **AWSDataLifecycleManagerSSMFullacesso** usada na *Etapa 3: Preparar a função IAM do Amazon Data Lifecycle Manager*. A política usa a chave de condição `aws:ResourceTag` para restringir o acesso aos documentos do SSM que tenham essa tag.
1. Escolha **Criar documento**.
------
#### [ AWS CLI ]
**Para criar um documento de comando do SSM**
Use o comando [create-document](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-document.html). Para `--name`, especifique um nome descritivo para o documento. Em `--document-type`, especifique `Command`. Para `--content`, especifique o caminho para o arquivo .yaml com o conteúdo do documento do SSM. Em `--tags`, especifique `"Key=DLMScriptsAccess,Value=true"`.
```
$ aws ssm create-document \
--content file://path/to/file/documentContent.yaml \
--name "document_name" \
--document-type "Command" \
--document-format YAML \
--tags "Key=DLMScriptsAccess,Value=true"
```
------
### Etapa 3: preparar o perfil do IAM do Amazon Data Lifecycle Manager
**nota**
Essa etapa é necessária se:
Você cria ou atualiza uma política pre/post de snapshot habilitada por script que usa uma função personalizada do IAM.
Você usa a linha de comando para criar ou atualizar uma política de snapshot pre/post habilitada por script que usa o padrão.
Se você usar o console para criar ou atualizar uma política de snapshot pre/post habilitada por script que usa a função padrão para gerenciar snapshots (**AWSDataLifecycleManagerDefaultRole**), pule esta etapa. Nesse caso, anexamos automaticamente a política de **AWSDataLifecycleManagerSSMFullacesso** a essa função.
Você deve garantir que o perfil do IAM que você usa para a política conceda ao Amazon Data Lifecycle Manager permissão para realizar as ações do SSM necessárias para executar scripts prévios e posteriores nas instâncias-alvo da política.
O Amazon Data Lifecycle Manager fornece uma política gerenciada (**AWSDataLifecycleManagerSSMFullAccess**) que inclui as permissões necessárias. Você pode anexar essa política ao perfil do IAM para gerenciar snapshots e garantir que ela inclua as permissões.
**Importante**
A política gerenciada de AWSData LifecycleManager SSMFull acesso usa a chave de `aws:ResourceTag` condição para restringir o acesso a documentos SSM específicos ao usar scripts anteriores e posteriores. Para permitir que o Amazon Data Lifecycle Manager acesse os documentos do SSM, você deve garantir que eles estejam marcados com `DLMScriptsAccess:true`.
Ou então, você pode criar manualmente uma política personalizada ou atribuir as permissões necessárias diretamente ao perfil do IAM que você usa. Você pode usar as mesmas permissões definidas na política gerenciada do AWSData LifecycleManager SSMFull Access, no entanto, a chave de `aws:ResourceTag` condição é opcional. Se você decidir não incluir essa chave de condição, não precisará marcar os documentos do SSM com `DLMScriptsAccess:true`.
Use um dos métodos a seguir para adicionar a política de **AWSDataLifecycleManagerSSMFullacesso** à sua função do IAM.
------
#### [ Console ]
**Para anexar a política gerenciada ao seu perfil personalizado**
1. Abra o console do IAM em [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. No painel de navegação, selecione **Roles** (Funções).
1. Pesquise e selecione o perfil personalizado para gerenciar os snapshots.
1. Na guia **Permissões**, escolha **Adicionar permissões**, **Anexar políticas**.
1. Pesquise e selecione a política gerenciada do **AWSDataLifecycleManagerSSMFullAccess** e escolha **Adicionar permissões**.
------
#### [ AWS CLI ]
**Para anexar a política gerenciada ao seu perfil personalizado**
Use o comando [ da attach-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/attach-role-policy.html). Para `---role-name`, especifique o nome do seu perfil personalizado. Em `--policy-arn`, especifique `arn:aws:iam::aws:policy/AWSDataLifecycleManagerSSMFullAccess`.
```
$ aws iam attach-role-policy \
--policy-arn arn:aws:iam::aws:policy/AWSDataLifecycleManagerSSMFullAccess \
--role-name your_role_name
```
------
### Etapa 4: criar uma política de ciclo de vida de snapshots
Para automatizar snapshots consistentes com a aplicação, você deve criar uma política de ciclo de vida de snapshots que tenha como alvo as instâncias e configurar scripts prévios e posteriores para essa política.
------
#### [ Console ]
**Para criar uma política de ciclo de vida de snapshots**
1. Abra o console do Amazon EC2 em [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. No painel de navegação, selecione **Elastic Block Store**, **Lifecycle Manager** ((Gerenciador de ciclo de vida) e **Create snapshot lifecycle policy** (Criar política de ciclo de vida de snapshot).
1. Na tela **Select policy type** (Selecionar tipo de política), escolha **EBS snapshot policy** (Política de snapshot do EBS) e depois **Next** (Próximo).
1. Na seção **Target resources** (Recursos de destino), faça o seguinte:
1. Para **Tipos de recursos-alvo**, escolha `Instance`.
1. Para **Tags de recurso-alvo**, especifique as tags de recurso que identificam as instâncias para backup. Só será feito backup dos recursos que têm as tags especificadas.
1. Para a **função do IAM**, escolha **AWSDataLifecycleManagerDefaultRole**(a função padrão para gerenciar instantâneos) ou escolha uma função personalizada que você criou e preparou para scripts anteriores e posteriores.
1. Configure as agendas e as opções adicionais conforme necessário. Recomendamos que você agende a criação dos snapshots para períodos que atendam à sua workload, como durante janelas de manutenção.
No SAP HANA, recomendamos que você habilite a restauração rápida de snapshots.
**nota**
Se você habilitar uma agenda para backups do VSS, não poderá habilitar **Excluir volumes de dados específicos** ou **Copiar tags da fonte**.
1. Na seção **Scripts prévios e posteriores**, selecione **Habilitar scripts prévios e posteriores** e depois, dependendo da sua workload, faça o seguinte:
+ Para criar snapshots consistentes com a aplicação para as aplicações do Windows, selecione **Backup do VSS**.
+ Para criar snapshots consistentes com a aplicação de suas workloads do SAP HANA, selecione **SAP HANA.**
+ **Para criar instantâneos consistentes com aplicativos de todos os outros bancos de dados e cargas de trabalho, incluindo seus bancos de dados MySQL, PostgreSQL InterSystems ou IRIS autogerenciados, usando um documento SSM personalizado, selecione Documento SSM personalizado.**
1. Para **Opção de automatização**, escolha **Scripts prévios e posteriores**.
1. Para **Documento do SSM**, selecione o documento do SSM que você preparou.
1. Dependendo da opção selecionada, configure as seguintes opções adicionais:
+ **Tempo limite do script**: (*somente documento do SSM personalizado*) O tempo limite após o qual o Amazon Data Lifecycle Manager considera que a tentativa de execução do script falhou se não foi concluída. Se um script não for concluído dentro do período limite, o Amazon Data Lifecycle Manager considerará que a tentativa falhou. O período de tempo limite se aplica aos scripts prévios e posteriores individualmente. O limite de tempo mínimo e padrão é de 10 segundos. E o tempo limite máximo é de 120 segundos.
+ **Tentar os scripts com falha novamente**: selecione essa opção para fazer novas tentativas de executar os scripts que não forem concluídos dentro do período de tempo limite. Se o script prévio falhar, o Amazon Data Lifecycle Manager tentará realizar novamente todo o processo de criação de snapshots, incluindo a execução dos scripts prévios e posteriores. Se o script posterior falhar, o Amazon Data Lifecycle Manager fará nova tentativa de executar apenas o script posterior; nesse caso, o script prévio estará sido concluído e o snapshot poderá ter sido criado.
+ **Usar o padrão de snapshots consistentes em caso de falha**: selecione essa opção para usar padrão de snapshots consistentes em caso de falha se a execução do script prévio falhar. Esse é o comportamento padrão da criação de snapshots para o Amazon Data Lifecycle Manager se os scripts prévios e posteriores não estiverem habilitados. Se você habilitou novas tentativas, o Amazon Data Lifecycle Manager só usará o padrão de snapshots consistentes em caso de falha após esgotar o todas as tentativas. Se o script prévio falhar e você não usar o padrão de snapshots consistentes em caso de falha, o Amazon Data Lifecycle Manager não criará snapshots para a instância durante da execução agendada.
**nota**
Se você estiver criando snapshots para o SAP HANA, talvez queira desabilitar essa opção. Os snapshots consistentes em caso de falha das workloads do SAP HANA não podem ser restaurados da mesma maneira.
1. Escolha **Criar política padrão**.
**nota**
Se receber um erro `Role with name AWSDataLifecycleManagerDefaultRole already exists`, consulte [Solucionar problemas do Amazon Data Lifecycle Manager](dlm-troubleshooting.md) para obter mais informações.
------
#### [ AWS CLI ]
**Para criar uma política de ciclo de vida de snapshots**
Use o [create-lifecycle-policy](https://docs.aws.amazon.com/cli/latest/reference/dlm/create-lifecycle-policy.html)comando e inclua os `Scripts` parâmetros em`CreateRule`. Para obter mais informações sobre os parâmetros, consulte [https://docs.aws.amazon.com/dlm/latest/APIReference/API_Script.html](https://docs.aws.amazon.com/dlm/latest/APIReference/API_Script.html).
```
$ aws dlm create-lifecycle-policy \
--description "policy_description" \
--state ENABLED \
--execution-role-arn iam_role_arn \
--policy-details file://policyDetails.json
```
Em que `policyDetails.json` inclui um dos seguintes itens dependendo do caso de uso:
+ **Backup do VSS**
```
{
"PolicyType": "EBS_SNAPSHOT_MANAGEMENT",
"ResourceTypes": [
"INSTANCE"
],
"TargetTags": [{
"Key": "tag_key",
"Value": "tag_value"
}],
"Schedules": [{
"Name": "schedule_name",
"CreateRule": {
"CronExpression": "cron_for_creation_frequency",
"Scripts": [{
"ExecutionHandler":"AWS_VSS_BACKUP",
"ExecuteOperationOnScriptFailure":true|false,
"MaximumRetryCount":retries (0-3)
}]
},
"RetainRule": {
"Count": retention_count
}
}]
}
```
+ **Backup do SAP HANA**
```
{
"PolicyType": "EBS_SNAPSHOT_MANAGEMENT",
"ResourceTypes": [
"INSTANCE"
],
"TargetTags": [{
"Key": "tag_key",
"Value": "tag_value"
}],
"Schedules": [{
"Name": "schedule_name",
"CreateRule": {
"CronExpression": "cron_for_creation_frequency",
"Scripts": [{
"Stages": ["PRE","POST"],
"ExecutionHandlerService":"AWS_SYSTEMS_MANAGER",
"ExecutionHandler":"AWSSystemsManagerSAP-CreateDLMSnapshotForSAPHANA",
"ExecuteOperationOnScriptFailure":true|false,
"ExecutionTimeout":timeout_in_seconds (10-120),
"MaximumRetryCount":retries (0-3)
}]
},
"RetainRule": {
"Count": retention_count
}
}]
}
```
+ **Documento do SSM personalizado**
```
{
"PolicyType": "EBS_SNAPSHOT_MANAGEMENT",
"ResourceTypes": [
"INSTANCE"
],
"TargetTags": [{
"Key": "tag_key",
"Value": "tag_value"
}],
"Schedules": [{
"Name": "schedule_name",
"CreateRule": {
"CronExpression": "cron_for_creation_frequency",
"Scripts": [{
"Stages": ["PRE","POST"],
"ExecutionHandlerService":"AWS_SYSTEMS_MANAGER",
"ExecutionHandler":"ssm_document_name|arn",
"ExecuteOperationOnScriptFailure":true|false,
"ExecutionTimeout":timeout_in_seconds (10-120),
"MaximumRetryCount":retries (0-3)
}]
},
"RetainRule": {
"Count": retention_count
}
}]
}
```
------
## Considerações sobre os backups do VSS com o Amazon Data Lifecycle Manager
Com o Amazon Data Lifecycle Manager, você pode fazer backup e restaurar aplicações do Windows habilitadas para o VSS (Volume Shadow Copy Service) sendo executadas em instâncias do Amazon EC2. Se a aplicação tiver um gravador de VSS registrado no VSS do Windows, o Amazon Data Lifecycle Manager criará um snapshot que será consistente com a aplicação para essa aplicação.
**nota**
Atualmente, o Amazon Data Lifecycle Manager é compatível com snapshots consistentes com a aplicação apenas dos recursos executados no Amazon EC2, especificamente em cenários de backup em que os dados da aplicação podem ser restaurados substituindo uma instância existente por uma nova instância criada do backup. Nem todos os tipos de instância ou aplicação são compatíveis com os backups do VSS. Para obter mais informações, consulte [Snapshots consistentes com aplicações do Windows VSS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/application-consistent-snapshots.html) no *Guia do usuário do Amazon EC2*.
**Tipos de instâncias não compatíveis**
Os seguintes tipos de instância do Amazon EC2 não são compatíveis com backups do VSS. Se sua política tiver como alvo um desses tipos de instância, o Amazon Data Lifecycle Manager ainda poderá criar backups do VSS, mas os snapshots talvez não estejam marcados com as tags de sistema necessárias. Sem essas tags, os snapshots não serão gerenciados pelo Amazon Data Lifecycle Manager após sua criação. Pode ser necessário excluir esses snapshots manualmente.
+ T3: `t3.nano` \$1 `t3.micro`
+ T3a: `t3a.nano` \$1 `t3a.micro`
+ T2: `t2.nano` \$1 `t2.micro`
## Responsabilidade compartilhada pelos snapshots consistentes com a aplicação
**Você deve garantir que:**
+ O Agente SSM está instalado e em execução nas instâncias de destino up-to-date
+ O Systems Manager tenha permissões para executar as ações necessárias nas instâncias-alvo
+ O Amazon Data Lifecycle Manager tenha permissões para realizar as ações do Systems Manager necessárias para executar scripts prévios e posteriores nas instâncias-alvo.
+ Para cargas de trabalho personalizadas, como bancos de dados MySQL, PostgreSQL InterSystems ou IRIS autogerenciados, o documento SSM que você usa inclui as ações corretas e necessárias para congelar, limpar e descongelar a configuração do banco de dados. I/O
+ Os horários de criação de snapshots estejam alinhados com sua agenda de workload. Por exemplo, tente agendar a criação de snapshots durante as janelas de manutenção agendadas.
**O Amazon Data Lifecycle Manager garante que:**
+ A criação do snapshot seja iniciada dentro de 60 minutos a partir do horário agendado para criação do snapshot.
+ Os scripts prévios sejam executados antes do início da criação do snapshot.
+ Os scripts posteriores sejam executados após o script prévio ser bem-sucedido e a criação do snapshot ter sido iniciada. O Amazon Data Lifecycle Manager só execute o script posterior se o script prévio for bem-sucedido. Se o script prévio falhar, o Amazon Data Lifecycle Manager não executará o script posterior.
+ Os snapshots sejam marcados com as tags apropriadas na criação.
+ CloudWatch métricas e eventos são emitidos quando os scripts são iniciados e quando eles falham ou são bem-sucedidos.
# Outros casos de uso de pré-scripts e pós-scripts
Além de usar scripts prévios e posteriores para automatizar snapshots consistentes com a aplicação, você pode usar os scripts prévios e posteriores juntos ou individualmente para automatizar outras tarefas administrativas antes ou depois da criação do snapshot. Por exemplo:
+ Usar um script prévio para aplicar patches antes de criar os snapshots. Isso pode ajudar você a criar snapshots depois de aplicar as atualizações regulares de software semanais ou mensais.
**nota**
Se você escolher executar somente um script prévio, a opção **Usar o padrão de snapshots consistentes em caso de falha** será habilitada por padrão.
+ Usar um script posterior para aplicar patches após a criação de snapshots. Isso pode ajudar você a criar snapshots antes de aplicar suas atualizações regulares de software semanais ou mensais.
## Introdução a outros casos de uso
Esta seção explica as etapas que você precisa executar ao usar scripts de and/or pré-publicação para **casos de uso que não sejam instantâneos consistentes com o aplicativo**.
### Etapa 1: preparar as instâncias-alvo
**Para preparar suas instâncias de destino para scripts and/or pré-publicação**
1. Instale o SSM Agent nas instâncias-alvo, se ainda não estiver instalado. Se o SSM Agent já estiver instalado em suas instâncias-alvo, pule esta etapa.
+ (Instâncias do Linux) [Instalar o SSM Agent manualmente em instâncias do EC2 para Linux](https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-linux.html)
+ (Instâncias do Windows) [Trabalhar com o SSM Agent em instâncias do EC2 para Windows Server](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-windows.html)
1. Certifique-se de que o SSM Agent esteja em execução. Para obter mais informações, consulte [Verificar o status do SSM Agent e iniciar o agente](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-status-and-restart.html).
1. Configure o Systems Manager para instâncias do Amazon EC2. Para obter mais informações, consulte [Configuração do Systems Manager para instâncias Amazon EC2](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-setting-up-ec2.html) no *AWS Systems Manager Guia do usuário do *.
### Etapa 2: preparar o documento do SSM
Você deve criar um documento de comando SSM que inclua os scripts de and/or pré-publicação com os comandos que você deseja executar.
Você pode criar um documento do SSM usando o modelo de documento do SSM em branco abaixo e adicionar os comandos de script prévio e posterior nas seções apropriadas do documento.
**Observe o seguinte:**
É sua responsabilidade garantir que o documento do SSM realize as ações corretas e necessárias para a sua workload.
O documento do SSM deve incluir os campos obrigatórios para `allowedValues`, incluindo `pre-script`, `post-script` e `dry-run`. O Amazon Data Lifecycle Manager executará os comandos na instância com base no conteúdo dessas seções. Se o documento do SSM não tiver essas seções, o Amazon Data Lifecycle Manager o tratará como uma execução que falhou.
```
###===============================================================================###
# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
# Permission is hereby granted, free of charge, to any person obtaining a copy of this
# software and associated documentation files (the "Software"), to deal in the Software
# without restriction, including without limitation the rights to use, copy, modify,
# merge, publish, distribute, sublicense, and/or sell copies of the Software, and to
# permit persons to whom the Software is furnished to do so.
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED,
# INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A
# PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
# HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
# OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
# SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
###===============================================================================###
schemaVersion: '2.2'
description: SSM Document Template for Amazon Data Lifecycle Manager Pre/Post script feature
parameters:
executionId:
type: String
default: None
description: (Required) Specifies the unique identifier associated with a pre and/or post execution
allowedPattern: ^(None|[a-fA-F0-9]{8}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{12})$
command:
# Data Lifecycle Manager will trigger the pre-script and post-script actions during policy execution.
# 'dry-run' option is intended for validating the document execution without triggering any commands
# on the instance. The following allowedValues will allow Data Lifecycle Manager to successfully
# trigger pre and post script actions.
type: String
default: 'dry-run'
description: (Required) Specifies whether pre-script and/or post-script should be executed.
allowedValues:
- pre-script
- post-script
- dry-run
mainSteps:
- action: aws:runShellScript
description: Run Database freeze/thaw commands
name: run_pre_post_scripts
precondition:
StringEquals:
- platformType
- Linux
inputs:
runCommand:
- |
#!/bin/bash
###===============================================================================###
### Error Codes
###===============================================================================###
# The following Error codes will inform Data Lifecycle Manager of the type of error
# and help guide handling of the error.
# The Error code will also be emitted via AWS Eventbridge events in the 'cause' field.
# 1 Pre-script failed during execution - 201
# 2 Post-script failed during execution - 202
# 3 Auto thaw occurred before post-script was initiated - 203
# 4 Pre-script initiated while post-script was expected - 204
# 5 Post-script initiated while pre-script was expected - 205
# 6 Application not ready for pre or post-script initiation - 206
###===============================================================================###
### Global variables
###===============================================================================###
START=$(date +%s)
# For testing this script locally, replace the below with OPERATION=$1.
OPERATION={{ command }}
# Add all pre-script actions to be performed within the function below
execute_pre_script() {
echo "INFO: Start execution of pre-script"
}
# Add all post-script actions to be performed within the function below
execute_post_script() {
echo "INFO: Start execution of post-script"
}
# Debug logging for parameters passed to the SSM document
echo "INFO: ${OPERATION} starting at $(date) with executionId: ${EXECUTION_ID}"
# Based on the command parameter value execute the function that supports
# pre-script/post-script operation
case ${OPERATION} in
pre-script)
execute_pre_script
;;
post-script)
execute_post_script
;;
dry-run)
echo "INFO: dry-run option invoked - taking no action"
;;
*)
echo "ERROR: Invalid command parameter passed. Please use either pre-script, post-script, dry-run."
exit 1 # return failure
;;
esac
END=$(date +%s)
# Debug Log for profiling the script time
echo "INFO: ${OPERATION} completed at $(date). Total runtime: $((${END} - ${START})) seconds."
```
### Etapa 3: preparar o perfil do IAM do Amazon Data Lifecycle Manager
**nota**
Essa etapa é necessária se:
Você cria ou atualiza uma política pre/post de snapshot habilitada por script que usa uma função personalizada do IAM.
Você usa a linha de comando para criar ou atualizar uma política de snapshot pre/post habilitada por script que usa o padrão.
Se você usar o console para criar ou atualizar uma política de snapshot pre/post habilitada por script que usa a função padrão para gerenciar snapshots (**AWSDataLifecycleManagerDefaultRole**), pule esta etapa. Nesse caso, anexamos automaticamente a política de **AWSDataLifecycleManagerSSMFullacesso** a essa função.
Você deve garantir que o perfil do IAM que você usa para a política conceda ao Amazon Data Lifecycle Manager permissão para realizar as ações do SSM necessárias para executar scripts prévios e posteriores nas instâncias-alvo da política.
O Amazon Data Lifecycle Manager fornece uma política gerenciada (**AWSDataLifecycleManagerSSMFullAccess**) que inclui as permissões necessárias. Você pode anexar essa política ao perfil do IAM para gerenciar snapshots e garantir que ela inclua as permissões.
**Importante**
A política gerenciada de AWSData LifecycleManager SSMFull acesso usa a chave de `aws:ResourceTag` condição para restringir o acesso a documentos SSM específicos ao usar scripts anteriores e posteriores. Para permitir que o Amazon Data Lifecycle Manager acesse os documentos do SSM, você deve garantir que eles estejam marcados com `DLMScriptsAccess:true`.
Ou então, você pode criar manualmente uma política personalizada ou atribuir as permissões necessárias diretamente ao perfil do IAM que você usa. Você pode usar as mesmas permissões definidas na política gerenciada do AWSData LifecycleManager SSMFull Access, no entanto, a chave de `aws:ResourceTag` condição é opcional. Se você decidir não usar essa chave de condição, não precisará marcar os documentos do SSM com `DLMScriptsAccess:true`.
Use um dos métodos a seguir para adicionar a política de **AWSDataLifecycleManagerSSMFullacesso** à sua função do IAM.
------
#### [ Console ]
**Para anexar a política gerenciada ao seu perfil personalizado**
1. Abra o console do IAM em [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. No painel de navegação, selecione **Roles** (Funções).
1. Pesquise e selecione o perfil personalizado para gerenciar os snapshots.
1. Na guia **Permissões**, escolha **Adicionar permissões**, **Anexar políticas**.
1. Pesquise e selecione a política gerenciada do **AWSDataLifecycleManagerSSMFullAccess** e escolha **Adicionar permissões**.
------
#### [ AWS CLI ]
**Para anexar a política gerenciada ao seu perfil personalizado**
Use o comando [ da attach-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/attach-role-policy.html). Para `---role-name`, especifique o nome do seu perfil personalizado. Em `--policy-arn`, especifique `arn:aws:iam::aws:policy/AWSDataLifecycleManagerSSMFullAccess`.
```
$ aws iam attach-role-policy \
--policy-arn arn:aws:iam::aws:policy/AWSDataLifecycleManagerSSMFullAccess \
--role-name your_role_name
```
------
### Criar uma política de ciclo de vida de snapshots
------
#### [ Console ]
**Para criar uma política de ciclo de vida de snapshots**
1. Abra o console do Amazon EC2 em [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. No painel de navegação, selecione **Elastic Block Store**, **Lifecycle Manager** ((Gerenciador de ciclo de vida) e **Create snapshot lifecycle policy** (Criar política de ciclo de vida de snapshot).
1. Na tela **Select policy type** (Selecionar tipo de política), escolha **EBS snapshot policy** (Política de snapshot do EBS) e depois **Next** (Próximo).
1. Na seção **Target resources** (Recursos de destino), faça o seguinte:
1. Para **Tipos de recursos-alvo**, escolha `Instance`.
1. Para **Tags de recurso-alvo**, especifique as tags de recurso que identificam as instâncias para backup. Só será feito backup dos recursos que têm as tags especificadas.
1. Para a **função do IAM**, escolha **AWSDataLifecycleManagerDefaultRole**(a função padrão para gerenciar instantâneos) ou escolha uma função personalizada que você criou e preparou para scripts anteriores e posteriores.
1. Configure as agendas e as opções adicionais conforme necessário. Recomendamos que você agende a criação dos snapshots para períodos que atendam à sua workload, como durante janelas de manutenção.
1. Na seção **Scripts prévios e posteriores**, selecione **Habilitar scripts prévios e posteriores** e depois faça o seguinte:
1. Selecione **Documento do SSM personalizado**.
1. Para **Opção de automatização**, escolha a opção que corresponde aos scripts que você deseja executar.
1. Para **Documento do SSM**, selecione o documento do SSM que você preparou.
1. Configure as seguintes opções adicionais se necessário:
+ **Tempo limite do script**: o período limite após o qual o Amazon Data Lifecycle Manager considera que a tentativa de execução do script falhou se ela não foi concluída. Se um script não for concluído dentro do período limite, o Amazon Data Lifecycle Manager considerará que a tentativa falhou. O período de tempo limite se aplica aos scripts prévios e posteriores individualmente. O limite de tempo mínimo e padrão é de 10 segundos. E o tempo limite máximo é de 120 segundos.
+ **Tentar os scripts com falha novamente**: selecione essa opção para fazer novas tentativas de executar os scripts que não forem concluídos dentro do período de tempo limite. Se o script prévio falhar, o Amazon Data Lifecycle Manager tentará realizar novamente todo o processo de criação de snapshots, incluindo a execução dos scripts prévios e posteriores. Se o script posterior falhar, o Amazon Data Lifecycle Manager fará nova tentativa de executar apenas o script posterior; nesse caso, o script prévio estará sido concluído e o snapshot poderá ter sido criado.
+ **Usar o padrão de snapshots consistentes em caso de falha**: selecione essa opção para usar padrão de snapshots consistentes em caso de falha se a execução do script prévio falhar. Esse é o comportamento padrão da criação de snapshots para o Amazon Data Lifecycle Manager se os scripts prévios e posteriores não estiverem habilitados. Se você habilitou novas tentativas, o Amazon Data Lifecycle Manager só usará o padrão de snapshots consistentes em caso de falha após esgotar o todas as tentativas. Se o script prévio falhar e você não usar o padrão de snapshots consistentes em caso de falha, o Amazon Data Lifecycle Manager não criará snapshots para a instância durante da execução agendada.
1. Escolha **Criar política padrão**.
**nota**
Se receber um erro `Role with name AWSDataLifecycleManagerDefaultRole already exists`, consulte [Solucionar problemas do Amazon Data Lifecycle Manager](dlm-troubleshooting.md) para obter mais informações.
------
#### [ AWS CLI ]
**Para criar uma política de ciclo de vida de snapshots**
Use o [create-lifecycle-policy](https://docs.aws.amazon.com/cli/latest/reference/dlm/create-lifecycle-policy.html)comando e inclua os `Scripts` parâmetros em`CreateRule`. Para obter mais informações sobre os parâmetros, consulte [https://docs.aws.amazon.com/dlm/latest/APIReference/API_Script.html](https://docs.aws.amazon.com/dlm/latest/APIReference/API_Script.html).
```
$ aws dlm create-lifecycle-policy \
--description "policy_description" \
--state ENABLED \
--execution-role-arn iam_role_arn \
--policy-details file://policyDetails.json
```
Em que `policyDetails.json` inclui o seguinte:
```
{
"PolicyType": "EBS_SNAPSHOT_MANAGEMENT",
"ResourceTypes": [
"INSTANCE"
],
"TargetTags": [{
"Key": "tag_key",
"Value": "tag_value"
}],
"Schedules": [{
"Name": "schedule_name",
"CreateRule": {
"CronExpression": "cron_for_creation_frequency",
"Scripts": [{
"Stages": ["PRE" | "POST" | "PRE","POST"],
"ExecutionHandlerService":"AWS_SYSTEMS_MANAGER",
"ExecutionHandler":"ssm_document_name|arn",
"ExecuteOperationOnScriptFailure":true|false,
"ExecutionTimeout":timeout_in_seconds (10-120),
"MaximumRetryCount":retries (0-3)
}]
},
"RetainRule": {
"Count": retention_count
}
}]
}
```
------
# Como funcionam os pré-scripts e pós-scripts do Amazon Data Lifecycle Manager
A imagem a seguir mostra o fluxograma dos scripts prévios e posteriores ao usar documentos do SSM personalizados. Isso não se aplica aos backups do VSS.
![\[Fluxo de processo dos scripts prévios e posteriores do Amazon Data Lifecycle Manager\]](http://docs.aws.amazon.com/pt_br/ebs/latest/userguide/images/dlm-scripts.png)
No horário agendado para a criação dos snapshots, as seguintes ações e interações entre serviços ocorrem.
1. O Amazon Data Lifecycle Manager inicia a ação de script prévio chamando o documento do SSM e passando o parâmetro `pre-script`.
**nota**
As etapas 1 a 3 só ocorrem se você executar os scripts prévios. Se você executar somente os scripts posteriores, as etapas 1 a 3 serão ignoradas.
1. O Systems Manager envia os comandos do script prévio para o SSM Agent em execução nas instâncias-alvo. O SSM Agent executa os comandos na instância e envia as informações de status de volta ao Systems Manager.
Por exemplo, se o documento SSM for usado para criar instantâneos consistentes com aplicativos, o pré-script poderá congelar e ser liberado I/O para garantir que todos os dados armazenados em buffer sejam gravados no volume antes da captura instantânea.
1. O Systems Manager envia atualizações de status dos comandos do script prévio para o Amazon Data Lifecycle Manager. Se o script prévio falhar, o Amazon Data Lifecycle Manager fará uma das seguintes ações, dependendo de como você configurar as opções de script prévio e posterior:
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/ebs/latest/userguide/script-flow.html)
1. O Amazon Data Lifecycle Manager inicia a criação de snapshots.
1. O Amazon Data Lifecycle Manager inicia a ação do script posterior chamando o documento do SSM e passando o parâmetro `post-script`.
**nota**
As etapas 5 a 7 só ocorrem se você executar os scripts prévios. Se você executar somente os scripts posteriores, as etapas 1 a 3 serão ignoradas.
1. O Systems Manager envia os comandos do script posterior para o SSM Agent em execução nas instâncias-alvo. O SSM Agent executa os comandos na instância e envia as informações de status de volta ao Systems Manager.
Por exemplo, se o documento SSM permitir instantâneos consistentes com aplicativos, esse pós-script poderá ser descongelado I/O para garantir que seus bancos de dados retomem as operações normais de E/S após a captura instantânea ter sido tirada.
1. Se você executar um script posterior e o Systems Manager indicar que ele foi concluído com sucesso, o processo será concluído.
Se o script posterior falhar, o Amazon Data Lifecycle Manager fará uma das seguintes ações, dependendo de como você configurar as opções de script prévio e posterior:
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/ebs/latest/userguide/script-flow.html)
Lembre-se de que, se o script posterior falhar, o script prévio (se habilitado) será concluído com sucesso e os snapshots poderão ter sido criados. Talvez seja necessário realizar outras ações na instância para garantir que ela esteja operando como esperado. Por exemplo, se o pré-script foi pausado e I/O, but the post script failed to thaw I/O, you might need to configure your database to auto-thaw I/O or you need to manually thaw I/O descarregado.
1. O processo de criação do snapshot talvez seja concluído após a conclusão do script posterior. O tempo necessário para concluir o snapshot depende do tamanho do snapshot.
# Identificar snapshots criados com pré-scripts e pós-scripts do Data Lifecycle Manager
O Amazon Data Lifecycle Manager atribui automaticamente as seguintes tags do sistema aos snapshots criados com scripts prévios e posteriores.
+ Chave: `aws:dlm:pre-script`; valor: `SUCCESS`\$1`FAILED`
Um valor de tag de `SUCCESS` indica que o script prévio foi executado com sucesso. Um valor de tag de `FAILED` indica que o script prévio não foi executado com sucesso.
+ Chave: `aws:dlm:post-script`; valor: `SUCCESS`\$1`FAILED`
Um valor de tag de `SUCCESS` indica que o script posterior foi executado com sucesso. Um valor de tag de `FAILED` indica que o script posterior não foi executado com sucesso.
Para documentos do SSM personalizados e backups do SAP HANA, você pode inferir a criação bem-sucedida de snapshots consistentes com a aplicação se o snapshot estiver marcado com `aws:dlm:pre-script:SUCCESS` e `aws:dlm:post-script:SUCCESS`.
Além disso, snapshots consistentes com a aplicação criados usando o backup do VSS são automaticamente marcados com:
+ Chave: `AppConsistent tag`; valor: `true`\$1`false`
Um valor de tag de `true` indica que o backup do VSS foi bem-sucedido e que os snapshots são consistentes com a aplicação. Um valor de tag de `false` indica que o backup do VSS não foi bem-sucedido e que os snapshots não são consistentes com a aplicação.
# Monitorar pré-scripts e pós-scripts do Amazon Data Lifecycle Manager
**CloudWatch Métricas da Amazon**
O Amazon Data Lifecycle Manager publica as seguintes CloudWatch métricas quando os scripts anteriores e posteriores falham e são bem-sucedidos e quando os backups do VSS falham e são bem-sucedidos.
+ `PreScriptStarted`
+ `PreScriptCompleted`
+ `PreScriptFailed`
+ `PostScriptStarted`
+ `PostScriptCompleted`
+ `PostScriptFailed`
+ `VSSBackupStarted`
+ `VSSBackupCompleted`
+ `VSSBackupFailed`
Para obter mais informações, consulte [Monitore as políticas do Data Lifecycle Manager usando CloudWatch](monitor-dlm-cw-metrics.md).
**Amazon EventBridge**
O Amazon Data Lifecycle Manager emite o seguinte evento da EventBridge Amazon quando um script pré ou pós-script é iniciado, é bem-sucedido ou falha
+ `DLM Pre Post Script Notification`
Para obter mais informações, consulte [Monitore as políticas do Data Lifecycle Manager usando EventBridge](monitor-cloudwatch-events.md).
# Crie uma política personalizada do Amazon Data Lifecycle Manager para suporte do EBS AMIs
O procedimento a seguir mostra como usar o Amazon Data Lifecycle Manager para automatizar os ciclos de vida da AMI com suporte do EBS.
**Topics**
+ [Criar uma política de ciclo de vida de AMI](#create-ami-policy)
+ [Considerações sobre políticas de ciclo de vida da AMI](#ami-considerations)
+ [Recursos adicionais do](#ami-additional-resources)
## Criar uma política de ciclo de vida de AMI
Use os procedimentos a seguir para criar uma política de ciclo de vida de AMI.
------
#### [ Console ]
**Para criar uma política de AMI**
1. Abra o console do Amazon EC2 em [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. No painel de navegação, selecione **Elastic Block Store**, **Lifecycle Manager** ((Gerenciador de ciclo de vida) e **Create snapshot lifecycle policy** (Criar política de ciclo de vida de snapshot).
1. Na tela **Select policy type** (Selecionar tipo de política), escolha **EBS-backed AMI policy** (Política de AMI com suporte do EBS) e depois **Next** (Próximo).
1. Na seção **Target resources** (Recursos de destino), em **Target resource tags** (Etiquetas de recurso de destino), escolha as etiquetas de recursos que identificam os volumes ou as instâncias dos quais deseja fazer backup. A política só oferece suporte aos recursos que tenham a chave de etiqueta e os pares de valor especificados.
1. Para **Description** (Descrição), insira uma breve descrição da rota.
1. Para a **função do IAM**, escolha a função do IAM que tem permissões para gerenciar AMIs , capturar imagens e descrever instâncias. Para usar a função padrão fornecida pelo Amazon Data Lifecycle Manager, escolha **Default role** (Função padrão). Se preferir, para usar uma função do IAM personalizada criada anteriormente, selecione **Choose another role** (Escolher outra função) e selecione a função a ser usada.
1. Em **Policy tags** (Etiquetas de políticas), adicione as etiquetas a serem aplicadas na política de ciclo de vida. É possível usar essas etiquetas para identificar e categorizar suas políticas.
1. Em **Policy status after creation** (Status da política após a criação), selecione **Enable policy** (Habilitar política) para iniciar as execuções da política no próximo horário agendado ou **Disable policy** (Desabilitar política) para impedir que a política seja executada. Se você não habilitar a política agora, ela não começará a ser criada AMIs até que você a habilite manualmente após a criação.
1. Na seção **Instance reboot** (Reinicialização da instância), indique se as instâncias devem ser reinicializadas antes da criação da AMI. Para evitar que as instâncias de destino sejam reinicializadas, escolha **No** (Não). Escolher **No** (Não) pode causar problemas de consistência de dados. Para reiniciar instâncias antes da criação da AMI, escolha **Yes** (Sim). Escolher isso garante a consistência dos dados, mas pode resultar na reinicialização de várias instâncias direcionadas simultaneamente.
1. Escolha **Próximo**.
1. Em **Configure schedule** (Configurar agendamento), configure os agendamentos de política. Uma política pode ter até quatro agendamentos. A Programação 1 é obrigatória. As Programações 2, 3 e 4 são opcionais. Para cada agendamento de política que você adicionar, faça o seguinte:
1. Na seção **Schedule details** (Detalhes do agendamento), faça o seguinte:
1. Em **Schedule name** (Nome do agendamento), especifique um nome descritivo para o agendamento.
1. Em **Frequency** (Frequência) e nos campos relacionados, configure o intervalo entre as execuções da política.
É possível configurar execuções de políticas com uma programação diária, semanal, mensal ou anual. Como opção, escolha **Custom cron expression** (Expressão cron personalizada) para especificar um intervalo de até 1 ano. Para obter mais informações, consulte [Cron e expressões de taxa](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-scheduled-rule-pattern.html) no *Guia do EventBridge usuário da Amazon*.
1. Em **Starting at** (Iniciando às), especifique a hora para iniciar as execuções da política. A primeira execução da política inicia uma hora depois do horário agendado. É necessário inserir a hora no formato `hh:mm` UTC.
1. Para **Tipo de retenção**, especifique a política de retenção AMIs criada pelo agendamento.
Você pode reter AMIs com base na contagem total ou na idade.
Para retenção baseada em contagem, o intervalo é de `1` a `1000`. Quando a contagem máxima for atingida, a AMI mais antiga será excluída quando uma nova for criada.
Para retenção baseada na idade, o intervalo é de `1` dia a `100` anos. Depois que o período de retenção de cada AMI expirar, ela será excluída.
**nota**
Todas as programações devem ter o mesmo tipo de retenção. É possível especificar o tipo de retenção somente para a Programação 1. As Programações 2, 3 e 4 herdam o tipo de retenção da Programação 1. Cada programação pode ter sua própria contagem ou período de retenção.
1. Configure a marcação para AMIs.
Na seção **Tagging** (Marcação), faça o seguinte:
1. Para copiar todas as tags definidas pelo usuário da instância de origem para a AMIs criada pelo agendamento, selecione **Copiar tags da fonte**.
1. Por padrão, os AMIs criados pelo agendamento são automaticamente marcados com o ID da instância de origem. Para evitar que essa marcação automática ocorra, em **Variable tags** (Etiquetas de variáveis), remova o bloco `instance-id:$(instance-id)`.
1. Para especificar tags adicionais para atribuir às AMIs criadas por essa agenda, escolha **Adicionar tags**.
1. Configurar a suspensão de uso da AMI.
Para descontinuar AMIs quando elas não devem mais ser usadas, na **seção Suspensão de uso da AMI, selecione Habilitar suspensão de uso da AMI para esse agendamento** **e, em seguida, especifique a regra de suspensão da AMI**. A regra de suspensão de uso da AMI especifica quando devem ser AMIs descontinuadas.
Se o cronograma usar retenção de AMI com base na contagem, você deverá especificar o número de mais antigas a AMIs serem suspensas. A contagem de defasagem deve ser menor ou igual à contagem de retenção de AMI da programação e não pode ser maior que 1.000. Por exemplo, se o agendamento estiver configurado para reter no máximo 5 AMIs, você poderá configurar o agendado para descontinuar até os 5 mais antigos. AMIs
Se o cronograma usar a retenção de AMI com base na idade, você deverá especificar o período após o qual AMIs será descontinuado. A contagem de defasagem deve ser menor ou igual ao período de retenção da AMI da programação e não pode ser superior a 10 anos (120 meses, 520 semanas ou 3.650 dias). Por exemplo, se o agendamento estiver configurado AMIs para ser retido por 10 dias, você poderá configurar o agendamento para ser suspenso AMIs após períodos de até 10 dias após a criação.
1. Configurar cópia entre regiões.
Para copiar a AMIs criação da agenda para diferentes regiões, na seção **Cópia entre regiões, selecione Ativar cópia** **entre regiões**. Você pode copiar AMIs para até três regiões adicionais em sua conta. Especifique uma regra de cópia entre regiões separada para cada região de destino.
Para cada região de destino, é possível especificar o seguinte:
+ Uma política de retenção para a cópia AMI. Quando o período de retenção expirar, a cópia na região de destino será automaticamente cancelada.
+ Status de criptografia para a cópia da AMI. Se a AMI de origem estiver criptografada ou se a criptografia por padrão estiver ativada, as copiadas serão sempre AMIs criptografadas. Se a AMI de origem não estiver criptografada e a criptografia por padrão estiver desabilitada, será possível habilitar a criptografia. Se você não especificar uma chave KMS, elas AMIs serão criptografadas usando a chave KMS padrão para criptografia do EBS em cada região de destino. Se você especificar uma Chave do KMS para a região de destino, a função do IAM selecionada deverá ter acesso à Chave do KMS.
+ Uma regra de defasagem para a cópia da AMI. Quando o período de descontinuação expira, a cópia da AMI é automaticamente substituída. O período de defasagem deve ser menor ou igual ao período de retenção de cópias e não pode ser superior a 10 anos.
+ Se deseja copiar todas as marcações ou nenhuma marcação da AMI de origem.
**nota**
Não exceda o número de cópias de AMI simultâneas por região.
1. Para adicionar outros agendamentos, escolha **Add another schedule** (Adicionar outro agendamento), localizado na parte superior da tela. Para cada agendamento adicional, preencha os campos conforme descrito anteriormente neste tópico.
1. Depois de adicionar os agendamentos necessárias, escolha **Review policy** (Revisar política).
1. Revise o resumo da política e escolha **Create policy** (Criar política).
**nota**
Se receber um erro `Role with name AWSDataLifecycleManagerDefaultRoleForAMIManagement already exists`, consulte [Solucionar problemas do Amazon Data Lifecycle Manager](dlm-troubleshooting.md) para obter mais informações.
------
#### [ Command line ]
Use o [create-lifecycle-policy](https://docs.aws.amazon.com/cli/latest/reference/dlm/create-lifecycle-policy.html)comando para criar uma política de ciclo de vida da AMI. Para `PolicyType`, especifique `IMAGE_MANAGEMENT`.
**nota**
Para simplificar a sintaxe, os exemplos a seguir usam um arquivo JSON `policyDetails.json`, que inclui os detalhes da política.
**Exemplo 1: retenção baseada em idade e defasagem de AMI**
Este exemplo cria uma política de ciclo de vida AMIs da AMI que cria todas as instâncias que têm uma chave de tag `purpose` com um valor de `production` sem reinicializar as instâncias de destino. A política inclui uma programação que cria uma AMI todos os dias às `01:00` UTC. A política é mantida AMIs por `2` dias e as suspende após dia. `1` Ele também copia as tags da instância de origem para a AMIs que ela cria.
```
aws dlm create-lifecycle-policy \
--description "My AMI policy" \
--state ENABLED \
--execution-role-arn arn:aws:iam::12345678910:role/AWSDataLifecycleManagerDefaultRoleForAMIManagement \
--policy-details file://policyDetails.json
```
Este é um exemplo do arquivo `policyDetails.json`.
```
{
"PolicyType": "IMAGE_MANAGEMENT",
"ResourceTypes": [
"INSTANCE"
],
"TargetTags": [{
"Key": "purpose",
"Value": "production"
}],
"Schedules": [{
"Name": "DailyAMIs",
"TagsToAdd": [{
"Key": "type",
"Value": "myDailyAMI"
}],
"CreateRule": {
"Interval": 24,
"IntervalUnit": "HOURS",
"Times": [
"01:00"
]
},
RetainRule":{
"Interval" : 2,
"IntervalUnit" : "DAYS"
},
DeprecateRule": {
"Interval" : 1,
"IntervalUnit" : "DAYS"
},
"CopyTags": true
}
],
"Parameters" : {
"NoReboot":true
}
}
```
Se a solicitação for bem-sucedida, o comando retornará o ID da política recém-criada. O seguinte é um exemplo de saída.
```
{
"PolicyId": "policy-9876543210abcdef0"
}
```
**Exemplo 2: retenção baseada em contagem e defasagem de AMI com cópia entre regiões**
Este exemplo cria uma política de ciclo de vida AMIs da AMI que cria todas as instâncias que têm uma chave de tag `purpose` com um valor de `production` e reinicializa as instâncias de destino. A política inclui uma programação que cria uma AMI a cada `6` horas a partir de `17:30` UTC. A política retém `3` AMIs e desaprova automaticamente a mais antiga. `2` AMIs Ela também tem uma regra de cópia entre regiões que copia AMIs para`us-east-1`, retém as cópias da `2` AMI e desaprova automaticamente a AMI mais antiga.
```
aws dlm create-lifecycle-policy \
--description "My AMI policy" \
--state ENABLED \
--execution-role-arn arn:aws:iam::12345678910:role/AWSDataLifecycleManagerDefaultRoleForAMIManagement \
--policy-details file://policyDetails.json
```
Este é um exemplo do arquivo `policyDetails.json`.
```
{
"PolicyType": "IMAGE_MANAGEMENT",
"ResourceTypes" : [
"INSTANCE"
],
"TargetTags": [{
"Key":"purpose",
"Value":"production"
}],
"Parameters" : {
"NoReboot": true
},
"Schedules" : [{
"Name" : "Schedule1",
"CopyTags": true,
"CreateRule" : {
"Interval": 6,
"IntervalUnit": "HOURS",
"Times" : ["17:30"]
},
"RetainRule":{
"Count" : 3
},
"DeprecateRule":{
"Count" : 2
},
"CrossRegionCopyRules": [{
"TargetRegion": "us-east-1",
"Encrypted": true,
"RetainRule":{
"IntervalUnit": "DAYS",
"Interval": 2
},
"DeprecateRule":{
"IntervalUnit": "DAYS",
"Interval": 1
},
"CopyTags": true
}]
}]
}
```
------
## Considerações sobre políticas de ciclo de vida da AMI
As seguintes **considerações gerais** se aplicam à criação de políticas de ciclo de vida de AMIs:
+ As políticas de ciclo de vida da AMI visam somente instâncias que estão na mesma região que a política.
+ A primeira operação de criação de AMI começa uma hora após o horário de início especificado. As operações de criação de AMI subsequentes começam uma hora após o horário programado.
+ Quando o Amazon Data Lifecycle Manager cancela o registro de uma AMI, ele exclui automaticamente o backup de snapshots.
+ Tags de recursos de destino diferenciam letras maiúsculas de minúsculas.
+ Se você remover as tags de destino de uma instância que é alvo de uma política, o Amazon Data Lifecycle Manager não gerencia mais as existentes AMIs no padrão; você deve excluí-las manualmente se elas não forem mais necessárias.
+ É possível criar várias políticas para fazer backup de uma instância. *Por exemplo, se uma instância tem duas tags, em que a tag A é a meta para a política A criar *uma* AMI a cada 12 horas e a tag *B* é a meta para a política *B* criar uma AMI a cada 24 horas, o Amazon Data Lifecycle Manager cria de AMIs acordo com os cronogramas de ambas as políticas.* Como alternativa, é possível obter o mesmo resultado criando uma única política que tenha várias programações. Por exemplo, é possível criar uma única política voltada apenas para tag *A* e especificar duas programações: uma para cada 12 horas e uma para cada 24 horas.
+ Novos volumes associados a uma instância de destino após a criação da política são incluídos automaticamente no backup na próxima execução da política. Todos os volumes associados à instância no momento da execução da política são incluídos.
+ Se você criar uma política com uma programação personalizada baseada em cron que esteja configurada para criar apenas uma AMI, a política não cancelará automaticamente o registro dessa AMI quando o limite de retenção for atingido. É necessário cancelar manualmente o registro da AMI caso ela não seja mais necessária.
+ Se você criar uma política baseada na idade em que o período de retenção seja menor do que a frequência de criação, o Amazon Data Lifecycle Manager sempre reterá o última AMI até que a próxima seja criada. Por exemplo, se uma política baseada na idade criar uma AMI por mês com um período de retenção de sete dias, o Amazon Data Lifecycle Manager reterá cada AMI por um mês, mesmo que o período de retenção seja de sete dias.
+ Para políticas baseadas em contagem, o Amazon Data Lifecycle Manager AMIs sempre cria de acordo com a frequência de criação antes de tentar cancelar o registro da AMI mais antiga de acordo com a política de retenção.
+ Pode levar várias horas para cancelar com êxito o registro de uma AMI e excluir os snapshots de backup associados. Se o Amazon Data Lifecycle Manager criar a próxima AMI antes que o registro da AMI criada anteriormente seja cancelado com sucesso, você poderá reter temporariamente um número maior do AMIs que sua contagem de retenção.
Os seguintes fatores são aplicáveis ao **encerramento de instâncias direcionado por uma política**:
+ Se você encerrar uma instância que foi alvo de uma política com um cronograma de retenção baseado em contagem, a política não gerenciará mais o AMIs que ela criou anteriormente a partir da instância encerrada. Você deve cancelar manualmente o registro deles mais cedo, AMIs caso não sejam mais necessários.
+ Se você encerrar uma instância que foi alvo de uma política com um cronograma de retenção baseado em idade, a política continuará cancelando o registro AMIs que foi criado anteriormente a partir da instância encerrada no cronograma definido, até, mas não incluindo, a última AMI. É necessário cancelar manualmente o registro da última AMI caso ela não seja mais necessária.
As considerações a seguir se aplicam às políticas de AMI à **descontinuação de AMIs**:
+ Se você aumentar a contagem de reprovação da AMI para uma agenda com retenção baseada na contagem, a alteração será aplicada a tudo AMIs (existente e novo) criado pelo cronograma.
+ Se você aumentar o período de suspensão da AMI para um cronograma com retenção com base na idade, a alteração será aplicada somente aos novos. AMIs AMIs Os existentes não são afetados.
+ Se você remover a regra de descontinuação da AMI de um cronograma, o Amazon Data Lifecycle Manager não cancelará a suspensão de uso das que foram anteriormente AMIs descontinuadas por esse cronograma.
+ Se você diminuir a contagem ou o período de depreciação da AMI para um cronograma, o Amazon Data Lifecycle Manager não cancelará a suspensão de uso das que foram anteriormente AMIs descontinuadas por esse cronograma.
+ Se você defasar manualmente uma AMI criada por uma política de AMI, o Amazon Data Lifecycle Manager não substituirá a defasagem.
+ Se você cancelar manualmente a defasagem de uma AMI que foi anteriormente defasada por uma política de AMI, o Amazon Data Lifecycle Manager não substituirá o cancelamento.
+ Se uma AMI for criada por várias programações conflitantes e uma ou mais dessas programações não tiverem uma regra de defasagem da AMI, o Amazon Data Lifecycle Manager não vai defasar essa AMI.
+ Se uma AMI for criada por várias programações conflitantes e todas essas programações tiverem uma regra de descontinuação da AMI, o Amazon Data Lifecycle Manager usará a regra de descontinuação que resulte na data de descontinuação mais posterior.
As seguintes considerações se aplicam a políticas de AMI e à [Lixeira](recycle-bin.md):
+ Se o Amazon Data Lifecycle Manager cancelar o registro de uma AMI e enviá-la para a lixeira quando o limite de retenção da política for atingido e você restaurar manualmente essa AMI da lixeira, você deverá cancelar manualmente o registro dessa AMI quando ela não for mais necessária. O Amazon Data Lifecycle Manager não poderá mais gerenciar a AMI.
+ Se você cancelar manualmente o registro uma AMI criada por uma política e essa AMI estiver na lixeira quando o limite de retenção da política for atingido, o Amazon Data Lifecycle Manager não cancelará o registro da AMI. O Amazon Data Lifecycle Manager não gerencia AMIs enquanto eles estão na lixeira.
Se a AMI for restaurada da lixeira antes que o limite de retenção da política seja atingido, o Amazon Data Lifecycle Manager cancelará o registro da AMI quando o limite de retenção da política for atingido.
Se a AMI for restaurada da lixeira depois que o limite de retenção da política seja atingido, o Amazon Data Lifecycle Manager não canelará mais o registro da AMI. Exclua-a manualmente quando ela não for mais necessária.
As seguintes considerações se aplicam a políticas de AMI que estão no estado **error**:
+ Para políticas com cronogramas de retenção com base na idade, AMIs que estão definidas para expirar enquanto a apólice estiver no `error` estado, são mantidas indefinidamente. Você deve cancelar o registro do AMIs manualmente. Quando você reativa a política, o Amazon Data Lifecycle Manager retoma o cancelamento do registro à medida que seus períodos de retenção expiram AMIs .
+ Para políticas com cronogramas de retenção baseados em contagem, a política interrompe a criação e o cancelamento do registro AMIs enquanto estiver no estado. `error` Quando você reativa a política, o Amazon Data Lifecycle Manager retoma a AMIs criação e retoma o cancelamento do registro à medida que o AMIs limite de retenção é atingido.
As considerações a seguir se aplicam às políticas e à **[desativação AMIs](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/disable-an-ami.html)** da AMI:
+ Se você desabilitar uma AMI criada pelo Amazon Data Lifecycle Manager, e essa AMI for desabilitada quando o limite de retenção for atingido, o Amazon Data Lifecycle Manager cancelará o registro da AMI e excluirá seus snapshots associados.
+ Se você desabilitar uma AMI criada pelo Amazon Data Lifecycle Manager e arquivar manualmente seus snapshots associados, e esses snapshots forem arquivados quando seu limite de retenção for atingido, o Amazon Data Lifecycle Manager não excluirá esses snapshots e não os gerenciará mais.
A consideração a seguir se aplica às políticas de AMIs e à **[proteção contra cancelamento de registro de AMIs](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/deregister-ami.html#ami-deregistration-protection)**:
+ Se você habilitar manualmente a proteção contra cancelamento de registro de uma AMI que foi criada pelo Amazon Data Lifecycle Manager e ela ainda estiver habilitada quando o limite de retenção da AMI for atingido, o Amazon Data Lifecycle Manager não gerenciará mais essa AMI. Você deverá cancelar manualmente o registro da AMI e excluir os snapshots subjacentes se ela não for mais necessária.
## Recursos adicionais do
Para obter mais informações, consulte o blog [Automatizando o snapshot e o gerenciamento de AMI do Amazon EBS usando o Amazon AWS Data Lifecycle Manager](https://aws.amazon.com/blogs/storage/automating-amazon-ebs-snapshot-and-ami-management-using-amazon-dlm/).
# Automatizar cópias de snapshots entre contas com o Data Lifecycle Manager
A automatização de cópias de snapshots entre contas permite copiar seus snapshots do Amazon EBS para regiões específicas em uma conta isolada e criptografar esses snapshots com uma chave de criptografia. Isso permite que você se proteja contra perda de dados no caso de sua conta ser comprometida.
A automatização de cópias de snapshots entre contas envolve duas contas:
+ **Conta de origem**—A conta de origem é a conta que cria e compartilha os snapshots com a conta de destino. Nessa conta, você deve criar uma política de instantâneos do EBS que crie instantâneos em intervalos definidos e depois os compartilhe com outras contas. AWS
+ **Conta**de destino—A conta de destino é a conta com a conta de destino com a qual os snapshots são compartilhados e é a conta que cria cópias dos snapshots compartilhados. Nesta conta, crie uma política de eventos de cópia entre contas que copia automaticamente snapshots compartilhados com ela por uma ou mais contas de origem especificadas.
**nota**
Tanto a política de snapshot do EBS da conta de origem quanto a política de eventos de cópia entre contas da conta de destino devem ser criadas na mesma região. AWS A conta de destino pode então copiar snapshots para diferentes regiões de destino, conforme necessário.
**Topics**
+ [Criar políticas de cópia de snapshot entre contas](#create-cac-policy)
+ [Especificar filtros de descrição de snapshot](#snapshot-descr-filters)
+ [Considerações sobre políticas de cópia de snapshot entre contas](#event-policy-considerations)
+ [Recursos adicionais do](#event-additional-resources)
## Criar políticas de cópia de snapshot entre contas
Para preparar as contas de origem e de destino para cópia de snapshot entre contas, você precisa executar as seguintes etapas:
**Topics**
### Etapa 1: Criar a política de snapshot do EBS (*conta de origem*)
Na conta de origem, crie uma política de snapshot do EBS que criará os snapshots e os compartilhará com as contas de destino necessárias.
Ao criar a política, certifique-se de habilitar o compartilhamento entre contas e de especificar as AWS contas de destino com as quais compartilhar os instantâneos. Estas são as contas com as quais os snapshots devem ser compartilhados. Se você estiver compartilhando snapshots criptografados, deverá dar permissão às contas de destino selecionadas para usar a Chave do KMS usada para criptografar o volume de origem. Para obter mais informações, consulte [Etapa 2: Compartilhe a chave gerenciada pelo cliente (*Conta de origem*)](#share-cmk).
**nota**
Crie essa política na mesma AWS região em que você criará a política de eventos de cópia entre contas da conta de destino na Etapa 3. Ambas as políticas devem estar na mesma região para que o compartilhamento de snapshots entre contas funcione adequadamente.
Você só pode compartilhar snapshots não criptografados ou criptografados usando uma chave gerenciada pelo cliente gerenciada pelo cliente. Você não pode compartilhar snapshots criptografados com a Chave do KMS de criptografia padrão do EBS. Se você compartilhar snapshots criptografados, também deverá compartilhar a Chave do KMS usada para criptografar o volume de origem com as contas de destino. Para obter mais informações, consulte [Como permitir que usuários em outras contas usem uma chave do KMS](https://docs.aws.amazon.com//kms/latest/developerguide/key-policy-modifying-external-accounts.html) no *Guia do desenvolvedor do AWS Key Management Service *.
Para obter mais informações sobre como criar um snapshot de política do EBS, consulte [Criar política padrão do Amazon Data Lifecycle Manager para snapshots](snapshot-ami-policy.md).
Use um dos métodos a seguir para criar a política de snapshot do EBS.
### Etapa 2: Compartilhe a chave gerenciada pelo cliente (*Conta de origem*)
Se você estiver compartilhando snapshots criptografados, conceda a função do IAM e as contas da AWS de destino (que você selecionou na etapa anterior) permissões para usar a chave gerenciada pelo cliente que foi usada para criptografar o volume de origem.
**nota**
Execute esta etapa apenas se você estiver compartilhando snapshots criptografados. Se você estiver compartilhando snapshots não criptografados, pule esta etapa.
------
#### [ Console ]
****
1. Abra o AWS KMS console em [https://console.aws.amazon.com/kms](https://console.aws.amazon.com/kms).
1. Para alterar o Região da AWS, use o seletor de região no canto superior direito da página.
1. No painel de navegação, escolha **Customer managed key** (Chave gerenciadas pelo cliente) e selecione a chave do KMS que você precisa compartilhar com as contas de destino.
Anote o ARN das Chave do KMS, você precisará disso mais tarde.
1. Na guia **Key policy** (Política de chaves), role para baixo até a seção **Key users** (Usuários chave). Escolha **Add** (Adicionar), insira o nome da função do IAM que você selecionou na etapa anterior e escolha **Add** (Adicionar).
1. Na guia **Key policy** (Política de chaves), role para a seção **Other AWS accounts** (Outras contas da ). Escolha **Adicionar outras AWS contas** e, em seguida, adicione todas as AWS contas de destino com as quais você escolheu compartilhar os instantâneos na etapa anterior.
1. Escolha **Salvar alterações**.
------
#### [ Command line ]
Use o [get-key-policy](https://docs.aws.amazon.com/cli/latest/reference/kms/get-key-policy.html)comando para recuperar a política de chaves atualmente anexada à chave KMS.
Por exemplo, o comando a seguir recupera a política de chaves para uma Chave do KMS com um ID de `9d5e2b3d-e410-4a27-a958-19e220d83a1e` e a grava em um arquivo chamado `snapshotKey.json`.
```
$ aws kms get-key-policy \
--policy-name default \
--key-id 9d5e2b3d-e410-4a27-a958-19e220d83a1e \
--query Policy \
--output text > snapshotKey.json
```
Abra a política de chaves usando seu editor de texto preferido. Adicione o ARN da função do IAM que você especificou ao criar a política de snapshot e as contas ARNs de destino com as quais compartilhar a chave KMS.
Por exemplo, na política a seguir, adicionamos o ARN da função padrão do IAM e o ARN da conta raiz da conta de destino `222222222222.`
**dica**
Para seguir o princípio de menor privilégio, não permita acesso total a `kms:CreateGrant`. Em vez disso, use a chave de `kms:GrantIsForAWSResource` condição para permitir que o usuário crie concessões na chave KMS somente quando a concessão for criada em nome do usuário por um AWS serviço, conforme mostrado no exemplo a seguir.
```
{
"Sid" : "Allow use of the key",
"Effect" : "Allow",
"Principal" : {
"AWS" : [
"arn:aws:iam::111111111111:role/service-role/AWSDataLifecycleManagerDefaultRole",
"arn:aws:iam::222222222222:root"
]
},
"Action" : [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
"Resource" : "*"
},
{
"Sid" : "Allow attachment of persistent resources",
"Effect" : "Allow",
"Principal" : {
"AWS" : [
"arn:aws:iam::111111111111:role/service-role/AWSDataLifecycleManagerDefaultRole",
"arn:aws:iam::222222222222:root"
]
},
"Action" : [
"kms:CreateGrant",
"kms:ListGrants",
"kms:RevokeGrant"
],
"Resource" : "*",
"Condition" : {
"Bool" : {
"kms:GrantIsForAWSResource" : "true"
}
}
}
```
Salve e feche o arquivo. Em seguida, use o [put-key-policy](https://docs.aws.amazon.com/cli/latest/reference/kms/put-key-policy.html)comando para anexar a política de chaves atualizada à chave KMS.
```
$ aws kms put-key-policy \
--policy-name default \
--key-id 9d5e2b3d-e410-4a27-a958-19e220d83a1e \
--policy file://snapshotKey.json
```
------
### Etapa 3: criar política de eventos de cópia entre contas (*conta de destino*)
Na conta de destino, crie uma política de eventos de cópia entre contas que copiará automaticamente os snapshots compartilhados pelas contas de origem necessárias.
Essa política só é executada na conta de destino quando uma das contas de origem especificadas compartilha o snapshot com a conta.
**nota**
Crie essa política na mesma AWS região da política de snapshot do EBS da conta de origem criada na Etapa 1. Ambas as políticas devem estar na mesma região para que o compartilhamento de snapshots entre contas funcione adequadamente. Em seguida, você pode configurar essa política para copiar snapshots para diferentes regiões de destino, conforme necessário.
Use um dos seguintes métodos para criar a política de eventos de cópia entre contas.
------
#### [ Console ]
1. Abra o console do Amazon EC2 em [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. No painel de navegação, selecione **Elastic Block Store**, **Lifecycle Manager** ((Gerenciador de ciclo de vida) e **Create snapshot lifecycle policy** (Criar política de ciclo de vida de snapshot).
1. Na tela **Select policy type** (Selecionar tipo de política), escolha **Cross-account copy event policy** (Cópia de política de eventos entre contas) e depois **Next** (Próximo).
1. Em **Policy description** (Descrição da política), insira uma breve descrição da política.
1. Em **Policy tags** (Etiquetas de políticas), adicione as etiquetas a serem aplicadas na política de ciclo de vida. É possível usar essas etiquetas para identificar e categorizar suas políticas.
1. Na seção **Event settings** (Configurações de evento), defina o evento de compartilhamento de snapshots que fará com que a política seja executada. Faça o seguinte:
1. Em **Contas de compartilhamento**, especifique as AWS contas de origem das quais você deseja copiar os instantâneos compartilhados. **Escolha **Adicionar conta**, insira o ID da AWS conta de 12 dígitos e escolha Adicionar.**
1. Em **Filter by description** (Filtrar por descrição), insira a descrição necessária do snapshot usando uma expressão regular. Somente os snapshots que são compartilhados pelas contas de origem especificadas e que tenham descrições que correspondam ao filtro especificado são copiados pela política. Para obter mais informações, consulte [Especificar filtros de descrição de snapshot](#snapshot-descr-filters).
1. Para a **IAM role** (função do IAM), escolha a função do IAM que tem permissões para executar ações de cópia de snapshots. Para usar a função padrão fornecida pelo Amazon Data Lifecycle Manager, escolha **Default role** (Função padrão). Se preferir, para usar uma função do IAM personalizada criada anteriormente, selecione **Choose another role** (Escolher outra função) e selecione a função a ser usada.
Se você estiver copiando snapshots criptografados, conceda as permissões de função do IAM selecionadas para usar a Chave do KMS de criptografia usada para criptografar o volume de origem. Da mesma forma, se você estiver criptografando o snapshot na região de destino usando uma Chave do KMS diferente, deverá conceder a permissão de função do IAM para usar a Chave do KMS de destino. Para obter mais informações, consulte [Etapa 4: permitir que a função do IAM use as Chaves do KMS necessárias (*conta de destino*)](#target_iam-role).
1. Na seção **Copy action** (Copiar ação), defina as ações de cópia de snapshots que a política deve executar quando for ativada. A política pode copiar snapshots para até três regiões. Especifique uma regra de cópia separada para cada região de destino. Para cada regra que você adicionar, faça o seguinte:
1. Para **Name** (Nome), insira um nome descritivo para a ação de cópia.
1. Em **Target Region** (Região de destino), selecione a região para a qual deseja copiar os snapshots.
1. Em **Expire**, especifique por quanto tempo manter as cópias de snapshot na região de destino após a criação.
1. Para criptografar a cópia do snapshot, Em **Encryption** (Criptografia), selecione **Enable encryption** (Habilitar criptografia). Se o snapshot de origem estiver criptografado ou se a criptografia por padrão estiver habilitada para a sua conta, a cópia do snapshot será sempre criptografada, mesmo que você não habilite a criptografia aqui. Se o snapshot de origem não estiver criptografado e a criptografia por padrão não estiver habilitada para sua conta, será possível optar por ativar ou desativar a criptografia. Se você habilitar a criptografia, mas não especificar uma Chave do KMS, os snapshots serão criptografados usando a Chave do KMS de criptografia padrão em cada região de destino. Se você especificar uma Chave do KMS para a região de destino, deverá ter acesso à Chave do KMS.
1. Para adicionar outras ações de cópia de snapshot, escolha **Add New Regions** (Adicionar novas regiões).
1. Em **Policy status after creation (Status da política após a criação)**, selecione **Enable policy (Habilitar política)** para iniciar as execuções da política no próximo horário agendado ou **Disable policy (Desabilitar política)** para impedir que a política seja executada. Se você não habilitar a política agora, ela não começará a copiar snapshots até que você a ative manualmente após a criação.
1. Selecione **Criar política**.
------
#### [ Command line ]
Use o [create-lifecycle-policy](https://docs.aws.amazon.com/cli/latest/reference/dlm/create-lifecycle-policy.html)comando para criar uma política. Para criar uma política de eventos de cópia entre contas, para `PolicyType`, especifique `EVENT_BASED_POLICY`.
Por exemplo, o comando a seguir cria uma política de eventos de cópia entre contas na conta de destino `222222222222`. A política copia snapshots que são compartilhados pela conta de origem `111111111111`. A política copia snapshots para `sa-east-1` e `eu-west-2`. Os snapshots copiados para `sa-east-1` são criptografados e retidos por 3 dias. Os snapshots copiados para `eu-west-2` são criptografados usando a Chave do KMS `8af79514-350d-4c52-bac8-8985e84171c7` e são retidos por 1 mês. A política usa a função padrão do IAM.
```
$ aws dlm create-lifecycle-policy \
--description "Copy policy" \
--state ENABLED \
--execution-role-arn arn:aws:iam::222222222222:role/service-role/AWSDataLifecycleManagerDefaultRole \
--policy-details file://policyDetails.json
```
O exemplo a seguir mostra o conteúdo do arquivo `policyDetails.json`.
```
{
"PolicyType" : "EVENT_BASED_POLICY",
"EventSource" : {
"Type" : "MANAGED_CWE",
"Parameters": {
"EventType" : "shareSnapshot",
"SnapshotOwner": ["111111111111"]
}
},
"Actions" : [{
"Name" :"Copy Snapshot to Sao Paulo and London",
"CrossRegionCopy" : [{
"Target" : "sa-east-1",
"EncryptionConfiguration" : {
"Encrypted" : false
},
"RetainRule" : {
"Interval" : 3,
"IntervalUnit" : "DAYS"
}
},
{
"Target" : "eu-west-2",
"EncryptionConfiguration" : {
"Encrypted" : true,
"CmkArn" : "arn:aws:kms:eu-west-2:222222222222:key/8af79514-350d-4c52-bac8-8985e84171c7"
},
"RetainRule" : {
"Interval" : 1,
"IntervalUnit" : "MONTHS"
}
}]
}]
}
```
Se a solicitação for bem-sucedida, o comando retornará o ID da política recém-criada. O seguinte é um exemplo de saída.
```
{
"PolicyId": "policy-9876543210abcdef0"
}
```
------
### Etapa 4: permitir que a função do IAM use as Chaves do KMS necessárias (*conta de destino*)
Se você estiver copiando snapshots criptografados, deverá conceder à função do IAM (que você selecionou na etapa anterior) permissões para usar a chave gerenciada pelo cliente que foi usada para criptografar o volume de origem.
**nota**
Execute esta etapa somente se você estiver copiando snapshots criptografados. Se você estiver copiando snapshots não criptografados, ignore esta etapa.
Use um dos métodos a seguir para adicionar as políticas necessárias à função do IAM.
------
#### [ Console ]
****
1. Abra o console do IAM em [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. No painel de navegação, selecione **Settings** (Configurações). Pesquise e selecione a função do IAM selecionada ao criar a política de eventos de cópia entre contas na etapa anterior. Se você optar por usar a função padrão, a função será nomeada **AWSDataLifecycleManagerDefaultRole**.
1. Escolha **Add inline policy** (Adicionar política em linha) e, em seguida, a guia **JSON**.
1. Substitua a política existente pela a seguir, e especifique o ARN da chave de KMS que foi usada para criptografar os volumes de origem e que foi compartilhado com você pela conta de origem na Etapa 2.
**nota**
Se você estiver copiando de várias contas de origem, deverá especificar o ARN da chave de KMS correspondente a partir de cada conta de origem.
No exemplo a seguir, a política concede a permissão de função do IAM para usar a Chave do KMS`1234abcd-12ab-34cd-56ef-1234567890ab`, que foi compartilhada pela conta de origem `111111111111` e Chave do KMS`4567dcba-23ab-34cd-56ef-0987654321yz` que existem na conta de destino `222222222222`.
**dica**
Para seguir o princípio de menor privilégio, não permita acesso total a `kms:CreateGrant`. Em vez disso, use a chave de `kms:GrantIsForAWSResource` condição para permitir que o usuário crie concessões na chave KMS somente quando a concessão for criada em nome do usuário por um AWS serviço, conforme mostrado no exemplo a seguir.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kms:RevokeGrant",
"kms:CreateGrant",
"kms:ListGrants"
],
"Resource": [
"arn:aws:kms:us-east-1:111111111111:key/1234abcd-12ab-34cd-56ef-1234567890ab",
"arn:aws:kms:us-east-1:222222222222:key/4567dcba-23ab-34cd-56ef-0987654321yz"
],
"Condition": {
"Bool": {
"kms:GrantIsForAWSResource": "true"
}
}
},
{
"Effect": "Allow",
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
"Resource": [
"arn:aws:kms:us-east-1:111111111111:key/1234abcd-12ab-34cd-56ef-1234567890ab",
"arn:aws:kms:us-east-1:222222222222:key/4567dcba-23ab-34cd-56ef-0987654321yz"
]
}
]
}
```
------
1. Escolha **Review policy (Revisar política)**
1. Para **Name** (Nome), insira um nome descritivo para a política e escolha **Create policy** (Criar política).
------
#### [ Command line ]
Usando seu editor de texto preferido, crie um novo arquivo JSON chamado `policyDetails.json`. Adicione a política a seguir e especifique o ARN da chave de KMS que foi usada para criptografar os volumes de origem e que foi compartilhada com você pela conta de origem na Etapa 2.
**nota**
Se você estiver copiando de várias contas de origem, deverá especificar o ARN da chave de KMS correspondente a partir de cada conta de origem.
No exemplo a seguir, a política concede a permissão de função do IAM para usar a Chave do KMS`1234abcd-12ab-34cd-56ef-1234567890ab`, que foi compartilhada pela conta de origem `111111111111` e Chave do KMS`4567dcba-23ab-34cd-56ef-0987654321yz` que existem na conta de destino `222222222222`.
**dica**
Para seguir o princípio de menor privilégio, não permita acesso total a `kms:CreateGrant`. Em vez disso, use a chave de `kms:GrantIsForAWSResource` condição para permitir que o usuário crie concessões na chave KMS somente quando a concessão for criada em nome do usuário por um AWS serviço, conforme mostrado no exemplo a seguir.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kms:RevokeGrant",
"kms:CreateGrant",
"kms:ListGrants"
],
"Resource": [
"arn:aws:kms:us-east-1:111111111111:key/1234abcd-12ab-34cd-56ef-1234567890ab",
"arn:aws:kms:us-east-1:222222222222:key/4567dcba-23ab-34cd-56ef-0987654321yz"
],
"Condition": {
"Bool": {
"kms:GrantIsForAWSResource": "true"
}
}
},
{
"Effect": "Allow",
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
"Resource": [
"arn:aws:kms:us-east-1:111111111111:key/1234abcd-12ab-34cd-56ef-1234567890ab",
"arn:aws:kms:us-east-1:222222222222:key/4567dcba-23ab-34cd-56ef-0987654321yz"
]
}
]
}
```
------
Salve e feche o arquivo. Em seguida, use o [put-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-policy.html)comando para adicionar a política à função do IAM.
Por exemplo
```
$ aws iam put-role-policy \
--role-name AWSDataLifecycleManagerDefaultRole \
--policy-name CopyPolicy \
--policy-document file://AdminPolicy.json
```
------
## Especificar filtros de descrição de snapshot
Quando você cria a política de cópia de snapshot na conta de destino, especifique um filtro de descrição de snapshot. O filtro de descrição do snapshot permite especificar um nível adicional de filtragem que permite controlar quais snapshots são copiados pela política. Isso significa que um snapshot só será copiado pela política se for compartilhado por uma das contas de origem especificadas e tiver uma descrição de snapshot que corresponda ao filtro especificado. Em outras palavras, se um snapshot for compartilhado por uma das contas de curso especificadas, mas não tiver uma descrição que corresponda ao filtro especificado, ele não será copiado pela política.
A descrição do filtro de snapshot deve ser especificada usando uma expressão regular. É um campo obrigatório ao criar políticas de eventos de cópia entre contas usando o console e a linha de comando. A seguir estão exemplos de expressões regulares que podem ser usadas:
+ `.*`—Esse filtro corresponde a todas as descrições de snapshot. Se você usar essa expressão, a política copiará todos os snapshots compartilhados por uma das contas de origem especificadas.
+ `Created for policy: policy-0123456789abcdef0.*`—Este filtro corresponde apenas aos snapshots criados por uma política com um ID de `policy-0123456789abcdef0`. Se você usar uma expressão como esta, apenas snapshots que são compartilhados com sua conta por uma das contas de origem especificadas e que foram criados por uma política com o ID especificado serão copiados pela política.
+ `.*production.*`—Esse filtro corresponde a qualquer snapshot que tenha a palavra `production` em qualquer lugar em sua descrição. Se você usar essa expressão, a política copiará todos os snapshots compartilhados por uma das contas de origem especificadas e que tenham o texto especificado em sua descrição.
## Considerações sobre políticas de cópia de snapshot entre contas
As seguintes considerações se aplicam às políticas de eventos de cópia entre contas:
+ A política de snapshot do EBS da conta de origem e a política de eventos de cópia entre contas da conta de destino devem ser criadas na mesma região. AWS Depois que o snapshot é compartilhado, a política da conta de destino pode copiar o snapshot para diferentes regiões de destino, conforme especificado nas ações de cópia.
+ Você só pode copiar snapshots não criptografados ou criptografados usando uma chave gerenciada pelo cliente.
+ É possível criar uma política de eventos de cópia entre contas para copiar snapshots compartilhados fora do Amazon Data Lifecycle Manager.
+ Se você quiser criptografar snapshots na conta de destino, a função do IAM selecionada para a política de eventos de cópia entre contas deve ter permissão para usar a Chave do KMS necessária.
## Recursos adicionais do
Para obter mais informações, consulte o blog [Automatizando a cópia de snapshots criptografados do Amazon EBS entre AWS contas](https://aws.amazon.com/blogs/storage/automating-copying-encrypted-amazon-ebs-snapshots-across-aws-accounts/). AWS
# Modificar políticas do Amazon Data Lifecycle Manager
Lembre-se do seguinte quando modificar políticas do Amazon Data Lifecycle Manager:
+ Se você modificar uma política de AMI ou snapshot removendo suas tags de destino, os volumes ou instâncias que possuam essas tags não serão mais gerenciados pela política.
+ Se você modificar o nome de um agendamento, os instantâneos ou AMIs criados com o nome antigo do agendamento não serão mais gerenciados pela política.
+ Se você modificar um cronograma de retenção com base na idade para usar um novo intervalo de tempo, o novo intervalo será usado somente para novos instantâneos ou AMIs criado após a alteração. O novo agendamento não afeta o cronograma de retenção de snapshots nem os AMIs criados antes da alteração.
+ Não é possível alterar a programação de retenção de uma política de baseada em contagem para baseada no tempo após a criação. Para fazer essa alteração, crie uma nova política.
+ Se você desabilitar uma política com um cronograma de retenção baseado na idade, os snapshots ou AMIs que estiverem configurados para expirar enquanto a política estiver desativada serão retidos indefinidamente. Você deve excluir os instantâneos ou cancelar o registro manualmente. AMIs Quando você reativa a política, o Amazon Data Lifecycle Manager retoma a exclusão de snapshots ou o cancelamento do registro à medida que seus períodos de retenção expiram. AMIs
+ Se você desabilitar uma política com um cronograma de retenção baseado em contagem, a política deixará de criar e excluir instantâneos ou. AMIs Quando você reativa a política, o Amazon Data Lifecycle Manager retoma a criação de snapshots AMIs e retoma a exclusão de snapshots ou quando o limite de retenção é atingido. AMIs
+ Se você desabilitar uma política que tenha uma política habilitada para arquivamento de snapshots, os snapshots que estiverem no nível de arquivamento no momento da desabilitação da política não serão mais gerenciados pelo Amazon Data Lifecycle Manager. Você deve excluir manualmente os snapshots, caso eles não sejam mais necessários.
+ Se você habilitar o arquivamento de snapshots segundo uma programação baseada em contagem, a regra de arquivamento se aplicará a todos os novos snapshots criados e arquivados segundo a programação e também aos snapshots existentes que foram criados e arquivados anteriormente segundo a programação.
+ Se você habilitar o arquivamento de snapshots segundo uma programação baseada em idade, a regra de arquivamento só se aplicará aos novos snapshots criados após a habilitação do arquivamento de snapshots. Os snapshots existentes criados antes da habilitação do arquivamento de snapshots continuarão sendo excluídos dos respectivos níveis de armazenamento, de acordo com a programação definida quando esses snapshots foram originalmente criados e arquivados.
+ Se você desabilitar o arquivamento de snapshots para uma programação baseada em contagem, a programação interromperá imediatamente o arquivamento de snapshots. Os snapshots que foram previamente arquivados de acordo com a programação permanecerão no nível de arquivamento e não serão excluídos pelo Amazon Data Lifecycle Manager.
+ Se você desabilitar o arquivamento de snapshots segundo uma programação baseada em idade, os snapshots criados pela política e que estão programados para serem arquivados serão excluídos permanentemente na data e hora de arquivamento programadas, conforme indicado pela tag `aws:dlm:expirationTime` do sistema.
+ Se você desabilitar o arquivamento de snapshots segundo uma programação, a programação interromperá imediatamente o arquivamento de snapshots. Os snapshots que foram previamente arquivados de acordo com a programação permanecerão no nível de arquivamento e não serão excluídos pelo Amazon Data Lifecycle Manager.
+ Se você modificar a contagem de retenção de arquivamento para uma programação baseada em contagem, a nova contagem de retenção incluirá os snapshots existentes que foram previamente arquivados segundo a programação.
+ Se você modificar o período de retenção no arquivamento para um uma programação baseada em idade, o novo período de retenção só se aplicará aos snapshots que forem arquivados após a modificação da regra de retenção.
Use um dos procedimentos a seguir para modificar uma política de ciclo de vida.
------
#### [ Console ]
**Para modificar uma política de ciclo de vida**
1. Abra o console do Amazon EC2 em [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. No painel de navegação, escolha **Elastic Block Store** e, depois, **Lifecycle Manager (Gerenciador de ciclo de vida)**.
1. Selecione uma política de ciclo de vida na lista.
1. Escolha **Ações**, **Modificar política de ciclo de vida**.
1. Modifique as configurações da política, conforme necessário. Por exemplo, é possível modificar a programação, adicionar ou remover tags ou habilitar e desabilitar a política.
1. Escolha **Modificar política**.
------
#### [ Command line ]
Use o [update-lifecycle-policy](https://docs.aws.amazon.com/cli/latest/reference/dlm/update-lifecycle-policy.html)comando para modificar as informações em uma política de ciclo de vida. Para simplificar a sintaxe, este exemplo faz referência ao arquivo JSON `policyDetailsUpdated.json` que inclui os detalhes da política.
```
aws dlm update-lifecycle-policy \
--state DISABLED \
--execution-role-arn arn:aws:iam::12345678910:role/AWSDataLifecycleManagerDefaultRole" \
--policy-details file://policyDetailsUpdated.json
```
Este é um exemplo do arquivo `policyDetailsUpdated.json`.
```
{
"ResourceTypes":[
"VOLUME"
],
"TargetTags":[
{
"Key": "costcenter",
"Value": "120"
}
],
"Schedules":[
{
"Name": "DailySnapshots",
"TagsToAdd": [
{
"Key": "type",
"Value": "myDailySnapshot"
}
],
"CreateRule": {
"Interval": 12,
"IntervalUnit": "HOURS",
"Times": [
"15:00"
]
},
"RetainRule": {
"Count" :5
},
"CopyTags": false
}
]
}
```
Para visualizar a política atualizada, use o comando `get-lifecycle-policy`. É possível ver que o estado, o valor da tag, o intervalo de snapshots e o horário de início do snapshot foram alterados.
------
# Excluir políticas do Amazon Data Lifecycle Manager
Lembre-se do seguinte quando excluir políticas do Amazon Data Lifecycle Manager:
+ Se você excluir uma política, os instantâneos ou AMIs criados por essa política não serão excluídos automaticamente. Se você não precisar mais dos instantâneos ou AMIs, deverá excluí-los manualmente.
+ Se você excluir uma política que tenha uma política habilitada para arquivamento de snapshots, os snapshots que estiverem no nível de arquivamento no momento da exclusão da política não serão mais gerenciados pelo Amazon Data Lifecycle Manager. Você deve excluir manualmente os snapshots, caso eles não sejam mais necessários.
+ Se você excluir uma política com uma programação baseada em idade e habilitada para arquivamento, os snapshots criados pela política e que estão programados para serem arquivados serão excluídos permanentemente na data e hora de arquivamento programadas, conforme indicado pela tag `aws:dlm:expirationtime`do sistema.
Use um dos procedimentos a seguir para excluir uma política de ciclo de vida.
------
#### [ Console ]
**Para excluir uma política de ciclo de vida**
1. Abra o console do Amazon EC2 em [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. No painel de navegação, escolha **Elastic Block Store** e, depois, **Lifecycle Manager (Gerenciador de ciclo de vida)**.
1. Selecione uma política de ciclo de vida na lista.
1. Escolha **Ações**, **Excluir política de ciclo de vida**.
1. Quando a confirmação for solicitada, escolha **Excluir política**.
------
#### [ Command line ]
Use o [delete-lifecycle-policy](https://docs.aws.amazon.com/cli/latest/reference/dlm/delete-lifecycle-policy.html)comando para excluir uma política de ciclo de vida e liberar as tags de destino especificadas na política para reutilização.
**nota**
É possível excluir snapshots criados somente por Amazon Data Lifecycle Manager.
```
aws dlm delete-lifecycle-policy --policy-id policy-0123456789abcdef0
```
------
A [Referência de API do Amazon Data Lifecycle Manager](https://docs.aws.amazon.com/dlm/latest/APIReference/) fornece as descrições e a sintaxe de cada uma das ações e dos tipos de dados para a API de consulta do Amazon Data Lifecycle Manager.
Como alternativa, você pode usar um deles AWS SDKs para acessar a API de uma forma adaptada à linguagem de programação ou plataforma que você está usando. Para obter mais informações, consulte [AWS SDKs](https://aws.amazon.com/developer/tools/).
# Controlar o acesso ao Amazon Data Lifecycle Manager usando o IAM
O acesso ao Amazon Data Lifecycle Manager exige credenciais. Essas credenciais devem ter permissões para acessar AWS recursos, como instâncias, volumes, instantâneos e. AMIs
As permissões do IAM a seguir são necessárias para usar o Amazon Data Lifecycle Manager.
**nota**
As permissões `ec2:DescribeAvailabilityZones`, `ec2:DescribeRegions`, `kms:ListAliases` e `kms:DescribeKey` são necessárias somente para usuários do console. Se o acesso ao console não for necessário, será possível remover as permissões.
O formato ARN da *AWSDataLifecycleManagerDefaultRole*função difere dependendo se ela foi criada usando o console ou o. AWS CLI Se a função foi criada usando o console, o formato do ARN é `arn:aws:iam::account_id:role/service-role/AWSDataLifecycleManagerDefaultRole`. Se a função foi criada usando o AWS CLI, o formato ARN é. `arn:aws:iam::account_id:role/AWSDataLifecycleManagerDefaultRole`
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "dlm:*",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": [
"arn:aws:iam::111122223333:role/AWSDataLifecycleManagerDefaultRole",
"arn:aws:iam::111122223333:role/AWSDataLifecycleManagerDefaultRoleForAMIManagement",
"arn:aws:iam::111122223333:role/service-role/AWSDataLifecycleManagerDefaultRole",
"arn:aws:iam::111122223333:role/service-role/AWSDataLifecycleManagerDefaultRoleForAMIManagement"
]
},
{
"Effect": "Allow",
"Action": "iam:ListRoles",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2:DescribeAvailabilityZones",
"ec2:DescribeRegions",
"kms:ListAliases",
"kms:DescribeKey"
],
"Resource": "*"
}
]
}
```
------
**Permissões para criptografia**
Considere o seguinte ao trabalhar com o Amazon Data Lifecycle Manager e recursos criptografados.
+ Se o volume de origem estiver criptografado, certifique-se de que as funções padrão do Amazon Data Lifecycle Manager (**AWSDataLifecycleManagerDefaultRole**e **AWSDataLifecycleManagerDefaultRoleForAMIManagement**) tenham permissão para usar as chaves KMS usadas para criptografar o volume.
+ Se você habilitar **a cópia entre regiões** para instantâneos não criptografados ou AMIs apoiada por instantâneos não criptografados e optar por ativar a criptografia na região de destino, certifique-se de que as funções padrão tenham permissão para usar a chave KMS necessária para realizar a criptografia na região de destino.
+ Se você habilitar **a cópia entre regiões** para instantâneos criptografados ou AMIs apoiada por instantâneos criptografados, certifique-se de que as funções padrão tenham permissão para usar as chaves KMS de origem e de destino.
+ Se você habilitar o arquivamento de snapshots para snapshots criptografados, certifique-se de que a **AWSDataLifecycleManagerDefaultRole**função padrão do Amazon Data Lifecycle Manager () tenha permissão para usar a chave KMS usada para criptografar o snapshot.
Para obter mais informações, consulte [Permissão para usuários em outras contas usarem uma chave KMS](https://docs.aws.amazon.com//kms/latest/developerguide/key-policy-modifying-external-accounts.html) no *Guia de desenvolvedor do AWS Key Management Service *.
Para obter mais informações, consulte [Alteração de permissões para um usuário](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html) no *Guia do usuário do IAM*.
# AWS políticas gerenciadas para o Amazon Data Lifecycle Manager
Uma política AWS gerenciada é uma política autônoma criada e administrada por AWS. AWS as políticas gerenciadas são projetadas para fornecer permissões para muitos casos de uso comuns. AWS as políticas gerenciadas tornam mais eficiente a atribuição de permissões apropriadas a usuários, grupos e funções do que se você mesmo tivesse que escrever as políticas.
No entanto, você não pode alterar as permissões definidas nas políticas AWS gerenciadas. AWS ocasionalmente atualiza as permissões definidas em uma política AWS gerenciada. Quando isso ocorre, a atualização afetará todas as entidades principais (usuários, grupos e perfis) às quais a política está anexada.
O Amazon Data Lifecycle Manager fornece políticas AWS gerenciadas para casos de uso comuns. Essas políticas tornam mais eficiente definir as permissões apropriadas e controlar o acesso aos seus recursos. As políticas AWS gerenciadas fornecidas pelo Amazon Data Lifecycle Manager foram projetadas para serem vinculadas às funções que você passa para o Amazon Data Lifecycle Manager.
**Topics**
+ [AWSDataLifecycleManagerServiceRole](#AWSDataLifecycleManagerServiceRole)
+ [AWSDataLifecycleManagerServiceRoleForAMIManagement](#AWSDataLifecycleManagerServiceRoleForAMIManagement)
+ [AWSDataLifecycleManagerSSMFullAcesso](#AWSDataLifecycleManagerSSMFullAccess)
+ [AWS atualizações de políticas gerenciadas](#policy-update)
## AWSDataLifecycleManagerServiceRole
A **AWSDataLifecycleManagerServiceRole**política fornece permissões apropriadas ao Amazon Data Lifecycle Manager para criar e gerenciar políticas de snapshot do Amazon EBS e políticas de eventos de cópia entre contas.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:CreateSnapshot",
"ec2:CreateSnapshots",
"ec2:DeleteSnapshot",
"ec2:DescribeInstances",
"ec2:DescribeVolumes",
"ec2:DescribeSnapshots",
"ec2:EnableFastSnapshotRestores",
"ec2:DescribeFastSnapshotRestores",
"ec2:DisableFastSnapshotRestores",
"ec2:CopySnapshot",
"ec2:ModifySnapshotAttribute",
"ec2:DescribeSnapshotAttribute",
"ec2:ModifySnapshotTier",
"ec2:DescribeSnapshotTierStatus",
"ec2:DescribeAvailabilityZones"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": "arn:aws:ec2:*::snapshot/*"
},
{
"Effect": "Allow",
"Action": [
"events:PutRule",
"events:DeleteRule",
"events:DescribeRule",
"events:EnableRule",
"events:DisableRule",
"events:ListTargetsByRule",
"events:PutTargets",
"events:RemoveTargets"
],
"Resource": "arn:aws:events:*:*:rule/AwsDataLifecycleRule.managed-cwe.*"
}
]
}
```
------
## AWSDataLifecycleManagerServiceRoleForAMIManagement
A **AWSDataLifecycleManagerServiceRoleForAMIManagement**política fornece permissões apropriadas ao Amazon Data Lifecycle Manager para criar e gerenciar políticas de AMI baseadas no Amazon EBS-Backed.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:CreateTags",
"Resource": [
"arn:aws:ec2:*::snapshot/*",
"arn:aws:ec2:*::image/*"
]
},
{
"Effect": "Allow",
"Action": [
"ec2:DescribeImages",
"ec2:DescribeInstances",
"ec2:DescribeImageAttribute",
"ec2:DescribeVolumes",
"ec2:DescribeSnapshots"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "ec2:DeleteSnapshot",
"Resource": "arn:aws:ec2:*::snapshot/*"
},
{
"Effect": "Allow",
"Action": [
"ec2:ResetImageAttribute",
"ec2:DeregisterImage",
"ec2:CreateImage",
"ec2:CopyImage",
"ec2:ModifyImageAttribute"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2:EnableImageDeprecation",
"ec2:DisableImageDeprecation"
],
"Resource": "arn:aws:ec2:*::image/*"
}
]
}
```
------
## AWSDataLifecycleManagerSSMFullAcesso
Fornece ao Amazon Data Lifecycle Manager permissão para realizar as ações do Systems Manager necessárias para executar scripts prévios e posteriores em todas as instâncias do Amazon EC2.
**Importante**
A política gerenciada usa a chave de condição `aws:ResourceTag` para restringir o acesso a documentos do SSM específicos ao usar scripts prévios e posteriores. Para permitir que o Amazon Data Lifecycle Manager acesse os documentos do SSM, você deve garantir que eles estejam marcados com `DLMScriptsAccess:true`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowSSMReadOnlyAccess",
"Effect": "Allow",
"Action": [
"ssm:GetCommandInvocation",
"ssm:ListCommands",
"ssm:DescribeInstanceInformation"
],
"Resource": "*"
},
{
"Sid": "AllowTaggedSSMDocumentsOnly",
"Effect": "Allow",
"Action": [
"ssm:SendCommand",
"ssm:DescribeDocument",
"ssm:GetDocument"
],
"Resource": [
"arn:aws:ssm:*:*:document/*"
],
"Condition": {
"StringEquals": {
"aws:ResourceTag/DLMScriptsAccess": "true"
}
}
},
{
"Sid": "AllowSpecificAWSOwnedSSMDocuments",
"Effect": "Allow",
"Action": [
"ssm:SendCommand",
"ssm:DescribeDocument",
"ssm:GetDocument"
],
"Resource": [
"arn:aws:ssm:*:*:document/AWSEC2-CreateVssSnapshot",
"arn:aws:ssm:*:*:document/AWSSystemsManagerSAP-CreateDLMSnapshotForSAPHANA"
]
},
{
"Sid": "AllowAllEC2Instances",
"Effect": "Allow",
"Action": [
"ssm:SendCommand"
],
"Resource": [
"arn:aws:ec2:*:*:instance/*"
]
}
]
}
```
------
## AWS atualizações de políticas gerenciadas
AWS os serviços mantêm e atualizam as políticas AWS gerenciadas. Você não pode alterar as permissões nas políticas AWS gerenciadas. Ocasionalmente, os serviços adicionam permissões adicionais a uma política AWS gerenciada para oferecer suporte a novos recursos. Esse tipo de atualização afeta todas as identidades (usuários, grupos e funções) em que a política está anexada. É mais provável que os serviços atualizem uma política AWS gerenciada quando um novo recurso é lançado ou quando novas operações são disponibilizadas. Os serviços não removem as permissões de uma política AWS gerenciada, portanto, as atualizações de políticas não violarão suas permissões existentes.
A tabela a seguir fornece detalhes sobre as atualizações das políticas AWS gerenciadas do Amazon Data Lifecycle Manager desde que esse serviço começou a rastrear essas alterações. Para obter alertas automáticos sobre alterações feitas nesta página, inscreva-se no feed de RSS em [Histórico de documentos do Guia do usuário do Amazon EBS](doc-history.md).
| Alteração | Descrição | Data |
| --- | --- | --- |
| AWSDataLifecycleManagerServiceRole— Atualizou as permissões da política. | O Amazon Data Lifecycle Manager adicionou a ação ec2:DescribeAvailabilityZones para conceder permissão às políticas de snapshot para obter informações sobre zonas locais. | 16 de dezembro de 2024 |
| AWSDataLifecycleManagerSSMFullAcesso — Atualizou as permissões da política. | Atualizada a política para garantir compatibilidade com snapshots consistentes com a aplicação para o SAP HANA usando o documento do SSM AWSSystemsManagerSAP-CreateDLMSnapshotForSAPHANA. | 17 de novembro de 2023 |
| AWSDataLifecycleManagerSSMFullAcesso — Foi adicionada uma nova política AWS gerenciada. | O Amazon Data Lifecycle Manager adicionou a política gerenciada de acesso. AWSData LifecycleManager SSMFull AWS | 7 de novembro de 2023 |
| AWSDataLifecycleManagerServiceRole— Permissões adicionadas para oferecer suporte ao arquivamento de instantâneos. | O Amazon Data Lifecycle Manager adicionou as ações ec2:ModifySnapshotTier e ec2:DescribeSnapshotTierStatus para conceder permissão às políticas de snapshots para arquivar snapshots e verificar seu status de arquivamento. | 30 de setembro de 2022 |
| AWSDataLifecycleManagerServiceRoleForAMIManagement— Permissões adicionadas para dar suporte à descontinuação da AMI. | O Amazon Data Lifecycle Manager adicionou as ações ec2:EnableImageDeprecation e ec2:DisableImageDeprecation para conceder permissão de políticas de AMI apoiadas pelo EBS para habilitar e desabilitar a defasagem da AMI. | 23 de agosto de 2021 |
| O Amazon Data Lifecycle Manager começou a monitorar alterações | O Amazon Data Lifecycle Manager começou a monitorar as alterações em suas políticas gerenciadas. AWS | 23 de agosto de 2021 |
# Perfis de serviço do IAM para o Amazon Data Lifecycle Manager
Uma função AWS Identity and Access Management (IAM) é semelhante à de um usuário, pois é uma AWS identidade com políticas de permissões que determinam o que a identidade pode ou não fazer AWS. No entanto, em vez de ser exclusivamente associada a uma pessoa, o propósito do perfil é ser assumido por qualquer pessoa que precisar dele. Uma função de serviço é uma função que um AWS serviço assume para realizar ações em seu nome. Como um serviço que executa as operações de backup para você, o Amazon Data Lifecycle Manager exige que você atribua uma função a ele ao executar operações de política para você. Para obter mais informações sobre funções do IAM, consulte [Funções do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) no *Guia do usuário do IAM*.
A função que você passa para o Amazon Data Lifecycle Manager deve ter uma política do IAM com as permissões que permitam ao Amazon Data Lifecycle Manager realizar ações associadas às operações de política, como criar AMIs snapshots e copiar AMIs snapshots, excluir snapshots e cancelar o registro. AMIs Diferentes permissões são necessárias para cada um dos tipos de política do Amazon Data Lifecycle Manager. A função também deve ter o Amazon Data Lifecycle Manager listado como uma entidade confiável, o que permite que o Amazon Data Lifecycle Manager assuma a função.
**Topics**
+ [Funções de serviço padrão para o Amazon Data Lifecycle Manager](#default-service-roles)
+ [Funções de serviço personalizadas para o Amazon Data Lifecycle Manager](#custom-role)
## Funções de serviço padrão para o Amazon Data Lifecycle Manager
O Amazon Data Lifecycle Manager usa as seguintes funções de serviço padrão:
+ **AWSDataLifecycleManagerDefaultRole**—função padrão para gerenciar instantâneos. Ele confia apenas no serviço `dlm.amazonaws.com` para assumir a função e permite que o Amazon Data Lifecycle Manager execute as ações exigidas pelas políticas de cópia de snapshot e de snapshot entre contas em seu nome. Essa função usa a política ` AWSDataLifecycleManagerServiceRole` AWS gerenciada.
**nota**
O formato do ARN da função é diferente dependendo se ela foi criada usando o console ou a AWS CLI. Se a função foi criada usando o console, o formato do ARN é `arn:aws:iam::account_id:role/service-role/AWSDataLifecycleManagerDefaultRole`. Se a função foi criada usando o AWS CLI, o formato ARN é. `arn:aws:iam::account_id:role/AWSDataLifecycleManagerDefaultRole`
+ **AWSDataLifecycleManagerDefaultRoleForAMIManagement**—função padrão para gerenciamento AMIs. Ela confia apenas no serviço `dlm.amazonaws.com` para assumir a função e permite que o Amazon Data Lifecycle Manager execute as ações exigidas pelas políticas de AMI apoiadas pelo EBS para você. Essa função usa a política `AWSDataLifecycleManagerServiceRoleForAMIManagement` AWS gerenciada.
Se você estiver usando o console do Amazon Data Lifecycle Manager, o Amazon Data Lifecycle Manager **AWSDataLifecycleManagerDefaultRole**cria automaticamente a função de serviço na primeira vez que você cria uma política de cópia de snapshot ou de snapshot entre contas, e cria automaticamente a função de serviço na primeira vez que você **AWSDataLifecycleManagerDefaultRoleForAMIManagement**cria uma política de AMI apoiada pelo EBS.
Se você não estiver usando o console, poderá criar manualmente as funções de serviço usando o [create-default-role](https://docs.aws.amazon.com/cli/latest/reference/dlm/create-default-role.html)comando. Para`--resource-type`, especifique `snapshot` para criar AWSData LifecycleManagerDefaultRole ou `image` criar AWSData LifecycleManagerDefaultRoleForAMIManagement.
```
$ aws dlm create-default-role --resource-type snapshot|image
```
Se você excluir essa função de serviço padrão e precisar criá-la novamente, poderá usar esse mesmo processo para recriar a função em sua conta.
## Funções de serviço personalizadas para o Amazon Data Lifecycle Manager
Como alternativa ao uso das funções de serviço padrão, é possível criar funções do IAM personalizadas com as permissões necessárias e selecioná-las ao criar uma política de ciclo de vida.
**Para criar uma função do IAM personalizada**
1. Crie funções com as seguintes permissões.
+ Permissões necessárias para gerenciar políticas de ciclo de vida de snapshot
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:CreateSnapshot",
"ec2:CreateSnapshots",
"ec2:DeleteSnapshot",
"ec2:DescribeInstances",
"ec2:DescribeVolumes",
"ec2:DescribeSnapshots",
"ec2:EnableFastSnapshotRestores",
"ec2:DescribeFastSnapshotRestores",
"ec2:DisableFastSnapshotRestores",
"ec2:CopySnapshot",
"ec2:ModifySnapshotAttribute",
"ec2:DescribeSnapshotAttribute",
"ec2:ModifySnapshotTier",
"ec2:DescribeSnapshotTierStatus",
"ec2:DescribeAvailabilityZones"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": "arn:aws:ec2:*::snapshot/*"
},
{
"Effect": "Allow",
"Action": [
"events:PutRule",
"events:DeleteRule",
"events:DescribeRule",
"events:EnableRule",
"events:DisableRule",
"events:ListTargetsByRule",
"events:PutTargets",
"events:RemoveTargets"
],
"Resource": "arn:aws:events:*:*:rule/AwsDataLifecycleRule.managed-cwe.*"
},
{
"Effect": "Allow",
"Action": [
"ssm:GetCommandInvocation",
"ssm:ListCommands",
"ssm:DescribeInstanceInformation"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ssm:SendCommand",
"ssm:DescribeDocument",
"ssm:GetDocument"
],
"Resource": [
"arn:aws:ssm:*:*:document/*"
],
"Condition": {
"StringEquals": {
"aws:ResourceTag/DLMScriptsAccess": "true"
}
}
},
{
"Effect": "Allow",
"Action": [
"ssm:SendCommand",
"ssm:DescribeDocument",
"ssm:GetDocument"
],
"Resource": [
"arn:aws:ssm:*::document/*"
]
},
{
"Effect": "Allow",
"Action": [
"ssm:SendCommand"
],
"Resource": [
"arn:aws:ec2:*:*:instance/*"
],
"Condition": {
"StringNotLike": {
"aws:ResourceTag/DLMScriptsAccess": "false"
}
}
}
]
}
```
------
+ Permissões necessárias para gerenciar políticas de ciclo de vida da AMI
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:CreateTags",
"Resource": [
"arn:aws:ec2:*::snapshot/*",
"arn:aws:ec2:*::image/*"
]
},
{
"Effect": "Allow",
"Action": [
"ec2:DescribeImages",
"ec2:DescribeInstances",
"ec2:DescribeImageAttribute",
"ec2:DescribeVolumes",
"ec2:DescribeSnapshots"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "ec2:DeleteSnapshot",
"Resource": "arn:aws:ec2:*::snapshot/*"
},
{
"Effect": "Allow",
"Action": [
"ec2:ResetImageAttribute",
"ec2:DeregisterImage",
"ec2:CreateImage",
"ec2:CopyImage",
"ec2:ModifyImageAttribute"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2:EnableImageDeprecation",
"ec2:DisableImageDeprecation"
],
"Resource": "arn:aws:ec2:*::image/*"
}
]
}
```
------
Para obter mais informações, consulte [Criar uma função](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user.html) no *Guia do usuário do IAM*.
1. Adicione uma relação de confiança às funções.
1. No console do IAM, selecione **Roles (Funções)**.
1. Selecione a função que você criou e, em seguida, escolha **Relações de confiança**.
1. Escolha **Edit Trust Relationship (Editar relação de confiança)**, adicione a seguinte política e, em seguida, escolha **Update Trust Policy (Atualizar política de confiança)**.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": {
"Service": "dlm.amazonaws.com"
},
"Action": "sts:AssumeRole"
}]
}
```
------
Recomendamos o uso das chaves de condição `aws:SourceAccount` e `aws:SourceArn` para se proteger contra [O problema do agente confuso](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html). Por exemplo, é possível adicionar o bloco de condições a seguir na política de confiança anterior. A `aws:SourceAccount` é a proprietária da política de ciclo de vida e o `aws:SourceArn` é o ARN da política de ciclo de vida. Se você não souber o ID da política de ciclo de vida, poderá substituir essa parte do ARN por um curinga (`*`) e atualizar a política após criar a política de ciclo de vida.
```
"Condition": {
"StringEquals": {
"aws:SourceAccount": "account_id"
},
"ArnLike": {
"aws:SourceArn": "arn:partition:dlm:region:account_id:policy/policy_id"
}
}
```
# Monitorar políticas do Amazon Data Lifecycle Manager
Você pode usar os seguintes recursos para monitorar o ciclo de vida de seus instantâneos e. AMIs
**Topics**
+ [Console e AWS CLI](#monitor-console-cli)
+ [AWS CloudTrail](#monitor-lifecycle-cloudtrail)
+ [Monitore as políticas do Data Lifecycle Manager usando EventBridge](monitor-cloudwatch-events.md)
+ [Monitore as políticas do Data Lifecycle Manager usando CloudWatch](monitor-dlm-cw-metrics.md)
## Console e AWS CLI
É possível visualizar as políticas de ciclo de vida usando o console do Amazon EC2 ou a AWS CLI. Cada snapshot e AMI criada por uma política possui um timestamp e tags relacionadas à política. Você pode filtrar instantâneos e AMIs usar essas tags para verificar se seus backups estão sendo criados conforme o esperado.
## AWS CloudTrail
Com AWS CloudTrail, você pode monitorar a atividade do usuário e o uso da API para demonstrar conformidade com políticas internas e padrões regulatórios. Para obter mais informações, consulte o [Guia do usuário do AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/).
# Monitore as políticas do Data Lifecycle Manager usando EventBridge
O Amazon EBS e o Amazon Data Lifecycle Manager geram eventos relacionados às ações das políticas de ciclo de vida. Você pode usar o AWS Lambda Amazon CloudWatch Events para lidar com notificações de eventos de forma programática. Os eventos são emitidos com base no melhor esforço. Para obter mais informações, consulte o [Guia EventBridge do usuário da Amazon](https://docs.aws.amazon.com/eventbridge/latest/userguide/).
Os seguintes eventos estão disponíveis:
**nota**
Nenhum evento é emitido para ações de política de ciclo de vida da AMI.
+ `createSnapshot`: um evento do Amazon EBS emitido quando uma ação `CreateSnapshot` é bem-sucedida ou falha. Para obter mais informações, consulte [EventBridge Eventos da Amazon para o Amazon EBS](ebs-cloud-watch-events.md).
+ `DLM Policy State Change`: um evento do Amazon Data Lifecycle Manager emitido quando uma política de ciclo de vida entra em um estado de erro. O evento contém uma descrição do que causou o erro.
O exemplo a seguir mostra um evento em que as permissões concedidas pela função do IAM não são suficientes.
```
{
"version": "0",
"id": "01234567-0123-0123-0123-0123456789ab",
"detail-type": "DLM Policy State Change",
source": "aws.dlm",
"account": "123456789012",
"time": "2018-05-25T13:12:22Z",
"region": "us-east-1",
"resources": [
"arn:aws:dlm:us-east-1:123456789012:policy/policy-0123456789abcdef"
],
"detail": {
"state": "ERROR",
"cause": "Role provided does not have sufficient permissions",
"policy_id": "arn:aws:dlm:us-east-1:123456789012:policy/policy-0123456789abcdef"
}
}
```
O exemplo a seguir mostra um evento em que um limite é excedido.
```
{
"version": "0",
"id": "01234567-0123-0123-0123-0123456789ab",
"detail-type": "DLM Policy State Change",
"source": "aws.dlm",
"account": "123456789012",
"time": "2018-05-25T13:12:22Z",
"region": "us-east-1",
"resources": [
"arn:aws:dlm:us-east-1:123456789012:policy/policy-0123456789abcdef"
],
"detail":{
"state": "ERROR",
"cause": "Maximum allowed active snapshot limit exceeded",
"policy_id": "arn:aws:dlm:us-east-1:123456789012:policy/policy-0123456789abcdef"
}
}
```
+ `DLM Pre Post Script Notification`: um evento que é emitido quando um prévio ou posterior é iniciado, é bem-sucedido ou falha.
Veja a seguir um exemplo de evento quando um backup do VSS é bem-sucedido.
```
{
"version": "0",
"id": "12345678-1234-1234-1234-123456789012",
"detail-type": "DLM Pre Post Script Notification",
"source": "aws.dlm",
"account": "123456789012",
"time": "2023-10-27T22:04:52Z",
"region": "us-east-1",
"resources": ["arn:aws:dlm:us-east-1:123456789012:policy/policy-01234567890abcdef"],
"detail": {
"script_stage": "",
"result": "success",
"cause": "",
"policy_id": "arn:aws:dlm:us-east-1:123456789012:policy/policy-01234567890abcdef",
"execution_handler": "AWS_VSS_BACKUP",
"source": "arn:aws:ec2:us-east-1:123456789012:instance/i-01234567890abcdef",
"resource_type": "EBS_SNAPSHOT",
"resources": [{
"status": "pending",
"resource_id": "arn:aws:ec2:us-east-1::snapshot/snap-01234567890abcdef",
"source": "arn:aws:ec2:us-east-1:123456789012:volume/vol-01234567890abcdef"
}],
"request_id": "a1b2c3d4-a1b2-a1b2-a1b2-a1b2c3d4e5f6",
"start_time": "2023-10-27T22:03:29.370Z",
"end_time": "2023-10-27T22:04:51.370Z",
"timeout_time": ""
}
}
```
# Monitore as políticas do Data Lifecycle Manager usando CloudWatch
Você pode monitorar suas políticas de ciclo de vida do Amazon Data Lifecycle Manager usando CloudWatch, que coleta dados brutos e os processa em métricas legíveis, quase em tempo real. Você pode usar essas métricas para ver exatamente quantos snapshots e snapshots do Amazon EBS baseados em EBS AMIs são criados, excluídos e copiados por suas políticas ao longo do tempo. Também é possível definir alarmes que observam determinados limites e enviam notificações ou realizam ações quando esses limites são atingidos.
As métricas ficam armazenadas por um período de 15 meses para que você possa acessar informações históricas e obter uma compreensão melhor sobre a performance de suas políticas de ciclo de vida em um período prolongado.
Para obter mais informações sobre a Amazon CloudWatch, consulte o [Guia CloudWatch do usuário da Amazon](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/).
**Topics**
+ [Métricas compatíveis](#metrics)
+ [Visualize CloudWatch métricas para suas políticas](#view-metrics)
+ [Representar métricas em gráficos](#graph-metrics)
+ [Criar um CloudWatch alarme para uma política](#create-alarm)
+ [Exemplo de casos de uso](#use-cases)
+ [Gerenciamento de políticas que relatam ações com falha](#manage)
## Métricas compatíveis
As seguintes métricas do Amazon Data Lifecycle Manager estão incluídas no namespace `AWS/EBS`. As métricas diferem de acordo com o tipo de política.
Todas as métricas podem ser medidas na dimensão do `DLMPolicyId`. As estatísticas mais úteis são `sum` e `average`, e a unidade de medida é `count`.
Escolha uma guia para visualizar as métricas compatíveis com esse tipo de política.
------
#### [ EBS snapshot policies ]
| Métrica | Description |
| --- | --- |
| `ResourcesTargeted` | O número de recursos de destino das tags especificadas em um snapshot ou política de AMI baseada no EBS. |
| `SnapshotsCreateStarted` | O número de ações de criação de snapshots iniciadas por uma política de snapshot. Toda ação é registrada apenas uma vez, mesmo que haja várias tentativas subsequentes. Se uma ação de criação de snapshots falhar, o Amazon Data Lifecycle Manager enviará uma métrica `SnapshotsCreateFailed`. |
| `SnapshotsCreateCompleted` | O número snapshots criados por uma política de snapshot. Inclui novas tentativas bem-sucedidas em até 60 minutos do horário agendado. |
| `SnapshotsCreateFailed` | O número snapshots que uma política de snapshot não conseguiu criar. Inclui novas tentativas malsucedidas em até 60 minutos do horário agendado. |
| `SnapshotsSharedCompleted` | O número de de snapshots compartilhados entre contas por uma política de snapshot. |
| `SnapshotsDeleteCompleted` | O número de snapshots excluídos por um snapshot ou por uma política de AMI baseada no EBS. Essa métrica se aplica apenas aos snapshots criados pela política. Não se aplica a cópias de snapshots entre regiões criadas pela política. Essa métrica inclui instantâneos que são excluídos quando uma política de AMI apoiada pelo EBS é cancelada. AMIs |
| `SnapshotsDeleteFailed` | O número de snapshots que o snapshot ou a política de AMI baseada no EBS não conseguiu excluir. Essa métrica se aplica apenas aos snapshots criados pela política. Não se aplica a cópias de snapshots entre regiões criadas pela política. Essa métrica inclui instantâneos que são excluídos quando uma política de AMI apoiada pelo EBS é cancelada. AMIs |
| `SnapshotsCopiedRegionStarted` | O número de ações de cópia de snapshots entre regiões iniciadas por uma política de snapshot. |
| `SnapshotsCopiedRegionCompleted` | O número de ações de cópias de snapshots entre regiões criadas por uma política de snapshot. Inclui novas tentativas bem-sucedidas em até 24 horas do horário agendado. |
| `SnapshotsCopiedRegionFailed` | O número de cópias de snapshots entre regiões que não foi possível criar por meio de uma política de snapshot. Inclui tentativas malsucedidas num prazo de 24 horas a partir do horário agendado. |
| `SnapshotsCopiedRegionDeleteCompleted` | O número de cópias de snapshots entre regiões excluídas, conforme designado pela regra de retenção, por uma política de snapshot. |
| `SnapshotsCopiedRegionDeleteFailed` | O número de cópias de snapshots entre regiões que não foi possível excluir, conforme designado pela regra de retenção, por meio de uma política de snapshot. |
| `snapshotsArchiveDeletionFailed` | O número de snapshots arquivados que o não puderam ser excluídos do nível de arquivamento por uma política de snapshot. |
| `snapshotsArchiveScheduled` | O número de snapshots que foram programados para serem arquivados por uma política de snapshot. |
| `snapshotsArchiveCompleted` | O número de snapshots que foram arquivados com sucesso por uma política de snapshot. |
| `snapshotsArchiveFailed` | O número snapshots que não puderam ser criados por uma política de snapshot. |
| `snapshotsArchiveDeletionCompleted` | O número de snapshots arquivados que foram excluídos com sucesso do nível de arquivamento por uma política de snapshot. |
| `PreScriptStarted` | O número de instâncias em que um script prévio foi iniciado com sucesso. Se novas tentativas de script estiverem habilitadas, essa métrica poderá ser emitida várias vezes por execução de política. |
| `PreScriptCompleted` | O número de instâncias em que um script prévio foi concluído com sucesso. A métrica é emitida mesmo que o script prévio seja concluído fora do período limite especificado. Se novas tentativas de script estiverem habilitadas, essa métrica poderá ser emitida várias vezes por execução de política. |
| `PreScriptFailed` | O número de instâncias em que um script prévio não foi concluído com sucesso. A métrica é emitida mesmo que o script prévio seja concluído fora do período limite especificado. Se novas tentativas de script estiverem habilitadas, essa métrica poderá ser emitida várias vezes por execução de política. |
| `PostScriptStarted` | O número de instâncias em que um script posterior foi iniciado com sucesso. Se novas tentativas de script estiverem habilitadas, essa métrica poderá ser emitida várias vezes por execução de política. |
| PostScriptCompleted | O número de instâncias em que um script posterior foi concluído com sucesso. A métrica é emitida mesmo que o script posterior seja concluído fora do período limite especificado. Se novas tentativas de script estiverem habilitadas, essa métrica poderá ser emitida várias vezes por execução de política. |
| PostScriptFailed | O número de instâncias em que um script posterior não foi concluído com sucesso. A métrica é emitida mesmo que o script posterior seja concluído fora do período limite especificado. Se novas tentativas de script estiverem habilitadas, essa métrica poderá ser emitida várias vezes por execução de política. |
| `VSSBackupStarted` | O número de instâncias em que um script do VSS foi iniciado com sucesso. Se novas tentativas de script estiverem habilitadas, essa métrica poderá ser emitida várias vezes por execução de política. |
| `VSSBackupCompleted` | O número de instâncias em que um backup do VSS foi concluído com sucesso. A métrica é emitida mesmo que o backup do VSS seja concluído fora do período limite especificado. Se novas tentativas de script estiverem habilitadas, essa métrica poderá ser emitida várias vezes por execução de política. |
| `VSSBackupFailed` | O número de instâncias em que um backup do VSS não foi concluído com sucesso. A métrica é emitida mesmo que o backup do VSS seja concluído fora do período limite especificado. Se novas tentativas de script estiverem habilitadas, essa métrica poderá ser emitida várias vezes por execução de política. |
------
#### [ EBS-backed AMI policies ]
As métricas a seguir podem ser usadas com políticas de AMI baseadas no EBS:
| Métrica | Description |
| --- | --- |
| `ResourcesTargeted` | O número de recursos de destino das tags especificadas em um snapshot ou política de AMI baseada no EBS. |
| `SnapshotsDeleteCompleted` | O número de snapshots excluídos por um snapshot ou por uma política de AMI baseada no EBS. Essa métrica se aplica apenas aos snapshots criados pela política. Não se aplica a cópias de snapshots entre regiões criadas pela política. Essa métrica inclui instantâneos que são excluídos quando uma política de AMI apoiada pelo EBS é cancelada. AMIs |
| `SnapshotsDeleteFailed` | O número de snapshots que o snapshot ou a política de AMI baseada no EBS não conseguiu excluir. Essa métrica se aplica apenas aos snapshots criados pela política. Não se aplica a cópias de snapshots entre regiões criadas pela política. Essa métrica inclui instantâneos que são excluídos quando uma política de AMI apoiada pelo EBS é cancelada. AMIs |
| `SnapshotsCopiedRegionDeleteCompleted` | O número de cópias de snapshots entre regiões excluídas, conforme designado pela regra de retenção, por uma política de snapshot. |
| `SnapshotsCopiedRegionDeleteFailed` | O número de cópias de snapshots entre regiões que não foi possível excluir, conforme designado pela regra de retenção, por meio de uma política de snapshot. |
| `ImagesCreateStarted` | O número de **CreateImage**ações iniciadas por uma política de AMI apoiada pelo EBS. |
| `ImagesCreateCompleted` | O número de AMIs criados por uma política de AMI apoiada pelo EBS. |
| `ImagesCreateFailed` | O número AMIs disso não pôde ser criado por uma política de AMI apoiada pelo EBS. |
| `ImagesDeregisterCompleted` | O número de registros cancelados AMIs por uma política de AMI apoiada pelo EBS. |
| `ImagesDeregisterFailed` | O número AMIs disso não pôde ser cancelado por uma política de AMI apoiada pelo EBS. |
| `ImagesCopiedRegionStarted` | O número de ações de cópia entre regiões iniciadas por uma política de AMI baseada no EBS. |
| `ImagesCopiedRegionCompleted` | O número de cópias de AMIs entre regiões criadas por uma política de AMI baseada no EBS. |
| `ImagesCopiedRegionFailed` | O número de cópias de AMIs entre regiões que não foi possível criar por meio de uma política de AMI baseada no EBS. |
| `ImagesCopiedRegionDeregisterCompleted` | O número de cópias de AMIs entre regiões que tiveram o registro cancelado, conforme designado pela regra de retenção, por meio de uma política de AMI baseada no EBS. |
| `ImagesCopiedRegionDeregisteredFailed` | O número de cópias de AMIs entre regiões cujo registro não foi possível cancelar, conforme designado pela regra de retenção, por meio de uma política de AMI baseada no EBS. |
| `EnableImageDeprecationCompleted` | O número deles AMIs foi marcado para suspensão de uso por uma política de AMI apoiada pelo EBS. |
| `EnableImageDeprecationFailed` | AMIs Esse número não pôde ser marcado para suspensão de uso por uma política de AMI apoiada pelo EBS. |
| `EnableCopiedImageDeprecationCompleted` | O número de cópias AMI entre regiões que foram marcadas para defasagem por meio de uma política de AMI baseada no EBS. |
| `EnableCopiedImageDeprecationFailed` | O número de cópias AMI entre regiões que não puderam ser marcadas para defasagem por meio de uma política de AMI baseada no EBS. |
------
#### [ Cross-account copy event policies ]
As seguintes métricas podem ser usadas com políticas de eventos de cópia entre contas:
| Métrica | Description |
| --- | --- |
| `SnapshotsCopiedAccountStarted` | O número de ações de cópia de snapshots entre contas iniciadas por uma política de eventos de cópia entre contas. |
| `SnapshotsCopiedAccountCompleted` | O número de snapshots copiados de outra conta por uma política de eventos de cópia entre contas. Inclui novas tentativas bem-sucedidas em até 24 horas do horário agendado. |
| `SnapshotsCopiedAccountFailed` | O número de snapshots que não foi possível copiar de outra conta por meio de uma política de eventos de cópia entre contas. Inclui tentativas malsucedidas num prazo de 24 horas do horário agendado. |
| `SnapshotsCopiedAccountDeleteCompleted` | O número de cópias de snapshots entre regiões excluídas, conforme designado pela regra de retenção, por uma política de evento de cópia entre contas. |
| `SnapshotsCopiedAccountDeleteFailed` | O número de cópias de snapshots entre regiões que não foi possível excluir, conforme designado pela regra de retenção, por meio de uma política de evento de cópia entre contas. |
------
## Visualize CloudWatch métricas para suas políticas
Você pode usar as ferramentas Console de gerenciamento da AWS ou a linha de comando para listar as métricas que o Amazon Data Lifecycle Manager envia para a Amazon. CloudWatch
------
#### [ Amazon EC2 console ]
**Para visualizar as métricas usando o console do Amazon EC2**
1. Abra o console do Amazon EC2 em [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. No painel de navegação, escolha **Gerenciador de ciclo de vida**.
1. Selecione uma política na grade e, em seguida, escolha a guia **Monitoramento**.
------
#### [ CloudWatch console ]
**Para visualizar métricas usando o CloudWatch console da Amazon**
1. Abra o CloudWatch console em [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. No painel de navegação, selecione **Métricas**.
1. Selecione o namespace do **EBS** e selecione as métricas do **Data Lifecycle Manager**.
------
#### [ AWS CLI ]
**Para listar todas as métricas disponíveis para o Amazon Data Lifecycle Manager**
Use o comando [list-metrics](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/list-metrics.html).
```
$ C:\> aws cloudwatch list-metrics \
--namespace AWS/EBS
```
**Para listar todas as métricas para uma política específica**
Use o comando [list-metrics](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/list-metrics.html) e especifique a dimensão `DLMPolicyId`.
```
$ C:\> aws cloudwatch list-metrics \
--namespace AWS/EBS \
--dimensions Name=DLMPolicyId,Value=policy-abcdef01234567890
```
**Para listar uma métrica única em todas as políticas**
Use o comando [list-metrics](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/list-metrics.html) e especifique a opção `--metric-name`.
```
$ C:\> aws cloudwatch list-metrics \
--namespace AWS/EBS \
--metric-name SnapshotsCreateCompleted
```
------
## Métricas de gráfico para suas políticas
Depois que criar uma política, é possível abrir o console do Amazon EC2 e ver os gráficos de monitoramento para a instância na guia **Monitoramento**. Cada gráfico se baseia em uma das métricas disponíveis do Amazon EC2.
As métricas de gráficos a seguir estão disponíveis:
+ Recursos direcionados (com base em `ResourcesTargeted`)
+ Criação de snapshots iniciada (com base em `SnapshotsCreateStarted`)
+ Criação de snapshots concluída (com base em `SnapshotsCreateCompleted`)
+ Falha na criação de snapshots (com base em `SnapshotsCreateFailed`)
+ Compartilhamento de snapshots concluído (com base em `SnapshotsSharedCompleted`)
+ Exclusão de snapshot concluída (com base em `SnapshotsDeleteCompleted`)
+ Falha na exclusão de snapshots (com base em `SnapshotsDeleteFailed`)
+ Cópia de snapshots entre regiões iniciada (com base em `SnapshotsCopiedRegionStarted`)
+ Cópia de snapshots entre regiões concluída (com base em `SnapshotsCopiedRegionCompleted`)
+ Falha na cópia de snapshots entre regiões (com base em `SnapshotsCopiedRegionFailed`)
+ Exclusão da cópia de snapshots entre regiões concluída (com base em `SnapshotsCopiedRegionDeleteCompleted`)
+ Falha na exclusão da cópia de snapshots entre regiões (com base em `SnapshotsCopiedRegionDeleteFailed`)
+ Cópia de snapshots entre contas iniciada (com base em `SnapshotsCopiedAccountStarted`)
+ Cópia de snapshots entre contas concluída (com base em `SnapshotsCopiedAccountCompleted`)
+ Falha na cópia de snapshots entre contas (com base em `SnapshotsCopiedAccountFailed`)
+ Exclusão de cópia de snapshots entre contas concluída (com base em `SnapshotsCopiedAccountDeleteCompleted`)
+ Falha na exclusão de cópia de snapshots entre contas (com base em `SnapshotsCopiedAccountDeleteFailed`)
+ Criação de AMI iniciada (com base em `ImagesCreateStarted`)
+ Criação de AMI concluída (com base em `ImagesCreateCompleted`)
+ Falha na criação de AMI (com base em `ImagesCreateFailed`)
+ Cancelamento de registro de AMI concluído (com base em `ImagesDeregisterCompleted`)
+ Falha no cancelamento do registro da AMI (com base em `ImagesDeregisterFailed`)
+ Cópia de AMI entre regiões iniciada (com base em `ImagesCopiedRegionStarted`)
+ Cópia de AMI entre regiões concluída (com base em `ImagesCopiedRegionCompleted`)
+ Falha na cópia de AMI entre regiões (com base em `ImagesCopiedRegionFailed`)
+ Cancelamento de registro de cópia de AMI entre regiões concluída (com base em `ImagesCopiedRegionDeregisterCompleted`)
+ Falha no cancelamento de registro da cópia de AMI entre regiões (com base em `ImagesCopiedRegionDeregisteredFailed`)
+ AMI para habilitar defasagem concluído (com base em `EnableImageDeprecationCompleted`)
+ Falha na AMI para habilitar defasagem (com base em `EnableImageDeprecationFailed`)
+ Cópia da AMI para habilitar defasagem entre regiões concluída (com base em `EnableCopiedImageDeprecationCompleted`)
+ Falha na cópia da AMI para habilitar defasagem entre regiões (com base em `EnableCopiedImageDeprecationFailed`)
## Criar um CloudWatch alarme para uma política
Você pode criar um CloudWatch alarme que monitore CloudWatch as métricas de suas políticas. CloudWatch enviará automaticamente uma notificação quando a métrica atingir um limite especificado por você. Você pode criar um CloudWatch alarme usando o CloudWatch console.
Para obter mais informações sobre a criação de alarmes usando o CloudWatch console, consulte o tópico a seguir no *Guia do CloudWatch usuário da Amazon*.
+ [Crie um CloudWatch alarme com base em um limite estático](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html)
+ [Crie um CloudWatch alarme com base na detecção de anomalias](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Anomaly_Detection_Alarm.html)
## Exemplo de casos de uso
Veja a seguir exemplos de casos de uso:
**Topics**
+ [Exemplo 1: ResourcesTargeted métrica](#case1)
+ [Exemplo 2: SnapshotDeleteFailed métrica](#case2)
+ [Exemplo 3: SnapshotsCopiedRegionFailed métrica](#case3)
### Exemplo 1: ResourcesTargeted métrica
É possível usar a métrica `ResourcesTargeted` para monitorar o número total de recursos de destino de uma política específica toda vez que ela é executada. Isso permite acionar um alarme quando o número de recursos de destino estiver abaixo ou acima do limite esperado.
Por exemplo, se você espera que sua política diária crie backups de não mais do que `50` volumes, é possível criar um alarme que envia uma notificação por e-mail quando a `sum` de `ResourcesTargeted` for maior que `50` pelo período de `1` hora. Dessa forma, é possível garantir que nenhum snapshot tenha sido criado inesperadamente de volumes que foram etiquetados de maneira incorreta.
É possível usar o seguinte comando para criar este alarme:
```
$ C:\> aws cloudwatch put-metric-alarm \
--alarm-name resource-targeted-monitor \
--alarm-description "Alarm when policy targets more than 50 resources" \
--metric-name ResourcesTargeted \
--namespace AWS/EBS \
--statistic Sum \
--period 3600 \
--threshold 50 \
--comparison-operator GreaterThanThreshold \
--dimensions "Name=DLMPolicyId,Value=policy_id" \
--evaluation-periods 1 \
--alarm-actions sns_topic_arn
```
### Exemplo 2: SnapshotDeleteFailed métrica
É possível usar a métrica `SnapshotDeleteFailed` para monitorar falhas na exclusão de snapshots, conforme a regra de retenção de snapshots da política.
Por exemplo, se você tiver criado uma política que deve excluir snapshots automaticamente a cada 12 horas, será possível criar um alarme que notifique sua equipe de engenharia quando a `sum` de `SnapshotDeletionFailed` for maior que `0` pelo período de `1` hora. Isso pode ajudar a averiguar a retenção incorreta de snapshots e a garantir que os custos de armazenamento não aumentem por causa de snapshots desnecessários.
É possível usar o seguinte comando para criar este alarme:
```
$ C:\> aws cloudwatch put-metric-alarm \
--alarm-name snapshot-deletion-failed-monitor \
--alarm-description "Alarm when snapshot deletions fail" \
--metric-name SnapshotsDeleteFailed \
--namespace AWS/EBS \
--statistic Sum \
--period 3600 \
--threshold 0 \
--comparison-operator GreaterThanThreshold \
--dimensions "Name=DLMPolicyId,Value=policy_id" \
--evaluation-periods 1 \
--alarm-actions sns_topic_arn
```
### Exemplo 3: SnapshotsCopiedRegionFailed métrica
Use a métrica `SnapshotsCopiedRegionFailed` para identificar quando suas políticas apresentam falha ao copiar snapshots para outras regiões.
Por exemplo, se sua política copia snapshots entre regiões diariamente, é possível criar um alarme que envia um SMS para sua equipe de engenharia quando a `sum` de `SnapshotCrossRegionCopyFailed` for maior que `0` pelo período de `1` hora. Isso pode ser útil para verificar se a política copiou corretamente os snapshots subsequentes na linhagem.
É possível usar o seguinte comando para criar este alarme:
```
$ C:\> aws cloudwatch put-metric-alarm \
--alarm-name snapshot-copy-region-failed-monitor \
--alarm-description "Alarm when snapshot copy fails" \
--metric-name SnapshotsCopiedRegionFailed \
--namespace AWS/EBS \
--statistic Sum \
--period 3600 \
--threshold 0 \
--comparison-operator GreaterThanThreshold \
--dimensions "Name=DLMPolicyId,Value=policy_id" \
--evaluation-periods 1 \
--alarm-actions sns_topic_arn
```
## Gerenciamento de políticas que relatam ações com falha
Para obter mais informações sobre o que fazer quando uma de suas políticas relata um valor inesperado diferente de zero para uma métrica de ação falhada, consulte o artigo O [que devo fazer se o Amazon Data Lifecycle Manager reportar](https://repost.aws/knowledge-center/cloudwatch-metrics-dlm) ações malsucedidas nas métricas? CloudWatch
# Endpoints de serviço do Amazon Data Lifecycle Manager
Um *endpoint* é uma URL que serve como ponto de entrada para um serviço AWS web. O Amazon Data Lifecycle Manager é compatível com os seguintes tipos de endpoints:
+ IPv4 endpoints
+ Endpoints de pilha dupla que suportam e IPv4 IPv6
+ Endpoints do FIPS
Ao fazer uma solicitação, você pode especificar o endpoint e a região a serem usados. Se você não especificar um endpoint, o IPv4 endpoint será usado por padrão. Para usar outro tipo de endpoint, você deve especificá-lo em sua solicitação. Para obter exemplos de como fazer isso, consulte [Especificar endpoints](#dlm-endpoint-examples).
Para o Amazon Data Lifecycle Manager, consulte [Endpoints do Amazon Data Lifecycle Manager](https://docs.aws.amazon.com/general/latest/gr/dlm.html) no *Referência geral da Amazon Web Services*.
**Topics**
+ [IPv4 endpoints](#dlm-ipv4)
+ [Endpoints de pilha dupla (IPv4 e) IPv6](#dlm-ipv6)
+ [Endpoints do FIPS](#dlm-fips)
+ [Especificar endpoints](#dlm-endpoint-examples)
## IPv4 endpoints
IPv4 os endpoints oferecem suporte somente ao IPv4 tráfego. IPv4 os endpoints estão disponíveis para todas as regiões.
Você deve especificar a região como parte do nome do endpoint. Os nomes de endpoint usam a seguinte convenção de nomenclatura:
+ dlm. *region*.amazonaws.com
Por exemplo, o IPv4 endpoint para a região Leste dos EUA (Norte da Virgínia) é`dlm.us-east-1.amazonaws.com`.
## Endpoints de pilha dupla (IPv4 e) IPv6
Os endpoints de pilha dupla oferecem suporte tanto ao tráfego quanto ao tráfego. IPv4 IPv6 Os endpoints de pilha dupla estão disponíveis em todas as regiões.
Para usar IPv6, você deve usar um endpoint de pilha dupla. Quando você faz uma solicitação para um endpoint de pilha dupla, o URL do endpoint é resolvido para um IPv4 endereço IPv6 ou, dependendo do protocolo usado pela rede e pelo cliente.
Você deve especificar a região como parte do nome do endpoint. Os nomes de endpoints de pilha dupla usam a seguinte convenção de nomenclatura:
+ `dlm.region.api.aws`
Por exemplo, o endpoint de pilha dupla da região Leste dos EUA (Norte da Virgínia) é `dlm.us-east-1.api.aws`.
## Endpoints do FIPS
O Amazon Data Lifecycle Manager fornece endpoints de pilha dupla (e) validados pelo FIPS para as seguintes regiões: IPv4 IPv6
+ `us-east-1` - Leste dos EUA (Norte da Virgínia):
+ `us-east-2` - Leste dos EUA (Ohio)
+ `us-west-1` - Oeste dos EUA (N. da Califórnia)
+ `us-west-2` - Oeste dos EUA (Oregon):
+ `ca-central-1` - Canadá (Central)
+ `ca-west-1` - Oeste do Canadá (Calgary)
Os endpoints FIPS de pilha dupla usam a seguinte convenção de nomenclatura:. `dlm-fips.region.api.aws` Por exemplo, o endpoint de pilha dupla FIPS na região Leste dos EUA (Norte da Virgínia) é `dlm-fips.us-east-1.api.aws`.
## Especificar endpoints
Os exemplos a seguir mostram como especificar um endpoint para a região de`US East (N. Virginia)` usando o AWS CLI.
+ **Pilha dupla**
```
aws dlm create-default-role \
--resource-type snapshot \
--endpoint-url https://dlm.us-east-2.api.aws
```
+ **IPv4**
```
aws dlm create-default-role \
--resource-type snapshot \
--endpoint-url https://dlm.us-east-2.amazonaws.com
```
# Criar uma conexão privada entre uma VPC e o Amazon EBS
É possível estabelecer uma conexão privada entre a VPC e o Amazon EBS criando um *endpoint da VPC de interface*, com tecnologia [AWS PrivateLink](https://aws.amazon.com/privatelink/). É possível acessar o Amazon EBS como se estivesse em sua VPC, sem usar um gateway da Internet, um dispositivo NAT, uma conexão VPN ou uma conexão AWS Direct Connect . As instâncias na sua VPC não precisam de endereços IP públicos para se comunicar com o Amazon EBS.
Criaremos um endpoint de interface de rede em cada sub-rede que você habilitar para o endpoint de interface.
Para obter mais informações, consulte [Acesso Serviços da AWS por meio AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/privatelink-access-aws-services.html) do *AWS PrivateLink Guia*.
**nota**
O Amazon Data Lifecycle Manager oferece suporte a endpoints IPv4 VPC de interface para todas as regiões e comerciais AWS GovCloud (US) , e a interface de IPv6 VPC endpoints somente para regiões comerciais.
## Considerações sobre endpoints da VPC do Amazon EBS
Antes de configurar um endpoint da VPC de interface para o Amazon EBS, analise as [Considerações](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#considerations-interface-endpoints) no *Guia do AWS PrivateLink *.
Por padrão, o acesso total ao Amazon EBS é permitido pelo endpoint. Você pode controlar o acesso ao endpoint de interface usando as políticas de endpoint da VPC. É possível anexar uma política de endpoint ao endpoint da VPC que controla o acesso ao Amazon EBS. Essa política especifica as seguintes informações:
+ A **entidade principal** que pode realizar ações.
+ As **ações** que podem ser realizadas.
+ Os **recursos** aos quais as ações podem ser aplicadas.
Para obter mais informações, consulte [Controlar o acesso a serviços com VPC endpoints](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html) no *Guia do usuário da Amazon VPC*.
Veja a seguir um exemplo de política de endpoint para o Amazon EBS. Quando anexada a um endpoint, essa política concede a todos os usuários permissão para obter informações resumidas sobre as políticas do Amazon Data Lifecycle Manager.
```
{
"Statement": [{
"Action": "dlm:GetLifecyclePolicies",
"Effect": "Allow",
"Principal": "*",
"Resource": "*"
}]
}
```
## Crie um endpoint da VPC de interface para o Amazon EBS
É possível criar um endpoint da VPC para o Amazon EBS usando o console da Amazon VPC ou a AWS Command Line Interface (AWS CLI). Para obter mais informações, consulte [Create a VPC endpoint](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#create-interface-endpoint-aws) (Criar um endpoint da VPC) no *Guia do AWS PrivateLink *.
Crie um endpoint da VPC para o Amazon EBS usando o seguinte nome de serviço:
+ `com.amazonaws.region.dlm`
Se você habilitar o DNS privado para o endpoint, poderá fazer solicitações de API para o Amazon EBS usando seu nome DNS padrão para a região, por exemplo, `dlm.us-east-1.amazonaws.com`.
# Solucionar problemas do Amazon Data Lifecycle Manager
A documentação a seguir pode ajudar a solucionar os problemas que você venha a encontrar.
**Topics**
+ [Erro: `Role with name already exists`](#dlm-role-arn-issue)
## Erro: `Role with name already exists`
**Description**
Você recebe o erro `Role with name AWSDataLifecycleManagerDefaultRole already exists` ou `Role with name AWSDataLifecycleManagerDefaultRoleForAMIManagement already exists` ao tentar criar uma política usando o console.
**Causa**
O formato do ARN do perfil padrão é diferente dependendo de ele ter sido criado usando o console ou a AWS CLI. Embora ARNs sejam diferentes, as funções usam o mesmo nome de função, o que resulta em um conflito de nomenclatura de função entre o console e o. AWS CLI
**Solução**
Para resolver esse problema, faça o seguinte:
1. (*Para políticas de snapshot habilitadas somente para scripts anteriores e posteriores*) Anexe manualmente a política AWS gerenciada do **AWSDataLifecycleManagerSSMFullAccess** à função do **AWSDataLifecycleManagerDefaultRole**IAM. Para obter mais informações, consulte [Adicionar permissões de identidade do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html#add-policies-console).
1. Ao criar sua política do Amazon Data Lifecycle Manager, para a **função do IAM, selecione **Escolher outra função**** e, em seguida, selecione **AWSDataLifecycleManagerDefaultRole**(para uma política de snapshot) ou (para uma política de **AWSDataLifecycleManagerDefaultRoleForAMIManagement**AMI).
1. Continue criando a política normalmente.