# Gerenciamento de falhas
**Topics**
+ [REL 9. Como você faz backup dos dados?](rel-09.md)
+ [REL 10. Como você usa o isolamento de falhas para proteger a workload?](rel-10.md)
+ [REL 11. Como projetar a workload para resistir a falhas de componentes?](rel-11.md)
+ [REL 12. Como testar a confiabilidade?](rel-12.md)
+ [REL 13. Como planejar para a recuperação de desastres (DR)?](rel-13.md)
# REL 9. Como você faz backup dos dados?
Faça backup de dados, aplicações e configurações para atender às suas necessidades de objetivos de tempo de recuperação (RTO) e objetivos de ponto de recuperação (RPO).
**Topics**
+ [REL09-BP01 Identificar e fazer backup de todos os dados que precisam de backup ou reproduzir os dados das fontes](rel_backing_up_data_identified_backups_data.md)
+ [REL09-BP02 Proteger e criptografar backups](rel_backing_up_data_secured_backups_data.md)
+ [REL09-BP03 Realizar backups de dados automaticamente](rel_backing_up_data_automated_backups_data.md)
+ [REL09-BP04 Realizar a recuperação periódica dos dados para verificar a integridade e os processos de backup](rel_backing_up_data_periodic_recovery_testing_data.md)
# REL09-BP01 Identificar e fazer backup de todos os dados que precisam de backup ou reproduzir os dados das fontes
Compreenda e use os recursos de backup dos serviços e recursos de dados usados pela workload. A maioria dos serviços oferece recursos para fazer backup dos dados da workload.
**Resultado desejado:** as fontes de dados foram identificadas e classificadas com base na criticidade. Depois, estabeleça uma estratégia de recuperação de dados com base no RPO. A estratégia envolve fazer backup dessas fontes de dados ou poder reproduzir dados de outras fontes. Em caso de perda de dados, a estratégia implementada permite a recuperação ou reprodução de dados dentro do RPO e RTO definidos.
**Fase de maturidade da nuvem:** fundamental
**Práticas comuns que devem ser evitadas:**
+ Não estar ciente de todas as fontes de dados para a workload e sua criticidade.
+ Não fazer backups de fontes de dados essenciais.
+ Fazer backups apenas de algumas fontes de dados sem usar a criticidade como critério.
+ Não ter um RPO definido ou a frequência de backup não atender ao RPO.
+ Não avaliar a necessidade de um backup ou se os dados podem ser reproduzidos de outras fontes.
**Benefícios de implementar esta prática recomendada:** identificar os locais onde os backups são necessários e implementar um mecanismo para criar backups, ou ser capaz de reproduzir os dados de uma fonte externa, melhora a capacidade de restaurar e recuperar dados durante uma interrupção.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** Alto
## Orientação para implementação
Todos os datastores da AWS oferecem recursos de backup. Serviços como o Amazon RDS e o Amazon DynamoDB oferecem suporte adicional ao backup automatizado que possibilita a recuperação para um ponto no tempo (PITR), permitindo restaurar um backup a qualquer momento até cinco minutos ou menos antes da hora atual. Muitos serviços da AWS oferecem a capacidade de copiar backups para outra Região da AWS. O AWS Backup é uma ferramenta que permite centralizar e automatizar a proteção de dados em todos os serviços da AWS. O [AWS Elastic Disaster Recovery](https://aws.amazon.com/disaster-recovery/) permite copiar workloads completas do servidor e manter a proteção contínua dos dados no local, entre AZ ou entre regiões, com um objetivo de ponto de recuperação (RPO) medido em segundos.
O Amazon S3 pode ser usado como um destino de backup para fontes de dados autogerenciadas e gerenciadas pela AWS. Serviços da AWS, como o Amazon EBS, o Amazon RDS e o Amazon DynamoDB, oferecem recursos integrados de criação de backups. É possível também usar um software de backup de terceiros.
Os dados on-premises podem ser copiados para a Nuvem AWS via [AWS Storage Gateway](https://docs.aws.amazon.com/storagegateway/latest/vgw/WhatIsStorageGateway.html) ou [AWS DataSync](https://docs.aws.amazon.com/datasync/latest/userguide/what-is-datasync.html). Os buckets do Amazon S3 podem ser usados para armazenar esses dados na AWS. O Amazon S3 oferece vários níveis de armazenamento, como [Amazon Glacier ou Amazon Glacier Deep Archive](https://docs.aws.amazon.com/prescriptive-guidance/latest/backup-recovery/amazon-s3-glacier.html), para reduzir o custo do armazenamento de dados.
É possível atender às necessidades de recuperação de dados reproduzindo os dados de outras fontes. Por exemplo, os [nós de réplica do Amazon ElastiCache](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Replication.Redis.Groups.html) ou as [réplicas de leitura do Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html) poderão ser usados para reproduzir dados se os dados primários forem perdidos. Nos casos em que fontes como essa podem ser usadas para atender ao [objetivo de ponto de recuperação (RPO) e ao objetivo de tempo de recuperação (RTO)](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/disaster-recovery-dr-objectives.html), talvez um backup não seja necessário. Outro exemplo, se estiver trabalhando com o Amazon EMR, é que talvez não seja necessário fazer backup do seu datastore HDFS, desde que você consiga [reproduzir os dados no Amazon EMR a partir do Amazon S3](https://aws.amazon.com/premiumsupport/knowledge-center/copy-s3-hdfs-emr/).
Ao selecionar uma estratégia de backup, considere o tempo necessário para recuperar os dados. Ele depende do tipo de backup (no caso de uma estratégia de backup) ou da complexidade do mecanismo de reprodução de dados. O tempo deve respeitar o RTO para a workload.
**Etapas de implementação**
1. **Identifique todas as fontes de dados para a workload**. Os dados podem ser armazenados em vários recursos, como [bancos de dados](https://aws.amazon.com/products/databases/), [volumes](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html), [sistemas de arquivos](https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html), [sistemas de registro em log](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) e [armazenamento de objetos](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html). Consulte a seção **Recursos** para encontrar **Documentos relacionados** sobre os diferentes serviços da AWS em que os dados são armazenados e sobre a capacidade de backup oferecida por esses serviços.
1. **Classifique as fontes de dados com base na criticidade**. Diferentes conjuntos de dados terão diferentes níveis de criticidade para uma workload e, portanto, diferentes requisitos de resiliência. Por exemplo, alguns dados podem ser críticos e exigir um RPO próximo de zero, enquanto outros dados podem ser menos críticos e tolerar um RPO mais alto e a perda de alguns dados. Da mesma forma, diferentes conjuntos de dados também podem ter diferentes requisitos de RTO.
1. **Use serviços da AWS serviços ou de terceiros para criar backups dos dados**. O [AWS Backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html) é um serviço gerenciado que permite criar backups de várias fontes de dados na AWS. O [AWS Elastic Disaster Recovery](https://aws.amazon.com/disaster-recovery/) cuida da replicação automatizada de dados em menos de um segundo para uma Região da AWS. A maioria dos serviços da AWS também possui recursos nativos para criar backups. O AWS Marketplace tem muitas soluções que também fornecem esses recursos. Consulte os **Recursos** listados abaixo para obter informações sobre como criar backups de dados de vários serviços da AWS.
1. **Para dados sem backup, estabeleça um mecanismo de reprodução de dados**. Você pode optar por não fazer backup dos dados que podem ser reproduzidos de outras fontes por vários motivos. Às vezes, pode ser mais barato reproduzir dados de fontes se necessário, em vez de criar um backup, pois pode haver um custo associado ao armazenamento de backups. Outro exemplo é quando a restauração de um backup demora mais do que a reprodução dos dados das fontes, resultando em uma violação no RTO. Nestas situações, considere concessões e estabeleça um processo bem definido de como os dados podem ser reproduzidos dessas fontes quando a recuperação de dados for necessária. Se você tiver carregado dados do Amazon S3 para um data warehouse (como o Amazon Redshift) ou cluster MapReduce (como o Amazon EMR) para fazer análises nesses dados, isso pode ser um exemplo de dados que podem ser reproduzidos de outras fontes. Desde que os resultados dessas análises sejam armazenados em algum lugar ou reproduzíveis, você não sofreria uma perda de dados devido a uma falha no data warehouse ou no cluster do MapReduce. Outros exemplos que podem ser reproduzidos de origens incluem caches (como o Amazon ElastiCache) ou réplicas de leitura do RDS.
1. **Estabeleça uma cadência para fazer backup dos dados.** A criação de backups de fontes de dados é um processo periódico, e a frequência deve depender do RPO.
**Nível de esforço do plano de implementação:** Moderado
## Recursos
**Práticas recomendadas relacionadas:**
[REL13-BP01 Definir os objetivos de recuperação para tempo de inatividade e perda de dados](rel_planning_for_recovery_objective_defined_recovery.md)
[REL13-BP02 Usar estratégias de recuperação definidas para cumprir os objetivos de recuperação](rel_planning_for_recovery_disaster_recovery.md)
**Documentos relacionados:**
+ [O que é o AWS Backup?](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html)
+ [O que é o AWS DataSync?](https://docs.aws.amazon.com/datasync/latest/userguide/what-is-datasync.html)
+ [O que é Gateway de Volumes?](https://docs.aws.amazon.com/storagegateway/latest/vgw/WhatIsStorageGateway.html)
+ [Parceiro da APN: parceiros que podem ajudar com o backup](https://aws.amazon.com/partners/find/results/?keyword=Backup)
+ [AWS Marketplace: produtos que podem ser usados para backup](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup)
+ [Snapshots do Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSSnapshots.html)
+ [Fazer backup do Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/efs-backup-solutions.html)
+ [Fazer backup do Amazon FSx para Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/using-backups.html)
+ [Backup e restauração do ElastiCache para Redis](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/backups.html)
+ [Criar um snapshot de cluster de banco de dados no Neptune](https://docs.aws.amazon.com/neptune/latest/userguide/backup-restore-create-snapshot.html)
+ [Criar um snapshot de banco de dados](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CreateSnapshot.html)
+ [Criar uma regra do EventBridge que é acionada de acordo com uma programação](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-scheduled-rule.html)
+ [Replicação entre regiões](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr.html) com o Amazon S3
+ [EFS para AWS Backup de EFS](https://aws.amazon.com/solutions/efs-to-efs-backup-solution/)
+ [Exportar dados de log para o Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/S3Export.html)
+ [Gerenciamento do ciclo de vida de objetos](https://docs.aws.amazon.com/AmazonS3/latest/dev/object-lifecycle-mgmt.html)
+ [Backup e restauração sob demanda para o DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/backuprestore_HowItWorks.html)
+ [Recuperação para um ponto no tempo para o DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/PointInTimeRecovery.html)
+ [Como trabalhar com snapshots de índices no Amazon OpenSearch Service](https://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/es-managedomains-snapshots.html)
+ [O que é o AWS Elastic Disaster Recovery?](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)
**Vídeos relacionados:**
+ [AWS re:Invent 2021: Backup, recuperação de desastres e proteção contra ransomware com a AWS](https://www.youtube.com/watch?v=Ru4jxh9qazc)
+ [Demonstração do AWS Backup: backup entre contas e regiões](https://www.youtube.com/watch?v=dCy7ixko3tE)
+ [AWS re:Invent 2019: Mergulho profundo no AWS Backup com destaque para o Rackspace (STG341)](https://youtu.be/av8DpL0uFjc)
# REL09-BP02 Proteger e criptografar backups
Controle e detecte o acesso a backups usando autenticação e autorização. Use a criptografia para prevenir e detectar se a integridade dos dados de backups está comprometida.
Implemente controles de segurança para evitar o acesso não autorizado aos dados de backup. Criptografe os backups para proteger a confidencialidade e a integridade dos dados.
**Práticas comuns que devem ser evitadas:**
+ Ter o mesmo acesso à automação de backups e restauração que tem aos dados.
+ Não criptografar seus backups.
+ Não implementar a imutabilidade para proteção contra exclusão ou adulteração.
+ Usar o mesmo domínio de segurança para sistemas de produção e backup.
+ Não validar a integridade do backup por meio de testes regulares.
**Benefícios de implementar esta prática recomendada:**
+ A proteção de backups impede a violação dos dados, ao passo que a criptografia de dados impede o acesso a eles caso sejam expostos por engano.
+ Proteção aprimorada contra ransomware e outras ameaças cibernéticas que visam à infraestrutura de backup.
+ Tempo de recuperação reduzido após incidentes cibernéticos por meio de processos de recuperação validados.
+ Recursos aprimorados de continuidade dos negócios durante incidentes de segurança.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** Alto
## Orientação para implementação
Controle e detecte o acesso a backups usando autenticação e autorização, como o AWS Identity and Access Management (IAM). Use a criptografia para prevenir e detectar se a integridade dos dados de backups está comprometida.
O Amazon S3 oferece suporte a vários métodos de criptografia de dados em repouso. Ao usar a criptografia do lado do servidor, o Amazon S3 aceita os objetos como dados não criptografados e, depois, criptografa-os à medida que são armazenados. Ao usar a criptografia do lado do cliente, a aplicação da workload é responsável por criptografar os dados antes de serem enviados ao Amazon S3. Ambos os métodos permitem que você use o AWS Key Management Service (AWS KMS) para criar e armazenar a chave de dados, ou você pode fornecer sua própria chave, pela qual você é responsável. Usando o AWS KMS, você pode definir políticas usando o IAM sobre quem pode e não pode acessar suas chaves de dados e dados descriptografados.
Para o Amazon RDS, se você tiver optado por criptografar seus bancos de dados, seus backups também serão criptografados. Os backups do DynamoDB sempre são criptografados. Quando o AWS Elastic Disaster Recovery é usado, todos os dados em trânsito e em repouso são criptografados. Com o Elastic Disaster Recovery, os dados em repouso podem ser criptografados usando a chave de criptografia de volume padrão do Amazon EBS ou uma chave personalizada gerenciada pelo cliente.
**Considerações sobre resiliência cibernética**
Para aprimorar a segurança do backup contra ameaças cibernéticas, considere a possibilidade de implementar estes controles adicionais além da criptografia:
+ Implemente a imutabilidade usando a Trava de Segurança do AWS Backup ou o Bloqueio de Objetos do Amazon S3 para evitar que os dados de backup sejam alterados ou excluídos durante o período de retenção e oferecer proteção contra ransomware e exclusão mal-intencionada.
+ Estabeleça um isolamento lógico entre os ambientes de produção e backup com um cofre logicamente isolado do AWS Backup para sistemas essenciais a fim de criar uma separação que ajude a evitar o comprometimento dos dois ambientes simultaneamente.
+ Valide a integridade do backup regularmente usando testes de restauração do AWS Backup para verificar se os backups não estão corrompidos e podem ser restaurados com êxito após incidentes cibernéticos.
+ Implemente a aprovação multilateral de operações essenciais de recuperação usando a aprovação multilateral do AWS Backup para evitar tentativas de recuperação não autorizadas ou mal-intencionadas ao exigir a autorização de vários aprovadores designados.
### Etapas de implementação
1. Use criptografia em cada um dos seus datastores. Se os dados de origem forem criptografados, o backup também será.
+ [Use criptografia no Amazon RDS.](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html) Você pode configurar a criptografia em repouso usando o AWS Key Management Service ao criar uma instância do RDS.
+ [Use criptografia nos volumes do Amazon EBS.](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html) Você pode configurar a criptografia padrão ou especificar uma chave exclusiva após a criação do volume.
+ Use a [criptografia do Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/EncryptionAtRest.html) necessária. O DynamoDB criptografa todos os dados em repouso. Você pode usar uma chave do AWS KMS pertencente à AWS ou uma chave do KMS gerenciada pela AWS, especificando uma chave armazenada na sua conta.
+ [Criptografe seus dados armazenados no Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/encryption.html). Configure a criptografia ao criar seu sistema de arquivos.
+ Configure a criptografia nas regiões de origem e de destino. Você pode configurar a criptografia em repouso no Amazon S3 usando as chaves armazenadas no KMS, mas as chaves são específicas da região. É possível especificar as chaves de destino ao configurar a replicação.
+ Escolha se deseja usar a criptografia padrão ou usar a [criptografia do Amazon EBS para Elastic Disaster Recovery](https://docs.aws.amazon.com/drs/latest/userguide/volumes-drs.html#ebs-encryption). Essa opção criptografa os dados em repouso replicados nos discos da sub-rede da área de preparação e os discos replicados.
1. Implemente permissões de privilégio mínimo para acessar seus backups. Siga as práticas recomendadas para limitar o acesso aos backups, aos snapshots e às réplicas de acordo com as [práticas recomendadas de segurança](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html).
1. Configure a imutabilidade para backups essenciais. Para dados essenciais, implemente a Trava de Segurança do AWS Backup ou o Bloqueio de Objetos do S3 para evitar exclusão ou alteração durante o período de retenção especificado. Para ver detalhes sobre a implementação, consulte [AWS Backup Vault Lock](https://docs.aws.amazon.com/aws-backup/latest/devguide/vault-lock.html).
1. Crie uma separação lógica para ambientes de backup. Implemente um cofre logicamente isolado do AWS Backup para sistemas essenciais que exigem proteção aprimorada contra ameaças cibernéticas. Para obter orientações sobre implementação, consulte [Building cyber resiliency with AWS Backup logically air-gapped vault](https://aws.amazon.com/blogs/storage/building-cyber-resiliency-with-aws-backup-logically-air-gapped-vault/).
1. Implemente processos de validação de backup. Configure testes de restauração do AWS Backup para verificar regularmente se os backups não estão corrompidos e podem ser restaurados com êxito após incidentes cibernéticos. Para ter mais informações, consulte [Validate recovery readiness with AWS Backup restore testing](https://aws.amazon.com/blogs/storage/validate-recovery-readiness-with-aws-backup-restore-testing/).
1. Configure a aprovação multilateral de operações de recuperação confidenciais. Para sistemas essenciais, implemente a aprovação multilateral do AWS Backup a fim de exigir a autorização de vários aprovadores designados para que a recuperação possa prosseguir. Para ver detalhes sobre a implementação, consulte [Improve recovery resilience with AWS Backup support for Multi-party approval](https://aws.amazon.com/blogs/storage/improve-recovery-resilience-with-aws-backup-support-for-multi-party-approval/).
## Recursos
**Documentos relacionados:**
+ [AWS Marketplace: produtos que podem ser usados para backup](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup)
+ [Criptografia do Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html)
+ [Amazon S3: proteger dados usando criptografia](https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingEncryption.html)
+ [Configuração adicional de CRR: replicar objetos criados com a criptografia do lado do servidor (SSE) usando as chaves de criptografia armazenadas no AWS KMS](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr-replication-config-for-kms-objects.html)
+ [Criptografia do DynamoDB em repouso](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/EncryptionAtRest.html)
+ [Como criptografar recursos do Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html)
+ [Criptografar dados e metadados no Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/encryption.html)
+ [Criptografia para backups no AWS](https://docs.aws.amazon.com/aws-backup/latest/devguide/encryption.html)
+ [Como gerenciar tabelas criptografadas](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/encryption.tutorial.html)
+ [Pilar Segurança: AWS Well-Architected Framework](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html)
+ [ O que é o AWS Elastic Disaster Recovery? ](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)
+ [FSISEC11: How are you protecting against ransomware?](https://docs.aws.amazon.com/wellarchitected/latest/financial-services-industry-lens/fsisec11.html)
+ [ Ransomware Risk Management on AWS Using the NIST Cyber Security Framework ](https://docs.aws.amazon.com/whitepapers/latest/ransomware-risk-management-on-aws-using-nist-csf/welcome.html)
+ [Building cyber resiliency with AWS Backup logically air-gapped vault](https://aws.amazon.com/blogs/storage/building-cyber-resiliency-with-aws-backup-logically-air-gapped-vault/)
+ [Validate recovery readiness with AWS Backup restore testing](https://aws.amazon.com/blogs/storage/validate-recovery-readiness-with-aws-backup-restore-testing/)
+ [Improve recovery resilience with AWS Backup support for Multi-party approval](https://aws.amazon.com/blogs/storage/improve-recovery-resilience-with-aws-backup-support-for-multi-party-approval/)
**Exemplos relacionados:**
+ [ Implementing Bi-Directional Cross-Region Replication (CRR) for Amazon Simple Storage Service (Amazon S3) ](https://wellarchitectedlabs.com/reliability/200_labs/200_bidirectional_replication_for_s3/)
# REL09-BP03 Realizar backups de dados automaticamente
Configure os backups para serem feitos automaticamente com base em uma programação periódica informada pelo objetivo de ponto de recuperação (RPO) ou de acordo com alterações no conjunto de dados. É necessário fazer frequentemente o backup automático de conjuntos de dados críticos com requisitos de baixa perda de dados, enquanto o backup de dados menos críticos, em que alguma perda é aceitável, pode ser feito com menos frequência.
**Resultado desejado:** um processo automatizado que cria backups das fontes de dados em uma cadência estabelecida.
**Práticas comuns que devem ser evitadas:**
+ Fazer backups manualmente.
+ Usar recursos que têm o recurso de backup, mas não incluir o backup em sua automação.
**Benefícios de implementar esta prática recomendada:** automatizar os backups verifica se eles são feitos regularmente com base no seu RPO e alerta você caso não sejam feitos.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio
## Orientação para implementação
O AWS Backup pode ser usado para criar backups de dados automatizados de várias fontes de dados da AWS. É possível fazer backup de instâncias do Amazon RDS quase continuamente a cada cinco minutos, e objetos do Amazon S3 podem ser feitos backup quase continuamente a cada quinze minutos, proporcionando recuperação para um ponto no tempo (PITR) dentro do histórico de backup. Para outras fontes de dados da AWS, como volumes do Amazon EBS, tabelas do Amazon DynamoDB ou sistemas de arquivos do Amazon FSx, o AWS Backup pode executar backup automatizado de hora em hora. Esses serviços também oferecem recursos de backup nativos. os serviços da AWS que oferecem backup automatizado com recuperação para um ponto no tempo incluem [Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/PointInTimeRecovery_Howitworks.html), [Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PIT.html) e [Amazon Keyspaces (para Apache Cassandra)](https://docs.aws.amazon.com/keyspaces/latest/devguide/PointInTimeRecovery.html): esses podem ser restaurados em um momento específico no histórico de backup. A maioria dos outros serviços de armazenamento de dados da AWS permite programar backups periódicos, até de hora em hora.
O Amazon RDS e o Amazon DynamoDB oferecem backup contínuo com recuperação para um ponto no tempo. O versionamento do Amazon S3, uma vez habilitado, é automático. O [Amazon Data Lifecycle Manager](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/snapshot-lifecycle.html) pode ser usado para automatizar a criação, a retenção e a exclusão de AMIs compatíveis com o EBS. Ele também pode automatizar a criação, a cópia, a suspensão e o cancelamento do registro de imagens de máquina da Amazon (AMIs) com base no Amazon EBS e seus snapshots subjacentes do Amazon EBS.
O AWS Elastic Disaster Recovery fornece replicação contínua no nível de bloco do ambiente de origem (on-premises ou a AWS) para a região de recuperação de destino. Os snapshots do Amazon EBS de um ponto anterior no tempo são criados automaticamente e gerenciados pelo serviço.
Para obter uma visão centralizada da automação e do histórico de backups, o AWS Backup oferece uma solução de backup totalmente gerenciada e baseada em políticas. Ele centraliza e automatiza o backup de dados em vários serviços da AWS, na nuvem e on-premises, usando o AWS Storage Gateway.
Além do controle de versões, o Amazon S3 oferece replicação. Todo o bucket do S3 pode ser replicado automaticamente para outro bucket na mesma Região da AWS ou em uma região diferente.
**Etapas de implementação**
1. **Identifique as fontes de dados** que estão sendo copiadas para backup manualmente no momento. Para obter mais detalhes, consulte [REL09-BP01 Identificar e fazer backup de todos os dados que precisam de backup ou reproduzir os dados das fontes](rel_backing_up_data_identified_backups_data.md).
1. **Determine o RPO** para a workload. Para obter mais detalhes, consulte [REL13-BP01 Definir os objetivos de recuperação para tempo de inatividade e perda de dados](rel_planning_for_recovery_objective_defined_recovery.md).
1. **Use uma solução automatizada ou um serviço de backup gerenciado**. O AWS Backup é um serviço totalmente gerenciado que ajuda você a [centralizar e automatizar a proteção de dados nos serviços da AWS, na nuvem e on-premises](https://docs.aws.amazon.com/aws-backup/latest/devguide/creating-a-backup.html#creating-automatic-backups). Usando planos de backup no AWS Backup, crie regras que definem os recursos para backup e a frequência com que esses backups devem ser criados. A frequência deve ser informada pelo RPO estabelecido na Etapa 2. Para obter orientação prática sobre como criar backups automatizados usando o AWS Backup, consulte [Testar o backup e a restauração de dados](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/). A maioria dos serviços da AWS que armazenam dados oferecem recursos de backup nativos. Por exemplo, o RDS pode ser utilizado para fazer backups automatizados com recuperação para um ponto no tempo (PITR).
1. **Para fontes de dados sem suporte** de uma solução de backup automatizada ou serviço gerenciado, como fontes de dados on-premises ou filas de mensagens, considere usar uma solução terceirizada confiável para criar backups automatizados. Como alternativa, você pode criar automação para fazer isso usando a AWS CLI ou os SDKs. É possível usar o AWS Lambda Functions ou o AWS Step Functions para definir a lógica envolvida na criação de um backup de dados e usar o Amazon EventBridge para executá-la em uma frequência baseada no RPO.
**Nível de esforço do plano de implementação:** Baixo.
## Recursos
**Documentos relacionados:**
+ [Parceiro da APN: parceiros que podem ajudar com o backup](https://aws.amazon.com/partners/find/results/?keyword=Backup)
+ [AWS Marketplace: produtos que podem ser usados para backup](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup)
+ [Criar uma regra do EventBridge que é acionada de acordo com uma programação](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-scheduled-rule.html)
+ [O que é o AWS Backup?](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html)
+ [O que é o AWS Step Functions?](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)
+ [O que é o AWS Elastic Disaster Recovery?](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)
**Vídeos relacionados:**
+ [AWS re:Invent 2019: Mergulho profundo no AWS Backup com destaque para o Rackspace (STG341)](https://youtu.be/av8DpL0uFjc)
# REL09-BP04 Realizar a recuperação periódica dos dados para verificar a integridade e os processos de backup
Execute um teste de recuperação para confirmar se a implementação do processo de backup atende aos seus objetivos de tempo de recuperação (RTO) e de ponto de recuperação (RPO).
**Resultado desejado:** os dados dos backups são recuperados periodicamente usando mecanismos bem definidos para verificar se a recuperação é possível dentro do objetivo de tempo de recuperação (RTO) estabelecido para a workload. Verifique se a restauração de um backup resulta em um recurso contendo os dados originais sem que estejam corrompidos ou inacessíveis e que a perda de dados esteja dentro do objetivo de ponto de recuperação (RPO).
**Práticas comuns que devem ser evitadas:**
+ Restaurar um backup, mas não consultar ou recuperar os dados para garantir que a restauração é utilizável.
+ Presumir a existência de um backup.
+ Presumir que o backup de um sistema esteja totalmente operacional e que os dados possam ser recuperados.
+ Presumir que o tempo para recuperar ou restaurar dados de um backup esteja dentro do RTO para a workload.
+ Presumir que os dados contidos no backup estejam dentro do RPO para a workload
+ Restaurar ad hoc, sem usar um runbook ou não seguir um procedimento automatizado estabelecido.
**Benefícios de estabelecer essa prática recomendada:** testar a recuperação dos backups verifica se os dados podem ser restaurados quando necessário, sem a preocupação de que os dados possam estar ausentes ou corrompidos, que a restauração e a recuperação sejam possíveis dentro do RTO da workload e que qualquer perda de dados esteja dentro do RPO da workload.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio
## Orientação para implementação
Testar o recurso de backup e restauração aumenta a confiança na capacidade de realizar essas ações durante uma interrupção. Restaure periodicamente os backups em um novo local e execute testes para verificar a integridade dos dados. Alguns testes comuns que devem ser realizados são verificar se todos os dados estão disponíveis, se eles não estão corrompidos e se eles estão acessíveis, bem como garantir que toda a perda de dados se enquadre no RPO da workload. Eles também podem ajudar a verificar se os mecanismos de recuperação são rápidos o suficiente para acomodar o RTO da workload.
Ao usar a AWS, você pode criar um ambiente de teste e restaurar os backups para avaliar os recursos de RTO e RPO e executar testes de conteúdo e integridade dos dados.
Além disso, o Amazon RDS e o Amazon DynamoDB permitem a recuperação para um ponto no tempo (PITR). Ao usar o backup contínuo, você pode restaurar o conjunto de dados para o estado em que ele se encontrava em uma data e hora especificadas.
Se todos os dados estão disponíveis, não corrompidos, acessíveis e qualquer perda de dados está de acordo com o RPO da workload. Eles também podem ajudar a verificar se os mecanismos de recuperação são rápidos o suficiente para acomodar o RTO da workload.
O AWS Elastic Disaster Recovery oferece snapshots contínuos de recuperação para um ponto no tempo de volumes do Amazon EBS. À medida que os servidores de origem são replicados, os estados pontuais são registrados ao longo do tempo com base na política configurada. O Elastic Disaster Recovery ajuda você a verificar a integridade desses snapshots lançando instâncias para fins de teste e detalhamento sem redirecionar o tráfego.
**Etapas de implementação**
1. **Identifique as fontes de dados** que estão sendo copiadas no momento e onde esses backups estão sendo armazenados. Para obter orientações de implementação, consulte [REL09-BP01 Identificar e fazer backup de todos os dados que precisam de backup ou reproduzir os dados das fontes](rel_backing_up_data_identified_backups_data.md).
1. **Estabeleça critérios para validação de dados** para cada fonte de dados. Diferentes tipos de dados terão propriedades distintas que podem exigir mecanismos de validação diferentes. Considere como validar esses dados antes de se sentir confiante em usá-los na produção. Algumas maneiras comuns de validar dados são o uso de dados e propriedades de backup, como tipo de dados, formato, soma de verificação, tamanho ou uma combinação deles com lógica de validação personalizada. Por exemplo, pode ser uma comparação dos valores de soma de verificação entre o recurso restaurado e a fonte de dados no momento em que o backup foi criado.
1. **Estabeleça o RTO e o RPO** para restaurar os dados com base na criticidade dos dados. Para obter orientações de implementação, consulte [REL13-BP01 Definir os objetivos de recuperação para tempo de inatividade e perda de dados](rel_planning_for_recovery_objective_defined_recovery.md).
1. **Avalie sua capacidade de recuperação**. Revise sua estratégia de backup e de restauração para entender se ela pode cumprir o RTO e o RPO e ajuste a estratégia conforme necessário. Usando o [Hub de Resiliência da AWS](https://docs.aws.amazon.com/resilience-hub/latest/userguide/create-policy.html), você pode executar uma avaliação da sua workload. Essa avaliação analisa a configuração da aplicação em relação à política de resiliência e relata se as metas de RTO e RPO podem ser cumpridas.
1. **Faça uma restauração de teste** usando os processos atualmente estabelecidos usados na produção para restauração de dados. Esses processos dependem de como foi feito o backup da fonte de dados original, do formato e do local de armazenamento do próprio backup ou se os dados são reproduzidos de outras fontes. Por exemplo, se você estiver usando um serviço gerenciado como o [AWS Backup, isso poderá ser tão simples quanto restaurar o backup em um novo recurso](https://docs.aws.amazon.com/aws-backup/latest/devguide/restoring-a-backup.html). Se você usou o AWS Elastic Disaster Recovery, pode [iniciar um exercício de recuperação](https://docs.aws.amazon.com/drs/latest/userguide/failback-preparing.html).
1. **Valide a recuperação de dados** do recurso restaurado com base nos critérios que você estabeleceu anteriormente para validação de dados. Os dados restaurados e recuperados contêm o registro ou item mais recente no momento do backup? Esses dados se enquadram no RPO da workload?
1. **Meça o tempo necessário** para restauração e recuperação e compare-o com seu RTO estabelecido. Esse processo se enquadra no RTO da workload? Por exemplo, compare o carimbo de data/hora em que o processo de restauração foi iniciado e que a validação da recuperação foi concluída para calcular quanto tempo esse processo demora. Todas as chamadas da API da AWS contêm informações de data e hora, e essas informações estão disponíveis no [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html). Embora essas informações possam fornecer detalhes sobre o início do processo de restauração, o carimbo final de data/hora da conclusão da validação deve ser registrado pela lógica de validação. Se estiver usando um processo automatizado, serviços como o [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) poderão ser usados para armazenar essas informações. Além disso, muitos serviços da AWS oferecem um histórico de eventos que fornece informações sobre a data e a hora em que determinadas ações ocorreram. No AWS Backup, as ações de backup e restauração são chamadas de *trabalhos*, e esses trabalhos contêm informações de data e hora como parte de seus metadados que podem ser usadas para medir o tempo necessário para restauração e recuperação.
1. **Notifique as partes interessadas** se a validação de dados falhar ou se o tempo necessário para restauração e recuperação exceder o RTO estabelecido para a workload. Ao implementar a automação para fazer isso, [como neste laboratório](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/), serviços como o Amazon Simple Notification Service (Amazon SNS) podem ser usados para enviar notificações push, como e-mail ou SMS, às partes interessadas. [Essas mensagens também podem ser publicadas em aplicações de mensagens, como Amazon Chime, Slack ou Microsoft Teams](https://aws.amazon.com/premiumsupport/knowledge-center/sns-lambda-webhooks-chime-slack-teams/) ou usadas para [criar tarefas como OpsItems usando o AWS Systems Manager OpsCenter](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-creating-OpsItems.html).
1. **Automatize esse processo para ser executado periodicamente**. Por exemplo, serviços como o AWS Lambda ou uma máquina de estado no AWS Step Functions podem ser usados para automatizar os processos de restauração e recuperação, e é possível usar o Amazon EventBridgepara invocar esse fluxo de trabalho de automação periodicamente, conforme mostrado no diagrama de arquitetura abaixo. Saiba como [automatizar a validação da recuperação de dados com o AWS Backup](https://aws.amazon.com/blogs/storage/automate-data-recovery-validation-with-aws-backup/). Além disso, [esse laboratório do Well-Architected](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/) fornece uma experiência prática sobre uma forma de automatizar várias das etapas descritas aqui.
![\[Diagrama que mostra um processo de backup e restauração automatizado\]](http://docs.aws.amazon.com/pt_br/wellarchitected/latest/framework/images/automated-backup-restore-process.png)
**Nível de esforço para o plano de implementação:** Moderado a alto, dependendo da complexidade dos critérios de validação.
## Recursos
**Documentos relacionados:**
+ [Automatizar a validação da recuperação de dados com o AWS Backup](https://aws.amazon.com/blogs/storage/automate-data-recovery-validation-with-aws-backup/).
+ [Parceiro da APN: parceiros que podem ajudar com o backup](https://aws.amazon.com/partners/find/results/?keyword=Backup)
+ [AWS Marketplace: produtos que podem ser usados para backup](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup)
+ [Criar uma regra do EventBridge que é acionada de acordo com uma programação](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-scheduled-rule.html)
+ [Backup e restauração sob demanda para o DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/BackupRestore.html)
+ [O que é o AWS Backup?](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html)
+ [O que é o AWS Step Functions?](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)
+ [O que é o AWS Elastic Disaster Recovery](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)
+ [AWS Elastic Disaster Recovery](https://aws.amazon.com/disaster-recovery/)
# REL 10. Como você usa o isolamento de falhas para proteger a workload?
O isolamento de falhas limita o impacto de uma falha de componente ou do sistema a um limite definido. Com o isolamento adequado, os componentes fora do limite não são afetados pela falha. Executar a workload em vários limites de isolamento de falhas pode torná-la mais resistente a falhas.
**Topics**
+ [REL10-BP01 Implantar a workload em vários locais](rel_fault_isolation_multiaz_region_system.md)
+ [REL10-BP02 Automatizar a recuperação de componentes restritos a um único local](rel_fault_isolation_single_az_system.md)
+ [REL10-BP03 Usar arquiteturas de anteparo para limitar o escopo de impactos](rel_fault_isolation_use_bulkhead.md)
# REL10-BP01 Implantar a workload em vários locais
Distribua os dados e os recursos da workload por várias zonas de disponibilidade ou, quando necessário, por Regiões da AWS.
Um princípio fundamental do design de serviço na AWS é evitar pontos únicos de falha, incluindo a infraestrutura física subjacente. A AWS fornece recursos e serviços de computação em nuvem globalmente em várias localizações geográficas chamadas [regiões](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/regions.html). Cada região é física e logicamente independente e consiste em três ou mais [zonas de disponibilidade (AZs)](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/availability-zones.html). As zonas de disponibilidade ficam geograficamente próximas umas das outras, mas estão fisicamente separadas e isoladas. Ao distribuir as workloads entre zonas de disponibilidade e regiões, você reduz o risco de ameaças, como incêndios, inundações, desastres relacionados ao clima, terremotos e erro humano.
Crie uma estratégia de localização para fornecer alta disponibilidade adequada às workloads.
**Resultado desejado:** as workloads de produção são distribuídas entre várias zonas de disponibilidade (AZs) ou regiões para oferecer tolerância a falhas e alta disponibilidade.
**Práticas comuns que devem ser evitadas:**
+ A workload de produção existe somente em uma única zona de disponibilidade.
+ Implantar uma arquitetura multirregional quando uma arquitetura multi-AZ é suficiente para satisfazer os requisitos de negócios.
+ As implantações ou os dados ficam dessincronizados, o que resulta em desvio na configuração ou em dados sub-replicados.
+ Não contabilizar as dependências entre os componentes da aplicação se os requisitos de resiliência e de vários locais são diferentes entre esses componentes.
**Benefícios de implementar essa prática recomendada:**
+ A workload é mais resistente a incidentes, como falhas de energia ou de controle ambiental, desastres naturais, falhas no serviço upstream ou problemas de rede que afetam uma AZ ou uma região inteira.
+ Você pode acessar um inventário mais amplo de instâncias do Amazon EC2 e reduzir a probabilidade de InsufficientCapacityExceptions (ICE) ao iniciar tipos específicos de instância do EC2.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** Alto
## Orientação para implementação
Implemente e opere todas as workloads de produção em pelo menos duas zonas de disponibilidade (AZs) em uma região.
**Usar várias zonas de disponibilidade**
As zonas de disponibilidade são locais de hospedagem de recursos fisicamente separados uns dos outros para evitar falhas correlacionadas devido a riscos como incêndios, inundações e tornados. Cada zona de disponibilidade tem uma infraestrutura física independente, incluindo conexões de energia elétrica, fontes de energia de backup, serviços mecânicos e conectividade de rede. Esse arranjo limita as falhas em qualquer um desses componentes apenas à zona de disponibilidade afetada. Por exemplo, se um incidente em toda a AZ tornar as instâncias do EC2 indisponíveis na zona de disponibilidade afetada, suas instâncias em outra zona de disponibilidade permanecerão disponíveis.
Apesar de serem separadas fisicamente, as zonas de disponibilidade na mesma Região da AWS são próximas o suficiente para fornecer redes de alto throughput e baixa latência (milissegundo de um dígito). Você pode replicar dados de forma síncrona entre as zonas de disponibilidade para a maioria das workloads sem afetar significativamente a experiência do usuário. Assim, você pode usar as zonas de disponibilidade de uma região em uma configuração ativa/ativa ou ativa/em espera.
Toda a computação associada à workload deve ser distribuída entre várias zonas de disponibilidade. Isso inclui instâncias do [Amazon EC2](https://aws.amazon.com/ec2/), tarefas do [AWS Fargate](https://aws.amazon.com/fargate/) e funções do [AWS Lambda](https://aws.amazon.com/lambda/) anexadas à VPC. Os serviços de computação da AWS, incluindo [EC2 Auto Scaling](https://aws.amazon.com/ec2/autoscaling/), [Amazon Elastic Container Service (ECS)](https://aws.amazon.com/ecs/) e [Amazon Elastic Kubernetes Service (EKS)](https://aws.amazon.com/eks/), fornecem maneiras de você iniciar e gerenciar a computação em todas as zonas de disponibilidade. Configure-os para substituir automaticamente a computação conforme necessário em uma zona de disponibilidade diferente para manter a disponibilidade. Para direcionar o tráfego para as zonas de disponibilidade disponíveis, coloque um balanceador de carga na frente da computação, como um Application Load Balancer ou Network Load Balancer. Os balanceadores de carga da AWS podem redirecionar o tráfego para instâncias disponíveis em caso de falha na zona de disponibilidade.
Você também deve replicar dados para a workload e disponibilizá-los em várias zonas de disponibilidade. Alguns serviços de dados gerenciados pela AWS, como o [Amazon S3](https://aws.amazon.com/s3/), o [Amazon Elastic File Service (EFS)](https://aws.amazon.com/efs/), o [Amazon Aurora](https://aws.amazon.com/aurora/), o [Amazon DynamoDB](https://aws.amazon.com/dynamodb/), o [Amazon Simple Queue Service (SQS)](https://aws.amazon.com/sqs/) e o [Amazon Kinesis Data Streams](https://aws.amazon.com/kinesis/data-streams/), replicam dados em várias zonas de disponibilidade por padrão e são robustos contra o comprometimento da zona de disponibilidade. Com outros serviços de dados gerenciados pela AWS, como [Amazon Relational Database Service (RDS)](https://aws.amazon.com/rds/), [Amazon Redshift](https://aws.amazon.com/redshift/) e [Amazon ElastiCache](https://aws.amazon.com/elasticache/), você deve habilitar a replicação multi-AZ. Depois de habilitados, esses serviços detectam automaticamente uma deficiência na zona de disponibilidade, redirecionam as solicitações para uma zona de disponibilidade disponível e replicam novamente os dados conforme necessário após a recuperação, sem a intervenção do cliente. Familiarize-se com o guia do usuário de cada serviço de dados gerenciado pela AWS que você usa para entender os recursos, os comportamentos e as operações multi-AZ deles.
Se você estiver usando armazenamento autogerenciado, como volumes do [Amazon Elastic Block Store (EBS)](https://aws.amazon.com/ebs/) ou armazenamento de instâncias do Amazon EC2, deverá gerenciar a replicação multi-AZ por conta própria.
![\[Diagrama que mostra uma arquitetura multicamada implantada em três zonas de disponibilidade. Observe que o Amazon S3 e o Amazon DynamoDB são sempre Multi-AZ automaticamente. O ELB também é implantado em todas as três zonas.\]](http://docs.aws.amazon.com/pt_br/wellarchitected/latest/framework/images/multi-tier-architecture.png)
**Usar várias Regiões da AWS**
Se você tem workloads que exigem extrema resiliência (como infraestrutura crítica, aplicações relacionadas à saúde ou serviços com rigorosos requisitos de clientes ou de disponibilidade obrigatória), pode precisar de disponibilidade adicional além do que uma única Região da AWS pode oferecer. Nesse caso, você deve implantar e operar a workload em pelo menos duas Regiões da AWS (supondo que os requisitos de residência de dados permitam isso).
As Regiões da AWS estão localizadas em diferentes regiões geográficas ao redor do mundo e em vários continentes. As Regiões da AWS têm separação física e isolamento ainda maiores do que as zonas de disponibilidade sozinhas. Os serviços da AWS, com poucas exceções, aproveitam esse design para operar de forma totalmente independente entre diferentes regiões (também conhecidos como *serviços regionais*). Uma falha em um serviço que opera por Região da AWS não deve afetar o serviço em uma região diferente.
Ao operar a workload em várias regiões, você deve considerar requisitos adicionais. Como os recursos em diferentes regiões são separados e independentes uns dos outros, você deve duplicar os componentes da workload em cada região. Isso inclui infraestrutura básica, como VPCs, além de serviços de computação e dados.
**OBSERVAÇÃO:** ao considerar um design multirregional, verifique se a workload é capaz de ser executada em uma única região. Se você criar dependências entre regiões, em que um componente em uma região depende de serviços ou componentes de outra região, poderá aumentar o risco de falha e enfraquecer significativamente sua postura de confiabilidade.
Para facilitar as implantações multirregionais e manter a consistência, o [AWS CloudFormation StackSets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html) pode replicar toda a sua infraestrutura da AWS em várias regiões. O [AWS CloudFormation](https://aws.amazon.com/cloudformation/) também pode detectar desvios na configuração e informar você quando os recursos da AWS em uma região estiverem fora de sincronia. Muitos serviços da AWS oferecem replicação multirregional para ativos importantes de workload. Por exemplo, o [EC2 Image Builder](https://aws.amazon.com/image-builder/) pode publicar as imagens de máquina (AMIs) do EC2 após cada compilação em cada região que você usa. O [Amazon Elastic Container Registry (ECR)](https://aws.amazon.com/ecr/) pode replicar as imagens de contêiner nas regiões selecionadas.
Você também deve replicar os dados em cada uma das regiões escolhidas. Muitos serviços de dados gerenciados pela AWS oferecem capacidade de replicação entre regiões, incluindo Amazon S3, Amazon DynamoDB, Amazon RDS, Amazon Aurora, Amazon Redshift, Amazon ElastiCache e Amazon EFS. As [tabelas globais do Amazon DynamoDB](https://aws.amazon.com/dynamodb/global-tables/) aceitam gravações em qualquer região compatível e replicarão dados entre todas as outras regiões configuradas. Com outros serviços, você deve designar uma região primária para gravações, pois outras regiões contêm réplicas somente leitura. Para cada serviço de dados gerenciado pela AWS que a workload usa, consulte o guia do usuário e o guia do desenvolvedor para entender as capacidades e limitações multirregionais de cada um. Preste atenção especial para onde as gravações devem ser direcionadas, aos recursos e limitações transacionais, à forma como a replicação é executada e à forma de monitorar a sincronização entre regiões.
A AWS também fornece a capacidade de rotear o tráfego de solicitações para as implantações regionais com grande flexibilidade. Por exemplo, você pode configurar os registros DNS usando o [Amazon Route 53](https://aws.amazon.com/route53/) a fim de direcionar o tráfego para a região disponível mais próxima do usuário. Como alternativa, você pode configurar os registros DNS em uma configuração ativa/em espera, em que designa uma região como primária e retorna a uma réplica regional somente se a região primária não estiver íntegra. Você pode configurar as [verificações de integridade do Route 53](https://docs.aws.amazon.com/Route 53/latest/DeveloperGuide/dns-failover.html) para detectar endpoints não íntegros e realizar failover automático, além de usar o [Controlador de Recuperação de Aplicações (ARC)](https://aws.amazon.com/application-recovery-controller/) para fornecer um controle de roteamento altamente disponível a fim de redirecionar manualmente o tráfego conforme necessário.
Mesmo que você opte por não operar em várias regiões para obter alta disponibilidade, considere várias regiões como parte da sua estratégia de recuperação de desastres (DR). Se possível, replique os componentes e os dados da infraestrutura da workload em uma configuração de *espera passiva* ou de *luz piloto* em uma região secundária. Nesse design, você replica a infraestrutura de linha de base da região primária, como VPCs, grupos do Auto Scaling, orquestradores de contêineres e outros componentes, mas configura os componentes de tamanho variável na região de espera (como o número de instâncias do EC2 e réplicas de banco de dados) para ter um tamanho minimamente operável. Você também organiza a replicação contínua de dados da região primária para a região de standby. Se ocorrer um incidente, você poderá aumentar a escala horizontalmente ou aumentar os recursos na região de standby e promovê-la para se tornar a região primária.
### Etapas de implementação
1. Trabalhe com partes interessadas empresariais e especialistas em residência de dados para determinar quais Regiões da AWS podem ser usadas para hospedar os recursos e os dados.
1. Trabalhe com partes interessadas de áreas comerciais e técnicas para avaliar a workload e determinar se as necessidades de resiliência podem ser atendidas por uma abordagem multi-AZ (Região da AWS única) ou se elas exigem uma abordagem multirregional (se várias regiões forem permitidas). O uso de várias regiões pode alcançar maior disponibilidade, mas pode envolver complexidade e custo adicionais. Considere os seguintes fatores em sua avaliação:
1. **Objetivos de negócios e requisitos do cliente**: quanto tempo de inatividade é permitido caso ocorra um incidente que afete a workload em uma zona de disponibilidade ou região? Avalie os objetivos de ponto de recuperação conforme discutido em [REL13-BP01 Definir objetivos de recuperação para tempo de inatividade e perda de dados](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_objective_defined_recovery.html).
1. **Requisitos de recuperação de desastres (DR)**: contra qual tipo de desastre potencial você quer se proteger? Considere a possibilidade de perda de dados ou indisponibilidade de longo prazo em diferentes escopos de impacto, de uma única zona de disponibilidade a uma região inteira. Se você replicar dados e recursos em todas as zonas de disponibilidade e uma única zona de disponibilidade apresentar uma falha contínua, você poderá recuperar o serviço em outra zona de disponibilidade. Se você replicar dados e recursos entre regiões, poderá recuperar o serviço em outra região.
1. Implemente seus recursos computacionais em várias zonas de disponibilidade.
1. Na VPC, crie várias sub-redes em diferentes zonas de disponibilidade. Configure cada uma para ser grande o suficiente para acomodar os recursos necessários e atender à workload, mesmo durante um incidente. Para conferir mais detalhes, consulte [REL02-BP03 Garantir contas de alocação de sub-rede IP para expansão e disponibilidade](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_network_topology_ip_subnet_allocation.html).
1. Se você estiver usando instâncias do Amazon EC2, use o [EC2 Auto Scaling](https://aws.amazon.com/ec2/autoscaling/) para gerenciar suas instâncias. Especifique as sub-redes que você escolheu na etapa anterior ao criar os grupos do Auto Scaling.
1. Se você estiver usando a computação do AWS Fargate para o [Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/AWS_Fargate.html) ou o [Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/fargate.html), selecione as sub-redes escolhidas na primeira etapa ao criar um serviço do ECS, inicializar uma tarefa do ECS ou criar um [perfil do Fargate](https://docs.aws.amazon.com/eks/latest/userguide/fargate-profile.html) para o EKS.
1. Se você estiver usando funções do AWS Lambda que precisam ser executadas na VPC, selecione as sub-redes escolhidas na primeira etapa ao criar a função do Lambda. Para qualquer função que não tenha uma configuração de VPC, o AWS Lambda gerencia a disponibilidade para você automaticamente.
1. Coloque diretores de tráfego, como balanceadores de carga, na frente dos recursos de computação. Se o balanceamento de carga entre zonas estiver habilitado, os [AWS Application Load Balancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html) e [Network Load Balancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html) detectarão quando destinos, como instâncias e contêineres do EC2, estiverem inacessíveis devido ao comprometimento da zona de disponibilidade e redirecionarão o tráfego para destinos em zonas de disponibilidade íntegras. Se você desabilitar o balanceamento de carga entre zonas, use o Controlador de Recuperação de Aplicações (ARC) para fornecer a capacidade de mudança de zona. Se você estiver usando um balanceador de carga de terceiros ou tiver implementado seus próprios balanceadores de carga, configure-os com vários front-ends em diferentes zonas de disponibilidade.
1. Replique os dados da workload em várias zonas de disponibilidade.
1. Se você usa um serviço de dados gerenciado pela AWS, como Amazon RDS, Amazon ElastiCache ou Amazon FSx, estude os guias do usuário para entender os recursos de replicação e resiliência de dados deles. Habilite o failover e a replicação entre AZs, se necessário.
1. Se você usa serviços de armazenamento gerenciados pela AWS, como Amazon S3, Amazon EFS e Amazon FSx, evite usar configurações single-AZ ou One Zone para dados que exijam alta durabilidade. Use uma configuração multi-AZ para esses serviços. Consulte o guia do usuário do respectivo serviço para determinar se a replicação multi-AZ está habilitada por padrão ou se você deve habilitá-la.
1. Se você executar um banco de dados, uma fila ou outro serviço de armazenamento autogerenciado, providencie a replicação multi-AZ de acordo com as instruções ou práticas recomendadas da aplicação. Familiarize-se com os procedimentos de failover da aplicação.
1. Configure o serviço DNS para detectar deficiências na AZ e redirecionar o tráfego para uma zona de disponibilidade íntegra. O Amazon Route 53, quando usado em combinação com Elastic Load Balancers, pode fazer isso automaticamente. O Route 53 também pode ser configurado com registros de failover que usam verificações de integridade para responder a consultas somente com endereços IP íntegros. Para registros DNS usados para failover, especifique um valor curto de vida útil (TTL) (por exemplo, 60 segundos ou menos) para ajudar a evitar que o armazenamento em cache de registros impeça a recuperação (os registros de alias do Route 53 fornecem TTLs apropriados para você).
**Etapas adicionais ao usar várias Regiões da AWS**
1. Replique todo o sistema operacional (SO) e código de aplicação usados pela workload nas regiões selecionadas. Replique as imagens de máquina da Amazon (AMIs) usadas pelas instâncias do EC2, se necessário, usando soluções como o Amazon EC2 Image Builder. Replique imagens de contêineres armazenadas em registros usando soluções como a replicação entre regiões do Amazon ECR. Habilite a replicação regional para qualquer bucket do Amazon S3 usado para armazenar recursos de aplicações.
1. Implante os recursos de computação e os metadados de configuração (como parâmetros armazenados no AWS Systems Manager Parameter Store) em várias regiões. Use os mesmos procedimentos descritos nas etapas anteriores, mas replique a configuração para cada região em que você está usando a workload. Use soluções de infraestrutura como código, como o AWS CloudFormation, para reproduzir uniformemente as configurações entre as regiões. Se você estiver usando uma região secundária em uma configuração de luz piloto para recuperação de desastres, poderá reduzir o número de recursos de computação a um valor mínimo para reduzir os custos, com um aumento correspondente no tempo de recuperação.
1. Replique os dados da região primária para as regiões secundárias.
1. As tabelas globais do Amazon DynamoDB fornecem réplicas globais dos dados que podem receber gravações de qualquer região compatível. Com outros serviços de dados gerenciados pela AWS, como Amazon RDS, Amazon Aurora e Amazon ElastiCache, designe uma região primária (leitura/gravação) e regiões de réplica (somente leitura). Consulte os guias do usuário e do desenvolvedor dos respectivos serviços para obter detalhes sobre a replicação regional.
1. Se você estiver executando um banco de dados autogerenciado, providencie a replicação multirregional de acordo com as instruções ou as práticas recomendadas da aplicação. Familiarize-se com os procedimentos de failover da aplicação.
1. Se a workload usa o AWS EventBridge, talvez seja necessário encaminhar eventos selecionados da região primária para as regiões secundárias. Para fazer isso, especifique os barramentos de eventos nas regiões secundárias como metas para eventos correspondentes na região primária.
1. Considere se e em que medida você deseja usar chaves de criptografia idênticas em todas as regiões. Uma abordagem típica que equilibra segurança e facilidade de uso é usar chaves com escopo regional para dados e autenticação locais em uma região e usar chaves com escopo global para criptografia de dados que são replicadas entre diferentes regiões. O [AWS Key Management Service (KMS)](https://aws.amazon.com/kms/) oferece suporte a [chaves multirregionais](https://docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-overview.html) para distribuição segura e proteção das chaves compartilhadas entre regiões.
1. Considere o AWS Global Accelerator para melhorar a disponibilidade da aplicação direcionando o tráfego para regiões que contêm endpoints íntegros.
## Recursos
**Práticas recomendadas relacionadas:**
+ [REL02-BP03 Garantir contas de alocação de sub-rede IP para expansão e disponibilidade](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_network_topology_ip_subnet_allocation.html)
+ [REL11-BP05 Usar estabilidade estática para evitar comportamento bimodal](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_static_stability.html)
+ [REL13-BP01 Definir objetivos de recuperação para tempo de inatividade e perda de dados](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_objective_defined_recovery.html)
**Documentos relacionados:**
+ [Infraestrutura global da AWS](https://aws.amazon.com/about-aws/global-infrastructure)
+ [White paper: AWS Fault Isolation Boundaries](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/availability-zones.html)
+ [Resiliência no Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/disaster-recovery-resiliency.html)
+ [Amazon EC2 Auto Scaling: exemplo: distribuir instâncias entre zonas de disponibilidade](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#arch-AutoScalingMultiAZ)
+ [Como o EC2 Image Builder funciona](https://docs.aws.amazon.com/imagebuilder/latest/userguide/how-image-builder-works.html#image-builder-distribution)
+ [Como o Amazon ECS posiciona tarefas em instâncias de contêineres (inclui o Fargate)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement.html)
+ [Resiliência no AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/security-resilience.html)
+ [Amazon S3: visão geral sobre a replicação de objetos](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html)
+ [Replicação de imagem privada no Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/replication.html)
+ [Tabelas globais: replicação em várias regiões com o DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GlobalTables.html)
+ [Amazon ElastiCache for Redis OSS: Replication across Regiões da AWS using global datastores](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Redis-Global-Datastore.html)
+ [Resiliência no Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/disaster-recovery-resiliency.html)
+ [Usar bancos de dados globais do Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html)
+ [Guia do desenvolvedor do AWS Global Accelerator](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html)
+ [Chaves de multirregiões no AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-overview.html)
+ [Amazon Route 53: configurar o failover de DNS](https://docs.aws.amazon.com/Route 53/latest/DeveloperGuide/dns-failover-configuring.html)
+ [Guia do desenvolvedor do Controlador de Recuperação de Aplicações (ARC) da Amazon](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
+ [Como enviar e receber eventos do Amazon EventBridge entre regiões da Regiões da AWS](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-cross-region.html)
+ [Série de blogs Criar aplicações multirregiões com serviços da AWS](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/)
+ [Arquitetura de recuperação de desastres (DR) na AWS, Parte I: estratégias de recuperação na nuvem](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-i-strategies-for-recovery-in-the-cloud/)
+ [Arquitetura de recuperação de desastres (DR) na AWS, parte III: luz piloto e standby passivo](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/)
**Vídeos relacionados:**
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications](https://youtu.be/2e29I3dA8o4)
+ [AWS re:Invent 2019: Innovation and operation of the AWS global network infrastructure](https://youtu.be/UObQZ3R9_4c)
# REL10-BP02 Automatizar a recuperação de componentes restritos a um único local
Se os componentes da workload só puderem ser executados em uma única zona de disponibilidade ou data center on-premises, será necessário implementar capacidade suficiente para fazer uma recompilação completa da workload em conformidade com os objetivos de recuperação definidos.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio
## Orientação para implementação
Se a prática recomendada para implantar a workload em vários locais não for possível devido a restrições tecnológicas, você deverá implementar um caminho alternativo para a resiliência. Você deve automatizar a capacidade de recriar a infraestrutura necessária, reimplantar aplicações e recriar os dados necessários para esses casos.
Por exemplo, o Amazon EMR executa todos os nós de um determinado cluster na mesma zona de disponibilidade porque a execução de um cluster na mesma zona melhora a performance dos fluxos de trabalho, pois fornece uma taxa de acesso a dados mais alta. Se esse componente for necessário para a resiliência da workload, você deverá ter uma maneira de reimplantar o cluster e seus dados. Além disso, para o Amazon EMR, você deve provisionar redundância de maneiras diferentes de usar o Multi-AZ. É possível provisionar [vários nós](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-ha-launch.html). Usando o [EMR File System (EMRFS)](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-fs.html),Regiões da AWS os dados no EMR podem ser armazenados no Amazon S3, que, por sua vez, podem ser replicados em várias zonas de disponibilidade ou regiões da .
Da mesma forma, o Amazon Redshift, por padrão, provisiona o cluster em uma zona de disponibilidade escolhida aleatoriamente dentro da Região da AWS selecionada. Todos os nós de cluster são provisionados na mesma zona.
Para workloads com estado baseadas em servidor e implantadas em um data center on-premises, é possível usar o AWS Elastic Disaster Recovery para proteger as workloads na AWS. Se você já estiver hospedado na AWS, poderá usar o Elastic Disaster Recovery para proteger sua workload em uma zona ou região de disponibilidade alternativa. O Elastic Disaster Recovery usa a replicação contínua em nível de bloco para uma área temporária leve para fornecer recuperação rápida e confiável de aplicações on-premises e baseadas na nuvem.
**Etapas de implementação**
1. Implemente a autorrecuperação. Quando possível, use o ajuste de escala automático para implantar instâncias ou contêineres. Quando não for possível, use a recuperação automática de instâncias do EC2 ou implemente a automação de autorrecuperação com base nos eventos de ciclo de vida do contêiner do Amazon EC2 ou do ECS.
+ Use os [grupos do Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html) para instâncias e workloads de contêiner que não têm requisitos de endereço IP de instância única, endereço IP privado, endereço IP elástico e metadados de instância.
+ Os dados do usuário do modelo de execução podem ser usados para implementar uma automação que pode recuperar automaticamente a maioria das workloads.
+ Use a [recuperação automática de instâncias do Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html) para workloads que exigem um endereço do ID de instância única, endereço IP privado, endereço IP elástico e metadados de instância.
+ A recuperação automática enviará alertas de status de recuperação para um tópico do SNS quando a falha na instância for detectada.
+ Use [eventos de ciclo de vida da instância do Amazon EC2](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html) ou [eventos do Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_cwe_events.html) para automatizar a autorrecuperação quando ajuste de escala automático ou a recuperação do EC2 não puderem ser usadas.
+ Use os eventos para invocar a automação que recuperará seu componente de acordo com a lógica do processo necessária.
+ Proteja workloads monitoradas que estão limitadas a um único local usando o [AWS Elastic Disaster Recovery](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html).
## Recursos
**Documentos relacionados:**
+ [Eventos do Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_cwe_events.html)
+ [Ganchos do ciclo de vida do Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html)
+ [Recuperar a instância](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html)
+ [Ajuste de escala automático do serviço](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-auto-scaling.html)
+ [O que é o Amazon EC2 Auto Scaling?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
+ [AWS Elastic Disaster Recovery](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)
# REL10-BP03 Usar arquiteturas de anteparo para limitar o escopo de impactos
Implemente arquiteturas de anteparo (também chamadas de arquiteturas baseadas em células) para restringir o efeito ou a falha em uma workload a um número limitado de componentes.
**Resultado desejado:** uma arquitetura baseada em células usa várias instâncias isoladas de uma workload em que cada instância é conhecida como célula. Cada célula é independente, não compartilha o estado com outras células e processa um subconjunto das solicitações gerais da workload. Isso reduz o possível impacto de uma falha, como uma atualização de software incorreta, a uma célula individual e às solicitações que ela está processando. Se uma workload usa 10 células para atender a 100 solicitações, quando uma falha ocorrer, 90% das solicitações gerais não serão afetadas pela falha.
**Práticas comuns que devem ser evitadas:**
+ Permitir que as células cresçam sem limites.
+ Aplicar implantações ou atualizações de código a todas as células ao mesmo tempo.
+ Compartilhar o estado ou os componentes entre as células (com a exceção da camada do roteador).
+ Adicionar negócios complexos ou rotear lógica para a camada do roteador.
+ Não minimizar as interações entre as células.
**Benefícios de implementar esta prática recomendada:** com arquiteturas baseadas em células, muitos tipos comuns de falha são contidos na própria célula, o que permite o isolamento adicional das falhas. Esses limites de falha podem fornecer resiliência contra tipos de falha que, de outra forma, seriam difíceis de conter, como implantações de código malsucedidas ou solicitações corrompidas ou que invocam um modo de falha específico (também conhecido como *solicitações de pílulas venenosas*).
**Nível de risco exposto se esta prática recomendada não for estabelecida:** Alto
## Orientação para implementação
Em uma embarcação, os anteparos garantem que uma ruptura no casco seja contida em uma seção do casco. Em sistemas complexos, esse padrão costuma ser replicado para permitir o isolamento de falhas. Os limites isolados de falhas restringem o efeito de uma falha em uma workload a um número controlado de componentes. Os componentes fora do limite não são afetados pela falha. Ao usar vários limites isolados de falhas, é possível limitar o impacto na workload. Na AWS, os clientes podem usar várias zonas de disponibilidade e regiões para fornecer o isolamento de falhas, mas o conceito do isolamento de falhas também pode ser estendido à arquitetura da workload.
A workload geral é composta por células particionadas por uma chave de partição. Ela precisa se alinhar à *granularidade* do serviço, ou da maneira natural que a workload de um serviço pode ser subdividida em interações mínimas entre células. Exemplos de chaves de partição são ID de cliente, ID de recurso ou qualquer outro parâmetro facilmente acessível na maioria das chamadas de API. Uma camada de roteamento de célula distribui solicitações a células individuais com base na chave de partição e apresenta um único endpoint aos clientes.
![\[Diagrama que mostra arquitetura baseada em células\]](http://docs.aws.amazon.com/pt_br/wellarchitected/latest/framework/images/cell-based-architecture.png)
**Etapas de implementação**
Ao projetar uma arquitetura baseada em células, há várias considerações de design a levar em conta:
1. **Chave de partição**: consideração especial deve ser feita em relação à chave de partição.
+ Ela precisa se alinhar à granularidade do serviço, ou à maneira natural que a workload de um serviço pode ser subdividida em interações mínimas entre células. Os exemplos são `customer ID` ou `resource ID`.
+ A chave de partição deve estar disponível em todas as solicitações, seja diretamente ou de uma maneira que possa ser facilmente inferida de forma determinística por outros parâmetros.
1. **Mapeamento celular persistente**: os serviços upstream devem interagir somente com uma única célula durante o ciclo de vida de seus recursos.
+ Dependendo da workload, uma estratégia de migração de células pode ser necessária para migrar os dados de uma célula para outra. Um possível cenário de quando é necessário fazer uma migração de célula seria quando um usuário ou recurso específico na workload se torna grande demais e exige uma célula dedicada.
+ As células não devem compartilhar estado ou componentes entre si.
+ Consequentemente, as interações entre as células devem ser evitadas e mantidas no mínimo, já que elas podem criar dependências entre as células e, assim, reduzir as melhorias do isolamento de falhas.
1. **Camada do roteador**: a camada do roteador é um componente compartilhado entre as células e, portanto, não pode seguir a mesma estratégia de compartimentação das células.
+ É recomendável que a camada do roteador distribua as solicitações para células individuais usando um algoritmo de mapeamento de partição de maneira computacionalmente eficiente, como combinando funções de hash criptográficas e aritmética modular para mapear chaves de partição a células.
+ Para evitar impactos em várias células, a camada de roteamento deve permanecer o mais simples e horizontalmente escalável possível, o que exige evitar uma lógica empresarial complexa nessa camada. Isso traz o benefício adicional de facilitar a compreensão de seu comportamento esperado em todos os momentos, permitindo a realização de testes rigorosos. Conforme explicado por Colm MacCárthaigh em [Confiabilidade, trabalho constante e uma boa xícara de café](https://aws.amazon.com/builders-library/reliability-and-constant-work/), designs simples e padrões de trabalho constantes produzem sistemas confiáveis e reduzem a antifragilidade.
1. **Tamanho da célula**: as células devem ter um tamanho máximo e não devem se estender além dele.
+ O tamanho máximo deve ser identificado com a realização de testes completos até que os pontos de ruptura sejam atingidos e margens operacionais seguras sejam estabelecidas. Para obter mais detalhes sobre como implementar práticas de testes, consulte [REL07-BP04 Fazer o teste de carga da workload](rel_adapt_to_changes_load_tested_adapt.md)
+ A workload geral deve crescer com a adição de mais células, permitindo que a workload seja escalada com aumentos na demanda.
1. **Estratégias multi-AZ ou multirregiões**: utilize várias camadas de resiliência para oferecer proteção contra diferentes domínios de falha.
+ Para resiliência, você deve usar uma abordagem que crie camadas de defesa. Uma camada protege contra interrupções menores e mais comuns criando uma arquitetura altamente disponível usando várias AZs. Outra camada de defesa destina-se a proteger contra eventos raros, como desastres naturais generalizados e interrupções em nível regional. Essa segunda camada envolve arquitetar a aplicação para abranger várias Regiões da AWS. A implementação de uma estratégia multirregiões para a workload ajuda a protegê-la contra desastres naturais generalizados, que afetam uma grande área geográfica de um país, ou falhas técnicas de escopo regional. Esteja ciente de que a implementação de uma arquitetura multirregiões pode ser complexa e, geralmente, não é necessária para a maioria das workloads. Para obter mais detalhes, consulte [REL10-BP01 Implantar a workload em vários locais](rel_fault_isolation_multiaz_region_system.md).
1. **Implantação de código**: uma estratégia de implantação de código em etapas deve ser preferida à implantação de alterações de código em todas as células ao mesmo tempo.
+ Isso ajuda a reduzir a possibilidade de falhas em várias células devido a uma implantação incorreta ou a erro humano. Para obter mais detalhes, consulte [Automatizar implantações seguras e sem intervenção manual](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/).
## Recursos
**Práticas recomendadas relacionadas:**
+ [REL07-BP04 Fazer o teste de carga da workload](rel_adapt_to_changes_load_tested_adapt.md)
+ [REL10-BP01 Implantar a workload em vários locais](rel_fault_isolation_multiaz_region_system.md)
**Documentos relacionados:**
+ [Confiabilidade, trabalho constante e uma boa xícara de café](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
+ [AWS e a compartimentalização](https://aws.amazon.com/blogs/architecture/aws-and-compartmentalization/)
+ [Isolamento de workloads via fragmentação aleatória](https://aws.amazon.com/builders-library/workload-isolation-using-shuffle-sharding/)
+ [Automatizar implantações seguras e sem intervenção manual](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/)
**Vídeos relacionados:**
+ [AWS re:Invent 2018: Fechar loops e abrir mentes: como assumir o controle de sistemas grandes e pequenos](https://www.youtube.com/watch?v=O8xLxNje30M)
+ [AWS re:Invent 2018: Como a AWS minimiza o raio de ação das falhas (ARC338)](https://youtu.be/swQbA4zub20)
+ [Fragmentação aleatória: AWS re:Invent 2019: Introdução à Amazon Builders' Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1373)
+ [AWS Summit ANZ 2021: Tudo falha, o tempo todo: projetando para resiliência](https://www.youtube.com/watch?v=wUzSeSfu1XA)
# REL 11. Como projetar a workload para resistir a falhas de componentes?
As workloads que exigem alta disponibilidade e baixo tempo médio até a recuperação (MTTR) devem ser projetadas visando a resiliência.
**Topics**
+ [REL11-BP01 Monitorar todos os componentes da workload para detectar falhas](rel_withstand_component_failures_monitoring_health.md)
+ [REL11-BP02 Failover para recursos íntegros](rel_withstand_component_failures_failover2good.md)
+ [REL11-BP03 Automatizar a reparação em todas as camadas](rel_withstand_component_failures_auto_healing_system.md)
+ [REL11-BP04 Confiar no plano de dados, e não no ambiente de gerenciamento, durante a recuperação](rel_withstand_component_failures_avoid_control_plane.md)
+ [REL11-BP05 Usar estabilidade estática para evitar comportamento bimodal](rel_withstand_component_failures_static_stability.md)
+ [REL11-BP06 Enviar notificações quando os eventos afetarem a disponibilidade](rel_withstand_component_failures_notifications_sent_system.md)
+ [REL11-BP07 Arquitetar o produto para cumprir as metas de disponibilidade e os acordos de serviço (SLAs) de tempo de atividade](rel_withstand_component_failures_service_level_agreements.md)
# REL11-BP01 Monitorar todos os componentes da workload para detectar falhas
Monitore constantemente a integridade da workload para que você e seus sistemas automatizados detectem falhas ou degradações assim que elas ocorrerem. Monitore os indicadores-chave de performance (KPIs) com base no valor empresarial.
Todos os mecanismos de recuperação e correção devem começar com a capacidade de detectar problemas rapidamente. As falhas técnicas devem ser detectadas primeiro para que possam ser resolvidas. No entanto, a disponibilidade é baseada na capacidade da workload de entregar valor empresarial, portanto, os indicadores-chave de performance (KPIs) que medem isso precisam fazer parte da sua estratégia de detecção e remediação.
**Resultado desejado:** os componentes essenciais de uma workload são monitorados de forma independente para detectar e alertar sobre falhas quando e onde elas acontecem.
**Práticas comuns que devem ser evitadas:**
+ Nenhum alarme foi configurado, portanto as interrupções ocorrem sem notificação.
+ Os alarmes existem, mas com limites que não permitem um tempo adequado para reação.
+ As métricas não são coletadas com frequência suficiente para atender ao objetivo de tempo de recuperação (RTO).
+ Somente as interfaces da workload voltadas para o cliente são monitoradas ativamente.
+ Coleta apenas das métricas técnicas, não das métricas de função de negócios.
+ Não há métricas que medem a experiência do usuário da workload.
+ Monitores em excesso são criados.
**Benefícios de implementar esta prática recomendada:** o monitoramento adequado de todas as camadas permite reduzir o tempo de recuperação ao reduzir o tempo de detecção.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** Alto
## Orientação para implementação
Identifique todas as workloads que serão analisadas para monitoramento. Depois de identificar todos os componentes da workload que precisarão ser monitorados, será necessário determinar o intervalo de monitoramento. O intervalo de monitoramento terá um impacto direto na rapidez com que a recuperação pode ser iniciada com base no tempo necessário para detectar uma falha. O tempo médio de detecção (MTTD) é a quantidade de tempo entre a ocorrência de uma falha e o início das operações de reparo. A lista de serviços deve ser extensa e completa.
O monitoramento deve abranger todas as camadas da pilha de aplicações, incluindo aplicação, plataforma, infraestrutura e rede.
Sua estratégia de monitoramento deve considerar o impacto de *falhas cinzentas*. Para obter mais detalhes sobre falhas cinzentas, consulte [Falhas cinzentas](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/gray-failures.html) no whitepaper Padrões de resiliência Multi-AZ avançados.
### Etapas de implementação
+ O intervalo de monitoramento depende da rapidez com que você precisa fazer a recuperação. O tempo de recuperação é determinado pelo tempo necessário para a recuperação. Desse modo, você deve considerar esse tempo e o objetivo de tempo de recuperação (RTO) para determinar a frequência da coleta.
+ Configure o monitoramento detalhado de componentes e serviços gerenciados.
+ Determine se o [monitoramento detalhado das instâncias do EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-cloudwatch-new.html) e do [Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-monitoring.html) é necessário. O monitoramento detalhado fornece métricas de intervalo de um minuto, e o monitoramento padrão fornece métricas de intervalo de cinco minutos.
+ Determine se o [monitoramento avançado](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Monitoring.html) para RDS é necessário. O monitoramento aprimorado usa um agente nas instâncias do RDS para obter informações úteis sobre processos ou threads diferentes.
+ Determine os requisitos de monitoramento de componentes essenciais sem servidor para [Lambda](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-metrics.html), [API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/monitoring_automated_manual.html), [Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/eks-observe.html), [Amazon ECS](https://catalog.workshops.aws/observability/en-US/aws-managed-oss/amp/ecs) e todos os tipos de [balanceadores de carga](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-monitoring.html).
+ Determine os requisitos de monitoramento dos componentes de armazenamento para [Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/monitoring-overview.html), [Amazon FSx](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/monitoring_overview.html), [Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/monitoring_overview.html) e [Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-volume-status.html).
+ Crie [métricas personalizadas](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) para medir os indicadores-chave de performance (KPIs) de negócios. As workloads implementam as principais funções empresariais, as quais devem ser usadas como KPIs para ajudar a identificar quando um problema indireto ocorre.
+ Utilize os canários de usuário para monitorar a experiência do usuário e verificar se há falhas. O [teste de transações sintéticas](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) (também conhecido como teste canário, que não deve ser confundidos com as implantações canário), capaz de executar e simular o comportamento do cliente, está entre os processos de teste mais importantes. Execute esses testes constantemente nos endpoints da workload de diversos locais remotos.
+ Crie [métricas personalizadas](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) que acompanhem a experiência do usuário Se você puder estabelecer instrumentos de medição da experiência do cliente, conseguirá determinar o momento de degradação da experiência do consumidor.
+ [Defina alarmes](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) para detectar quando uma parte da workload não estiver funcionando corretamente e indicar quando o ajuste de escala automático dos recursos deve ser feito. Os alarmes podem ser exibidos visualmente em painéis, enviar alertas via Amazon SNS ou e-mail e trabalhar com o Auto Scaling para aumentar ou reduzir a escala dos recursos da workload.
+ Crie [painéis](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html) para visualizar as métricas. É possível usar os painéis para ver as tendências, os casos atípicos e outros indicadores de possíveis problemas ou para obter uma indicação de problemas a serem investigados.
+ Crie [monitoramento de rastreamento distribuído](https://aws.amazon.com/xray/faqs/) para seus serviços. Com o monitoramento distribuído, você compreende como está a performance de sua aplicação e seus serviços subjacentes para identificar e solucionar a causa principal de problemas e erros de performance.
+ Crie painéis de sistemas de monitoramento (usando [CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_xaxr_dashboard.html) ou [X-Ray](https://aws.amazon.com/xray/faqs/)) e coleta de dados em uma região e conta separadas.
+ Mantenha-se a par das degradações de serviço por meio do [AWS Health](https://aws.amazon.com/premiumsupport/technology/aws-health/). [Crie notificações de eventos do AWS Health ajustadas à finalidade](https://docs.aws.amazon.com/health/latest/ug/user-notifications.html) para canais de e-mail e chat por meio do [Notificações de Usuários da AWS](https://docs.aws.amazon.com/notifications/latest/userguide/what-is-service.html) e integre-as programaticamente às [suas ferramentas de monitoramento e alerta por meio do Amazon EventBridge](https://docs.aws.amazon.com/health/latest/ug/cloudwatch-events-health.html).
## Recursos
**Práticas recomendadas relacionadas:**
+ [Definição de disponibilidade](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+ [REL11-BP06 Enviar notificações quando os eventos afetarem a disponibilidade](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_notifications_sent_system.html)
**Documentos relacionados:**
+ [O Amazon CloudWatch Synthetics permite criar canários de usuário](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [Habilitar ou desabilitar o monitoramento detalhado da instância](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-cloudwatch-new.html)
+ [Monitoramento avançado](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html)
+ [Monitorar grupos do Auto Scaling e instâncias usando o Amazon CloudWatch](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-monitoring.html)
+ [Publicar métricas personalizadas](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ [Usar alarmes do Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Usar painéis do CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ [Usar painéis do CloudWatch entre regiões e contas](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_xaxr_dashboard.html)
+ [Usar o rastreamento do X-Ray entre regiões e contas](https://aws.amazon.com/xray/faqs/)
+ [Noções básicas da disponibilidade](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/understanding-availability.html)
**Vídeos relacionados:**
+ [Como mitigar falhas cinzentas](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/gray-failures.html)
**Exemplos relacionados:**
+ [Workshop One Observability: explorar o X-Ray](https://catalog.workshops.aws/observability/en-US/aws-native/xray/explore-xray)
**Ferramentas relacionadas:**
+ [CloudWatch](https://aws.amazon.com/cloudwatch/)
+ [CloudWatch X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/security-logging-monitoring.html)
# REL11-BP02 Failover para recursos íntegros
Se uma falha ocorrer no recurso, os recursos íntegros deverão continuar atendendo às solicitações. Para falhas de localização (como zona de disponibilidade ou Região da AWS), garanta que você tenha sistemas implementados para realizar failover para recursos íntegros em locais que não apresentam problemas.
Ao projetar um serviço, distribua a carga entre recursos, zonas de disponibilidade ou regiões. Portanto, a falha ou a deficiência de um recurso individual podem ser atenuadas por meio da transferência do tráfego para os recursos íntegros restantes. Pense em como os serviços são descobertos e encaminhados em caso de falha.
Projete seus serviços pensando na recuperação de falhas. Na AWS, projetamos os serviços para minimizar o tempo para recuperação de falhas e o impacto sobre os dados. Nossos serviços usam principalmente datastores que reconhecem solicitações apenas após serem armazenadas de modo durável entre várias réplicas em uma região. Eles são criados para usar isolamento com base em células e usar o isolamento de falhas fornecido por zonas de disponibilidade. Usamos automação extensivamente em nossos procedimentos operacionais. Também otimizamos nossa funcionalidade de substituir e reiniciar para a recuperação rápida de interrupções.
Os padrões e os designs que permitem o failover variam para cada serviço de plataforma da AWS. Muitos serviços gerenciados nativos da AWS são nativamente várias zonas de disponibilidade (como o Lambda ou o API Gateway). Outros serviços da AWS (como EC2 e EKS) exigem designs específicos de práticas recomendadas para oferecer compatibilidade com o failover de recursos ou armazenamento de dados entre AZs.
O monitoramento deve ser configurado para conferir se o recurso de failover está íntegro, rastrear o andamento do failover dos recursos e monitorar a recuperação do processo empresarial.
**Resultado desejado:** os sistemas são capazes de usar novos recursos de forma automática ou manual para se recuperarem da degradação.
**Práticas comuns que devem ser evitadas:**
+ Planejar o fracasso não faz parte da fase de planejamento e design.
+ O RTO e o RPO não são estabelecidos.
+ Monitoramento insuficiente para detectar falhas nos recursos.
+ Isolamento adequado dos domínios de falha.
+ O failover multirregiões não é considerado.
+ A detecção de falhas é sensível ou agressiva demais ao decidir realizar o failover.
+ Não testar nem validar o design de failover.
+ Executar a automação de autocorreção sem notificar que a reparação era necessária.
+ Falta de um período de amortecimento a fim de evitar o failback cedo demais.
**Benefícios de implementar esta prática recomendada:** é possível criar sistemas mais resilientes que mantenham a confiabilidade em caso de falhas, degradando-se normalmente e se recuperando com rapidez.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** Alto
## Orientação para implementação
Os serviços da AWS como o [Elastic Load Balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-subnets.html) e o [Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-groups.html) ajudam a distribuir a carga entre recursos e zonas de disponibilidade. Portanto, a falha de um recurso individual (como uma instância do EC2) ou o comprometimento de uma zona de disponibilidade podem ser atenuados por meio do desvio do tráfego para os recursos íntegros restantes.
Para workloads multirregiões, os designs são mais complicados. Por exemplo, as réplicas de leitura entre regiões permitem que você implante os dados em várias Regiões da AWS. No entanto, o failover ainda é necessário para promover a réplica de leitura como primária e direcionar seu tráfego para o novo endpoint. O Amazon Route 53, o [Amazon Application Recovery Controller (ARC)](https://aws.amazon.com/application-recovery-controller/), o Amazon CloudFront e o AWS Global Accelerator podem ajudar a direcionar o tráfego nas Regiões da AWS.
Os serviços da AWS como Amazon S3, Lambda, API Gateway, Amazon SQS, Amazon SNS, Amazon SES, Amazon Pinpoint, Amazon ECR, AWS Certificate Manager, EventBridge ou Amazon DynamoDB são implantados automaticamente em várias zonas de disponibilidade pela AWS. Em caso de falha, esses serviços da AWS direcionam automaticamente o tráfego para locais íntegros. Os dados são armazenados de forma redundante em várias zonas de disponibilidade e permanecem disponíveis.
O Multi-AZ é uma opção de configuração para o Amazon RDS, Amazon Aurora, Amazon Redshift, Amazon EKS ou Amazon ECS. A AWS pode direcionar o tráfego para a instância íntegra se o failover for iniciado. Essa ação de failover pode ser realizada pela AWS ou conforme exigido pelo cliente.
Para instâncias do Amazon EC2, o Amazon Redshift, tarefas do Amazon ECS ou pods do Amazon EKS, escolha em quais zonas de disponibilidade deseja fazer a implantação. Em alguns designs, o Elastic Load Balancing fornece a solução para detectar as instâncias nas zonas com problemas de integridade e rotear o tráfego para as instâncias íntegras. O Elastic Load Balancing também pode rotear tráfego para componentes no seu data center on-premises.
No caso de failover de tráfego em várias regiões, o redirecionamento pode utilizar o Amazon Route 53, o Amazon Application Recovery Controller, o AWS Global Accelerator, o Route 53 Private DNS para VPCs ou o CloudFront para oferecer uma maneira de definir domínios da internet e atribuir políticas de roteamento, incluindo verificações de integridade, e rotear o tráfego para regiões íntegras. O AWS Global Accelerator fornece endereços IP estáticos que atuam como um ponto de entrada fixo para a aplicação e, depois, são roteados para os endpoints nas Regiões da AWS de sua escolha, usando a rede global da AWS em vez da internet com o objetivo de melhorar a performance e a confiabilidade.
### Etapas de implementação
+ Crie designs de failover para todas as aplicações e serviços apropriados. Isole cada componente da arquitetura e crie designs de failover que atendam ao RTO e ao RPO de cada componente.
+ Configure ambientes inferiores (como desenvolvimento ou teste) com todos os serviços necessários para ter um plano de failover. Implemente as soluções usando a infraestrutura como código (IaC) para garantir repetibilidade.
+ Configure um local de recuperação, como uma segunda região, para implementar e testar os designs de failover. Se necessário, os recursos para testes podem ser configurados temporariamente para limitar os custos adicionais.
+ Determine quais planos de failover são automatizados pela AWS, quais podem ser automatizados por um processo de DevOps e quais podem ser manuais. Documente e avalie o RTO e o RPO de cada serviço.
+ Crie um playbook de failover e inclua todas as etapas para realizar o failover de cada recurso, aplicação e serviço.
+ Crie um playbook de failback e inclua todas as etapas de failback (com tempo) de cada recurso, aplicação e serviço.
+ Crie um plano para iniciar e ensaiar o playbook. Use simulações e testes de caos para testar a automação e as etapas do playbook.
+ Para falhas de localização (como zona de disponibilidade ou Região da AWS), garanta que você tenha sistemas implementados para realizar failover para recursos íntegros em locais que não apresentam problemas. Confira a cota, os níveis de ajuste de escala automático e os recursos em execução antes do teste de failover.
## Recursos
**Práticas recomendadas do Well-Architected relacionadas:**
+ [REL13: planejar para DR](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-for-disaster-recovery-dr.html)
+ [REL10: usar o isolamento de falhas para proteger a workload](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/use-fault-isolation-to-protect-your-workload.html)
**Documentos relacionados:**
+ [Definir metas de RTO e RPO](https://aws.amazon.com/blogs/mt/establishing-rpo-and-rto-targets-for-cloud-applications/)
+ [Failover usando o roteamento ponderado do Route 53](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-2-multi-region-stack)
+ [Disaster Recovery with Amazon Route 53 Application Recovery Controller (ARC)](https://catalog.us-east-1.prod.workshops.aws/workshops/4d9ab448-5083-4db7-bee8-85b58cd53158/en-US/)
+ [EC2 com ajuste de escala automático](https://github.com/adriaanbd/aws-asg-ecs-starter)
+ [Implantações do EC2: Multi-AZ](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
+ [Implantações do ECS: Multi-AZ](https://github.com/aws-samples/ecs-refarch-cloudformation)
+ [Switch traffic using Amazon Application Recovery Controller](https://docs.aws.amazon.com/r53recovery/latest/dg/routing-control.failover-different-accounts.html)
+ [Lambda com um Application Load Balancer e failover](https://docs.aws.amazon.com/lambda/latest/dg/services-alb.html)
+ [Replicação e failover do ACM](https://github.com/aws-samples/amazon-ecr-cross-region-replication)
+ [Replicação e failover do repositório de parâmetros](https://medium.com/devops-techable/how-to-design-an-ssm-parameter-store-for-multi-region-replication-support-aws-infrastructure-db7388be454d)
+ [Replicação entre regiões e failover do ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/registry-settings-configure.html)
+ [Configuração da replicação entre regiões do Secrets Manager](https://disaster-recovery.workshop.aws/en/labs/basics/secrets-manager.html)
+ [Habilitar a replicação entre regiões para EFS e failover](https://aws.amazon.com/blogs/aws/new-replication-for-amazon-elastic-file-system-efs/)
+ [Replicação entre regiões e failover do EFS](https://aws.amazon.com/blogs/storage/transferring-file-data-across-aws-regions-and-accounts-using-aws-datasync/)
+ [Failover de rede](https://docs.aws.amazon.com/whitepapers/latest/hybrid-connectivity/aws-dx-dxgw-with-vgw-multi-regions-and-aws-public-peering.html)
+ [Failover de endpoint do S3 usando MRAP](https://catalog.workshops.aws/s3multiregionaccesspoints/en-US/0-setup/1-review-mrap)
+ [Criar replicação entre regiões para o S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html)
+ [Guidance for Cross Region Failover and Graceful Failback on AWS](https://d1.awsstatic.com/solutions/guidance/architecture-diagrams/cross-region-failover-and-graceful-failback-on-aws.pdf)
+ [Failover com o acelerador global multirregiões](https://aws.amazon.com/blogs/networking-and-content-delivery/deploying-multi-region-applications-in-aws-using-aws-global-accelerator/)
+ [Failover com DRS](https://docs.aws.amazon.com/drs/latest/userguide/failback-overview.html)
**Exemplos relacionados:**
+ [Recuperação de desastres na AWS](https://disaster-recovery.workshop.aws/en/)
+ [Recuperação elástica de desastres na AWS](https://catalog.us-east-1.prod.workshops.aws/workshops/080af3a5-623d-4147-934d-c8d17daba346/en-US)
# REL11-BP03 Automatizar a reparação em todas as camadas
Após a detecção de uma falha, use recursos automatizados para executar ações de correção. As degradações podem ser corrigidas automaticamente por meio de mecanismos internos de serviço ou exigir que os recursos sejam reiniciados ou removidos por meio de ações de remediação.
Para aplicações autogerenciadas e reparação entre regiões, os projetos de recuperação e os processos de recuperação automatizados podem ser extraídos de [práticas recomendadas existentes](https://aws.amazon.com/blogs/architecture/understand-resiliency-patterns-and-trade-offs-to-architect-efficiently-in-the-cloud/).
A capacidade de reiniciar ou remover um recurso é uma ferramenta importante para corrigir falhas. Uma prática recomendada é deixar os serviços sem estado sempre que possível. Isso evita a perda de dados ou disponibilidade na reinicialização do recurso. Na nuvem, você pode (e geralmente deve) substituir todo o recurso (por exemplo, uma instância de computação ou função sem servidor) como parte da reinicialização. A reinicialização em si é uma maneira simples e confiável de se recuperar de falhas. Muitos tipos diferentes de falhas ocorrem em workloads. As falhas podem ocorrer em hardware, software, comunicações e operações.
Reiniciar ou tentar novamente também se aplica às solicitações de rede. Aplique a mesma abordagem de recuperação tanto a um tempo limite de rede quanto a uma falha de dependência em que a dependência retorna um erro. Ambos os eventos têm um efeito similar sobre o sistema. Assim, em vez de tentar tornar qualquer um dos eventos um caso especial, aplique uma estratégia similar de nova tentativa limitada com recuo exponencial e jitter. A capacidade de reiniciar é um mecanismo de recuperação presente na computação orientada para a recuperação e arquiteturas de cluster de alta disponibilidade.
**Resultado desejado:** ações automatizadas são executadas para corrigir a detecção de uma falha.
**Práticas comuns que devem ser evitadas:**
+ Provisionamento de recursos sem dimensionamento automático.
+ Implantação de aplicações em instâncias ou contêineres individualmente.
+ Implantação de aplicações que não podem ser implantadas em vários locais sem usar a recuperação automática.
+ Reparação manual de aplicações que não são reparadas por meio do ajuste de escala automático e da recuperação automática.
+ Sem automação para failover dos bancos de dados.
+ Não há métodos automatizados para redirecionar o tráfego para novos endpoints.
+ Sem replicação de armazenamento.
**Benefícios de implementar esta prática recomendada:** a reparação automatizada pode reduzir seu tempo médio de recuperação e melhorar sua disponibilidade.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** Alto
## Orientação para implementação
Os designs para Amazon EKS ou outros serviços do Kubernetes devem incluir conjuntos mínimos e máximos de réplicas ou com estado e tamanho mínimo do cluster e do grupo de nós. Esses mecanismos fornecem uma quantidade mínima de recursos de processamento continuamente disponíveis e, ao mesmo tempo, remediam automaticamente quaisquer falhas usando o ambiente de gerenciamento do Kubernetes.
Os padrões de design que são acessados por meio de um balanceador de carga usando clusters de computação devem utilizar grupos do Auto Scaling. O Elastic Load Balancing (ELB) distribui automaticamente o tráfego de entrada das aplicações entre vários destinos e appliances virtuais em uma ou mais Zonas de Disponibilidade (AZs).
Designs baseados em computação em cluster que não usam balanceamento de carga devem ter seu tamanho projetado para a perda de pelo menos um nó. Isso permitirá que o serviço se mantenha funcionando em uma capacidade potencialmente reduzida enquanto recupera um novo nó. Exemplos de serviços são Mongo, DynamoDB Accelerator, Amazon Redshift, Amazon EMR, Cassandra, Kafka, MSK-EC2, Couchbase, ELK e Amazon OpenSearch Service. Muitos desses serviços podem ser projetados com recursos adicionais de recuperação automática. Algumas tecnologias de cluster devem gerar um alerta sobre a perda de um nó acionando um fluxo de trabalho automatizado ou manual para recriar um novo nó. Esse fluxo de trabalho pode ser automatizado usando o AWS Systems Manager para corrigir problemas rapidamente.
É possível usar o Amazon EventBridge para monitorar e filtrar eventos, como alarmes do CloudWatch ou alterações no estado de outros serviços da AWS. Com base nas informações do evento, ele pode invocar o AWS Lambda, o Systems Manager Automation (ou outros destinos) para executar a lógica de correção personalizada na workload. O Amazon EC2 Auto Scaling pode ser configurado para verificar a integridade da instância do EC2. Se a instância estiver em qualquer estado que não seja em execução, ou se o status do sistema for prejudicado, o Amazon EC2 Auto Scaling considerará a instância como não íntegra e iniciará uma instância de substituição. Para substituições em grande escala (como a perda de uma zona de disponibilidade inteira), a estabilidade estática é preferida para alta disponibilidade.
### Etapas de implementação
+ Use grupos do Auto Scaling para implantar camadas em uma workload. O [Auto Scaling](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html) pode executar a autocorreção em aplicações sem estado e adicionar e remover capacidade.
+ Para instâncias computacionais mencionadas anteriormente, use o [balanceamento de carga](https://docs.aws.amazon.com/autoscaling/ec2/userguide/autoscaling-load-balancer.html) e escolha o tipo apropriado de balanceador de carga.
+ Considere a possibilidade de reparação do Amazon RDS. Com instâncias em espera, configure o [failover automático](https://repost.aws/questions/QU4DYhqh2yQGGmjE_x0ylBYg/what-happens-after-failover-in-rds) para a instância em espera. Para a réplica de leitura do Amazon RDS, é necessário um fluxo de trabalho automatizado para transformar uma réplica de leitura em primária.
+ Implemente a [recuperação automática em instâncias do EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html) que tenham aplicações implantadas que não possam ser implantadas em vários locais e possam tolerar a reinicialização em caso de falhas. É possível usar a recuperação automática para substituir o hardware com falha e reiniciar a instância quando a aplicação não puder ser implantada em vários locais. Os metadados e os endereços IP associados da instância são mantidos, assim como os [volumes do EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html) e os pontos de montagem para [Amazon Elastic File Systems](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEFS.html) ou [File Systems para Lustre](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html) e [Windows](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html). Com o [AWS OpsWorks](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html), é possível configurar a autocorreção das instâncias do EC2 no nível da camada.
+ Implemente a recuperação automatizada por meio do [AWS Step Functions](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html) e do [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) quando não for possível usar o ajuste de escala automático ou a recuperação automática, ou quando a recuperação automática falhar. Quando não for possível usar o ajuste de escala automático e a recuperação automática ou quando a recuperação automática falhar, você poderá automatizar a reparação usando o AWS Step Functions e o AWS Lambda.
+ É possível usar o [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html) para monitorar e filtrar eventos, como [alarmes do CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) ou alterações no estado de outros serviços da AWS. Com base nas informações do evento, ele pode invocar o AWS Lambda (ou outros destinos) para executar a lógica de correção personalizada na workload.
## Recursos
**Práticas recomendadas relacionadas:**
+ [Definição de disponibilidade](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+ [REL11-BP01 Monitorar todos os componentes da workload para detectar falhas](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_notifications_sent_system.html)
**Documentos relacionados:**
+ [Como o AWS Auto Scaling funciona](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ [Recuperação automática do Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html)
+ [Amazon Elastic Block Store (Amazon EBS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html)
+ [Amazon Elastic File System (Amazon EFS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEFS.html)
+ [O que é o Amazon FSx para Lustre?](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html)
+ [O que é o Amazon FSx para Windows File Server?](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html)
+ [AWS OpsWorks: Como usar a reparação automática para substituir instâncias com falha](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html)
+ [O que é o AWS Step Functions?](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)
+ [O que é o AWS Lambda?](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)
+ [O que é o Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Usar alarmes do Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Failover do Amazon RDS](https://d1.awsstatic.com/rdsImages/IG1_RDS1_AvailabilityDurability_Final.pdf)
+ [SSM: Systems Manager Automation](https://docs.aws.amazon.com/resilience-hub/latest/userguide/integrate-ssm.html)
+ [Práticas recomendadas de arquitetura resiliente](https://aws.amazon.com/blogs/architecture/understand-resiliency-patterns-and-trade-offs-to-architect-efficiently-in-the-cloud/)
**Vídeos relacionados:**
+ [Provisionar e escalar automaticamente o serviço OpenSearch](https://www.youtube.com/watch?v=GPQKetORzmE)
+ [Failover automático do Amazon RDS](https://www.youtube.com/watch?v=Mu7fgHOzOn0)
**Exemplos relacionados:**
+ [Workshop Failover do Amazon RDS](https://catalog.workshops.aws/resilient-apps/en-US/rds-multi-availability-zone/failover-db-instance)
**Ferramentas relacionadas:**
+ [CloudWatch](https://aws.amazon.com/cloudwatch/)
+ [CloudWatch X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/security-logging-monitoring.html)
# REL11-BP04 Confiar no plano de dados, e não no ambiente de gerenciamento, durante a recuperação
Os ambientes de gerenciamento fornecem as APIs administrativas usadas para criar, ler e descrever, atualizar, excluir e listar recursos (CRUDL), enquanto os planos de dados lidam com o tráfego diário de serviços. Ao implementar respostas de recuperação ou mitigação a eventos potencialmente impactantes na resiliência, concentre-se em usar um número mínimo de operações do ambiente de gerenciamento para recuperar, redimensionar, restaurar, reparar ou realizar o failover do serviço. A ação do plano de dados deve substituir qualquer atividade durante esses eventos de degradação.
Por exemplo, estas são ações do ambiente de gerenciamento: iniciar uma nova instância de computação, criar armazenamento em bloco e descrever serviços de fila. Quando você executa instâncias de computação, o ambiente de gerenciamento precisa realizar várias tarefas, como encontrar um host físico com capacidade, alocar interfaces de rede, preparar volumes de armazenamento em blocos locais, gerar credenciais e adicionar regras de segurança. Os ambientes de gerenciamento tendem a ser uma orquestração complicada.
**Resultado desejado:** quando um recurso entra em um estado comprometido, o sistema é capaz de se recuperar automática ou manualmente, transferindo o tráfego de recursos danificados para recursos saudáveis.
**Práticas comuns que devem ser evitadas:**
+ Dependência da alteração dos registros DNS para redirecionar o tráfego.
+ Dependência das operações de escalação do ambiente de gerenciamento para substituir componentes danificados devido a recursos insuficientemente provisionados.
+ Dependência de ações de ambiente de gerenciamento abrangentes, com vários serviços e várias APIs para remediar qualquer categoria de deficiência.
**Benefícios de implementar esta prática recomendada:** o aumento da taxa de sucesso da remediação automatizada pode reduzir seu tempo médio de recuperação e melhorar a disponibilidade da workload.
**Nível de risco exposto se essa prática recomendada não for estabelecida:** Médio. Para certos tipos de degradação do serviço, os ambientes de gerenciamento são afetados. As dependências do uso extensivo do ambiente de gerenciamento para remediação podem aumentar o tempo de recuperação (RTO) e o tempo médio de recuperação (MTTR).
## Orientação para implementação
Para limitar as ações do plano de dados, avalie cada serviço quanto às ações necessárias para restaurar o serviço.
Utilize o Amazon Application Recovery Controller para mudar o tráfego de DNS. Esses recursos monitoram continuamente a capacidade da aplicação de se recuperar de falhas, permitindo que você controle a recuperação da aplicação em várias Regiões da AWS, Zonas de Disponibilidade e ambientes on-premises.
As políticas de roteamento do Route 53 usam o ambiente de gerenciamento. Portanto, não confie nele para recuperação. Os planos de dados do Route 53 respondem às consultas ao DNS, além de realizarem e avaliarem verificações de integridade. Eles são distribuídos globalmente e projetados para um [acordo de serviço (SLA) com 100% de disponibilidade](https://aws.amazon.com/route53/sla/).
As APIs e os consoles de gerenciamento do Route 53 usados para criar, atualizar e excluir recursos do Route 53 são executados em ambientes de gerenciamento projetados para priorizar a consistência e a durabilidade necessária para gerenciar o DNS. Para que isso aconteça, os ambientes de gerenciamento estão localizados em uma única região: Leste dos EUA (Norte da Virgínia). Embora ambos os sistemas sejam construídos para serem muito confiáveis, os ambientes de gerenciamento não estão incluídos no SLA. Pode ser que ocorram raros eventos onde o design resiliente do plano de dados permita que ele mantenha a disponibilidade, enquanto os ambientes de gerenciamento não. Para mecanismos de recuperação de desastres e failover, use funções de plano de dados para fornecer a melhor confiabilidade possível.
Projete sua infraestrutura de computação de modo que ela seja estaticamente estável para evitar o uso do ambiente de gerenciamento durante um incidente. Por exemplo, se você estiver usando instâncias do Amazon EC2, evite provisionar novas instâncias manualmente ou instruir grupos do Auto Scaling a adicionar instâncias em resposta. Para obter os níveis mais altos de resiliência, provisione capacidade suficiente no cluster usado para failover. Se essa capacidade precisar ser limitada, defina valores no sistema geral completo para definir com segurança o tráfego total que atinge o conjunto limitado de recursos.
Para serviços como Amazon DynamoDB, Amazon API Gateway, balanceadores de carga e AWS Lambda sem servidor, a utilização desses serviços faz uso do plano de dados. No entanto, criar novas funções, balanceadores de carga, API gateways ou tabelas do DynamoDB é uma ação do ambiente de gerenciamento e deve ser concluída antes da degradação, como preparação para um evento e ensaio das ações de failover. Para o Amazon RDS, as ações do plano de dados permitem o acesso aos dados.
Para obter mais informações sobre planos de dados, ambientes de gerenciamento e como a AWS cria serviços para atender às metas de alta disponibilidade, consulte o whitepaper [Estabilidade estática usando zonas de disponibilidade](https://aws.amazon.com/builders-library/static-stability-using-availability-zones/).
Entenda quais operações estão no plano de dados e quais estão no ambiente de gerenciamento.
### Etapas de implementação
Para cada workload que precisa ser restaurada após um evento de degradação, avalie o runbook de failover, o projeto de alta disponibilidade, o projeto de recuperação automática ou o plano de restauração de recursos de HA. Identifique cada ação que pode ser considerada uma ação do ambiente de gerenciamento.
Considere alterar a ação de gerenciamento para uma ação do plano de dados:
+ Auto Scaling (ambiente de gerenciamento) para recursos do Amazon EC2 pré-escalados (plano de dados)
+ Ajuste de escala de instâncias do Amazon EC2 (ambiente de gerenciamento) para ajuste de escala do AWS Lambda (plano de dados)
+ Avalie qualquer design usando o Kubernetes e a natureza das ações do ambiente de gerenciamento. Adicionar pods é uma ação do plano de dados no Kubernetes. As ações devem se limitar à adição de pods e não adição de nós. Usar [nós superprovisionados](https://www.eksworkshop.com/docs/autoscaling/compute/cluster-autoscaler/overprovisioning/) é o método preferido para limitar as ações do ambiente de gerenciamento
Considere abordagens alternativas que permitam que as ações do plano de dados afetem a mesma remediação.
+ Alteração de registro do Route 53 (ambiente de gerenciamento) ou Amazon Application Recovery Controller (plano de dados)
+ [Verificações de integridade do Route 53 para atualizações mais automatizadas](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/)
Se o serviço for essencial, considere alguns serviços em uma região secundária para permitir mais ações no ambiente de gerenciamento e no plano de dados em uma região não afetada.
+ Amazon EC2 Auto Scaling ou Amazon EKS em uma região primária em comparação com Amazon EC2 Auto Scaling ou Amazon EKS em uma região secundária e roteamento de tráfego para região secundária (ação do ambiente de gerenciamento)
+ Faça uma réplica de leitura na primária secundária ou tente a mesma ação na região primária (ação do ambiente de gerenciamento).
## Recursos
**Práticas recomendadas relacionadas:**
+ [Definição de disponibilidade](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+ [REL11-BP01 Monitorar todos os componentes da workload para detectar falhas](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_notifications_sent_system.html)
**Documentos relacionados:**
+ [Parceiro da APN: parceiros que podem ajudar na automação da tolerância a falhas](https://aws.amazon.com/partners/find/results/?keyword=automation)
+ [AWS Marketplace: produtos que podem ser usados para tolerância a falhas](https://aws.amazon.com/marketplace/search/results?searchTerms=fault+tolerance)
+ [Amazon Builders' Library: evitar a sobrecarga em sistemas distribuídos colocando o menor serviço no controle](https://aws.amazon.com/builders-library/avoiding-overload-in-distributed-systems-by-putting-the-smaller-service-in-control/)
+ [API do Amazon DynamoDB (ambiente de gerenciamento e plano de dados)](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.API.html)
+ [Execuções do AWS Lambda](https://docs.aws.amazon.com/whitepapers/latest/security-overview-aws-lambda/lambda-executions.html) (divididas entre o ambiente de gerenciamento e o plano de dados)
+ [AWS Elemental MediaStore Plano de dados de](https://docs.aws.amazon.com/mediastore/latest/apireference/API_Operations_AWS_Elemental_MediaStore_Data_Plane.html)
+ [Building highly resilient applications using Amazon Application Recovery Controller, Part 1: Single-Region stack](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-1-single-region-stack/)
+ [Building highly resilient applications using Amazon Application Recovery Controller, Part 2: Multi-Region stack](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-2-multi-region-stack/)
+ [Criar mecanismos de recuperação de desastres usando o Amazon Route 53](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/)
+ [What is Amazon Application Recovery Controller](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
+ [Ambiente de gerenciamento e plano de dados do Kubernetes](https://aws.amazon.com/blogs/containers/managing-kubernetes-control-plane-events-in-amazon-eks/)
**Vídeos relacionados:**
+ [De volta ao básico: uso da estabilidade estática](https://www.youtube.com/watch?v=gy1RITZ7N7s)
+ [Como criar workloads resilientes em vários sites usando serviços globais da AWS](https://www.youtube.com/watch?v=62ZQHTruBnk)
**Exemplos relacionados:**
+ [Introducing Amazon Application Recovery Controller](https://aws.amazon.com/blogs/aws/amazon-route-53-application-recovery-controller/)
+ [Amazon Builders' Library: evitar a sobrecarga em sistemas distribuídos colocando o menor serviço no controle](https://aws.amazon.com/builders-library/avoiding-overload-in-distributed-systems-by-putting-the-smaller-service-in-control/)
+ [Building highly resilient applications using Amazon Application Recovery Controller, Part 1: Single-Region stack ](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-1-single-region-stack/)
+ [Building highly resilient applications using Amazon Application Recovery Controller, Part 2: Multi-Region stack ](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-2-multi-region-stack/)
+ [Estabilidade estática com zonas de disponibilidade](https://aws.amazon.com/builders-library/static-stability-using-availability-zones/)
**Ferramentas relacionadas:**
+ [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/)
+ [AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/security-logging-monitoring.html)
# REL11-BP05 Usar estabilidade estática para evitar comportamento bimodal
As workloads devem ser estaticamente estáveis e operar somente em um único modo normal. O comportamento bimodal ocorre quando a workload exibe um comportamento diferente nos modos normal e de falha.
Por exemplo, você pode tentar se recuperar de uma falha na zona de disponibilidade iniciando novas instâncias em uma zona de disponibilidade diferente. Isso pode resultar em uma resposta bimodal durante um modo de falha. Em vez disso, você deve criar workloads que sejam estaticamente estáveis e que operem em apenas um modo. Neste exemplo, essas instâncias deveriam ter sido provisionadas na segunda zona de disponibilidade antes da falha. Esse design de estabilidade estática verifica se a workload opera somente em um único modo.
**Resultado desejado:** as workloads não apresentam comportamento bimodal durante os modos normal e de falha.
**Práticas comuns que devem ser evitadas:**
+ Supor que os recursos sempre possam ser provisionados, independentemente do escopo da falha.
+ Tentar adquirir recursos dinamicamente durante uma falha.
+ Não provisionar recursos adequados entre zonas ou regiões até que ocorra uma falha.
+ Pensar em projetos estáticos estáveis somente para recursos computacionais.
**Benefícios de implementar esta prática recomendada:** as workloads executadas com projetos estaticamente estáveis podem ter resultados previsíveis durante eventos normais e de falha.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio
## Orientação para implementação
O comportamento bimodal ocorre quando a workload apresenta um comportamento diferente nos modos normal e de falha (por exemplo, depender da inicialização de novas instâncias se uma zona de disponibilidade falhar). Um exemplo de comportamento bimodal é quando designs estáveis do Amazon EC2 provisionam instâncias suficientes em cada zona de disponibilidade para lidar com a workload se uma AZ for removidas. O Elastic Load Balancing ou o Amazon Route 53 verificariam a integridade para afastar a carga das instâncias danificadas. Depois que o tráfego for deslocado, use o AWS Auto Scaling para substituir de forma assíncrona instâncias da zona com falha e executá-las nas zonas íntegras. A estabilidade estática para implantação de computação (como instâncias ou contêineres do EC2) resulta na mais alta confiabilidade.
![\[Diagrama mostrando a estabilidade estática de instâncias do EC2 em várias zonas de disponibilidade\]](http://docs.aws.amazon.com/pt_br/wellarchitected/latest/framework/images/static-stability.png)
Isso deve ser comparado ao custo desse modelo e ao valor comercial de manter a workload em todos os casos de resiliência. É mais barato provisionar menos capacidade computacional e depender da inicialização de novas instâncias em caso de falha. No entanto, para falhas em grande escala (como um dano regional ou da zona de disponibilidade), essa abordagem é menos eficaz porque depende tanto de um plano operacional quanto de recursos suficientes disponíveis nas zonas ou regiões não afetadas.
A solução também deve comparar a confiabilidade com os custos necessários para a workload. As arquiteturas de estabilidade estática se aplicam a uma variedade de arquiteturas, incluindo instâncias de computação espalhadas por zonas de disponibilidade, designs de réplicas de leitura de banco de dados, designs de cluster do Kubernetes (Amazon EKS) e arquiteturas de failover multirregiões.
Também é possível implementar um design mais estável estaticamente usando mais recursos em cada zona. Ao adicionar mais zonas, você reduz a quantidade de computação adicional necessária para a estabilidade estática.
Um exemplo de comportamento bimodal seria um tempo limite de rede que poderia fazer com que um sistema tentasse atualizar seu próprio estado de configuração por completo. Isso adicionaria uma carga inesperada a outro componente e poderia fazê-lo falhar, resultando em outras consequências inesperadas. Esse ciclo de feedback negativo afeta a disponibilidade da workload. Em vez disso, você pode criar sistemas estaticamente estáveis e operar em apenas um modo. Um design estático estável faria um trabalho constante e sempre atualizaria o estado da configuração em um ritmo fixo. Quando uma chamada falha, a workload usa o valor previamente armazenado em cache e inicia um alarme.
Outro exemplo de comportamento bimodal é permitir que os clientes ignorem o cache da workload em caso de falhas. Essa pode parecer uma solução que acomoda as necessidades do cliente, mas pode alterar significativamente as demandas da workload e provavelmente resultar em falhas.
Avalie workloads importantes para determinar quais workloads exigem esse tipo de projeto de resiliência. Para as que são consideradas críticas, cada componente da aplicação deve ser revisado. Exemplos de tipos de serviço que exigem avaliações de estabilidade estática são:
+ **Computação**: Amazon EC2, EKS-EC2, ECS-EC2, EMR-EC2
+ **Bancos de dados**: Amazon Redshift, Amazon RDS, Amazon Aurora
+ **Armazenamento**: Amazon S3 (zona única), Amazon EFS (montagens), Amazon FSx (montagens)
+ **Balanceadores de carga:** sob determinados designs
### Etapas de implementação
+ Crie sistemas que sejam estaticamente estáveis e que operem em apenas um modo. Nesse caso, provisione instâncias suficientes em cada zona de disponibilidade ou região para lidar com a capacidade da workload se uma zona de disponibilidade ou região for removida. Diversos serviços podem ser usados para roteamento a recursos íntegros, como:
+ [Roteamento de DNS entre regiões](https://docs.aws.amazon.com/whitepapers/latest/real-time-communication-on-aws/cross-region-dns-based-load-balancing-and-failover.html)
+ [Roteamento multirregiões MRAP do Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiRegionAccessPointRequestRouting.html)
+ [AWS Global Accelerator](https://aws.amazon.com/global-accelerator/)
+ [Amazon Application Recovery Controller](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
+ Configure [réplicas de leitura de banco de dados](https://aws.amazon.com/rds/features/multi-az/) para contabilizar a perda de uma única instância principal ou de uma réplica de leitura. Se o tráfego estiver sendo servido por réplicas de leitura, a quantidade em cada zona de disponibilidade e cada região deve ser igual à necessidade geral em caso de falha na zona ou região.
+ Configure dados críticos no armazenamento do Amazon S3 desenvolvido para ser estaticamente estável para dados armazenados em caso de falha na zona de disponibilidade. Se a classe de armazenamento [One Zone-IA do Amazon S3](https://aws.amazon.com/about-aws/whats-new/2018/04/announcing-s3-one-zone-infrequent-access-a-new-amazon-s3-storage-class/) for usada, ela não deverá ser considerada estaticamente estável, pois a perda dessa zona minimiza o acesso a esses dados armazenados.
+ Os [balanceadores de carga](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/disable-cross-zone.html) algumas vezes são configurados incorreta ou intencionalmente para atender a uma zona de disponibilidade específica. Nesse caso, o design estaticamente estável pode envolver a distribuição de uma workload entre várias zonas de disponibilidade em um design mais complexo. O design original pode ser usado para reduzir o tráfego entre zonas por motivos de segurança, latência ou custo.
## Recursos
**Práticas recomendadas do Well-Architected relacionadas:**
+ [Definição de disponibilidade](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+ [REL11-BP01 Monitorar todos os componentes da workload para detectar falhas](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_notifications_sent_system.html)
+ [REL11-BP04 Confiar no plano de dados, e não no ambiente de gerenciamento, durante a recuperação](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_avoid_control_plane.html)
**Documentos relacionados:**
+ [Minimizar dependências em um plano de recuperação de desastres](https://aws.amazon.com/blogs/architecture/minimizing-dependencies-in-a-disaster-recovery-plan/)
+ [Amazon Builders' Library: estabilidade estática usando zonas de disponibilidade](https://aws.amazon.com/builders-library/static-stability-using-availability-zones)
+ [Limites de isolamento de falhas](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/appendix-a---partitional-service-guidance.html)
+ [Estabilidade estática usando zonas de disponibilidade](https://aws.amazon.com/builders-library/static-stability-using-availability-zones)
+ [RDS Multi-AZ](https://aws.amazon.com/rds/features/multi-az/)
+ [Minimizar dependências em um plano de recuperação de desastres](https://aws.amazon.com/blogs/architecture/minimizing-dependencies-in-a-disaster-recovery-plan/)
+ [Roteamento de DNS entre regiões](https://docs.aws.amazon.com/whitepapers/latest/real-time-communication-on-aws/cross-region-dns-based-load-balancing-and-failover.html)
+ [Roteamento multirregiões MRAP do Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiRegionAccessPointRequestRouting.html)
+ [AWS Global Accelerator](https://aws.amazon.com/global-accelerator/)
+ [Amazon Application Recovery Controller](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
+ [Amazon S3 de zona única](https://aws.amazon.com/about-aws/whats-new/2018/04/announcing-s3-one-zone-infrequent-access-a-new-amazon-s3-storage-class/)
+ [Balanceamento de carga entre zonas](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/disable-cross-zone.html)
**Vídeos relacionados:**
+ [Estabilidade estática na AWS: AWS re:Invent 2019: introdução à Amazon Builders' Library (DOP328)](https://youtu.be/sKRdemSirDM?t=704)
# REL11-BP06 Enviar notificações quando os eventos afetarem a disponibilidade
As notificações são enviadas após a detecção de limites violados, mesmo que o evento causado pelo problema tenha sido resolvido automaticamente.
A correção automatizada permite que a workload seja confiável. No entanto, ele também pode ocultar problemas subjacentes que precisam ser resolvidos. Implemente eventos e monitoramento apropriados para que você possa detectar padrões de problemas, incluindo aqueles abordados pela autocorreção, e consiga resolver problemas de causa-raiz.
Os sistemas resilientes são projetados para que os eventos de degradação sejam comunicados imediatamente às equipes apropriadas. Essas notificações devem ser enviadas por meio de um ou vários canais de comunicação.
**Resultado desejado:** os alertas são enviados imediatamente às equipes de operações quando os limites são violados. Esses alertas podem incluir taxas de erro, latência ou outras métricas importantes de indicadores-chave de performance (KPI), permitindo que esses problemas sejam resolvidos o mais rápido possível e o impacto do usuário seja evitado ou minimizado.
**Práticas comuns que devem ser evitadas:**
+ Enviar muitos alarmes.
+ Enviar alarmes não acionáveis.
+ Definir limites de alarme muito altos (supersensíveis) ou muito baixos (subsensíveis).
+ Não enviar alarmes para dependências externas.
+ Não considerar [falhas cinzentas](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/gray-failures.html) ao projetar monitoramento e alarmes.
+ Executar a automação da correção, mas sem notificar a equipe apropriada de que a correção era necessária.
**Benefícios de implementar esta prática recomendada:** as notificações de recuperação alertam as equipes operacionais e empresariais sobre as degradações do serviço para que elas possam reagir imediatamente a fim de minimizar o tempo médio de detecção (MTTD) e o tempo médio de reparo (MTTR). As notificações de eventos de recuperação também garantem que você não ignore problemas que ocorrem com pouca frequência.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio A falha na implementação de mecanismos adequados de monitoramento e notificação de eventos pode resultar em falha na detecção de padrões de problemas, incluindo aqueles resolvidos pela recuperação automática. Uma equipe só será informada da degradação do sistema quando os usuários entrarem em contato com o atendimento ao cliente ou por acaso.
## Orientação para implementação
Ao definir uma estratégia de monitoramento, um alarme acionado é um evento comum. Esse evento provavelmente conteria um identificador para o alarme, o estado do alarme (como `IN ALARM` e `OK`) e detalhes sobre o que o acionou. Em muitos casos, um evento de alarme deve ser detectado e uma notificação por e-mail deve ser enviada. Este é um exemplo de uma ação em um alarme. A notificação do alarme é fundamental para a observabilidade, pois informa às pessoas certas que há um problema. No entanto, quando a ação sobre eventos amadurece em sua solução de observabilidade, ela pode corrigir automaticamente o problema sem a necessidade de intervenção humana.
Depois que os alarmes de monitoramento de KPI forem estabelecidos, os alertas deverão ser enviados às equipes apropriadas quando os limites forem excedidos. Esses alertas também podem ser usados para acionar processos automatizados que tentarão remediar a degradação.
Para um monitoramento de limites mais complexo, considere usar alarmes compostos. Eles usam vários alarmes de monitoramento de KPI para criar um alerta com base na lógica operacional de negócios. Os alarmes do CloudWatch podem ser configurados para enviar e-mails ou registrar incidentes em sistemas de rastreamento de incidentes de terceiros usando a integração com o Amazon SNS ou Amazon EventBridge.
### Etapas de implementação
Crie vários tipos de alarme com base na forma como as workloads são monitoradas, por exemplo:
+ Os alarmes de aplicações são usados para detectar quando alguma parte da workload não está funcionando adequadamente.
+ Os [alarmes de infraestrutura](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) indicam quando escalar os recursos. Os alarmes podem ser exibidos visualmente em painéis, enviar alertas via Amazon SNS ou e-mail e trabalhar com o Auto Scaling para aumentar ou reduzir a escala dos recursos da workload.
+ [Alarmes estáticos](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html) de exemplo podem ser criados para monitorar quando uma métrica ultrapassa um limite estático durante um número específico de períodos de avaliação.
+ Os [alarmes compostos](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Composite_Alarm.html) podem representar alarmes complexos de várias origens.
+ Depois que o alarme for criado, crie eventos de notificação apropriados. Você pode invocar diretamente uma [API do Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) para enviar notificações e vincular qualquer automação para remediação ou comunicação.
+ Mantenha-se a par das degradações de serviço por meio do [AWS Health](https://aws.amazon.com/premiumsupport/technology/aws-health/). [Crie notificações de eventos do AWS Health ajustadas à finalidade](https://docs.aws.amazon.com/health/latest/ug/user-notifications.html) para canais de e-mail e chat por meio do [Notificações de Usuários da AWS](https://docs.aws.amazon.com/notifications/latest/userguide/what-is-service.html) e integre-as programaticamente às [suas ferramentas de monitoramento e alerta por meio do Amazon EventBridge](https://docs.aws.amazon.com/health/latest/ug/cloudwatch-events-health.html).
## Recursos
**Práticas recomendadas do Well-Architected relacionadas:**
+ [Definição de disponibilidade](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
**Documentos relacionados:**
+ [Criar um alarme do CloudWatch com base em um limite estático](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html)
+ [O que é o Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [O que é o Amazon Simple Notification Service?](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)
+ [Publicar métricas personalizadas](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ [Usar alarmes do Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Configurar alarmes do CloudWatch Composite](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Composite_Alarm.html)
+ [Novidades no AWS Observability na re:Invent 2022](https://aws.amazon.com/blogs/mt/whats-new-in-aws-observability-at-reinvent-2022/)
**Ferramentas relacionadas:**
+ [CloudWatch](https://aws.amazon.com/cloudwatch/)
+ [CloudWatch X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/security-logging-monitoring.html)
# REL11-BP07 Arquitetar o produto para cumprir as metas de disponibilidade e os acordos de serviço (SLAs) de tempo de atividade
Arquitete o produto para cumprir as metas de disponibilidade e os acordos de serviço (SLAs) de tempo de atividade. Se você publicar ou concordar de forma privada com as metas de disponibilidade ou SLAs de tempo de atividade, verifique se sua arquitetura e seus processos operacionais foram projetados para comportá-los.
**Resultado desejado:** cada aplicação tem uma meta definida de disponibilidade e um SLA para métricas de performance, as quais podem ser monitoradas e mantidas para atingir os resultados comerciais.
**Práticas comuns que devem ser evitadas:**
+ Planejar e implantar workloads sem definir SLAs.
+ As métricas de SLA são definidas muito altas sem justificativas ou requisitos comerciais.
+ Definir SLAs sem considerar as dependências e o SLA subjacente.
+ Os designs das aplicações são criados sem considerar o modelo de responsabilidade compartilhada para resiliência.
**Benefícios de implementar esta prática recomendada:** desenvolver aplicações com base nas principais metas de resiliência ajuda a atingir os objetivos de negócios e as expectativas dos clientes. Esses objetivos ajudam a orientar o processo de design da aplicação que avalia diferentes tecnologias e considera as vantagens e desvantagens.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio
## Orientação para implementação
Os designs da aplicação precisam levar em conta um conjunto de requisitos diversos que são derivados de objetivos empresariais, operacionais e financeiros. Nos requisitos operacionais, as workloads precisam ter metas de métricas de resiliência específicas para que possam ser monitorados e comportados adequadamente. As métricas de resiliência não devem ser definidas nem derivadas depois de implantar a workload. Elas devem ser definidas durante a fase de design e ajudar a orientar as diversas decisões e concessões.
+ Cada workload deve ter seu próprio conjunto de métricas de resiliência. Essas métricas podem ser diferentes de outras aplicações empresariais.
+ Reduzir as dependências pode ter um impacto positivo na disponibilidade. Cada workload deve considerar suas dependências e seus SLAs. Em geral, escolha dependências com metas de disponibilidade iguais ou maiores que as metas da workload.
+ Considere designs com acoplamento fraco para que a workload possa operar corretamente apesar do comprometimento da dependência, quando possível.
+ Reduza as dependências do ambiente de gerenciamento, especialmente durante uma recuperação ou degradação. Avalie os designs estaticamente estáveis com relação às workloads essenciais à missão. Use a economia de recursos para aumentar a disponibilidade dessas dependências em uma workload.
+ A capacidade de observação e a instrumentalização são críticas para cumprir os SLAs reduzindo o tempo médio de detecção (MTTD) e o tempo médio de reparo (MTTR).
+ Falhas menos frequentes (MTBF mais longo), tempos de detecção de falhas mais curtos (MTTD mais curto) e tempos de reparo mais curtos (MTTR mais curto) são os três fatores usados para melhorar a disponibilidade em sistemas distribuídos.
+ Estabelecer e cumprir métricas de resiliência para uma workload é fundamental para qualquer design eficaz. Esses designs devem levar em consideração as vantagens e desvantagens da complexidade de design, as dependências do serviço, a performance, o ajuste de escala e os custos.
**Etapas de implementação**
+ Analise e documente o design da workload considerando as seguintes questões:
+ Onde os ambientes de gerenciamento são usados na workload?
+ Como a workload implementa tolerância a falhas?
+ Quais são os padrões de design para componentes de ajuste de escala, ajuste de escala automático, redundância e alta disponibilidade?
+ Quais são os requisitos para disponibilidade e consistência de dados?
+ Há considerações quanto à economia de recursos ou estabilidade estática de recursos?
+ Quais são as dependências do serviço?
+ Defina métricas de SLA com base na arquitetura da workload enquanto trabalha com as partes interessadas. Considere os SLAs de todas as dependências usadas pela workload.
+ Quando a meta de SLA for definida, otimize a arquitetura para cumprir o SLA.
+ Quando o design que cumprirá o SLA for definido, implemente mudanças operacionais, automação do processo e runbooks que também terão como foco uma redução de MTTD e MTTR.
+ Depois da implantação, monitore e informe sobre o SLA.
## Recursos
**Práticas recomendadas relacionadas:**
+ [REL03-BP01 Escolher como segmentar a workload](rel_service_architecture_monolith_soa_microservice.md)
+ [REL10-BP01 Implantar a workload em vários locais](rel_fault_isolation_multiaz_region_system.md)
+ [REL11-BP01 Monitorar todos os componentes da workload para detectar falhas](rel_withstand_component_failures_monitoring_health.md)
+ [REL11-BP03 Automatizar a reparação em todas as camadas](rel_withstand_component_failures_auto_healing_system.md)
+ [REL12-BP04 Testar a resiliência com engenharia do caos](rel_testing_resiliency_failure_injection_resiliency.md)
+ [REL13-BP01 Definir os objetivos de recuperação para tempo de inatividade e perda de dados](rel_planning_for_recovery_objective_defined_recovery.md)
+ [Como a integridade da workload funciona](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/understanding-workload-health.html)
**Documentos relacionados:**
+ [Disponibilidade com redundância](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/availability-with-redundancy.html)
+ [Pilar Confiabilidade: disponibilidade](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+ [Como medir a disponibilidade](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/measuring-availability.html)
+ [Limites de isolamento de falhas da AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/abstract-and-introduction.html)
+ [Modelo de responsabilidade compartilhada para resiliência](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/shared-responsibility-model-for-resiliency.html)
+ [Estabilidade estática com zonas de disponibilidade](https://aws.amazon.com/builders-library/static-stability-using-availability-zones/)
+ [Acordos de serviço (SLAs) da AWS](https://aws.amazon.com/legal/service-level-agreements/)
+ [Orientação para arquitetura baseada em células na AWS](https://aws.amazon.com/solutions/guidance/cell-based-architecture-on-aws/)
+ [Infraestrutura da AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/aws-infrastructure.html)
+ [Whitepaper Padrões avançados de resiliência multi-AZ](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/advanced-multi-az-resilience-patterns.html)
**Serviços relacionados:**
+ [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/)
+ [AWS Config](https://aws.amazon.com/config/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)
# REL 12. Como testar a confiabilidade?
Depois de projetar a workload para resiliência à pressão da produção, o teste é a única maneira de garantir que ela opere conforme projetado e com a resiliência esperada.
**Topics**
+ [REL12-BP01 Usar playbooks para investigar falhas](rel_testing_resiliency_playbook_resiliency.md)
+ [REL12-BP02 Realizar análises pós-incidentes](rel_testing_resiliency_rca_resiliency.md)
+ [REL12-BP03 Testar os requisitos de escalabilidade e desempenho](rel_testing_resiliency_test_non_functional.md)
+ [REL12-BP04 Testar a resiliência com engenharia do caos](rel_testing_resiliency_failure_injection_resiliency.md)
+ [REL12-BP05 Conduzir dias de jogo regularmente](rel_testing_resiliency_game_days_resiliency.md)
# REL12-BP01 Usar playbooks para investigar falhas
Documente o processo de investigação em playbooks para permitir respostas consistentes e rápidas em cenários de falha. Os playbooks consistem em etapas predefinidas executadas para identificar os fatores que contribuem para um cenário de falha. Os resultados de qualquer etapa do processo são usados para determinar as próximas etapas a serem seguidas até que o problema seja identificado ou escalado.
O playbook é um planejamento proativo que deve ser feito para poder executar ações reativas com eficácia. Quando cenários de falha não cobertos pelo playbook forem encontrados na produção, aborde o problema primeiro ("apague o fogo"). Em seguida, volte e veja as etapas que você seguiu para resolver o problema e use-as para adicionar uma nova entrada no playbook.
Observe que os playbooks são usados em resposta a incidentes específicos, enquanto runbooks são usados para alcançar resultados específicos. Muitas vezes, os runbooks são usados para atividades de rotina e os playbooks são usados para responder a eventos que não são rotineiros.
**Práticas comuns que devem ser evitadas:**
+ Planejar a implantação de uma workload sem conhecer os processos para diagnosticar problemas ou responder a incidentes.
+ Decisões não planejadas de quais sistemas coletar logs e métricas ao investigar um evento.
+ Não armazenar as métricas e os eventos por tempo suficiente para recuperar os dados.
**Benefícios de implementar esta prática recomendada:** capturar playbooks garante que os processos possam ser seguidos de forma consistente. A codificação dos seus playbooks limita a introdução de erros por atividades manuais. A automação dos playbooks reduz o tempo de resposta a um evento ao eliminar a necessidade de intervenção de membros da equipe ou ao fornecer a eles informações adicionais desde o início da intervenção.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** Alto
## Orientação para implementação
+ Use playbooks para identificar problemas. Os playbooks são processos documentados para investigar problemas. Documente os processos em playbooks para permitir respostas consistentes e rápidas em cenários de falha. Os playbooks devem incluir as informações e as diretrizes necessárias para que uma pessoa com as devidas qualificações colete as informações aplicáveis, identifique possíveis fontes de falha, isole as falhas e determine os fatores contribuintes (ou seja, faça uma análise pós-incidente).
+ Implemente playbooks como código. Execute suas operações como código ao criar scripts de seus playbooks para garantir a consistência e reduzir os erros causados por processos manuais. Os playbooks podem ser compostos por vários scripts representando as diferentes etapas que podem ser necessárias para identificar os fatores que contribuem para um problema. As atividades do runbook podem ser acionadas ou executadas como parte das atividades do playbook, ou podem solicitar a execução de um playbook em resposta a eventos identificados.
+ [Automatizar seus playbooks operacionais com o AWS Systems Manager](https://aws.amazon.com/about-aws/whats-new/2019/11/automate-your-operational-playbooks-with-aws-systems-manager/)
+ [AWS Systems Manager Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html)
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [O que é AWS Lambda?](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)
+ [O que é o Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Usar alarmes do Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
## Recursos
**Documentos relacionados:**
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [AWS Systems Manager Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html)
+ [Automatizar seus playbooks operacionais com o AWS Systems Manager](https://aws.amazon.com/about-aws/whats-new/2019/11/automate-your-operational-playbooks-with-aws-systems-manager/)
+ [Usar alarmes do Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Usar canários (Amazon CloudWatch Synthetics)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [O que é o Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [O que é AWS Lambda?](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)
**Exemplos relacionados:**
+ [Automatizar operações com playbooks e runbooks](https://wellarchitectedlabs.com/operational-excellence/200_labs/200_automating_operations_with_playbooks_and_runbooks/)
# REL12-BP02 Realizar análises pós-incidentes
Analise os eventos que afetam o cliente e identifique os fatores contribuintes e os itens de ação preventiva. Use essas informações para desenvolver mitigações e limitar ou evitar recorrência. Desenvolva procedimentos para respostas rápidas e eficazes. Comunique os fatores contribuintes e as ações corretivas conforme apropriado, de acordo com o público-alvo. Tenha um método para comunicar essas causas a outras pessoas, conforme necessário.
Avalie por que os testes existentes não encontraram o problema. Adicione testes para esse caso se os testes ainda não existirem.
**Resultado desejado:** suas equipes têm uma abordagem consistente e consensual para lidar com a análise pós-incidente. Um mecanismo é o [processo de correção de erros (COE)](https://aws.amazon.com/blogs/mt/why-you-should-develop-a-correction-of-error-coe/). O processo de COE ajuda as equipes a identificar, compreender e abordar as causas básicas dos incidentes, ao mesmo tempo que cria mecanismos e barreiras de proteção para limitar a probabilidade do mesmo incidente ocorrer novamente.
**Práticas comuns que devem ser evitadas:**
+ Encontrar fatores contribuintes, mas não continuar buscando mais profundamente outros possíveis problemas e abordagens de mitigação.
+ Identificar apenas as causas de erros humanos e não oferecer nenhum treinamento ou automação que possa evitar erros humanos.
+ Concentrar-se em atribuir a culpa em vez de compreender a causa-raiz, criando uma cultura de medo e impedindo a comunicação aberta.
+ Não compartilhar insights, o que mantém as descobertas da análise de incidentes em um pequeno grupo e impede que outras pessoas se beneficiem das lições aprendidas.
+ Não ter um mecanismo para capturar conhecimento institucional e, dessa forma, perder insights valiosos por não preservar as lições aprendidas na forma de práticas recomendadas atualizadas e resultando em incidentes repetidos com a mesma causa-raiz ou similar.
**Benefícios de implementar esta prática recomendada:** a realização de análises pós-incidentes e o compartilhamento dos resultados permitem que outras workloads atenuem o risco caso tenham implementado os mesmos fatores contribuintes, além de permitir que elas implementem a mitigação ou a recuperação automatizada antes que ocorra um incidente.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** Alto
## Orientação para implementação
Uma boa análise pós-incidente oferece oportunidades para propor soluções comuns a problemas com padrões de arquitetura usados em outros locais nos sistemas.
A base do processo da COE é documentar e resolver problemas. É recomendável definir uma forma padronizada de documentar as causas-raiz essenciais e garantir que elas sejam analisadas e abordadas. Atribua uma propriedade clara ao processo de análise pós-incidente. Atribua uma equipe ou uma pessoa responsável para supervisionar as investigações e o rastreamento de incidentes.
Incentive uma cultura que se concentre no aprendizado e na melhoria, em vez de na atribuição de culpas. Enfatize que a meta é evitar futuros incidentes, não penalizar pessoas.
Desenvolva procedimentos bem definidos para conduzir análises pós-incidentes. Esses procedimentos devem descrever as etapas a serem seguidas, as informações a serem coletadas e as principais questões a serem abordadas durante a análise. Investigue os incidentes minuciosamente, indo além das causas imediatas para identificar as causas-raiz e os fatores contribuintes. Use técnicas como os *[cinco porquês](https://en.wikipedia.org/wiki/Five_whys)* para se aprofundar nos problemas subjacentes.
Mantenha um repositório das lições aprendidas com as análises dos incidentes. Esse conhecimento institucional pode servir como referência para futuros incidentes e iniciativas de prevenção. Compartilhe descobertas e insights de análises pós-incidentes e considere realizar reuniões abertas sobre a revisão pós-incidente para discutir as lições aprendidas.
### Etapas de implementação
+ Ao conduzir a análise pós-incidente, verifique se o processo está livre de culpabilização. Isso permite que as pessoas envolvidas no incidente sejam imparciais com as ações corretivas propostas e promovam uma autoavaliação honesta e a colaboração entre as equipes.
+ Defina uma forma padronizada de documentar problemas essenciais. Um exemplo de estrutura para esse documento é o seguinte:
+ O que aconteceu?
+ Qual foi o impacto nos clientes e em sua empresa?
+ Qual foi a causa-raiz?
+ Quais dados você tem para apoiar isso?
+ Por exemplo, métricas e grafos
+ Quais foram as implicações críticas nos pilares, especialmente em relação à segurança?
+ Ao arquitetar workloads, você faz concessões entre os pilares com base no contexto da sua empresa. Essas decisões comerciais podem determinar suas prioridades de engenharia. Você pode reduzir custos e assim diminuir a confiabilidade em ambientes de desenvolvimento, ou otimizar a confiabilidade e aumentar os custos para soluções importantes. A segurança é sempre prioritária, porque você precisa proteger seus clientes.
+ Que lições você aprendeu?
+ Que ações corretivas você está adotando?
+ Itens de ação
+ Itens relacionados
+ Crie procedimentos operacionais padrão bem definidos para conduzir análises pós-incidentes.
+ Configure um processo padronizado de relatórios de incidentes. Documente todos os incidentes de forma abrangente, incluindo o relatório inicial do incidente, logs, comunicações e ações tomadas durante o incidente.
+ Lembre-se de que um incidente não exige uma interrupção. Por exemplo, uma quase falha ou um sistema que, embora esteja funcionando de forma inesperada, cumpre sua função de negócios.
+ Melhore continuamente o processo de análise pós-incidente com base no feedback e nas lições aprendidas.
+ Capture as principais descobertas em um sistema de gerenciamento de conhecimento e considere os padrões que devem ser adicionados aos guias de desenvolvedor ou às listas de verificação de pré-implantação.
## Recursos
**Documentos relacionados:**
+ [Por que você deve desenvolver uma correção de erro (COE)](https://aws.amazon.com/blogs/mt/why-you-should-develop-a-correction-of-error-coe/)
**Vídeos relacionados:**
+ [A abordagem da Amazon para falhar com sucesso](https://aws.amazon.com/builders-library/amazon-approach-to-failing-successfully/)
+ [AWS re:Invent 2021: Amazon Builders' Library: excelência operacional da Amazon](https://www.youtube.com/watch?v=7MrD4VSLC_w)
# REL12-BP03 Testar os requisitos de escalabilidade e desempenho
Use técnicas como teste de carga para validar se a workload atende aos requisitos de escalabilidade e desempenho.
É possível criar na nuvem um ambiente de teste em escala de produção sob demanda para a workload. Em vez de depender de um ambiente de teste com escala vertical reduzida, o que pode levar a previsões imprecisas dos comportamentos de produção, você pode usar a nuvem para provisionar um ambiente de teste que espelhe o ambiente de produção esperado. Esse ambiente ajuda você a testar em uma simulação mais precisa das condições reais que a aplicação enfrenta.
Além das ações de teste de desempenho, é essencial validar que os recursos básicos, as configurações escalabilidade, as cotas de serviço e o design de resiliência operem conforme o esperado sob carga. Essa abordagem holística verifica se a aplicação pode ser escalada e executada de forma confiável conforme necessário, mesmo sob as condições mais exigentes.
**Resultado desejado:** a workload mantém o comportamento esperado mesmo quando está sujeita a picos de carga. Você aborda proativamente quaisquer problemas relacionados ao desempenho que possam surgir à medida que a aplicação cresce e evolui.
**Práticas comuns que devem ser evitadas:**
+ Usar ambientes de teste que não são muito parecidos com o ambiente de produção.
+ Tratar o teste de carga como uma atividade separada e única, em vez de uma parte integrada do pipeline de integração contínua (CI) da implantação.
+ Não definir requisitos de desempenho claros e mensuráveis, como metas de tempo de resposta, throughput e escalabilidade.
+ Executar testes com cenários de carga irrealistas ou insuficientes e não conseguir testar cargas de pico, picos repentinos e alta carga sustentada.
+ Não testar o estresse da workload excedendo os limites de carga esperados.
+ Usar ferramentas de teste de carga e perfil de desempenho inadequadas ou indevidas.
+ Não ter sistemas abrangentes de monitoramento e alerta para rastrear métricas de desempenho e detectar anomalias.
**Benefícios de implementar essa prática recomendada:**
+ O teste de carga ajuda você a identificar possíveis gargalos de desempenho no sistema antes da entrada em produção. Ao simular tráfego e workloads em nível de produção, você pode identificar áreas em que o sistema pode ter dificuldades para lidar com a carga, como tempos de resposta lentos, restrições de recursos ou falhas do sistema.
+ Ao testar o sistema sob várias condições de carga, você pode entender melhor os requisitos de recursos necessários para oferecer suporte à workload. Essas informações podem ajudar você a tomar decisões informadas sobre a alocação de recursos e evitar o provisionamento excessivo ou insuficiente de recursos.
+ Para identificar possíveis pontos de falha, você pode observar o desempenho da workload em condições de alta carga. Essas informações ajudam você a melhorar a confiabilidade e a resiliência da workload, implementando mecanismos de tolerância a falhas, estratégias de failover e medidas de redundância, conforme apropriado.
+ Você identifica e aborda problemas de desempenho com antecedência, o que ajuda a evitar as consequências dispendiosas de interrupções do sistema, tempos de resposta lentos e usuários insatisfeitos.
+ Dados detalhados de desempenho e informações de perfil coletados durante o teste podem ajudar você a solucionar problemas relacionados ao desempenho que possam surgir na produção. Isso pode proporcionar mais agilidade na resposta e resolução de incidentes, o que reduz o impacto nos usuários e nas operações da organização.
+ Em certos setores, os testes proativos de desempenho podem ajudar a workload a atender aos padrões de conformidade, o que reduz o risco de penalidades ou problemas legais.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** Alto
## Orientação para implementação
A primeira etapa é definir uma estratégia de teste abrangente que cubra todos os aspectos dos requisitos de escalabilidade e desempenho. Para começar, defina claramente os objetivos de nível de serviço (SLOs) da workload com base nas necessidades de empresa, como throughput, histograma de latência e taxa de erros. Depois, crie um conjunto de testes que possa simular vários cenários de carga, que variam de uso médio a picos repentinos e picos contínuos de carga, e verifique se o comportamento da workload atende aos SLOs. Esses testes devem ser automatizados e integrados ao pipeline contínuo de integração e implantação para detectar regressões de desempenho no início do processo de desenvolvimento.
Para testar com eficácia a escalabilidade e o desempenho, invista nas ferramentas e na infraestrutura certas. Isso inclui ferramentas de teste de carga que podem gerar tráfego realista de usuários, ferramentas de perfil de desempenho para identificar gargalos e soluções de monitoramento para rastrear as principais métricas. É importante ressaltar que você deve verificar se os ambientes de teste correspondem perfeitamente ao ambiente de produção em termos de infraestrutura e condições do ambiente para tornar os resultados dos testes o mais precisos possível. Para facilitar a replicação e a escalabilidade confiáveis de configurações semelhantes às de produção, use a infraestrutura como código e aplicações baseadas em contêineres.
Os testes de escalabilidade e desempenho são um processo contínuo, não uma atividade que deve ser realizada uma única vez. Implemente monitoramento e alertas abrangentes para monitorar o desempenho da aplicação em produção e use esses dados para refinar continuamente as estratégias de teste e os esforços de otimização. Analise regularmente os dados de desempenho para identificar problemas emergentes, testar novas estratégias de escalabilidade e implementar otimizações para melhorar a eficiência e a confiabilidade da aplicação. Ao adotar uma abordagem iterativa e aprender constantemente com os dados de produção, você pode verificar se a aplicação pode se adaptar às demandas variáveis do usuário e manter a resiliência e o desempenho ideal ao longo do tempo.
### Etapas de implementação
1. Estabeleça requisitos de desempenho claros e mensuráveis, como metas de tempo de resposta, throughput e escalabilidade. Esses requisitos devem se basear nos padrões de uso da workload, nas expectativas dos usuários e nas necessidades comerciais.
1. Selecione e configure uma ferramenta de teste de carga que possa imitar com precisão os padrões de carga e o comportamento do usuário no ambiente de produção.
1. Configure um ambiente de teste que corresponda perfeitamente ao ambiente de produção, incluindo condições ambientais e de infraestrutura, para melhorar a precisão dos resultados dos testes.
1. Crie um conjunto de testes que cubra uma ampla variedade de cenários, desde padrões de uso médio até picos de carga, picos rápidos e altas cargas contínuas. Integre os testes aos pipelines contínuos de integração e implantação para capturar regressões de desempenho no início do processo de desenvolvimento.
1. Realize testes de carga para simular o tráfego real de usuários e entender como a aplicação se comporta sob diferentes condições de carga. Para testar o estresse da aplicação, exceda a carga esperada e observe o comportamento dela, como degradação do tempo de resposta, esgotamento de recursos ou falhas do sistema, o que ajuda a identificar o ponto de ruptura da aplicação e informar as estratégias de escalabilidade. Avalie a escalabilidade da workload aumentando incrementalmente a carga e meça o impacto no desempenho para identificar limites de escalabilidade e planejar futuras necessidades de capacidade.
1. Implemente monitoramento e alertas abrangentes para rastrear métricas de desempenho, detectar anomalias e iniciar ações ou notificações de escalabilidade quando os limites forem excedidos.
1. Monitore e analise continuamente os dados de desempenho para identificar áreas de melhoria. Itere as estratégias de teste e os esforços de otimização.
## Recursos
**Práticas recomendadas relacionadas:**
+ [REL01-BP04 Monitorar e gerenciar cotas](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_manage_service_limits_monitor_manage_limits.html)
+ [REL06-BP01 Monitorar todos os componentes da workload (geração)](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_monitor_resources.html)
+ [REL06-BP03 Enviar notificações (processamento e emissão de alarmes em tempo real)](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_notification_monitor.html)
**Documentos relacionados:**
+ [Aplicações de teste de carga](https://docs.aws.amazon.com/prescriptive-guidance/latest/load-testing/welcome.html)
+ [Teste de carga distribuída na AWS](https://aws.amazon.com/solutions/implementations/distributed-load-testing-on-aws/)
+ [Monitoramento do desempenho de aplicações](https://aws.amazon.com/what-is/application-performance-monitoring/)
+ [Amazon EC2 Testing Policy](https://aws.amazon.com/ec2/testing/)
**Exemplos relacionados:**
+ [Distributed Load Testing on AWS (GitHub)](https://github.com/aws-solutions/distributed-load-testing-on-aws)
**Ferramentas relacionadas:**
+ [Amazon CodeGuru Profiler](https://docs.aws.amazon.com/codeguru/latest/profiler-ug/what-is-codeguru-profiler.html)
+ [Amazon CloudWatch RUM](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html)
+ [Apache JMeter](https://jmeter.apache.org/)
+ [K6](https://k6.io/)
+ [Vegeta](https://github.com/tsenart/vegeta)
+ [Hey](https://github.com/rakyll/hey)
+ [ab](https://httpd.apache.org/docs/2.4/programs/ab.html)
+ [trabalho](https://github.com/wg/wrk)
+ [Teste de carga distribuída na AWS](https://aws.amazon.com/solutions/implementations/distributed-load-testing-on-aws/)
# REL12-BP04 Testar a resiliência com engenharia do caos
Execute experimentos de caos regularmente em ambientes que estão em produção ou muito próximos de entrar em produção para entender como seu sistema responde a condições adversas.
**Resultado desejado:**
A resiliência da workload é verificada regularmente por meio da aplicação de engenharia do caos na forma de experimentos de injeção de falha ou injeção de carga inesperada, além de testes de resiliência que validam o comportamento conhecido esperado da workload durante um evento. Combine engenharia do caos e testes de resiliência para ter confiança de que sua workload poderá sobreviver à falha de componentes e se recuperar de interferências inesperadas com pouco ou nenhum impacto.
**Práticas comuns que devem ser evitadas:**
+ Projetar para resiliência, mas não verificar como a workload funciona como um todo quando falhas ocorrem.
+ Nunca realizar experimentos sob condições reais e de carga esperada.
+ Não tratar seus experimentos como código nem mantê-los ao longo do ciclo de desenvolvimento.
+ Não realizar experimentos de caos tanto como parte do pipeline de CI/CD quanto fora das implantações.
+ Negar o uso de análises pós-incidentes passadas ao determinar quais falhas usar para realizar experimentos.
**Benefícios de implementar esta prática recomendada:** a injeção de falhas para verificar a resiliência de uma workload permite que você obtenha confiança de que os procedimentos de recuperação de seu design resiliente vão funcionar em caso de falha real.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio
## Orientação para implementação
A engenharia do caos proporciona à sua equipe os recursos para injetar continuamente interferências (simulações) reais de maneira controlada no provedor de serviço, na infraestrutura, na workload e no componente, com pouco ou nenhum impacto para os clientes. Ela permite que as equipes aprendam com as falhas e observem, mensurem e aumentem a resiliência das workloads, além de validar o acionamento de alertas e a notificação das equipes em caso de evento.
Quando realizada continuamente, a engenharia do caos pode destacar deficiências nas workloads que, se não respondidas, podem afetar negativamente a disponibilidade e a operação.
**nota**
A engenharia do caos é a disciplina de experimentar um sistema distribuído para aumentar a confiança na capacidade do sistema de resistir a condições turbulentas na produção. [Princípios da engenharia do caos](https://principlesofchaos.org/)
Se um sistema é capaz de suportar essas interferências, os experimentos de caos devem ser mantidos como testes de regressão automatizados. Dessa forma, os experimentos de caos devem ser realizados como parte do ciclo de vida de desenvolvimento dos sistemas (SDLC) e como parte do pipeline de CI/CD.
Para garantir que sua workload possa sobreviver à falha de componentes, injete eventos reais como parte dos experimentos. Por exemplo, realize experimentos com perda de instâncias do Amazon EC2 ou failover da instância de banco de dados primária do Amazon RDS e verifique se a workload não é afetada (ou apenas minimamente afetada). Use uma combinação de falhas de componentes para simular eventos que podem ser causados por uma interferência em uma zona de disponibilidade.
Para falhas no nível da aplicação (como travamentos), você pode começar com fatores de estresse, como exaustão de memória e CPU.
Para validar os [mecanismos de fallback ou failover](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems/) para dependências externas devido a interferências intermitentes na rede, os componentes devem simular esse tipo de evento bloqueando o acesso aos provedores externos durante um período especificado, que pode variar de segundos a horas.
Outros modos de degradação podem levar a uma redução nas funcionalidades e a respostas lentas, muitas vezes levando a uma interrupção dos serviços. Essa degradação costuma resultar de um aumento na latência de serviços críticos e comunicação de rede não confiável (pacotes abandonados). Experimentos com essas falhas, incluindo efeitos de rede como latência, mensagens perdidas e falhas de DNS, podem incluir a incapacidade de resolver um nome, alcançar o serviço de DNS ou estabelecer conexões com serviços dependentes.
**Ferramentas de engenharia do caos:**
O AWS Fault Injection Service (AWS FIS) é um serviço totalmente gerenciado para a execução de experimentos de injeção de falha que podem ser usados como parte do pipeline de CD, ou fora do pipeline. O AWS FIS é uma boa opção para ser usado durante game days de engenharia de caos. Ele oferece suporte à introdução simultânea de falhas em diferentes tipos de recursos, incluindo Amazon EC2, Amazon Elastic Container Service (Amazon ECS), Amazon Elastic Kubernetes Service (Amazon EKS) e Amazon RDS. Essas falhas incluem encerramento de recursos, failovers forçados, esgotamento de CPU ou memória, controle de utilização, latência e perda de pacotes. Por ser integrado a alarmes do Amazon CloudWatch, é possível definir condições de parada como barreiras de proteção para reverter um experimento se ele causar impacto inesperado.
![\[Diagrama que mostra que o AWS Fault Injection Service se integra a recursos da AWS para permitir a execução de experimentos de injeção de falha para as workloads.\]](http://docs.aws.amazon.com/pt_br/wellarchitected/latest/framework/images/fault-injection-simulator.png)
Existem também várias opções de terceiros para experimentos de injeção de falhas. Isso inclui ferramentas de código aberto, como [Chaos Toolkit](https://chaostoolkit.org/), [Chaos Mesh](https://chaos-mesh.org/) e [Litmus Chaos](https://litmuschaos.io/), além de opções comerciais, como o Gremlin. Para expandir o escopo de falhas que podem ser injetadas na AWS, o AWS FIS [integra-se ao Chaos Mesh e ao Litmus Chaos](https://aws.amazon.com/about-aws/whats-new/2022/07/aws-fault-injection-simulator-supports-chaosmesh-litmus-experiments/), permitindo que você coordene fluxos de trabalho de injeção de falhas entre várias ferramentas. Por exemplo, você pode executar um teste de estresse na CPU de um pod usando falhas do Chaos Mesh ou Litmus enquanto encerra uma porcentagem selecionada aleatoriamente de nós de cluster usando ações de falha do AWS FIS.
## Etapas de implementação
1. Determine quais falhas usar em seus experimentos.
Avalie o design da workload quanto à resiliência. Esses designs (criados usando as práticas recomendadas do [Well-Architected Framework](https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html)) consideram os riscos com base em dependências críticas, eventos passados, problemas conhecidos e requisitos de conformidade. Liste cada elemento do design destinado a manter a resiliência e as falhas para o qual foi projetado para mitigar. Para obter mais informações sobre a criação dessas listas, consulte o [whitepaper Revisões de prontidão operacional](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html), o qual orienta você sobre como criar um processo para evitar a recorrência de incidentes anteriores. O processo de modos de falhas e análises de efeitos (FMEA) proporciona um framework para realização de análise de falhas em nível de componente e como elas afetam a workload. O FMEA é descrito com mais detalhes por Adrian Cockcroft em [Modos de falha e resiliência contínua](https://adrianco.medium.com/failure-modes-and-continuous-resilience-6553078caad5).
1. Atribua uma prioridade a cada falha.
Comece com uma categorização bruta, como alta, média e baixa. Para avaliar a prioridade, considere a frequência da falha e o impacto da falha na workload total.
Ao considerar a frequência de determinada falha, analise os dados passados para essa workload sempre que disponíveis. Caso contrário, use os dados de outras workloads executadas em ambientes semelhantes.
Ao considerar o impacto de determinada falha, em geral, quanto maior o escopo da falha, maior o impacto. Considere também o design e a finalidade da workload. Por exemplo, a capacidade de acessar os datastores de origem é essencial para uma workload que executa análise e transformação de dados. Nesse caso, priorize experimentos de falhas de acesso, além de acesso controlado e inserção de latência.
Análises pós-incidente são boas fontes de dados para entender a frequência e o impacto dos modos de falha.
Use a prioridade atribuída para determinar quais falhas escolher para experimentar primeiro e a sequência para desenvolver novos experimentos de injeção de falhas.
1. Para cada experimento realizado, siga o flywheel de engenharia do caos e resiliência contínua na figura a seguir.
![\[Diagrama do flywheel de engenharia do caos e resiliência contínua que mostra as fases Melhoria, Estado estável, Hipótese, Executar experimento e Verificar.\]](http://docs.aws.amazon.com/pt_br/wellarchitected/latest/framework/images/chaos-engineering-flywheel.png)
1. Defina o estado estável como uma saída mensurável de uma workload que indica comportamento normal.
Sua workload apresentará estado estável se estiver operando de maneira confiável e conforme o esperado. Portanto, valide a integridade da workload antes de definir o estado estável. O estado estável nem sempre significa que não há nenhum impacto à workload quando ocorre uma falha, já que determinada porcentagem de falhas pode estar dentro de limites aceitáveis. O estado estável é a linha de base que você poderá observar durante o experimento, o que irá destacar anomalias se a hipótese definida na próxima etapa não sair conforme o esperado.
Por exemplo, um estado estável de um sistema de pagamentos pode ser definido como o processamento de 300 TPS com taxa de sucesso de 99% e tempo de ida e volta de 500 ms.
1. Formule uma hipótese sobre como a workload irá reagir à falha.
Uma boa hipótese baseia-se em como se espera que a workload mitigue a falha para manter o estado estável. A hipótese afirma que para determinado tipo de falha, o sistema ou a workload permanecerá em estado estável, pois a workload foi projetada com mitigações específicas. O tipo específico de falhas e mitigações deve ser especificado na hipótese.
O modelo a seguir pode ser usado para a hipótese (mas uma redação diferente também é aceitável):
**nota**
Se uma *falha específica* ocorrer, o *nome da workload* *descreverá os controles de mitigação* para manter o *impacto da métrica técnica ou comercial*.
Por exemplo:
+ Se 20% dos nós no grupo de nós do Amazon EKS forem desativados, a API Transaction Create continuará atendendo ao 99º percentil das solicitações em menos de 100 ms (estado estável). Os nós do Amazon EKS se recuperarão em cinco minutos e os pods serão agendados e processarão o tráfego oito minutos depois do início do experimento. Os alertas serão acionados em três minutos.
+ Se uma única falha de instância do Amazon EC2 ocorrer, a verificação de integridade do Elastic Load Balancing do sistema de ordem fará com que o Elastic Load Balancing envie solicitações apenas para as instâncias íntegras restantes, enquanto o Amazon EC2 Auto Scaling substitui a instância com falha, mantendo um aumento inferior a 0,01% na quantidade de erros no servidor (5xx) (estado estável).
+ Se a instância de banco de dados primária do Amazon RDS falhar, a workload de coleta de dados da cadeia de suprimentos vai entrar em failover e se conectará à instância de banco de dados de espera do Amazon RDS para manter menos de um minuto de erros de leitura ou gravação de banco de dados (estado estável).
1. Execute o experimento injetando a falha.
Um experimento deve, por padrão, ser seguro contra falhas e tolerado pela workload. Se você sabe que a workload irá falhar, não execute o experimento. A engenharia do caos deve ser usada para encontrar incertezas conhecidas ou desconhecidas. *Incertezas conhecidas* são coisas que você conhece, mas não entende completamente, enquanto *incertezas desconhecidas* são coisas das quais você não está ciente nem compreende totalmente. Realizar experimentos em uma workload que você sabe que não funciona não oferecerá novos insights. Seu experimento deve ser cuidadosamente planejado, ter um escopo claro do impacto e fornecer um mecanismo de reversão que possa ser aplicado em caso de turbulência inesperada. Se sua devida diligência mostrar que a workload sobreviverá ao experimento, prossiga com o teste. Há diversas opções para injetar as falhas. Para workloads na AWS, o [AWS FIS](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html) fornece muitas simulações de falhas predefinidas chamadas [ações](https://docs.aws.amazon.com/fis/latest/userguide/actions.html). Você também pode definir ações personalizadas que são executadas no AWS FIS usando [documentos do AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-ssm-docs.html).
Recomendamos não usar scripts personalizados para experimentos de caos, a menos que os scripts tenham a capacidade de entender o estado atual da workload, sejam capazes de emitir logs e ofereçam mecanismos para rollbacks e condições de parada sempre que possível.
Um conjunto de ferramentas ou framework eficaz que ofereça suporte à engenharia do caos deve monitorar o estado atual de um experimento, emitir logs e fornecer mecanismos de rollback para acomodar à execução controlada de um experimento. Comece com um serviço estabelecido, como o AWS FIS, que permita que você realize experimentos com um escopo claramente definido e mecanismos de segurança que reverterão o experimento se ele introduzir turbulência inesperada. Para saber mais sobre uma variedade maior de experimentos usando o AWS FIS, consulte também o [laboratório Aplicações resilientes e bem arquitetadas com engenharia do caos](https://catalog.us-east-1.prod.workshops.aws/workshops/44e29d0c-6c38-4ef3-8ff3-6d95a51ce5ac/en-US). Além disso, o [AWS Resilience Hub](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html) analisará sua workload e criará experimentos que podem ser escolhidos para implementação e execução no AWS FIS.
**nota**
Para cada experimento, entenda claramente o escopo e seu impacto. Recomendamos que as falhas sejam simuladas primeiro em um ambiente de não produção, antes de serem executadas em produção.
Os experimentos devem ser executados em produção sob carga real usando [implantações canário](https://medium.com/the-cloud-architect/chaos-engineering-q-a-how-to-safely-inject-failure-ced26e11b3db) que ativam a implantação de um sistema de controle e experimental, sempre que possível. A realização de experimentos durante horários fora de pico é uma boa prática para mitigar o impacto potencial durante o primeiro experimento na produção. Além disso, se o uso de tráfego real de clientes for algo muito arriscado, você poderá executar experimentos usando tráfego sintético na infraestrutura de produção nas implantações de controle e experimentais. Quando não for possível usar a produção, realize os experimentos em ambientes de pré-produção que sejam o mais parecido possível com a produção.
Estabeleça e monitore barreiras de proteção para garantir que o experimento não afete o tráfego de produção ou outros sistemas além dos limites aceitáveis. Estabeleça condições de parada para interromper um experimento se ele atingir um limite definido de uma métrica de barreira de proteção. Isso deve incluir as métricas de estado estável da workload, bem como a métrica em relação aos componentes em que você está injetando a falha. Um [monitor sintético](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) (também conhecido como canário de usuário) é uma métrica que geralmente deve ser incluída como proxy de usuário. As [condições de parada para AWS FIS](https://docs.aws.amazon.com/fis/latest/userguide/stop-conditions.html) são aceitas como parte do modelo de experimento, permitindo até cinco condições de parada por modelo.
Um dos princípios de caos é minimizar o escopo do experimento e seu impacto:
Embora deva existir uma provisão para algum impacto negativo de curto prazo, é responsabilidade e obrigação do engenheiro de caos garantir que as perdas dos experimentos sejam minimizadas e contidas.
Um método para verificar o escopo e o impacto potencial é realizar o experimento primeiro em um ambiente de não produção, verificando se os limites para as condições de parada são ativados conforme o esperado durante o experimento e se há observabilidade em vigor para identificar uma exceção, em vez de testar diretamente em produção.
Ao executar experimentos de injeção de falhas, verifique se todas as partes responsáveis estão bem informadas. Comunique-se com as equipes adequadas, como equipes de operações, equipes de confiabilidade do serviço e atendimento ao cliente, para avisá-las sobre quando os experimentos serão realizados e o que esperar. Ofereça a essas equipes ferramentas de comunicação para que informem os responsáveis pela execução do experimento caso percebam algum efeito adverso.
Você deve restaurar a workload e seus sistemas subjacentes de volta para o estado íntegro original. Normalmente, o design resiliente da workload irá se restaurar automaticamente. No entanto, alguns designs de falhas ou experimentos malsucedidos podem deixar a workload em um estado de falha inesperado. Ao final do experimento, você deverá estar ciente disso e restaurar a workload e os sistemas. Com o AWS FIS, é possível definir uma configuração de reversão (também chamada de ação posterior) nos parâmetros de ação. Uma ação posterior retorna o destino ao estado em que estava antes da execução da ação. Independentemente de serem automatizadas (como as que usam o AWS FIS) ou manuais, essas ações posteriores devem fazer parte de um playbook que descreve como detectar e lidar com falhas.
1. Verifique a hipótese.
Os [Princípios da engenharia do caos](https://principlesofchaos.org/) oferecem a seguinte orientação sobre como verificar o estado estável de sua workload:
Concentre-se na saída mensurável de um sistema, em vez de atributos internos do sistema. As medições dessa saída durante um curto período constituem um proxy do estado estável do sistema. O throughput total do sistema, as taxas de erros e os percentis de latência podem ser métricas de interesse que representam o comportamento do estado estável. Ao focar em padrões de comportamento sistêmicos durante os experimentos, a engenharia de caos verifica se o sistema de fato funciona em vez de tentar validar como ele funciona.
Nos dois exemplos anteriores, incluímos métricas de estado estável de menos de 0,01% de aumento na quantidade de erros no servidor (5xx) e menos de um minuto de erros de leitura ou gravação de banco de dados.
Os erros 5xx são uma boa métrica, pois são consequência do modo de falha que um cliente da workload vivenciará diretamente. A medição dos erros do banco de dados é boa como consequência direta da falha, mas também deve ser complementada com uma medição de impacto para o cliente, como solicitações malsucedidas ou erros apresentados ao cliente. Além disso, inclua um monitor sintético (também conhecido como canário de usuário) em todas as APIs ou URIs acessadas pelo cliente da workload.
1. Melhore o design da workload para agregar resiliência.
Se o estado estável não tiver sido mantido, investigue como o design da workload pode ser melhorado para mitigar a falha, aplicando as práticas recomendadas do [pilar Confiabilidade do AWS Well-Architected](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html). Orientações e recursos adicionais podem ser encontrados na [AWS Builder's Library](https://aws.amazon.com/builders-library/), a que qual contém artigos sobre como [melhorar suas verificações de interidade](https://aws.amazon.com/builders-library/implementing-health-checks/) ou [empregar novas tentativas com atraso no código da aplicação](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/), entre outros.
Depois de implementar essas mudanças, execute o experimento novamente (mostrado pela linha pontilhada no flywheel de engenharia de caos) para determinar a eficácia. Se a etapa de verificação indicar que a hipótese é verdadeira, a workload estará em estado estável e o ciclo continuará.
1. Execute experimentos regularmente.
Um experimento de caos é um ciclo, e os experimentos devem ser realizados regularmente como parte da engenharia de caos. Depois que uma workload cumprir a hipótese do teste, o experimento deverá ser automatizado para ser executado continuamente como parte de regressão do pipeline de CI/CD. Para saber como fazer isso, consulte este blog sobre [como realizar experimentos do AWS FIS usando o AWS CodePipeline](https://aws.amazon.com/blogs/architecture/chaos-testing-with-aws-fault-injection-simulator-and-aws-codepipeline/). Este laboratório sobre [experimentos do AWS FIS recorrentes em um pipeline de CI/CD](https://chaos-engineering.workshop.aws/en/030_basic_content/080_cicd.html) permite que você trabalhe de forma prática.
Os experimentos de injeção de falhas também fazem parte dos game days (consulte [REL12-BP05 Conduzir dias de jogo regularmente](rel_testing_resiliency_game_days_resiliency.md)). Os game days simulam uma falha ou um evento para verificar sistemas, processos e respostas das equipes. O objetivo é executar de fato as ações que a equipe executaria como se um evento excepcional acontecesse.
1. Capture e armazene os resultados do experimento.
Os resultados dos experimentos de injeção de falhas devem ser capturados e persistidos. Inclua todos os dados necessários (como tempo, workload e condições) para poder analisar os resultados e as tendências do experimento posteriormente. Exemplos de resultados podem incluir capturas de tela de painéis, despejos em CSV do banco de dados da métrica ou um registro manual dos eventos e das observações do experimento. O [registro em log de experimentos com o AWS FIS](https://docs.aws.amazon.com/fis/latest/userguide/monitoring-logging.html) pode fazer parte dessa captura de dados.
## Recursos
**Práticas recomendadas relacionadas:**
+ [REL08-BP03 Integrar testes de resiliência como parte da implantação](rel_tracking_change_management_resiliency_testing.md)
+ [REL13-BP03 Testar a implementação da recuperação de desastres para validá-la](rel_planning_for_recovery_dr_tested.md)
**Documentos relacionados:**
+ [O que é o AWS Fault Injection Service?](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html)
+ [O que é o AWS Resilience Hub?](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html)
+ [Princípios da engenharia do caos](https://principlesofchaos.org/)
+ [Engenharia de caos: como planejar seu primeiro experimento](https://medium.com/the-cloud-architect/chaos-engineering-part-2-b9c78a9f3dde)
+ [Engenharia de resiliência: como aprender a aceitar falhas](https://queue.acm.org/detail.cfm?id=2371297)
+ [Histórias sobre engenharia do caos](https://github.com/ldomb/ChaosEngineeringPublicStories)
+ [Como evitar fallback em sistemas distribuídos](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems/)
+ [Implantação canário para experimentos de caos](https://medium.com/the-cloud-architect/chaos-engineering-q-a-how-to-safely-inject-failure-ced26e11b3db)
**Vídeos relacionados:**
+ [AWS re:Invent 2020: Testar a resiliência via engenharia do caos (ARC316)](https://www.youtube.com/watch?v=OlobVYPkxgg)
+ [AWS re:Invent 2019: Melhorar a resiliência com engenharia do caos (DOP309-R1)](https://youtu.be/ztiPjey2rfY)
+ [AWS re:Invent 2019: Aplicar a engenharia do caos em um universo de tecnologia sem servidor (CMY301)](https://www.youtube.com/watch?v=vbyjpMeYitA)
** Ferramentas relacionadas: **
+ [AWS Fault Injection Service](https://aws.amazon.com/fis/)
+ AWS Marketplace: [Plataforma de engenharia de caos Gremlin](https://aws.amazon.com/marketplace/pp/prodview-tosyg6v5cyney)
+ [Chaos Toolkit](https://chaostoolkit.org/)
+ [Chaos Mesh](https://chaos-mesh.org/)
+ [Litmus](https://litmuschaos.io/)
# REL12-BP05 Conduzir dias de jogo regularmente
Conduza dias de jogo para exercitar regularmente os procedimentos de resposta a eventos e deficiências que afetam a workload. Envolva as mesmas equipes que seriam responsáveis por lidar com os cenários de produção. Esses exercícios ajudam a aplicar medidas para evitar o impacto do usuário causado por eventos de produção. Ao praticar os procedimentos de resposta em condições realistas, você pode identificar e resolver quaisquer lacunas ou fragilidades antes que um evento real ocorra.
Os dias de jogo simulam eventos em ambientes parecidos com os de produção para testar sistemas, processos e respostas das equipes. O objetivo é executar as mesmas ações que a equipe executaria se um evento excepcional acontecesse. Esses exercícios ajudam você a compreender onde é possível aplicar melhorias e podem ajudar a desenvolver experiência organizacional para lidar com eventos e deficiências. Eles devem ser realizados regularmente para que a equipe desenvolva hábitos enraizados sobre como responder.
Os dias de jogo preparam as equipes para lidar com eventos de produção com maior confiança. Equipes bem treinadas são mais capazes de detectar e responder rapidamente a vários cenários. Isso resulta em uma postura de prontidão e resiliência significativamente melhor.
**Resultado desejado:** você realiza dias de jogos de resiliência de forma consistente e programada. Esses dias de jogo são vistos como uma parte normal e esperada dos negócios. A organização desenvolveu uma cultura de preparação, e quando ocorrem problemas de produção, as equipes estão bem preparadas para responder com eficácia, resolver os problemas de maneira eficiente e mitigar o impacto nos clientes.
**Práticas comuns que devem ser evitadas:**
+ Documentar seus procedimentos, mas nunca colocá-los em prática.
+ Excluir os responsáveis pelas decisões de negócios das simulações de teste.
+ Organizar um dia de jogo, mas não informar todas as partes interessadas relevantes.
+ Concentrar-se apenas nas falhas técnicas, mas não envolver as partes interessadas empresariais.
+ Não incorporar as lições aprendidas nos dias de jogo nos processos de recuperação.
+ Culpar as equipes por falhas ou bugs.
**Benefícios de implementar essa prática recomendada:**
+ Melhore as habilidades de resposta: nos dias de jogo, as equipes praticam tarefas e testam mecanismos de comunicação durante eventos simulados, o que cria uma resposta mais coordenada e eficiente em situações de produção.
+ Identifique e resolva dependências: ambientes complexos geralmente envolvem dependências complexas entre vários sistemas, serviços e componentes. Os dias de jogo podem ajudar você a identificar e resolver essas dependências e a verificar se os sistemas e serviços essenciais estão devidamente cobertos pelos procedimentos do runbook e podem passar por aumento vertical da escala ou ser recuperados em tempo hábil.
+ Promova uma cultura de resiliência: os dias de jogos podem ajudar a cultivar uma mentalidade de resiliência dentro de uma organização. Quando você envolve equipes multifuncionais e partes interessadas, esses exercícios promovem a conscientização, a colaboração e uma compreensão compartilhada da importância da resiliência em toda a organização.
+ Melhoria e adaptação contínuas: dias de jogo periódicos ajudam você a avaliar e adaptar continuamente as estratégias de resiliência, o que as mantém relevantes e eficazes diante das mudanças nas circunstâncias.
+ Aumente a confiança no sistema: os dias de jogo bem-sucedidos podem ajudar você a aumentar a confiança na capacidade do sistema de resistir e se recuperar das interrupções.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio
## Orientação para implementação
Depois de projetar e implementar as medidas de resiliência necessárias, realize um dia de jogo para validar se tudo funciona conforme planejado na produção. Um dia de jogo, especialmente o primeiro, deve envolver todos os membros da equipe. Todas as partes interessadas e participantes devem ser informados com antecedência sobre a data, a hora e os cenários simulados.
Durante o dia do jogo, as equipes envolvidas simulam vários eventos e cenários potenciais de acordo com os procedimentos prescritos. Os participantes monitoram e avaliam de perto o impacto desses eventos simulados. Se o sistema operar conforme projetado, os mecanismos automatizados de detecção, escalabilidade e autorrecuperação deverão ser ativados e resultar em pouco ou nenhum impacto nos usuários. Se a equipe observar algum impacto negativo, ela reverte o teste e soluciona os problemas identificados, seja por meios automatizados ou por meio de intervenção manual documentada nos runbooks aplicáveis.
Para melhorar continuamente a resiliência, é fundamental documentar e incorporar as lições aprendidas. Esse processo é um ciclo de *feedback* que captura sistematicamente os insights dos dias de jogo e os usa para aprimorar sistemas, processos e capacidades da equipe.
Para ajudar você a reproduzir cenários do mundo real em que serviços ou componentes do sistema podem falhar inesperadamente, injete falhas simuladas como um exercício do dia de jogo. As equipes podem testar a resiliência e a tolerância a falhas dos sistemas e simular os processos de resposta e recuperação de incidentes em um ambiente controlado.
Na AWS, os dias de jogo podem ser realizados com réplicas do ambiente de produção usando infraestrutura como código. Por meio desse processo, você pode realizar testes em um ambiente seguro muito semelhante ao seu ambiente de produção. Considere usar o [AWS Fault Injection Service](https://aws.amazon.com/fis/) para criar diferentes cenários de falha. Use serviços, como o [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) e o [AWS X-Ray](https://aws.amazon.com/xray/), para monitorar o comportamento do sistema durante os dias de jogo. Use o [AWS Systems Manager](https://aws.amazon.com/systems-manager/) para gerenciar e executar playbooks e use o [AWS Step Functions](https://aws.amazon.com/step-functions/)para orquestrar fluxos de trabalho recorrentes no dia de jogo.
### Etapas de implementação
+ **Estabeleça um programa de dias de jogo:** desenvolva um programa estruturado que defina a frequência, o escopo e os objetivos dos dias de jogo. Envolva as principais partes interessadas e especialistas no assunto no planejamento e execução desses exercícios.
+ **Prepare o dia do jogo:**
1. Identifique os principais serviços essenciais para os negócios que serão o foco do dia do jogo. Catalogue e mapeie as pessoas, os processos e as tecnologias que oferecem suporte a esses serviços.
1. Defina a agenda para o dia de jogo e prepare as equipes envolvidas para participar do evento. Prepare os serviços de automação para simular os cenários planejados e executar os processos de recuperação apropriados. Os serviços da AWS, como [AWS Fault Injection Service](https://aws.amazon.com/fis/), [AWS Step Functions](https://aws.amazon.com/step-functions/) e [AWS Systems Manager](https://aws.amazon.com/systems-manager/), podem ajudar você a automatizar vários aspectos dos dias de jogo, como injeção de falhas e início das ações de recuperação.
+ **Execute a simulação:** no dia de jogo, execute o cenário planejado. Observe e documente como as pessoas, os processos e as tecnologias reagem ao evento simulado.
+ **Faça análises após o exercício:** depois do dia de jogo, faça uma sessão retrospectiva para revisar as lições aprendidas. Identifique áreas de melhoria e quaisquer ações necessárias para melhorar a resiliência operacional. Documente as descobertas e acompanhe todas as mudanças necessárias para aprimorar as estratégias de resiliência e preparação para a conclusão.
## Recursos
**Práticas recomendadas relacionadas:**
+ [REL12-BP01 Usar playbooks para investigar falhas](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_testing_resiliency_playbook_resiliency.html)
+ [REL12-BP04 Testar a resiliência com engenharia do caos](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_testing_resiliency_failure_injection_resiliency.html)
+ [OPS04-BP01 Identificar indicadores-chave de performance](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_observability_identify_kpis.html)
+ [OPS07-BP03 Usar runbooks para realizar procedimentos](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ready_to_support_use_runbooks.html)
+ [OPS10-BP01 Usar um processo para gerenciamento de eventos, incidentes e problemas](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_event_response_event_incident_problem_process.html)
**Documentos relacionados:**
+ [O que é o AWS GameDay?](https://aws.amazon.com/gameday/)
**Vídeos relacionados:**
+ [AWS re:Invent 2023 - Practice like you play: How Amazon scales resilience to new heights](https://www.youtube.com/watch?v=r3J0fEgNCLQ&t=1734s)
**Exemplos relacionados:**
+ [AWS Workshop - Navigate the storm: Unleashing controlled chaos for resilient systems](https://catalog.us-east-1.prod.workshops.aws/workshops/eb89c4d5-7c9a-40e0-b0bc-1cde2df1cb97)
+ [Build Your Own Game Day to Support Operational Resilience](https://aws.amazon.com/blogs/architecture/build-your-own-game-day-to-support-operational-resilience/)
# REL 13. Como planejar para a recuperação de desastres (DR)?
Implementar backups e componentes redundantes de workload é o ponto de partida da sua estratégia de DR. O [RTO e o RPO são os objetivos](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/disaster-recovery-dr-objectives.html) para restaurar a workload. Defina-os de acordo com suas necessidades de negócios. Implemente uma estratégia para atender a esses objetivos, considerando os locais e a função dos recursos e dos dados da workload. A probabilidade de interrupção e o custo de recuperação também são fatores principais que ajudam a determinar o valor empresarial de fornecer a recuperação de desastres para uma workload.
**Topics**
+ [REL13-BP01 Definir os objetivos de recuperação para tempo de inatividade e perda de dados](rel_planning_for_recovery_objective_defined_recovery.md)
+ [REL13-BP02 Usar estratégias de recuperação definidas para cumprir os objetivos de recuperação](rel_planning_for_recovery_disaster_recovery.md)
+ [REL13-BP03 Testar a implementação da recuperação de desastres para validá-la](rel_planning_for_recovery_dr_tested.md)
+ [REL13-BP04 Gerenciar o desvio de configuração no local ou na região de recuperação de desastres](rel_planning_for_recovery_config_drift.md)
+ [REL13-BP05 Automatizar a recuperação](rel_planning_for_recovery_auto_recovery.md)
# REL13-BP01 Definir os objetivos de recuperação para tempo de inatividade e perda de dados
As falhas podem afetar os negócios de várias maneiras. Primeiro, elas podem causar interrupção do serviço (tempo de inatividade). Em segundo lugar, as falhas podem fazer com que os dados se tornem perdidos, inconsistentes ou obsoletos. Para orientar a maneira como você responde e se recupera de falhas, defina um objetivo de tempo de recuperação (RTO) e um objetivo de ponto de recuperação (RPO) para cada workload. O *objetivo de tempo de recuperação (RTO)* é o atraso aceitável entre a interrupção e a restauração do serviço. O *objetivo de ponto de recuperação (RPO)* é o tempo máximo aceitável após o último ponto de recuperação de dados.
**Resultado desejado:** cada workload tem um RTO e um RPO designados com base em considerações técnicas e no impacto comercial.
**Práticas comuns que devem ser evitadas:**
+ Não designar objetivos de recuperação.
+ Selecionar objetivos de recuperação arbitrários.
+ Selecionar objetivos de recuperação que são muito permissivos e que não atendem aos objetivos de negócios.
+ Não avaliar o impacto do tempo de inatividade e da perda de dados.
+ Selecionar objetivos de recuperação irreais, como tempo de recuperação zerado ou nenhuma perda de dados, o que pode não ser possível para a configuração da workload.
+ Selecionar objetivos de recuperação mais rigorosos do que os objetivos de negócios reais. Isso força implementações de recuperação mais caras e complicadas do que as necessidades da workload.
+ Selecionar objetivos de recuperação incompatíveis com os de uma workload dependente.
+ Deixar de considerar os requisitos regulatórios e de conformidade.
**Benefícios de implementar essa prática recomendada:** ao definir RTOs e RPOs para as workloads, você estabelece metas claras e mensuráveis de recuperação com base nas necessidades de negócios. Depois de definir essas metas, você pode criar planos de recuperação de desastres (DR) personalizados para atendê-las.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** Alto
## Orientação para implementação
Elabore uma matriz ou planilha para ajudar a orientar o planejamento da recuperação de desastres. Na matriz, crie diferentes categorias ou níveis de workload com base no impacto delas nos negócios (como crítico, alto, médio e baixo) e nas metas de RTO e RPO associadas a cada um. A seguinte matriz fornece um exemplo (observe que os valores de RTO e RPO podem ser diferentes) que você pode seguir:
![\[Tabela que mostra a matriz de recuperação de desastres\]](http://docs.aws.amazon.com/pt_br/wellarchitected/latest/framework/images/disaster-recovery-matrix.png)
Para cada workload, investigue e entenda o impacto do tempo de inatividade e da perda de dados para os negócios. O impacto geralmente aumenta com tempo de inatividade e perda de dados, mas a forma do impacto pode ser diferente com base no tipo de workload. Por exemplo, o tempo de inatividade por até uma hora pode ter baixo impacto, mas depois disso o impacto pode se intensificar rapidamente. O impacto pode assumir várias formas, incluindo impacto financeiro (como perda de receita), impacto sobre a reputação (inclusive perda de confiança do cliente), impacto operacional (como folha de pagamento perdida ou diminuição da produtividade) e risco regulatório. Depois de concluído, atribua a workload ao nível apropriado.
Considere as seguintes perguntas ao analisar o impacto da falha:
1. Qual é o tempo máximo em que a workload pode permanecer inativa antes que um impacto inaceitável ocorra nos negócios?
1. Quanto impacto e de que tipo será causado pela empresa devido a uma interrupção na workload? Considere todos os tipos de impacto, incluindo financeiro, reputacional, operacional e regulatório.
1. Qual é a quantidade máxima de dados que podem ser perdidos ou não recuperados antes que um impacto inaceitável ocorra nos negócios?
1. Os dados perdidos podem ser recriados a partir de outras fontes (também conhecidas como dados *derivados*)? Nesse caso, considere também os RPOs de todos os dados de origem usados para recriar os dados da workload.
1. Quais são os objetivos de recuperação e as expectativas de disponibilidade das workloads das quais esta depende (downstream)? Os objetivos da workload devem ser alcançáveis com base nos recursos de recuperação das respectivas dependências downstream. Considere possíveis soluções alternativas ou mitigações das dependências downstream que possam melhorar a capacidade de recuperação dessa workload.
1. Quais são os objetivos de recuperação e as expectativas de disponibilidade das workloads que dependem desta (upstream)? Os objetivos da workload upstream podem exigir que ela tenha recursos de recuperação mais rigorosos do que parece à primeira vista.
1. Há objetivos de recuperação diferentes com base no tipo de incidente? Por exemplo, você pode ter RTOs e RPOs diferentes, dependendo se o incidente afeta uma zona de disponibilidade ou uma região inteira.
1. Os objetivos de recuperação mudam durante determinados eventos ou épocas do ano? Por exemplo, você pode ter RTOs e RPOs diferentes em temporadas de compras natalinas, eventos esportivos, vendas especiais e lançamentos de novos produtos.
1. Como os objetivos de recuperação se alinham às estratégias de recuperação de desastres organizacional e de linha de negócios que você possa ter?
1. Há ramificações legais ou contratuais a serem consideradas? Por exemplo, você está contratualmente obrigado a fornecer um serviço com um determinado RTO ou RPO? Quais penalidades você pode receber por não cumpri-las?
1. Você precisa manter a integridade dos dados para atender aos requisitos normativos ou de conformidade?
A planilha a seguir pode ajudar na avaliação de cada workload. É possível modificá-la para atender às suas necessidades específicas, como incluir perguntas adicionais.
![\[Planilha\]](http://docs.aws.amazon.com/pt_br/wellarchitected/latest/framework/images/worksheet.png)
### Etapas de implementação
1. Identifique as partes interessadas empresariais e as equipes técnicas responsáveis por cada workload e interaja com elas.
1. Crie categorias ou níveis de criticidade para o impacto da workload na organização. As categorias de exemplo incluem: crítica, alta, média e baixa. Para cada categoria, escolha um RTO e um RPO que reflitam seus objetivos e requisitos de negócios.
1. Atribua uma das categorias de impacto que você criou na etapa anterior a cada workload. Para decidir como é o mapeamento entre uma workload e uma categoria, considere a importância dela para os negócios e o impacto da interrupção ou perda de dados e use as perguntas acima como guia. Isso resulta em um RTO e um RPO para cada workload.
1. Considere o RTO e o RPO para cada workload determinada na etapa anterior. Envolva as equipes técnicas e comerciais da workload para determinar se os objetivos devem ser ajustados. Por exemplo, as partes interessadas da empresa podem determinar que metas mais rigorosas são necessárias. Como alternativa, as equipes técnicas poderiam determinar que as metas deveriam ser modificadas para torná-las alcançáveis com os recursos disponíveis e as restrições tecnológicas.
## Recursos
**Práticas recomendadas relacionadas:**
+ [REL09-BP04 Realizar a recuperação periódica dos dados para verificar a integridade e os processos de backup](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_backing_up_data_periodic_recovery_testing_data.html)
+ [REL12-BP01 Usar playbooks para investigar falhas](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_testing_resiliency_playbook_resiliency.html)
+ [REL13-BP02 Usar estratégias de recuperação definidas para cumprir os objetivos de recuperação](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_disaster_recovery.html)
+ [REL13-BP03 Testar a implementação da recuperação de desastres para validá-la](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_dr_tested.html)
**Documentos relacionados:**
+ [AWS Blog de arquitetura da : série de recuperação de desastres](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [Recuperação de desastres de workloads na AWS: recuperação na nuvem (whitepaper da AWS)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [Gerenciar políticas de resiliência com o AWS Resilience Hub](https://docs.aws.amazon.com/resilience-hub/latest/userguide/resiliency-policies.html)
+ [Parceiro da APN: parceiros que podem ajudar com a recuperação de desastres](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [AWS Marketplace: produtos que podem ser usados para recuperação de desastres](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
**Vídeos relacionados:**
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications](https://youtu.be/2e29I3dA8o4)
+ [Recuperação de desastres de workloads na AWS](https://www.youtube.com/watch?v=cJZw5mrxryA)
# REL13-BP02 Usar estratégias de recuperação definidas para cumprir os objetivos de recuperação
Defina uma estratégia de recuperação de desastres (DR) que cumpra os objetivos de recuperação da workload. Escolha uma estratégia como backup e restauração, standby (ativa/passiva) ou ativa/ativa.
**Resultado desejado:** para cada workload, há uma estratégia de DR definida e implementada que permite que a workload alcance os objetivos de DR. As estratégias de DR entre workloads fazem uso de padrões reutilizáveis (como as estratégias descritas anteriormente).
**Práticas comuns que devem ser evitadas:**
+ Implementar procedimentos de recuperação inconsistentes para workloads com objetivos de DR semelhantes.
+ Deixar que a estratégia de DR seja implementada ad hoc quando um desastre ocorrer.
+ Não ter um plano para a recuperação de desastres.
+ Depender das operações do ambiente de gerenciamento durante a recuperação.
**Benefícios de implementar esta prática recomendada:**
+ O uso de estratégias de recuperação definidas permite que você adote ferramentas comuns e procedimentos de teste.
+ Usar estratégias de recuperação definidas melhora o compartilhamento de conhecimento entre as equipes e a implementação da DR nas workloads pertencentes a elas.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** Alto. Sem uma estratégia de DR planejada, implementada e testada, é improvável que você cumpra os objetivos de recuperação em caso de desastre.
## Orientação para implementação
Uma estratégia de DR depende da capacidade de manter a workload em um site de recuperação se o local primário não puder executar a workload. Os objetivos de recuperação mais comuns são o RTO e o RPO, conforme discutido em [REL13-BP01 Definir os objetivos de recuperação para tempo de inatividade e perda de dados](rel_planning_for_recovery_objective_defined_recovery.md).
Uma estratégia de DR em várias zonas de disponibilidade (AZs) em uma única Região da AWS pode fornecer mitigação contra eventos de desastre, como incêndios, inundações e grandes interrupções de energia. Se implementar proteção contra um evento improvável que impeça a execução da workload em determinada Região da AWS for um requisito, você poderá optar por uma estratégia de DR que use várias regiões.
Ao arquitetar uma estratégia de DR em várias regiões, é necessário escolher uma das estratégias a seguir. Elas são listadas em ordem crescente de custo e complexidade e em ordem decrescente de RTO e RPO. *Região de recuperação* se refere a uma Região da AWS diferente da principal usada para sua workload.
![\[Diagrama que mostra estratégias de DR\]](http://docs.aws.amazon.com/pt_br/wellarchitected/latest/framework/images/disaster-recovery-strategies.png)
+ **Backup e restauração** (RPO em horas, RTO em 24 horas ou menos): faça backup de seus dados e aplicações na região de recuperação. O uso de backups automatizados ou contínuos permitirá a recuperação para um ponto no tempo (PITR), o que pode reduzir o RPO para até cinco minutos em alguns casos. Em caso de desastre, você implantará a infraestrutura (usando a infraestrutura como código para reduzir o RTO), implantará o código e restaurará os dados salvos para se recuperar de um desastre na região de recuperação.
+ **Luz piloto** (RPO em minutos, RTO em dezenas de minutos): provisione uma cópia da sua infraestrutura principal de workload na região de recuperação. Replique seus dados na região de recuperação e crie backups deles nessa região. Os recursos necessários para permitir a replicação e o backup, como bancos de dados e armazenamento de objetos, estão sempre ativos. Outros elementos, como servidores de aplicações ou computação com tecnologia sem servidor, não são implantados. No entanto, eles podem ser criados com a configuração e o código da aplicação necessários.
+ **Standby passivo** (RPO em segundos, RTO em minutos): mantenha uma versão em escala vertical reduzida, mas totalmente funcional, da workload sempre em execução na região de recuperação. Os sistemas críticos para os negócios são totalmente duplicados e estão sempre ativados, mas com uma frota reduzida. Os dados são replicados e residem na região de recuperação. No momento da recuperação, a escala do sistema é aumentada vertical e rapidamente para processar a carga de produção. Quanto mais a escala do standby passivo for aumentada verticalmente, menor será a dependência do RTO e do ambiente de gerenciamento. Quando totalmente dimensionado, isso é conhecido como *standby a quente*.
+ **Ativo-ativo em várias regiões (vários sites)** (RPO próximo de zero, RTO potencialmente zero): sua workload é implantada e atende ativamente ao tráfego de várias Regiões da AWS. Essa estratégia exige que você sincronize os dados entre regiões. É necessário evitar ou lidar com possíveis conflitos causados por gravações no mesmo registro em duas réplicas regionais diferentes, o que pode ser complexo. A replicação de dados é útil para a sincronização de dados e protegerá você contra alguns tipos de desastre, mas não contra corrupção ou destruição de dados, a menos que sua solução também inclua opções para recuperação a um ponto anterior no tempo.
**nota**
Às vezes, a diferença entre luz-piloto e standby passivo pode ser difícil de entender. Ambos incluem um ambiente na região de recuperação com cópias dos ativos da região primária. A diferença é que a luz piloto não pode processar solicitações sem primeiro realizar uma ação adicional, enquanto o standby passivo pode processar o tráfego (em níveis de capacidade reduzidos) imediatamente. A abordagem de luz piloto exigirá que você ative os servidores, possivelmente implante infraestrutura adicional (não essencial) e aumente a escala verticalmente. Já o standby passivo exige apenas que você aumente a escala verticalmente (tudo já está implantado e em execução). Escolha entre ambas as opções com base nas suas necessidades de RTO e RPO.
Quando o custo é uma preocupação e você deseja alcançar objetivos de RPO e RTO semelhantes, conforme definido na estratégia de standby passivo, é possível considerar soluções nativas da nuvem, como AWS Elastic Disaster Recovery, que adota a abordagem de luz piloto e oferece metas de RPO e RTO aprimoradas.
**Etapas de implementação**
1. **Determine uma estratégia de recuperação de desastres que satisfaça os requisitos de recuperação dessa workload.**
Escolher uma estratégia de recuperação de desastres é uma troca entre reduzir o tempo de inatividade e a perda de dados (RTO e RPO) e o custo e a complexidade da implementação da estratégia. Você deve evitar implementar uma estratégia mais rigorosa do que necessário, pois isso resulta em custos desnecessários.
Por exemplo, no diagrama a seguir, a empresa determinou o RTO máximo permitido e o orçamento limite da estratégia de restauração de serviço. Considerando os objetivos empresariais, as estratégias de recuperação de desastres de luz-piloto e standby passivo atenderão tanto ao RTO quanto aos critérios de custo.
![\[Gráfico que mostra a escolha de uma estratégia de recuperação de desastres com base no RTO e no custo\]](http://docs.aws.amazon.com/pt_br/wellarchitected/latest/framework/images/choosing-a-dr-strategy.png)
Para saber mais, consulte [Plano de continuidade de negócios (BCP](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/business-continuity-plan-bcp.html)).
1. **Analise os padrões de como a estratégia de recuperação de desastres selecionada pode ser implementada.**
O objetivo dessa etapa é entender como implementar a estratégia selecionada. As estratégias são explicadas usando as Regiões da AWS como locais primários e de recuperação. No entanto, também é possível optar por usar as zonas de disponibilidade em uma única região como sua estratégia de recuperação de desastres, a qual faz uso de elementos de várias dessas estratégias.
Nas etapas a seguir, é possível aplicar a estratégia para sua workload específica.
**Backup e restauração**
*Backup e restauração* é a estratégia menos complexa de implementar, mas exigirá mais tempo e esforços para restaurar a workload, resultando em maior RTO e RPO. É uma boa prática sempre fazer backups dos dados e copiá-los para outro local (como outra Região da AWS).
![\[Diagrama que mostra uma arquitetura de backup e restauração\]](http://docs.aws.amazon.com/pt_br/wellarchitected/latest/framework/images/backup-restore-architecture.png)
Para obter mais detalhes sobre essa estratégia, consulte [Arquitetura de recuperação de desastres (DR) na AWS, Parte II: backup e restauração com recuperação rápida](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-ii-backup-and-restore-with-rapid-recovery/).
**Luz piloto**
Com a abordagem *luz piloto*, você replica seus dados da região principal para a região de recuperação. Os principais recursos usados para a infraestrutura da workload são implantados na região de recuperação. No entanto, recursos adicionais e as dependências ainda são necessários para tornar a pilha funcional. Por exemplo, na Figura 20, nenhuma instância de computação é implantada.
![\[Diagrama que mostra uma arquitetura de luz piloto\]](http://docs.aws.amazon.com/pt_br/wellarchitected/latest/framework/images/pilot-light-architecture.png)
Para obter mais detalhes sobre essa estratégia, consulte [Arquitetura de recuperação de desastres (DR) na AWS, parte III: luz piloto e standby passivo](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/).
**Standby passivo**
A abordagem de *standby passivo* envolve garantir que haja uma cópia reduzida, mas totalmente funcional, do seu ambiente de produção em outra região. Essa abordagem estende o conceito de luz piloto e diminui o tempo de recuperação, já que a workload está sempre ativa em outra região. Se a região de recuperação for implantada com capacidade total, isso será conhecido como *standby a quente*.
![\[Diagrama que mostra a Figura 21: Arquitetura de standby passivo\]](http://docs.aws.amazon.com/pt_br/wellarchitected/latest/framework/images/warm-standby-architecture.png)
O uso de standby passivo ou luz piloto requer que a escala dos recursos seja aumentada verticalmente na região de recuperação. Para verificar se a capacidade está disponível quando necessário, considere o uso de [reservas de capacidade](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-reservations.html) para instâncias do EC2. Quando o AWS Lambda é usado, a [simultaneidade provisionada](https://docs.aws.amazon.com/lambda/latest/dg/provisioned-concurrency.html) pode fornecer ambientes de runtime para que eles estejam preparados para responder imediatamente às invocações da sua função.
Para obter mais detalhes sobre essa estratégia, consulte [Arquitetura de recuperação de desastres (DR) na AWS, parte III: luz piloto e standby passivo](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/).
**Multissite ativa/ativa**
Você pode executar sua workload simultaneamente em várias regiões como parte de uma estratégia *multissite ativa/ativa*. A estratégia multissite ativa-ativa atende ao tráfego de todas as regiões onde está implantada. Os clientes podem selecionar essa estratégia para outros fins além da recuperação de desastres. Ela pode ser usada para aumentar a disponibilidade ou ao implantar uma workload para um público global (a fim de aproximar o endpoint dos usuários e/ou implantar pilhas localizadas para o público nessa região). Como uma estratégia de DR, se a workload não for compatível com uma das Regiões da AWS onde está implantada, essa região será evacuada e as regiões restantes serão usadas para manter a disponibilidade. A multissite ativa/ativa é a estratégia de DR mais complexa operacionalmente e deve ser selecionada apenas quando os requisitos empresariais exigirem.
![\[Diagrama mostrando uma arquitetura multissite ativa/ativa\]](http://docs.aws.amazon.com/pt_br/wellarchitected/latest/framework/images/multi-site-active-active-architecture.png)
Para obter mais detalhes sobre essa estratégia, consulte [Arquitetura de recuperação de desastres (DR) na AWS, Parte IV: multissite ativa/ativa](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iv-multi-site-active-active/)
**AWS Elastic Disaster Recovery**
Se você está considerando a estratégia de luz piloto ou standby passivo para recuperação de desastres, o AWS Elastic Disaster Recovery pode fornecer uma abordagem alternativa com benefícios aprimorados. O Elastic Disaster Recovery pode oferecer uma meta de RPO e RTO semelhante ao standby passivo, mas mantendo a abordagem de baixo custo da luz piloto. O Elastic Disaster Recovery replica os dados da sua região primária para sua região de recuperação usando proteção contínua de dados para obter um RPO medido em segundos e um RTO que pode ser medido em minutos. Somente os recursos necessários para replicar os dados são implantados na região de recuperação, o que mantém os custos baixos, semelhante à estratégia de luz piloto. Quando o Elastic Disaster Recovery é usado, o serviço coordena e orquestra a recuperação de recursos de computação quando iniciado como parte de um failover ou de uma simulação.
![\[Diagrama da arquitetura descrevendo como o AWS Elastic Disaster Recovery opera.\]](http://docs.aws.amazon.com/pt_br/wellarchitected/latest/framework/images/drs-architecture.png)
**Práticas adicionais para proteger dados**
Com todas as estratégias, você também deve mitigar as consequências de um desastre de dados. A replicação contínua de dados protege você contra alguns tipos de desastre, mas não contra corrompimento ou destruição de dados, a menos que sua solução também inclua o versionamento de dados armazenados ou opções para recuperação a um ponto anterior no tempo. Você também deve fazer backup dos dados replicados no local de recuperação para criar backups pontuais além das réplicas.
**Usar várias zonas de disponibilidade (AZs) em uma única Região da AWS**
Ao utilizar várias AZs em uma única região, a implementação de DR usa vários elementos das estratégias acima. Primeiro, você deve criar uma arquitetura de alta disponibilidade (HA), usando várias AZs, conforme mostrado na Figura 23. Essa arquitetura faz uso de uma multissite ativa/ativa, já que as [instâncias do Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#concepts-availability-zones) e o [Elastic Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html#availability-zones) têm recursos implantados em várias AZs, processando ativamente as solicitações. A arquitetura também demonstra o standby a quente, em que, se a instância primária do [Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html) falhar (ou a própria AZ falhar), a instância em espera será promovida para primária.
![\[Diagrama que mostra a Figura 24: Arquitetura Multi-AZ\]](http://docs.aws.amazon.com/pt_br/wellarchitected/latest/framework/images/multi-az-architecture2.png)
Além da arquitetura de alta disponibilidade, é necessário adicionar backups de todos os dados necessários para executar a workload. Isso é especialmente importante para dados restritos a uma única zona, como [volumes do Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volumes.html) ou clusters do [Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html). Se uma AZ falhar, você precisará restaurar esses dados para outra AZ. Sempre que possível, copie os backups de dados para outra Região da AWS como uma camada adicional de proteção.
Uma abordagem alternativa menos comum para uma única região, a recuperação de desastres multi-AZ é ilustrada na publicação do blog [Building highly resilient applications using Amazon Application Recovery Controller, Part 1: Single-Region stack](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-1-single-region-stack/). Aqui, a estratégia é manter o máximo de isolamento possível entre as AZs, da mesma forma que as regiões operam. Ao usar esta estratégia alternativa, você pode escolher uma abordagem ativa/ativa ou ativa/passiva.
**nota**
Algumas workloads têm requisitos regulatórios de residência de dados. Se isso se aplicar à sua workload em uma localidade que atualmente tem apenas uma Região da AWS, a opção de multirregiões não atenderá às suas necessidades empresariais. As estratégias Multi-AZ fornecem boa proteção contra a maioria dos desastres.
1. **Avalie os recursos da sua workload e qual será sua configuração na região de recuperação antes do failover (durante a operação normal).**
Para infraestrutura e recursos da AWS, use infraestrutura como código como o [AWS CloudFormation](https://aws.amazon.com/cloudformation) ou ferramentas de terceiros como o Hashicorp Terraform. Para implantar em várias contas e regiões com uma única operação, é possível usar o [AWS CloudFormation StackSets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html). Para estratégias multissite ativa/ativa e standby a quente, a infraestrutura implantada na região de recuperação tem os mesmos recursos que a região primária. Para as estratégias de luz piloto e standby passivo, a infraestrutura implantada exigirá ações adicionais para ficar pronta para produção. Usando os [parâmetros](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/parameters-section-structure.html) e a [lógica condicional](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-conditions.html) do CloudFormation, é possível controlar se uma pilha implantada está ativa ou em espera com [um único modelo](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/). Quando o Elastic Disaster Recovery é usado, o serviço replica e orquestra a restauração de configurações da aplicação e os recursos de computação.
Todas as estratégias de recuperação de desastres exigem que as fontes de dados sejam copiadas para backup dentro da Região da AWS e que esses backups sejam copiados para a região de recuperação. O [AWS Backup](https://aws.amazon.com/backup/) fornece uma visão centralizada na qual é possível configurar, programar e monitorar backups desses recursos. Para luz piloto, standby passivo e multissite ativa/ativa, também é necessário replicar dados da região principal para recursos de dados na região de recuperação, como instâncias de banco de dados do [Amazon Relational Database Service (Amazon RDS)](https://aws.amazon.com/rds) ou tabelas do [Amazon DynamoDB](https://aws.amazon.com/dynamodb). Esses recursos de dados estão ativos e prontos para atender a solicitações na região de recuperação.
Para saber mais sobre como os serviços da AWS operam entre regiões, consulte esta série de blogs sobre como [Criar aplicações multirregiões com serviços da AWS](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/).
1. **Determine e implemente como você preparará sua região de recuperação para failover quando necessário (durante um evento de desastre).**
Para multissite ativa/ativa, failover significa evacuar uma região e confiar nas regiões ativas restantes. No geral, essas regiões estão prontas para aceitar tráfego. Para as estratégias de luz piloto e standby passivo, as ações de recuperação precisarão implantar os recursos ausentes, como as instâncias do EC2 na Figura 20, além de quaisquer outros recursos ausentes.
Para todas as estratégias acima, talvez seja necessário promover instâncias somente leitura de bancos de dados para transformá-las na instância primária de leitura/gravação.
Para backup e restauração, a restauração de dados do backup cria recursos para esses dados, como volumes do EBS, instâncias de banco de dados do RDS e tabelas do DynamoDB. Você também precisa restaurar a infraestrutura e implantar o código. É possível usar o AWS Backup para restaurar dados na região de recuperação. Consulte [REL09-BP01 Identificar e fazer backup de todos os dados que precisam de backup ou reproduzir os dados das fontes](rel_backing_up_data_identified_backups_data.md) para obter mais detalhes. A reconstrução da infraestrutura inclui a criação de recursos como instâncias do EC2, além da [Amazon Virtual Private Cloud (Amazon VPC)](https://aws.amazon.com/vpc), sub-redes e grupos de segurança necessários. É possível automatizar grande parte do processo de restauração. Para saber como, consulte [esta postagem do blog](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-ii-backup-and-restore-with-rapid-recovery/).
1. **Determine e implemente como você preparará sua região de recuperação para failover quando necessário (durante um evento de desastre).**
Essa operação de failover pode ser iniciada de forma manual ou automática. O failover iniciado automaticamente com base em verificações de integridade ou alarmes deve ser usado com cautela, pois um failover desnecessário (alarme falso) resulta em custos como indisponibilidade e perda de dados. Portanto, o failover iniciado manualmente é usado com frequência. Nesse caso, você ainda deve automatizar as etapas para failover para que a inicialização manual ocorra com o apertar um botão.
Há várias opções de gerenciamento de tráfego a serem consideradas ao usar os serviços da AWS. Uma opção é usar o [Amazon Route 53](https://aws.amazon.com/route53). Ao usar o Amazon Route 53, você pode associar vários endpoints de IP em uma ou mais Regiões da AWS a um nome de domínio do Route 53. Para implementar o failover iniciado manualmente, é possível usar o [Amazon Application Recovery Controller](https://aws.amazon.com/application-recovery-controller/), que fornece uma API de plano de dados altamente disponível destinada a redirecionar o tráfego para a região de recuperação. Ao implementar o failover, use as operações do plano de dados e evite as do ambiente de gerenciamento, conforme descrito em [REL11-BP04 Confiar no plano de dados, e não no ambiente de gerenciamento, durante a recuperação](rel_withstand_component_failures_avoid_control_plane.md).
Para saber mais sobre essa e outras opções, consulte [esta seção do whitepaper de recuperação de desastres](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html#pilot-light).
1. **Crie um plano de como será failback da workload.**
O failback é quando a operação da workload retorna para a região primária após o término de um evento de desastre. O provisionamento de infraestrutura e código para a região primária geralmente segue as mesmas etapas que foram usadas inicialmente, contando com a infraestrutura como código e pipelines de implantação de código. O desafio com o failback é restaurar os datastores e garantir sua consistência com a região de recuperação em operação.
No estado de failover, os bancos de dados na região de recuperação estão ativos e têm dados atualizados. O objetivo é ressincronizar da região de recuperação para a região primária, garantindo que ela permaneça atualizada.
Alguns serviços da AWS fazem isso automaticamente. Se estiver usando tabelas [globais do Amazon DynamoDB](https://aws.amazon.com/dynamodb/global-tables/), mesmo que a tabela na região primária tenha se tornado indisponível, o DynamoDB retomará a propagação de todas as gravações pendentes assim que ela retornar online. Se estiver usando o [Amazon Aurora Global Database](https://aws.amazon.com/rds/aurora/global-database/) e usando [failover planejado gerenciado](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-disaster-recovery.html#aurora-global-database-disaster-recovery.managed-failover), a topologia de replicação existente do banco de dados global do Aurora será mantida. Portanto, a antiga instância de leitura/gravação na região primária se tornará uma réplica e receberá atualizações da região de recuperação.
Nos casos em que isso não é automático, será necessário restabelecer o banco de dados na região primária como uma réplica do banco de dados na região de recuperação. Em muitos casos, isso envolverá a exclusão do banco de dados primário antigo e a criação de outras réplicas.
Após um failover, se você puder continuar a execução na região de recuperação, considere torná-la a nova região primária. Você ainda seguiria todas as etapas acima para transformar a antiga região primária em uma região de recuperação. Algumas organizações praticam uma rotação agendada, trocando as regiões primárias e de recuperação periodicamente (por exemplo, a cada três meses).
Todas as etapas necessárias para failover e failback devem ser mantidas em um playbook disponível para todos os membros da equipe e que seja revisado periodicamente.
Ao usar o Elastic Disaster Recovery, o serviço auxiliará na orquestração e automatização do processo de failback. Para obter mais detalhes, consulte [Como executar um failback](https://docs.aws.amazon.com/drs/latest/userguide/failback-performing-main.html).
**Nível de esforço do plano de implementação:** Alto
## Recursos
**Práticas recomendadas relacionadas:**
+ [REL09-BP01 Identificar e fazer backup de todos os dados que precisam de backup ou reproduzir os dados das fontes](rel_backing_up_data_identified_backups_data.md)
+ [REL11-BP04 Confiar no plano de dados, e não no ambiente de gerenciamento, durante a recuperação](rel_withstand_component_failures_avoid_control_plane.md)
+ [REL13-BP01 Definir os objetivos de recuperação para tempo de inatividade e perda de dados](rel_planning_for_recovery_objective_defined_recovery.md)
**Documentos relacionados:**
+ [Blog de arquitetura da AWS: série de recuperação de desastres](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [Recuperação de desastres de workloads na AWS: recuperação na nuvem (whitepaper da AWS)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [Opções de recuperação de desastres na nuvem](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html)
+ [Criar uma solução de backend multirregiões ativa-ativa sem servidor em uma hora](https://read.acloud.guru/building-a-serverless-multi-region-active-active-backend-36f28bed4ecf)
+ [Backend multirregiões sem servidor: recarregado](https://medium.com/@adhorn/multi-region-serverless-backend-reloaded-1b887bc615c0)
+ [RDS: como replicar uma réplica de leitura entre regiões](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html#USER_ReadRepl.XRgn)
+ [Route 53: configurar o failover de DNS](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover-configuring.html)
+ [S3: replicação entre regiões](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr.html)
+ [O que é o AWS Backup?](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html)
+ [What is Amazon Application Recovery Controller?](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
+ [AWS Elastic Disaster Recovery](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)
+ [HashiCorp Terraform: introdução - AWS](https://learn.hashicorp.com/collections/terraform/aws-get-started)
+ [Parceiro da APN: parceiros que podem ajudar com a recuperação de desastres](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [AWS Marketplace: produtos que podem ser usados para recuperação de desastres](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
**Vídeos relacionados:**
+ [Recuperação de desastres de workloads na AWS](https://www.youtube.com/watch?v=cJZw5mrxryA)
+ [AWS re:Invent 2018: Padrões de arquitetura para aplicações ativas-ativas multirregiões (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [Introdução ao AWS Elastic Disaster Recovery \$1 Amazon Web Services](https://www.youtube.com/watch?v=GAMUCIJR5as)
# REL13-BP03 Testar a implementação da recuperação de desastres para validá-la
Teste regularmente o failover para o local de recuperação para verificar se a operação está correta e se o RTO e o RPO são cumpridos.
**Práticas comuns que devem ser evitadas:**
+ Nunca praticar failovers na produção.
**Benefícios de implementar esta prática recomendada:** testar regularmente seu plano de recuperação de desastres garantirá que ele funcione quando necessário e que sua equipe saiba como executar a estratégia.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** Alto
## Orientação para implementação
Um padrão que deve ser evitado é o desenvolvimento de caminhos de recuperação que raramente são executados. Por exemplo, você pode ter um datastore secundário utilizado para consultas somente leitura. Quando você grava em um datastore e o datastore primário falha, pode ser necessário fazer o failover para o repositório de dados secundário. Se você não testar esse failover com frequência, poderá descobrir que suas suposições sobre as capacidades do datastore secundário são incorretas. A capacidade do secundário, que talvez tenha sido suficiente quando testado pela última vez, pode não conseguir mais tolerar a carga nesse cenário. Nossa experiência mostrou que a única recuperação de erro que funciona é o caminho testado com frequência. É por isso que é melhor ter um pequeno número de caminhos de recuperação. Você pode estabelecer padrões de recuperação e testá-los regularmente. Se você tiver um caminho de recuperação complexo ou crítico, ainda precisará praticar regularmente essa falha na produção para se convencer de que o caminho de recuperação funciona. No exemplo que acabamos de discutir, você deve realizar o failover para o standby regularmente, não importa a necessidade.
**Etapas de implementação**
1. Projete suas workloads para recuperação. Teste regularmente seus caminhos de recuperação. A computação orientada para a recuperação identifica as características em sistemas que aprimoram a recuperação: isolamento e redundância, capacidade de reverter alterações em todo o sistema, capacidade de monitorar e determinar a integridade, capacidade de realizar diagnósticos, recuperação automatizada, design modular e capacidade de reinicialização. Pratique o caminho da recuperação para verificar se é possível realizá-la no tempo especificado para o estado determinado. Use seus runbooks durante essa recuperação para documentar problemas e encontrar soluções para eles antes do próximo teste.
1. Para workloads baseadas no Amazon EC2, use o [AWS Elastic Disaster Recovery](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html) para implementar e lançar instâncias de simulação para sua estratégia de DR. A AWS Elastic Disaster Recovery fornece a capacidade de realizar exercícios com eficiência, o que ajuda você a se preparar para um evento de failover. Também é possível iniciar frequentemente as instâncias usando o Elastic Disaster Recovery para fins de teste e simulação sem redirecionar o tráfego.
## Recursos
**Documentos relacionados:**
+ [Parceiro da APN: parceiros que podem ajudar com a recuperação de desastres](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [Blog de arquitetura da AWS: série de recuperação de desastres](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [AWS Marketplace: produtos que podem ser usados para recuperação de desastres](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
+ [AWS Elastic Disaster Recovery](https://aws.amazon.com/disaster-recovery/)
+ [Recuperação de desastres de workloads na AWS: recuperação na nuvem (whitepaper da AWS)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [AWS Elastic Disaster Recovery: como se preparar para o failover](https://docs.aws.amazon.com/drs/latest/userguide/failback-preparing.html)
+ [O projeto de computação orientado por recuperação de Berkeley/Stanford](http://roc.cs.berkeley.edu/)
+ [O que é o AWS Fault Injection Simulator?](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html)
**Vídeos relacionados:**
+ [AWS re:Invent 2018: Padrões de arquitetura para aplicações ativas-ativas multirregiões (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [AWS re:Invent 2019: Soluções de backup e restauração e recuperação de desastres com a AWS](https://youtu.be/7gNXfo5HZN8)
# REL13-BP04 Gerenciar o desvio de configuração no local ou na região de recuperação de desastres
Para realizar um procedimento bem-sucedido de recuperação de desastres (DR), a workload deve ser capaz de retomar as operações normais em tempo hábil, sem perda relevante de funcionalidade ou dados, assim que o ambiente de DR ficar on-line. Para atingir essa meta, é essencial manter a infraestrutura, os dados e as configurações consistentes entre o ambiente de DR e o ambiente primário.
**Resultado desejado:** a configuração e os dados do local de recuperação de desastres estão em paridade com o local primário, o que facilita a recuperação rápida e completa quando necessário.
**Práticas comuns que devem ser evitadas:**
+ Não atualizar os locais de recuperação quando são feitas alterações nos locais primários, o que resulta em configurações desatualizadas que podem prejudicar os esforços de recuperação.
+ Não considerar possíveis limitações, como diferenças de serviço entre locais primários e de recuperação, o que pode levar a falhas inesperadas durante o failover.
+ Depender de processos manuais para atualizar e sincronizar o ambiente de DR, o que aumenta o risco de erro humano e inconsistência.
+ Não conseguir detectar desvio na configuração, o que leva a uma falsa sensação de prontidão do local de DR antes de um incidente.
**Benefícios de implementar essa prática recomendada:** a consistência entre o ambiente de DR e o ambiente primário melhora significativamente a probabilidade de uma recuperação bem-sucedida após um incidente e reduz o risco de falha no procedimento de recuperação.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** Alto
## Orientação para implementação
Uma abordagem abrangente ao gerenciamento de configuração e preparação para failover pode ajudar você a verificar se o local de DR está constantemente atualizado e preparado para assumir o controle em caso de falha no local primário.
Para obter consistência entre os ambientes primário e de recuperação de desastres (DR), valide se os pipelines de entrega distribuem aplicações tanto para os locais primários quanto para os locais de DR. Implemente as alterações nos locais de DR após um período de avaliação apropriado (também conhecido como *implantações progressivas*) para detectar problemas no local primário e interromper a implantação antes que eles se espalhem. Implemente o monitoramento para detectar desvios na configuração e rastrear as alterações e a conformidade dos ambientes. Execute a remediação automatizada no local de DR para mantê-lo totalmente consistente e pronto para assumir o controle no caso de um incidente.
### Etapas de implementação
1. Valide se a região de DR contém os recursos e serviços da AWS necessários para uma execução bem-sucedida do seu plano de DR.
1. Use a infraestrutura como código (IaC). Mantenha a infraestrutura de produção e modelos de configuração de aplicações precisos e aplique-os regularmente ao ambiente de recuperação de desastres. O [AWS CloudFormation](https://aws.amazon.com/cloudformation/) pode detectar desvios entre o que os modelos do CloudFormation especificam e o que é realmente implantado.
1. Configure pipelines de CI/CD para implantar atualizações de aplicações e infraestrutura em todos os ambientes, incluindo locais primários e de DR. Soluções de CI/CD, como o [AWS CodePipeline](https://aws.amazon.com/codepipeline/), podem automatizar o processo de implantação, o que reduz o risco de desvio na configuração.
1. Faça implantações progressivas entre os ambientes primário e de DR. Essa abordagem permite que as atualizações sejam inicialmente implantadas e testadas no ambiente primário, o que isola os problemas no local primário antes que eles sejam propagados para o local de DR. Essa abordagem evita que defeitos sejam enviados simultaneamente para a produção e para o local de DR e mantém a integridade do ambiente de DR.
1. Monitore continuamente as configurações de recursos nos ambientes primário e de DR. Soluções como o [AWS Config](https://aws.amazon.com/config/) podem ajudar a impor a conformidade da configuração e detectar desvios, o que ajuda a manter as configurações consistentes entre os ambientes.
1. Implemente mecanismos de alerta para rastrear e notificar sobre qualquer desvio de configuração ou interrupção ou atraso na replicação de dados.
1. Automatize a correção do desvio de configuração detectado.
1. Agende auditorias regulares e verificações de conformidade para verificar o alinhamento contínuo entre as configurações primária e de DR. As revisões periódicas ajudam você a manter a conformidade com as regras definidas e a identificar quaisquer discrepâncias que precisem ser resolvidas.
1. Verifique se há incompatibilidades na capacidade provisionada pela AWS, nas cotas de serviço, nos controles de utilização e nas discrepâncias de configuração e versão.
## Recursos
**Práticas recomendadas relacionadas:**
+ [REL01-BP01 Conhecer as cotas e restrições de serviços](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_manage_service_limits_aware_quotas_and_constraints.html)
+ [REL01-BP02 Gerenciar cotas de serviço em várias contas e regiões](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_manage_service_limits_limits_considered.html)
+ [REL01-BP04 Monitorar e gerenciar cotas](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_manage_service_limits_monitor_manage_limits.html)
+ [REL13-BP03 Testar a implementação da recuperação de desastres para validá-la](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_dr_tested.html)
**Documentos relacionados:**
+ [Como remediar recursos não compatíveis da AWS pelo Regras do AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html)
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [AWS CloudFormationDetectar alterações de configuração não gerenciadas em pilhas e recursos](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-stack-drift.html)
+ [AWS CloudFormation: detectar desvios em uma pilha inteira do CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/detect-drift-stack.html)
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [Recuperação de desastres de workloads na AWS: recuperação na nuvem (whitepaper da AWS)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [Como faço para implementar uma solução de gerenciamento de configuração de infraestrutura na AWS?](https://aws.amazon.com/answers/configuration-management/aws-infrastructure-configuration-management/?ref=wellarchitected)
+ [Como remediar recursos não compatíveis da AWS pelo Regras do AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html)
**Vídeos relacionados:**
+ [AWS re:Invent 2018: Padrões de arquitetura para aplicações ativas-ativas multirregiões (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
**Exemplos relacionados:**
+ [CloudFormation Registry](https://aws.amazon.com/blogs/devops/identify-regional-feature-parity-using-the-aws-cloudformation-registry/)
+ [Monitor de cotas para AWS](https://aws.amazon.com/solutions/implementations/quota-monitor/)
+ [Implement automatic drift remediation for AWS CloudFormation using Amazon CloudWatch and AWS Lambda](https://aws.amazon.com/blogs/mt/implement-automatic-drift-remediation-for-aws-cloudformation-using-amazon-cloudwatch-and-aws-lambda/)
+ [AWS Blog de arquitetura da : série de recuperação de desastres](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [AWS Marketplace: produtos que podem ser usados para recuperação de desastres](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
+ [Automatizar implantações seguras e sem intervenção manual](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/)
# REL13-BP05 Automatizar a recuperação
Implemente mecanismos de recuperação testados e automatizados que sejam confiáveis, observáveis e reproduzíveis para reduzir o risco e o impacto comercial da falha.
**Resultado desejado:** você implementou um fluxo de trabalho de automação bem documentado, padronizado e completamente testado para processos de recuperação. Sua automação de recuperação corrige automaticamente pequenos problemas que apresentam baixo risco de perda ou indisponibilidade de dados. Você pode invocar rapidamente processos de recuperação para incidentes graves, observar o comportamento de remediação enquanto eles operam e encerrar os processos se observar situações perigosas ou falhas.
**Práticas comuns que devem ser evitadas:**
+ Você depende de componentes ou mecanismos que estão em estado de falha ou degradação como parte do seu plano de recuperação.
+ Seus processos de recuperação exigem intervenção manual, como acesso ao console (também conhecido como *operações de clique*).
+ Você inicia automaticamente os procedimentos de recuperação em situações que apresentam um alto risco de perda ou indisponibilidade de dados.
+ Você não inclui um mecanismo para abortar um procedimento de recuperação (como um *cabo Andon* ou um *grande botão vermelho de parada*) que não está funcionando ou que apresenta riscos adicionais.
**Benefícios de implementar essa prática recomendada:**
+ Maior confiabilidade, previsibilidade e consistência das operações de recuperação.
+ Capacidade de atingir objetivos de recuperação mais rigorosos, incluindo Objetivo de Tempo de Recuperação (RTO) e Objetivo de Ponto de Recuperação (RPO).
+ Probabilidade reduzida de falha na recuperação durante um incidente.
+ Risco reduzido de falhas associadas a processos de recuperação manual propensos a erros humanos.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio
## Orientação para implementação
Para implementar a recuperação automatizada, você precisa de uma abordagem abrangente que use serviços da AWS e práticas recomendadas. Para começar, identifique componentes críticos e possíveis pontos de falha em sua workload. Desenvolva processos automatizados que possam recuperar suas workloads e dados de falhas sem intervenção humana.
Desenvolva a automação da recuperação usando princípios de infraestrutura como código (IaC). Isso torna seu ambiente de recuperação consistente com o ambiente de origem e permite o controle de versão de seus processos de recuperação. Para orquestrar fluxos de trabalho de recuperação complexos, considere soluções como o [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) ou o [AWS Step Functions](https://aws.amazon.com/step-functions/).
A automação de processos de recuperação oferece benefícios significativos e pode facilitar o alcance do objetivo de tempo de recuperação (RTO) e do objetivo de ponto de recuperação (RPO). No entanto, podem ocorrer situações inesperadas que podem provocar falhas ou criar novos riscos, como tempo de inatividade adicional e perda de dados. Para mitigar esse risco, forneça a capacidade de interromper rapidamente uma automação de recuperação em andamento. Uma vez interrompida, você pode investigar e tomar medidas corretivas.
Para workloads compatíveis, considere soluções como o AWS Elastic Disaster Recovery (AWS DRS) para fornecer failover automatizado. AWS O DRS replica continuamente suas máquinas (incluindo o sistema operacional, a configuração do estado do sistema, bancos de dados, aplicações e arquivos) em uma área de armazenamento de baixo custo em sua Conta da AWS de destino e região preferida. Se ocorrer um incidente, o AWS DRS automatiza a conversão de seus servidores replicados em workloads totalmente provisionadas em sua região de recuperação na AWS.
A manutenção e o aprimoramento da recuperação automatizada são um processo contínuo. Teste e refine continuamente os procedimentos de recuperação com base nas lições aprendidas e mantenha-se atualizado sobre novos serviços e recursos da AWS que podem aprimorar os recursos de recuperação.
### Etapas de implementação
1. **Planeje a recuperação automatizada**
1. Faça uma análise completa da arquitetura, dos componentes e das dependências da workload para identificar e planejar mecanismos de recuperação automatizados. Categorize as dependências da workload em dependências *rígidas* e *flexíveis*. Dependências rígidas são aquelas sem as quais a workload não pode operar e para as quais nenhum substituto pode ser fornecido. Dependências flexíveis são aquelas que a workload normalmente usa, mas que são substituíveis por sistemas ou processos substitutos temporários ou que podem ser tratadas por meio de uma [degradação gradual](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_mitigate_interaction_failure_graceful_degradation).
1. Estabeleça processos para identificar e recuperar dados perdidos ou corrompidos.
1. Defina as etapas para confirmar um estado estável recuperado após a conclusão das ações de recuperação.
1. Considere todas as ações necessárias para preparar o sistema recuperado para o serviço completo, como pré-aquecimento e preenchimento de caches.
1. Considere os problemas que podem ser encontrados durante o processo de recuperação e como detectá-los e corrigi-los.
1. Considere cenários em que o local primário e o respectivo ambiente de gerenciamento estejam inacessíveis. Verifique se as ações de recuperação podem ser executadas de forma independente, sem depender do local primário. Considere soluções como o [Controlador de Recuperação de Aplicações (ARC) da Amazon](https://aws.amazon.com/application-recovery-controller/) para redirecionar o tráfego sem a necessidade de alterar manualmente os registros DNS.
1. **Desenvolva um processo de recuperação automatizado**
1. Implemente mecanismos automatizados de detecção de falhas e failover para recuperação sem usar as mãos. Crie painéis, como com o [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/), para relatar o progresso e a integridade dos procedimentos automatizados de recuperação. Inclua procedimentos para validar a recuperação bem-sucedida. Forneça um mecanismo para abortar uma recuperação em andamento.
1. Crie [manuais](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_testing_resiliency_playbook_resiliency) como um processo alternativo para falhas que não podem ser recuperadas automaticamente e leve em consideração seu [plano de recuperação de desastres](https://aws.amazon.com/disaster-recovery/faqs/#Core_concepts).
1. Teste os processos de recuperação conforme discutido em [REL13-BP03](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_planning_for_recovery_dr_tested.html).
1. **Prepare-se para a recuperação**
1. Avalie o estado do seu local de recuperação e implante componentes essenciais nele com antecedência. Para conferir mais detalhes, consulte [REL13-BP04](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_config_drift.html).
1. Defina funções, responsabilidades e processos de tomada de decisão claros para operações de recuperação, envolvendo partes interessadas e equipes relevantes em toda a organização.
1. Defina as condições para iniciar seus processos de recuperação.
1. Crie um plano para reverter o processo de recuperação e retornar ao local primário, se necessário ou depois que ele for considerado seguro.
## Recursos
**Práticas recomendadas relacionadas:**
+ [REL07-BP01 Usar automação ao obter ou escalar recursos](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_adapt_to_changes_autoscale_adapt.html)
+ [REL11-BP01 Monitorar todos os componentes da workload para detectar falhas](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_withstand_component_failures_monitoring_health.html)
+ [REL13-BP02 Usar estratégias de recuperação definidas para cumprir os objetivos de recuperação](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_disaster_recovery.html)
+ [REL13-BP03 Testar a implementação da recuperação de desastres para validá-la](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_planning_for_recovery_dr_tested.html)
+ [REL13-BP04 Gerenciar o desvio de configuração no local ou na região de recuperação de desastres](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_config_drift.html)
**Documentos relacionados:**
+ [Blog de arquitetura da AWS: série de recuperação de desastres](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [Recuperação de desastres de workloads na AWS: recuperação na nuvem (whitepaper da AWS)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [Orchestrate Disaster Recovery Automation using Amazon Route 53 ARC and AWS Step Functions](https://aws.amazon.com/blogs/networking-and-content-delivery/orchestrate-disaster-recovery-automation-using-amazon-route-53-arc-and-aws-step-functions/)
+ [Build AWS Systems Manager Automation runbooks using AWS CDK](https://aws.amazon.com/blogs/mtbuild-aws-systems-manager-automation-runbooks-using-aws-cdk/)
+ [AWS Marketplace: Produtos que podem ser usados para recuperação de desastres](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [AWS Elastic Disaster Recovery](https://aws.amazon.com/disaster-recovery/)
+ [Usar o Elastic Disaster Recovery para failover e failback](https://docs.aws.amazon.com/drs/latest/userguide/failback.html)
+ [Recursos do AWS Elastic Disaster Recovery](https://aws.amazon.com/disaster-recovery/resources/)
+ [Parceiro da APN: parceiros que podem ajudar com a recuperação de desastres](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
**Vídeos relacionados:**
+ [AWS re:Invent 2018: Padrões de arquitetura para aplicações ativas-ativas multirregiões (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [AWS re:Invent 2022: AWS On Air ft. AWS Failback for AWS Elastic Disaster Recovery](https://youtu.be/Ok-vpV8b1Hs)